You may find the following useful if you or your team are creating over optimistic plans and then not achieving all of them, and there is resistance to reducing the commitment because the achievement will then be too low.
We got interested in this problem because we had a run of two week sprints without all of the work completed, and it was mostly due to dependencies that didn’t come out as expected rather than underestimating the effort to complete tasks.
The solution concepts were
Make plans more pessimistic, reducing the scope and adjusting the approach to include all imaginable problems such as the platform would have instability issues, there would be weird deployment failures, someone would be ill, and any dependencies outside the team that weren’t based entirely on using a mature production service would be somehow delayed
Make plans more aggressive, so the scope is as high as could possibly be justified, and no one could reasonably suggest working harder is possible
Using a quadrant device we can see the following:
If we only add pessimism, we get a cautious approach where delivery is too slow for stakeholder satisfaction, and the team gets bored
If we only add aggression, we get some initial “JFDI” enthusiasm followed by delivery failure because dependencies still aren’t managed correctly and the team burns out
If we add both pessimism and aggression, we get an “Aggressimistic” approach where we deliver as fast as is actually possible and the team is inspired by its own success
The solution in practice
It seemed like the concept should just have been doing what we were already doing, but we cut a lot of scope due to dependency issues the first time we used it, indicating that previously we weren’t pessimistic enough.
We had to do the planning process itself more pessimistically in terms of making sure the planning activities were themselves planned and scheduled thoroughly, and more aggressively to get through the detail.
Some dependencies resolve themselves but others don’t. Solving dependency issues is something that can be pursued aggressively, but the amount of effort and elapsed time is unpredictable. We optimise for visibility of work and minimise uncontrolled time searching for a solution by planning spike solutions for these dependencies, but there’s a risk of making extra work with spike solutions while it would be better to solve the problem without any more work. To avoid waste it may be useful to check if the solution design and backlog refinement work respects the following order of preference:
First class - solution requires minimal or no development work
Second class - solution requires clearly specified achievable development work
Third class - not clear what work is actually required
It may be self evident that a third class set of stories would fail because of a lack of pessimism and applying aggressimistic planning would prevent these being accepted into a sprint. We would warn against taking a third class backlog and only concentrating on applying aggressimism with a strong bias to spike solutions because it’s not clear that this optimises the effort for finding first class solutions. The team should first look for a first class solution by adding simplicity before adding aggressimism. This isn’t a downside of the approach itself, instead it’s a reminder not to let simplicity get neglected if the team gets enthusiastic about aggressimism.
Regarding the increased risk of running out of work to do in the coming sprint, the first option would be to elaborate the stories for subsequent sprints and work through the dependencies, and the second would be to look for ways to increase performance, and the third would be bringing forward stories. The risk is fully managed.
The disconnect became apparent between how bad it is to miss finishing stories for a sprint vs how bad it is to miss a release deadline. We’re not connecting the two well enough, and therefore corrupting both of them. Mike Cohn's explanation of the distinction between iteration and project critical paths is a useful way to frame this. This excellently written post criticising scrum mentions two week iterations causing needless anxiety about microfluctuations in one’s own productivity. It’s an interesting idea because this anxiety might not be apparent. My personal experience is that the short term focus causes less anxiety because I don’t have to think about the long term when doing it, but it falls apart if the long term focus is either missing due to not having created a valid long term plan or if that long term plan is based on scrum plans that can’t be trusted. We’d suggest the biggest problem is creating a plan that can’t be followed and the corruption that then occurs. Sometimes two week sprints make that difficult - there can be too many dependencies. With this “aggressimistic” approach the dependencies need to get managed in the story definition process and the story can’t get allocated to a sprint until that is done. The actual scrum work itself then becomes more predictable. The story definitions work is not predictable though and we don’t answer here how to do this except to say it doesn’t easily fit in a sprint, and we risk presenting the two week scrum process as a container for dumbed down work. Similar to the risk of running out of stories in a sprint, it’s a manageable risk.
Other Considerations
It gets out of hand if we make the plan aggressive before making it pessimistic, mainly because some elements disappear altogether when given a hearty beating with the pessimism stick. There’s no point figuring out how to be aggressive about something you then determine you can’t do at all. Pessimism comes first! But the made up word aggressimistic presents the concept more positively by starting with getting after it, as it were. The system 1 thinking model offers a possible explanation for the appeal. If that is too far removed from cold blooded abstraction, consider that reading from left to right it looks like a contraction of the following:
Another reason to add the pessimism before the aggression is that if you add pessimism to create a cautious plan, and then add aggression to create an aggressimistic plan, then stakeholders who want more scope can help you find ways to increase the aggression in the plan by obtaining resources.
If you add the aggression first, the stakeholders will anchor on a JFDI plan with a ridiculous scope, and then adding pessimism will be a battle against the stakeholders.
Discussion about what’s best between optimism and pessimism appears a source of useful concepts but I’d suggest it’s not actually the primary issue here. For example psychology professor Julie Norem's work concerns how a constructive responses to negative thoughts can help anxious people manage anxiety and perform their best work. The pathologically optimistic scrum team isn’t anxious though, and that’s the problem. Edward de Bono’s classic six thinking hats method has a black hat for pessimism, that method can be very effective, but it can be too easy to treat superficially. We need to deliberately use tools like the concept of a premortem to engage a visceral sense of pessimism at a time when we can actually do something about it. Only then do we have a realistic understanding of the challenge that we can then build on, and have the opportunity to get the associated benefits. The ideal attitude is to aggressively emphasize pessimism and take suitable actions in planning, then the team can afford a more positive attitude during the rest of the sprint. It appears very important to sprint planning to tie the choices made at the sprint level to the choices made at the release level. The disastrous attitude is to miss either the pessimism or the actions in the planning when there’s a chance to do something about it, and either be ignoring the likely reality during the rest of the sprint and missing deadlines, or falling into a death march mentality which also results in missing deadlines.
It could deserve further discussion elsewhere but we suspect the six thinking hats approach is missing a seventh hat, which is looks like this:
Having added a lot of pessimism, if people are feeling beaten down by the challenge then it essential that the team doesn’t give up! In the worst case scenario the team is in a death march mindset. Leif Babin explaining applying a default aggressive mindset to getting a book published might help. The psychological benefit of aggressively pursuing objectives rather than bracing to react to problems is clearly illustrated in the first two minutes of this video of Jocko Willink and Jordan Peterson.