Continuing on with my abuse of Jeff Foxworthy’s classic formulation, here are a few more ways in which you might be missing the full value of Scrum. You can see the first list in Part 1.
If your developers keep getting ahead of your testers, you may be a Scrum-but.
If any member of the team is getting ahead of the other members, they’re losing track of the goal. The goal is for the entire team to complete the committed work by the end of the Sprint. If a developer feels he can go ahead and work on code from the next Sprint while the testers struggle to keep up, he’s not helping the team achieve the goal, and he’s probably slowing things down in the long run. Team members do what it takes to keep the team on track. This developer needs to determine what the testers need to help them become more efficient, and help them get it. Maybe he can build or customize some tools. Maybe he can build a testing framework. Maybe he can simplify his code base so it is easier to automate tests. But he needs to own the concept, “If your team is failing, you’re failing your team.”
If you’re falling behind on the regulatory documentation, you may be a Scrum-but.
It’s easy to think that the development team writes and tests software. But it’s wrong to think that. The development team delivers working code. And code isn’t working if it can’t be used, or if it can’t meet key regulatory requirements necessary to approve its release. If you build the most wonderful user experience, unbeatable functionality, and uncompromising quality, it doesn’t matter if regulations keep the software from ever being used. Your customer won’t be ecstatic, and you will have failed as a team. Writing or updating necessary documentation is part of the Scrum Team’s Definition of Done. Make sure it is included, and that team members pick up and complete those tasks during the Sprint. They may complain that writing the documentation reduces their velocity. Remind them that any velocity that doesn’t result in releasable software is a false velocity. Don’t try to game the system.
If you’re focused more on metrics than on excellence, you may be a Scrum-but.
There are lots of things a ScrumMaster and Scrum Team members can look at to determine how things are going. What’s the velocity? How are we doing on the burn-down chart? How many defects are we finding and closing per Sprint? What percentage of stories pass the customer demo? The value in these metrics is when they let the Scrum Team know that it isn’t achieving its potential. The danger in these metrics is that they can become substituted for the goal. In the end, the team is only successful if the software is released and the customer is ecstatic. If you’re struggling to meet that goal, the metrics can help you figure out why. But a low velocity, by itself, can’t be considered a problem. Too many or too few defects found during the Sprint, by themselves, can’t be considered a problem. A good retrospective looks at the success of the Sprint in producing releasable code that the customer loved. If the team decides that goal wasn’t met, or that it could have achieved more, then these metrics can be used to help generate ideas for improvement. Too intense a focus on the metrics will cause your team to game the system, which is the opposite of Agile.
If failing a customer demo demoralizes your Scrum Team, you may be a Scrum-but.
Of course the team would rather hit home runs every time, but that’s hardly a realistic expectation. The ScrumMaster should help the team set realistic expectations. One important expectation in Scrum is that the team will fail, but failing isn’t bad. The only bad failure is the one you don’t learn from. The runner-up is the failure you don’t discover for months after it happened. In my experience with traditional Project Management, failures often aren’t realized until near the end of the project, when 6, 12, or even 18 months have elapsed. In contrast, a Scrum Team often fails within 2 Sprints, allowing for a much faster, cheaper, and more complete recovery. This is good news, not news that should upset the team. I’ve also found that the traditional world rarely learns its own lessons. They hold lessons learned meetings, but their process for incorporating changes isn’t any more lean than their SDLC is. Conversely, Scrum Teams can make a significant change within 2 Sprints. Failure is what leads to these leaps, so failure should never lower morale. This doesn’t mean the Scrum Team plans to fail, just that it needn’t be afraid.
My next blog will have my final installment on this topic. Take a look at Part 3.