Beware Complacent Scrum
Now that agile has essentially gone mainstream I have had the opportunity to work with teams that have been practicing Scrum for several years. These organizations have generally embraced the Scrum framework due to experiencing first-hand the benefits Scrum can offer, such as consistent team output, more collaboration and improved communication between IT and the business. Most of the initial pain points of Scrum adoption are over with, people have accepted the framework and the chaos of implementing change has worn off. The teams are working in consistent sprints and producing relatively consistent results. However, the teams and the organization recognize there are areas that need improvement, but are not quite sure what to focus on. Organizations at this stage reach out to CollabNet Agile Coaches to help them asses current practices within the organization and provide recommendations for improvement.
Scrum is a simple framework that is very difficult to implement and maintain. Daily Stand-Up meetings can start feeling tedious rather than helpful, retrospectives turn into bitch sessions rather than improvement seeking sessions and the business side, who many have never fully understood their role in an agile organization to begin with, stops engaging with the team on a regular basis. If any of these or other “lazy” manifestations of Scrum are creeping into your organization, it’s time to nip it the bud now, or eventually the whole thing will unravel.
When I introduce the Scrum process to new teams, I strongly advise against amending any aspect of the framework during the initial pilot. Without experiencing Scrum prescribed as-is, it is impossible to know what will/will not work at your organization. After experiencing “true Scrum” if you still need to amend the process, do what you need to do. However, in my experience, working with teams who have amended the process, I have yet to encounter a team that has amended the process to greater benefit for the business. The teams may feel better, they have less meetings, for example, but the teams aren’t producing the quality results they did under pure Scrum.
The two most common Scrum modifications I have encountered are 1) reduction or elimination altogether of the daily stand-up meeting, and/or 2) elimination of retrospectives.
First, I’ll address reduction/elimination of the Daily-Stand-Up meeting: When interviewed, the teams felt this was a good improvement to the process because they had more time to work. When pressed about collaboration opportunities among the team that become highly visible during the daily stand-up, comments trended along the lines of, “we all know what work we’re supposed to do, so we don’t need to talk about it daily.” Really? How do you know that if you don’t talk? In most cases the ScrumMaster wasn’t a strong enough presence or personality on the team to address the tedium of the daily stand-up. A good ScrumMaster needs to recognize when the team is no longer attaining value from the meeting, but rather than eliminate the meeting, change the format so the value returns. On the other side of the Scrum framework, Product Owners complained that teams were not as prepared as they used to be for Planning Meetings; the teams hadn’t discussed the work together and had trouble committing to a Sprint goal everyone could agree to. This resulted in longer and more frustrating Planning Meetings. So, while the team eliminated one meeting, they made another one longer, losing any gains they had to get more work done.
Eliminating the retrospective certainly provided the team with another hour in their sprint cycle to get work done. In the short-term, that seems like a good thing. But Scrum is about continuous improvement, constantly looking for ways to improve quality and value in output. When the Product Owners and stakeholders were interviewed, they commented that it felt like the teams were stuck in a rut and hadn’t made efforts to address certain project impediments. So, while the team was able to work an extra hour, the team doing simply that: working, not thinking about ways to improve work. Again, a good ScrumMaster would have worked with the team to retain the value of the retrospective.
It is important to remember a key purpose of Scrum: to constantly examine current work habits and practices and look for ways to improve. Removing the critical meeting, in which conversations occur around inspecting current process and potentially adapting new solutions, means the team has to fit this examination in elsewhere. But if a team is removing meetings with the sole purpose of creating an environment to “get more work done,” it is doubtful that team is spending time examining current processes and looking for improvement.
Anyone who has started a regular exercise regimen knows just how easy it is to stop exercising and just how hard it is to get back on the program. We know those sit-ups are good for us, but there are many things out there much more enjoyable than sit-ups. Sure, it feels great being a productive team member churning out work rather than “wasting time in meetings” but how do you know the work you’re churning out is the right work if you don’t take time to reflect on your process and discuss objectives with teammates?
Agile advocates need to be on the lookout for “complacent” Scrum within their organizations. Complacent Scrum doesn’t happen overnight, it is a gradual build-up with seemingly little consequences, until one day, the organization misses a few key milestones and since no one likes to point fingers at themselves, it’s very easy to just blame Scrum. However, if in actual practice, the teams have eliminated key elements of Scrum, while still calling what they’re doing, “Scrum.” Scrum isn’t to blame, for in reality, the team is no longer doing Scrum. They have lost some key disciplines and it is probably time for a tune-up.