Sometimes you have make major changes, even in the middle of a project.
This post titled “How we do a retrospective” at Scrum Breakfast got me to thinking. I’m a big fan of project retrospectives or post-mortems. The general principle is to have the team identify areas that need improvement, select a very small number of them (from 1 to 5, preferably 2 or 3), and focus on those areas during the next sprint (or release or project).
It sounds good and if done meticulously can have a strong positive impact over time. There’s the potential problem — “over time”. If the project is deep trouble, or worse, the company is in danger of going under, you may not have much time.
If you face that type of difficult situation, you need to escalate the problem solving. Your focus needs to be on staying alive not just building a strong team or a great product.
Assemble a group of senior-level managers and individual contributors. Follow whatever retrospective format you are comfortable with and raise the stakes.
- Identify team strengths and find ways to take full advantage of them.
- Identify team weaknesses and either fix them fast or eliminate whatever is drawing them out.
- Reduce the scope of the project to the bare minimum required to be successful.
This won’t be easy or quick. It works best if you have a goal such as reducing the schedule by 25% or cutting the expected cost by 30%. You can’t solve big problems with small incremental steps — not when you’re dealing with a life or death situation.