8 ms·

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a cont

by js8 6y ago

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. It's more like mathematics, where it takes time to discover that things are actually rather easy (this quote comes to mind https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-mathematics/ https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...). Of course, if you look at the project from the longer time perspective, it can appear as continuous production of improvements. But it has a kind of quantum nature, if you decrease the scale of time, you will see less continuity and more discrete bursts of code production. There is something like uncertainty principle that on certain scale, it's pointless to try to predict things, because making the correct prediction (which is needed at least to define thing DONE) will take as long as doing the thing in the first place. I don't consider myself special, but it is possible that Scrum ruins great minds because they seek conceptual clarity (we sometimes humbly call it "lack of technical debt"). I am not sure how to make that work with Scrum. Perhaps if everything was done three times, punctuated by a team discussion, each time with shorter code. Second thing that I dislike the most about Scrum is that it threw away (or at least "conveniently" renamed) pretty much everything that was ever known about project management. Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. (I think it comes from the fact they actually realized the quantum nature of development is a problem.) To me, that is a huge red flag that it is, in fact, a snake oil. P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.

rawoke083600 6y ago
>that ideal software development is just a continuous production This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !
- xtracto 6y ago
  One think I havent read being mentioned on this thread is how Scrum discrete sprint units allow the dev team to focus in a task for some time. I have been in both "sides" of scrum (dev and manager) and it is good not to have objectives changed every days. As a manager I even have had to split a scrum team in two (scrum and kanban) to maintain devs sanity. Kanban is my preferred PMing process but only if there are defined "cutout" periods to perform releases or a CI/CD cycle.
- deleted 6y ago
  [deleted]
fxtentacle 6y ago
I remember we had a discussion about 10x developers a while ago and how some developers are perceived as moody divas. My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.
- js8 6y ago
  I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day. In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first. (There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.) In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work. Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.
  - jariel 6y ago
    1) Communicating is part of the job 2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not. 3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everything up.
MattGaiser 6y ago
> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload. On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen? Planning could be far more accurate if we just got a proposed task list a day before planning.
- jay_kyburz 6y ago
  >Planning could be far more accurate if we just got a proposed task list a day before planning. Why don't you work that in to your process. It's called Agile for a reason.
  - js8 6y ago
    Why don't they put it into Agile books? They're called books for a reason. Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it. It's a return to medieval times, where all the expertise was just the experience of the master.
    - jay_kyburz 6y ago
      I think the value of Agile is that everybody is different, and every problem posses unique challenges. You don't want to just follow some process in a book and expect it to work with your unique group of developers and designers, or for the unique problem you are trying to solve. You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.
    - Supermancho 6y ago
      > Why don't they put it into Agile books? They're called books for a reason. Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team. In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.
remontoire 6y ago
what does YADIW mean?
- usrusr 6y ago
  "You are doing it wrong", the first and last thing any scrum believer will say to someone for whom it does not work.
  - mindcrime 6y ago
    And in a great many cases, when you dig into the details, it turns out that they are - in fact - doing it wrong. Or at least blaming scrum for things that scrum does not actually entail. Or blaming "agile" for things that are 100% contrary to both the letter and spirit of the agile manifesto.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- nnevala 6y ago
  I think it stands for You Are Doing It Wrong.
- augustk 6y ago
  YADIW = You Are Doing It Wrong.
jay_kyburz 6y ago
>idea that ideal software development is just a continuous production of small improvements to the code. Many of us do believe this. Absolutely. >It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. But on the flip side, if you get it wrong you waste an incredible amount of time. The smaller the steps you take, the smaller the risk you step in the wrong direction. I can't really comment on the rest of your comment because as far as I'm aware SCRUM means something different everywhere. I have no idea, for example, why a scrum team would not use formal estimation methods and rely on intuition. Agile project management should mean you can examine your process and improve it. If your intuitive estimates are not accurate, you should be able to suggest a different method and see if you get better estimates.
- dogecoinbase 6y ago
  > The smaller the steps you take, the smaller the risk you step in the wrong direction. This is the route to local maxima.
- aliante 6y ago
  I am fine with the small improvements to code part, but I at least want an idea of where I am going. Small improvements to solve the problem? Sure. But I at least want an idea of what the entire problem is, not just the two weeks of problem shards I am given.
  - jay_kyburz 6y ago
    Absolutly agree, if you don't know where you are going, how can you possibly move towards it. At the end of every milestone its super important to take a step back and ask, are you on the write track. If nobody can clearly tell you the end goal, your project management process is not the problem.
  - sergeykish 6y ago
    I have seen project made three turns based on users feedback until it found niche. SCRUM has not denied our vision but made it possible to continuously roll out to tighten feedback loop. Something else wrong in your case. In SCRUM you should be able to voice your concerns, to work with Product Owner.
jariel 6y ago
This is a very good point, but often for established code bases, many things are just incremental. If the architecture is in place and well understood, especially if it's more of a business app ... then it's not Math ... it's more like Carpentry.
wirrbel 6y ago
> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation wasn't really there. Sure, there was a difference for the very large work items and the very small one but overall the estimates were fairly useless, especially when it came to anything that touched operations. I just googled formal methods for estimation in order to see what you might mean by that and nothing appeared to be something I'd assume to be more powerful (a priori) due to my lack of confidence in workload estimation overall. Note, btw. that the Scrum Guide doesn't make any mention of estimation at all, neither prescribes it nor disallows it, just says that the team should plan a sprint (roughly speaking). Even the typical "story point estimation" stuff that people think is attached with Scrum, its more of an XP practice that has been carried over. Personally I think that Scrum took a weird turn in its lifetime with Sprints becoming shorter and shorter to the point where there can be no meaningful work (with customer benefit / demoable in the sprint review) be completed within a Scrum. Maybe its possible to ship a couple of CRUD-website-features within 2 weeks, but for the B2B software I am working on a feature is too complex for 2 week cycles. And if your tasks are small enough to fit into two week cycles, why aren't you doing Kanban?
- js8 6y ago
  > I wonder whether any formal way of estimation actually works I agree that it is a legitimate concern, I certainly do not advocate a position that software cannot be estimated or planned at all. I think it can be, but only up to certain time granularity, where the attempt to gain understanding for a sensible estimate (and describing what needs to be done) becomes essentially comparable to writing the code in the first place. I actually have an underdeveloped idea how we could have a completely formal approach to tackle uncertainty in SW development, but it is purely theoretical so far (using a combination of functional programming and information theory).
C1sc0cat 6y ago
I think the obsession with tickets /Jira as the be all and end all of SCRUM is the main problem. What is lacking in a lot of cases is an overall vison and plan for the desired end state - I have seen doing a classic waterfall design stage with a RAD/AGILE/DSDM/SCRUM development stage right at the end work well.
tragic 6y ago
> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed. If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are. This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.
- ricardobeat 6y ago
  Despite what every book says, despite having three agile coaches run workshops with the team, despite this issue being specifically addressed with everyone involved, and being acknowledged as wrong, it still becomes the purpose of the standup. No amount of "this is not the purpose of a standup" and "you're doing it wrong" can fix human nature. Management is mostly interested in progress and timelines, and will give unintentional (or not) feedback, even through body language, whenever a task is delayed or impacted in any way. They have some authority over team members' performance eval. Hence people will end up reporting to them no matter how hard you try. The only possible fix is to remove management or product from the standup, which is how it was originally supposed to be - but that seems unthinkable in the "agile at scale' format most companies have adopted today.
  - 6y ago
seer 6y ago
Maybe I've been lucky up to this point myself, a kind of survival bias or something, but a "lightened" version of Scrum has always made so much sense to me when it comes to developing software. Our requirements change, they often change daily, from forces outside of our control. Fickle clients are one thing, but even things as predictable as implementing protocols can be uncertain. Many times you'll design and implement the perfect solution to the problem at hand, and then hit a nasty bug mid way of some tool / lib you're relying on that would make you rethink your whole approach. This can drive you into a rabbit whole in itself. Its always nice to consult with your team at that point to see if its actually worth it. As far as I understand "Scrum" is just a collection of practices that helps us actually ship something in a reasonable amount of time. Each standup can be a "battle plan meets the enemy" kind of moment. And as we know, "no battle plan survives first contact with the enemy". Yes its uncomfortable sometimes, but it should force us to deal with reality a bit more often and I think that's a good thing. And scrum and it mutations has survived to this day for a reason. Teams that employ it are much faster to adopt to changing conditions, and thus "outevlove" the competition. I really hope that we can codify a more humane way of dealing with those problems, but at its heart, I think scrum is better suited for software development than its predecessors. We need time (and willingness) to "evolve" it as well.
greatgib 6y ago
I agree with this point of view. In my opinion, one of the greatest fallacy of Scrum and some agile methods is: "Another note on breaking down tasks into chunks" This is the management trick of "divide and conquer". But for real good dev, that is not a good development process. Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned: If you were in an agile/scrum setup, it would be asked to do that file by file, function by function, problem/code change type by type code change. And possibly not break the rest so that there is something 'runnable' at least every week or some other people can work on another file/function. But that does not make any sense for a great dev. What you would do if you were experienced is to know the overall direction but rework the code line by line progressively, fixing side things on the way and maybe regularly fixing in other files/functions pattern that are similars. And maybe at some point decide to change again something you did until the point where you achieve your goal. In my mind, it works more like a path searching algorithm in action. The scrum concept is probably good for the devops/web script kiddy devs, where you just change hundreds of individual small items without too much interdependance. For example, change the style of button, reorder blocks on a page, change the icons, increase the font size. Also, something that makes great dev become average is this concept that every dev should be exchangeable and a commodity. Dev become workers on a factory production line where they have no value than to follow process and apply patterns. They say "what if something happen to your autonomous great dev?" but this argument is not used for the rest of the intellectual society: you don't see 2 doctors at a time, 2 lawyers for your case, 2 CEO in the company, 2 main architects. This thinking is just applied to low level replaceable workers. Normally, if you lose a great dev and you find another great dev, the new one should be able to understand the problem and the code in a short time and be operational quite fast. One example we can easily see of efficient dev are the great open source projects. Most of them were not created and led by an army of dev clones but by a few efficient ones: linux, python, php ... In these cases, most of the time we don't consider people to be interchangeable. Some people are keys to topics/code/features and that leads to great dev. But in case of problem, there is almost always someone smart capable to take over after a short time.
- sergeykish 6y ago
  You know you've described the opposite of agile approach, right? "management", "file by file, function by function", "exchangeable and a commodity"... at least not what agile was ten years ago. Actually the points in favor of agile were: * utilize persons strong points * reduce management * reduce burden * improve working environment
sergeykish 6y ago
Agile builds on the premise that developers like to build. That we self organize our teams and don't like slackers. Bring transparency for business so it can trust us. Give estimates and accept priorities. Ship from time to time so all can see that process works. It is really easy to screw. I've seen far to many broken versions. Community building is harder than management. And for management there is no benefit beside budge. So they say SCRUM and change nothing but cosmetics. It sells.
- KSteffensen 6y ago
  You'd think products shipped on time as agreed with the customer was a benefit for management.
  - sergeykish 6y ago
    I thought same. I fought for roll out in time, velocity and quality. Now I'm burned out. PM had his own agenda - introduced a men who, he was like 1/10x developer on senior position, promised to fire in a few month, have not happened in a year and a half, this destroyed velocity and as tech lead I was blamed. I stayed so long because our customers were awesome, could not leave them. Managers are not friends. The moment I've said I'm leaving I become nothing. Time to learn.
- etripe 6y ago
  > Bring transparency for business so it can trust us. The problem is no methodology can make them trust us. Software development is one of the few professions where to the business it's simultaneously "magic" and they think we - as experts - don't know what we're doing. Management is supposed to empower employees and remove obstacles, not disempower and introduce them. At the same time, there's this illusion that as long as we developers change the way we operate, the rest of the enterprise will magically be affected. A cultural shift without management buy-in won't work.
mindcrime 6y ago
I think in reality, SW development done right is nothing like that. I would argue that it's more correct to say something like "Not all software development done right is like that." Or in other words, some software development is closer to that model. Some teams are doing work that involves real "invention", things that require using cutting edge C.S. research, implementing algorithms from papers, or using just-released open source libraries, etc. Other teams are building the nth iteration of some CRUD application that amounts to a database, some REST API's built using Spring Boot, and a UI built in React, where today's work isn't (usually) that different from yesteday's work. Depending on which end of that spectrum your project falls on, it would make sense that the details of the methodology you use would need to vary. I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work. Unfortunately, I have found that few shops take either of these factors into account.
- dragonwriter 6y ago
  > I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work. I think this is basically true but incomplete; early and late are misleading a bit, because it can be early in the life of a product that is in a well-explored space and it will look “late”, while a product can experience change in requirements or external context which makes it look “early”. A product should expect to move between modes multiple times if it is long-lived.
AnimalMuppet 6y ago
> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed. Well, I think that Scrum (or, more widely, agile) can in fact be done "right" - done in a way that works well. So in one sense, "you aren't doing it right" is in fact a correct statement. But then you look around, and you see how often it isn't done "right". If something is almost impossible to do "right", then yes, there may in fact be a problem.
deleted 6y ago
[deleted]
jasonbourne1901 6y ago
Scrum is being applied like a shiny new hammer to everything that might have seen or heard of nail a once. The primary reason scrum should be used for software development is when iterating closely with a knowledgeable customer. The pattern basically outsources the discovery of what to build onto the customer - and if the customer can tell what good looks like, shazam! scrum is downright magical! Guess what, most software teams are isolated from the customer, or the customer/product owner doesn't know what good looks like, so no wonder scrum is getting a bad name as teams struggle to get value out of scrum activities. There is a reason why teams need to have flexibility to modify their R&D patterns and processes. Without that flexibility you get to do scrum and the results make you wonder if you are doing it wrong.

by js8 6y ago

rawoke083600 6y ago

>that ideal software development is just a continuous production This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !

xtracto 6y ago
One think I havent read being mentioned on this thread is how Scrum discrete sprint units allow the dev team to focus in a task for some time. I have been in both "sides" of scrum (dev and manager) and it is good not to have objectives changed every days. As a manager I even have had to split a scrum team in two (scrum and kanban) to maintain devs sanity. Kanban is my preferred PMing process but only if there are defined "cutout" periods to perform releases or a CI/CD cycle.
deleted 6y ago
[deleted]

fxtentacle 6y ago

I remember we had a discussion about 10x developers a while ago and how some developers are perceived as moody divas. My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.

js8 6y ago
I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day. In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first. (There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.) In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work. Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.
- jariel 6y ago
  1) Communicating is part of the job 2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not. 3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everything up.

MattGaiser 6y ago

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload. On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen? Planning could be far more accurate if we just got a proposed task list a day before planning.

jay_kyburz 6y ago
>Planning could be far more accurate if we just got a proposed task list a day before planning. Why don't you work that in to your process. It's called Agile for a reason.
- js8 6y ago
  Why don't they put it into Agile books? They're called books for a reason. Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it. It's a return to medieval times, where all the expertise was just the experience of the master.
  - jay_kyburz 6y ago
    I think the value of Agile is that everybody is different, and every problem posses unique challenges. You don't want to just follow some process in a book and expect it to work with your unique group of developers and designers, or for the unique problem you are trying to solve. You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.
  - Supermancho 6y ago
    > Why don't they put it into Agile books? They're called books for a reason. Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team. In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.

remontoire 6y ago

what does YADIW mean?

usrusr 6y ago
"You are doing it wrong", the first and last thing any scrum believer will say to someone for whom it does not work.
- mindcrime 6y ago
  And in a great many cases, when you dig into the details, it turns out that they are - in fact - doing it wrong. Or at least blaming scrum for things that scrum does not actually entail. Or blaming "agile" for things that are 100% contrary to both the letter and spirit of the agile manifesto.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
nnevala 6y ago
I think it stands for You Are Doing It Wrong.
augustk 6y ago
YADIW = You Are Doing It Wrong.

jay_kyburz 6y ago

>idea that ideal software development is just a continuous production of small improvements to the code. Many of us do believe this. Absolutely. >It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. But on the flip side, if you get it wrong you waste an incredible amount of time. The smaller the steps you take, the smaller the risk you step in the wrong direction. I can't really comment on the rest of your comment because as far as I'm aware SCRUM means something different everywhere. I have no idea, for example, why a scrum team would not use formal estimation methods and rely on intuition. Agile project management should mean you can examine your process and improve it. If your intuitive estimates are not accurate, you should be able to suggest a different method and see if you get better estimates.

dogecoinbase 6y ago
> The smaller the steps you take, the smaller the risk you step in the wrong direction. This is the route to local maxima.
aliante 6y ago
I am fine with the small improvements to code part, but I at least want an idea of where I am going. Small improvements to solve the problem? Sure. But I at least want an idea of what the entire problem is, not just the two weeks of problem shards I am given.
- jay_kyburz 6y ago
  Absolutly agree, if you don't know where you are going, how can you possibly move towards it. At the end of every milestone its super important to take a step back and ask, are you on the write track. If nobody can clearly tell you the end goal, your project management process is not the problem.
- sergeykish 6y ago
  I have seen project made three turns based on users feedback until it found niche. SCRUM has not denied our vision but made it possible to continuously roll out to tighten feedback loop. Something else wrong in your case. In SCRUM you should be able to voice your concerns, to work with Product Owner.

jariel 6y ago

This is a very good point, but often for established code bases, many things are just incremental. If the architecture is in place and well understood, especially if it's more of a business app ... then it's not Math ... it's more like Carpentry.

wirrbel 6y ago

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation wasn't really there. Sure, there was a difference for the very large work items and the very small one but overall the estimates were fairly useless, especially when it came to anything that touched operations. I just googled formal methods for estimation in order to see what you might mean by that and nothing appeared to be something I'd assume to be more powerful (a priori) due to my lack of confidence in workload estimation overall. Note, btw. that the Scrum Guide doesn't make any mention of estimation at all, neither prescribes it nor disallows it, just says that the team should plan a sprint (roughly speaking). Even the typical "story point estimation" stuff that people think is attached with Scrum, its more of an XP practice that has been carried over. Personally I think that Scrum took a weird turn in its lifetime with Sprints becoming shorter and shorter to the point where there can be no meaningful work (with customer benefit / demoable in the sprint review) be completed within a Scrum. Maybe its possible to ship a couple of CRUD-website-features within 2 weeks, but for the B2B software I am working on a feature is too complex for 2 week cycles. And if your tasks are small enough to fit into two week cycles, why aren't you doing Kanban?

js8 6y ago
> I wonder whether any formal way of estimation actually works I agree that it is a legitimate concern, I certainly do not advocate a position that software cannot be estimated or planned at all. I think it can be, but only up to certain time granularity, where the attempt to gain understanding for a sensible estimate (and describing what needs to be done) becomes essentially comparable to writing the code in the first place. I actually have an underdeveloped idea how we could have a completely formal approach to tackle uncertainty in SW development, but it is purely theoretical so far (using a combination of functional programming and information theory).

C1sc0cat 6y ago

I think the obsession with tickets /Jira as the be all and end all of SCRUM is the main problem. What is lacking in a lot of cases is an overall vison and plan for the desired end state - I have seen doing a classic waterfall design stage with a RAD/AGILE/DSDM/SCRUM development stage right at the end work well.

tragic 6y ago

> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed. If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are. This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.

ricardobeat 6y ago
Despite what every book says, despite having three agile coaches run workshops with the team, despite this issue being specifically addressed with everyone involved, and being acknowledged as wrong, it still becomes the purpose of the standup. No amount of "this is not the purpose of a standup" and "you're doing it wrong" can fix human nature. Management is mostly interested in progress and timelines, and will give unintentional (or not) feedback, even through body language, whenever a task is delayed or impacted in any way. They have some authority over team members' performance eval. Hence people will end up reporting to them no matter how hard you try. The only possible fix is to remove management or product from the standup, which is how it was originally supposed to be - but that seems unthinkable in the "agile at scale' format most companies have adopted today.
- 6y ago

seer 6y ago

Maybe I've been lucky up to this point myself, a kind of survival bias or something, but a "lightened" version of Scrum has always made so much sense to me when it comes to developing software. Our requirements change, they often change daily, from forces outside of our control. Fickle clients are one thing, but even things as predictable as implementing protocols can be uncertain. Many times you'll design and implement the perfect solution to the problem at hand, and then hit a nasty bug mid way of some tool / lib you're relying on that would make you rethink your whole approach. This can drive you into a rabbit whole in itself. Its always nice to consult with your team at that point to see if its actually worth it. As far as I understand "Scrum" is just a collection of practices that helps us actually ship something in a reasonable amount of time. Each standup can be a "battle plan meets the enemy" kind of moment. And as we know, "no battle plan survives first contact with the enemy". Yes its uncomfortable sometimes, but it should force us to deal with reality a bit more often and I think that's a good thing. And scrum and it mutations has survived to this day for a reason. Teams that employ it are much faster to adopt to changing conditions, and thus "outevlove" the competition. I really hope that we can codify a more humane way of dealing with those problems, but at its heart, I think scrum is better suited for software development than its predecessors. We need time (and willingness) to "evolve" it as well.

greatgib 6y ago

I agree with this point of view. In my opinion, one of the greatest fallacy of Scrum and some agile methods is: "Another note on breaking down tasks into chunks" This is the management trick of "divide and conquer". But for real good dev, that is not a good development process. Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned: If you were in an agile/scrum setup, it would be asked to do that file by file, function by function, problem/code change type by type code change. And possibly not break the rest so that there is something 'runnable' at least every week or some other people can work on another file/function. But that does not make any sense for a great dev. What you would do if you were experienced is to know the overall direction but rework the code line by line progressively, fixing side things on the way and maybe regularly fixing in other files/functions pattern that are similars. And maybe at some point decide to change again something you did until the point where you achieve your goal. In my mind, it works more like a path searching algorithm in action. The scrum concept is probably good for the devops/web script kiddy devs, where you just change hundreds of individual small items without too much interdependance. For example, change the style of button, reorder blocks on a page, change the icons, increase the font size. Also, something that makes great dev become average is this concept that every dev should be exchangeable and a commodity. Dev become workers on a factory production line where they have no value than to follow process and apply patterns. They say "what if something happen to your autonomous great dev?" but this argument is not used for the rest of the intellectual society: you don't see 2 doctors at a time, 2 lawyers for your case, 2 CEO in the company, 2 main architects. This thinking is just applied to low level replaceable workers. Normally, if you lose a great dev and you find another great dev, the new one should be able to understand the problem and the code in a short time and be operational quite fast. One example we can easily see of efficient dev are the great open source projects. Most of them were not created and led by an army of dev clones but by a few efficient ones: linux, python, php ... In these cases, most of the time we don't consider people to be interchangeable. Some people are keys to topics/code/features and that leads to great dev. But in case of problem, there is almost always someone smart capable to take over after a short time.

sergeykish 6y ago
You know you've described the opposite of agile approach, right? "management", "file by file, function by function", "exchangeable and a commodity"... at least not what agile was ten years ago. Actually the points in favor of agile were: * utilize persons strong points * reduce management * reduce burden * improve working environment

sergeykish 6y ago

Agile builds on the premise that developers like to build. That we self organize our teams and don't like slackers. Bring transparency for business so it can trust us. Give estimates and accept priorities. Ship from time to time so all can see that process works. It is really easy to screw. I've seen far to many broken versions. Community building is harder than management. And for management there is no benefit beside budge. So they say SCRUM and change nothing but cosmetics. It sells.

KSteffensen 6y ago
You'd think products shipped on time as agreed with the customer was a benefit for management.
- sergeykish 6y ago
  I thought same. I fought for roll out in time, velocity and quality. Now I'm burned out. PM had his own agenda - introduced a men who, he was like 1/10x developer on senior position, promised to fire in a few month, have not happened in a year and a half, this destroyed velocity and as tech lead I was blamed. I stayed so long because our customers were awesome, could not leave them. Managers are not friends. The moment I've said I'm leaving I become nothing. Time to learn.
etripe 6y ago
> Bring transparency for business so it can trust us. The problem is no methodology can make them trust us. Software development is one of the few professions where to the business it's simultaneously "magic" and they think we - as experts - don't know what we're doing. Management is supposed to empower employees and remove obstacles, not disempower and introduce them. At the same time, there's this illusion that as long as we developers change the way we operate, the rest of the enterprise will magically be affected. A cultural shift without management buy-in won't work.

mindcrime 6y ago

I think in reality, SW development done right is nothing like that. I would argue that it's more correct to say something like "Not all software development done right is like that." Or in other words, some software development is closer to that model. Some teams are doing work that involves real "invention", things that require using cutting edge C.S. research, implementing algorithms from papers, or using just-released open source libraries, etc. Other teams are building the nth iteration of some CRUD application that amounts to a database, some REST API's built using Spring Boot, and a UI built in React, where today's work isn't (usually) that different from yesteday's work. Depending on which end of that spectrum your project falls on, it would make sense that the details of the methodology you use would need to vary. I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work. Unfortunately, I have found that few shops take either of these factors into account.

dragonwriter 6y ago
> I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work. I think this is basically true but incomplete; early and late are misleading a bit, because it can be early in the life of a product that is in a well-explored space and it will look “late”, while a product can experience change in requirements or external context which makes it look “early”. A product should expect to move between modes multiple times if it is long-lived.

AnimalMuppet 6y ago

> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed. Well, I think that Scrum (or, more widely, agile) can in fact be done "right" - done in a way that works well. So in one sense, "you aren't doing it right" is in fact a correct statement. But then you look around, and you see how often it isn't done "right". If something is almost impossible to do "right", then yes, there may in fact be a problem.

deleted 6y ago

[deleted]

jasonbourne1901 6y ago

Scrum is being applied like a shiny new hammer to everything that might have seen or heard of nail a once. The primary reason scrum should be used for software development is when iterating closely with a knowledgeable customer. The pattern basically outsources the discovery of what to build onto the customer - and if the customer can tell what good looks like, shazam! scrum is downright magical! Guess what, most software teams are isolated from the customer, or the customer/product owner doesn't know what good looks like, so no wonder scrum is getting a bad name as teams struggle to get value out of scrum activities. There is a reason why teams need to have flexibility to modify their R&D patterns and processes. Without that flexibility you get to do scrum and the results make you wonder if you are doing it wrong.