4 ms·

Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case w

Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest) And the third paragraph kind of lays bare the problem with sprints: The PM can only look at all the work that needs to be done if, well, there was a discovery phase to list all the work that needs to be done. That discovery looks suspiciously like planning. That's why agile focuses on continuous delivery of value. It's excellent for projects where it's hard to estimate the full scope, but there are many intermediate targets that are valuable to the customer. You go along until enough value is delivered, and then move on. Not all projects work like that. Some things only generate any value at the end of a long slog. Some things can be delivered incrementally but require a predictable end date. (Hello, Black Friday!) And so, you get to adopt methodology to the problem at hand. Sometimes, you really need to spend the planning up front. Sometimes it's enough to sketch it out on a napkin. Sometimes you can do things sprint-by-sprint. Sometimes, you have larger checkpoints and sprints in between. The idea that any single methodology works for every problem is an idea favored by the consulting industry, but not a reality. And it predates agile, by a lot - I've been a process consulting victim way back in the early 80s. (And the mass of miracle methodologies directly led to "No Silver Bullet")

dasil003 4y ago
Exactly this. That is why the Agile Manifesto said to favor "Individuals and interactions over processes and tools". The problem is that approach only works when you have a team of experts with clear goals and enough space to address them. It doesn't necessarily lend itself to being quantifiable or standardized across multiple teams (depending on the problem), so the bean counters and middle managers get nervous. This is an environment ripe for agile consultants to swoop in with the siren song of the silver bullet process du jour.
shagie 4y ago
I believe you misread my "Plan enough is sometimes 3 months of work." which was referring to the wording of the parent comment "How bout, plan enough then just build the thing until we agree its usable and correct." Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning. My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road. Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier. Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work." Sprints are designed to make projects that fall into those situations fail sooner. The fail fast part of agile is often a hard pill for people to swallow. https://www.agile-academy.com/en/agile-dictionary/fail-fast/ https://www.agile-academy.com/en/agile-dictionary/fail-fast/ and https://www.ibm.com/garage/method/practices/culture/failing-fast/ https://www.ibm.com/garage/method/practices/culture/failing-... Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.

dasil003 4y ago

Exactly this. That is why the Agile Manifesto said to favor "Individuals and interactions over processes and tools". The problem is that approach only works when you have a team of experts with clear goals and enough space to address them. It doesn't necessarily lend itself to being quantifiable or standardized across multiple teams (depending on the problem), so the bean counters and middle managers get nervous. This is an environment ripe for agile consultants to swoop in with the siren song of the silver bullet process du jour.

shagie 4y ago

I believe you misread my "Plan enough is sometimes 3 months of work." which was referring to the wording of the parent comment "How bout, plan enough then just build the thing until we agree its usable and correct." Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning. My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road. Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier. Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work." Sprints are designed to make projects that fall into those situations fail sooner. The fail fast part of agile is often a hard pill for people to swallow. https://www.agile-academy.com/en/agile-dictionary/fail-fast/ https://www.agile-academy.com/en/agile-dictionary/fail-fast/ and https://www.ibm.com/garage/method/practices/culture/failing-fast/ https://www.ibm.com/garage/method/practices/culture/failing-... Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.