So, your team is using Scrum and it’s not working. Symptoms include the following:
- Sprints are not delivering the stories as promised.
- Sprints are taking longer and longer.
- The number of defects found during testing is high and there’s no time for fixes.
- Morale is low as the team struggles and becomes argumentative.
The natural inclination of many managers is to revert to command-and-control. Identify the features, functions and software modules being developed. Focus on function and module delivery — not stories. Set deadlines and hold the team accountable.
Sounds like a reversion to waterfall, right?
Yes, it is and it’s the wrong approach. Here’s what should happen:
- Identify why the sprints are not delivering the stories promised. It’s likely to be because the stories are too big and/or they were not sized accurately. Solution: Reduce the story sizes and rework the associated task estimates. You’ll also need to re-prioritize the backlog.
- Examine the reasons for the sprints taking too long. Sprints should not be arbitrarily lengthened. When they are scheduled to end, they end. Taking more time is an admission that something is fundamentally wrong. More time will not fix the underlying problem. Solution: Stop. Re-group and re-plan. Empower the team to self-organize. Making all the sprints slightly longer may help but do not exceed 30 days.
- A high defect rate is symptomatic of poor quality source code and/or inadequate testing. Neither is acceptable. Solution: Insist on code reviews and/or pair programming with an emphasis on quality. Also automate as much of the testing as you reasonably can to shorten the test cycles.
- Poor morale results from frustration. Find out why the team is frustrated. Solution(s): If there is a “bad apple” on the team, remove him. If the team does not buy into the goals and objectives for the project, listen and make changes. If the team lacks tools, skills, etc., find what they need and make it happen — or eliminate the need entirely.
Reverting to the old (waterfall) way of doing things only preserves and protects what you were trying to change in the first place. It may result in a short term improvement but will make things worse in the long run.
Agile development in the form of Scrum, XP, Kanban or anything else is not easy. Agile approaches may be simpler in some respects than waterfall, but they are not easy. Keep trying. Other ideas?