The Scrum framework revolutionized the way large projects were managed and made them incredibly more efficient. However, it is important not to blindly adhere to Scrum principles – even Jeff Sutherland would agree with this comment. Very briefly, I want to discuss where Scrum comes from, its core principles, why it’s excellent, and when not to follow it.
Scrum came out of improving software development for large companies (think Toyota or the US Government) implementing multi-year contracts with hard requirements. Scrum is designed to fix the ubiquitous problem of projects running late and over budget. Or even worse, the problem of canceling projects because they are so far behind schedule and over budget that the funds run out. While there are a lot of great concepts in Scrum, since it derived from very large, multi-year projects, be careful not to apply all concepts to your project.
The main principles behind Scrum come from the Agile Manifesto: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. A fundamental part of “Individuals” is that they “take responsibility” in achieving their goal, something I touched on in the Engineers Are Not Fungible blog. While Scrum itself suggests implementing processes, even Jeff Sutherland knows “in a theoretically perfect world, there would be no process” and “any process that people use is wasteful, including Scrum”. I love all these ideas. Light process, concentration on individuals, working software, agility. They are fantastic and I’ve seen them work!
What I don’t like about Scrum are the specific methodologies that it suggests. The weekly sprint, which includes planning, effort estimation (via story points instead of hours), velocity calculations, daily stand ups, sprint demos, and post-mortems. Even if you only do it once per month (though Scrum methodology advocates the shorter the better), it is too much overhead and process in today’s fast-changing world. The backlog should already be prioritized, so no planning is necessary, simply grab the next priority item after you finish a task. Remove completely effort estimation and velocity, however, instill in your engineers to speak up once a task becomes more complicated than at first glance. Instill in your engineers to speak up if roadblocks are encountered. Instill in your engineers to speak up on interesting issues that arise. Basically, communication within the team should be event driven, not poll based. You should not wait until the next daily stand up to hear about an issue, the issue should be communicated immediately. As such, remove the daily standup. Replace sprint demos with emails containing screen shots or videos. Demos are momentary and live, whereas emails and videos can be archived and referenced in the future. And finally, remove post-mortems. Again, instill in your engineers to speak up when they see something that can be improved. Meetings are the #1 killer of productivity so minimize them. Despite their popularity, face to face meetings are highly overrated. It’s becoming clear (through data) that employees not only like to work from home but they are often more productive working from home. To get back to topic, Scrum has a lot of processes that in 2017 with today’s knowledgeable employees, specifically employees knowledgeable with Scrum-like process, many of the mandated processes are just no longer necessary.
In sum, the overarching and guiding principles of Scrum are spot on. Every project should adhere to light process, emphasis on individuals, collaboration, responsiveness to change, and ultimately, the end result. Avoid the Scrum-specific methodologies that are rooted in making large, behemoth corporations and governments better, rooted in forcing communication via scheduled meetings, and rooted in poll-based feedback from engineers. Most likely your company and project – today in 2017 – do not operate like these behemoth corporations did twenty years ago and would not benefit from these methodologies. Don’t just blindly adhere to the processes of Scrum but understand the principles behind Scrum and apply them to your project.