Chapter 8 - Scrum: The Good and Bad
If there is one methodological framework most strongly mentally associated with Agile, it would be Scrum. In many people’s minds, the two are the same thing.
However, that’s not quite accurate. Scrum and its practices are just one of the ways people try to be Agile. For all the praise and hate it attracts, the truth is that it offers some powerful lessons along with some significant downsides.
In a nutshell, what is Scrum?
Scrum is about tackling a project with a number of similar-sized iterations. It places a high value on a fixed set of practices to standardize all projects. It’s a means of organizing the whole team and involving every team member during each key part of the project.
Where the primary tool in Kanban is the Kanban board for visualizing workflow, the primary tool in Scrum is an iteration, which is also referred to as a sprint.
Good Result: Team Planning / Demo / Retrospective
One of the good results of Scrum is the emphasis on these particular three essential rituals. They are considered essential parts of every iteration.
Before an iteration begins, the team assembles and plans the top priority work tasks that become the sprint’s focus. By always setting some intentional planning at the start, there is a mindfulness that will set up the project for success.
During the iteration, the team focuses on regularly demonstrating the project progress, preferably by using the current version of the software. This is hugely valuable since it ensures that everyone knows how the project is progressing, and how much value has been fully delivered.
At the end of the iteration, the team comes together to reflect on what went well, what didn’t go well, and what can be improved. When a project embraces the concept of continual improvement, the project continually gets better, rather than worse. This is a potent tool for increasing project momentum, which is the key metric of project health.
These three practices provide strong benefits for every project I have ever led or contributed to.
Bad Result: Daily Standup Meetings
One of the bad contributions of Scrum is the daily standup meeting.
There are many problems with the ritual of a daily standup meeting. I will only list a few. There are many more.
Once a day is a very slow communication cadence. If a team is working very closely together, there should be much more communication. If a team has very distinct tasks, then there isn’t a need for that much communication. Once a week or ad hoc might be a better cadence.
For teams with more than 3 people, some team members don’t care about the details of what other teammates are working on. This leads to boredom and disinterest. For teams with less than 3, no information sync is needed.
Many companies use daily standups as a psychological motivator to indirectly shame low performers. This is a terrible way to solve motivation problems.
Communicating technical information just by speaking about it without using documents, visuals, real code, and real artifacts is an exercise in futility.
Some use daily standups as a means of creating social bonding. Why are people pretending to talk about work, then? You can just hold regular team socials and do something fun, instead.
In my many years of working on projects, I have never come across a single compelling reason for the Daily Standup Meeting that isn’t better solved with other methods.
Good Result: Sprints
The idea that a time-boxed interval where people work as fast as possible and deliver a sizable chunk of functionality is a fantastic idea.
Single-minded deep focus is a creator’s best friend. It’s easier to put a lot of energy in when you know you’ll have something cool to show and when you know you can ease off the gas afterward.
Some of the world’s best projects began with a weekend of crunching, a hackathon, or a game jam. Now-famous tools and games such as Gmail, Twitter, Superhot, and Hollow Knight have their origins in 1-7 day sprints.
With a sprint, it’s very important to have a hard deadline and to have everyone focus intensely. Also, it’s crucially important NOT to sprint all the time.
Speaking of which…
Bad Result: Unsustainable Pace / Burnout
Many companies love the idea of the Sprint since so much can be accomplished in such a short period of time. They love to combine that idea with the idea of iterations.
On projects that try to combine these two concepts, you’ll find people saying that they are continually doing “back-to-back 2-week sprints”. I’m not really sure how anyone can say those words out loud without seeing the inherent irony in such a statement.
At some companies, they want as much output from their workers as possible. By setting ambitious scope goals for every iteration and having an infinite series of iterations, they think that they will get TONS more work delivered.
There are only two possible outcomes that result from this heavy-handed management approach.
- The teams know they can’t stay at full speed, and so they increase all work estimates until the pace is comfortable, completely negating the benefits of true Sprints.
- The teams work themselves to the bone, get progressively more tired and burned out, and eventually either quit the project, or become mental vegetables and a project liability.
Even if you like Scrum, don’t push your people to work fast all the time. You can either do back-to-back Iterations at a relaxed long-term pace, or you can do true Sprints with plenty of recovery time in between each. But you cannot effectively do both, and no amount of wishing will change that fact.
Good Result: It’s Team-Centric
One of the big perks of Scrum is the focus on the whole team, which is very closely aligned with the core tenets of Agile, as we discussed a few chapters ago.
If you are working on a solo project, or with a single client, or with a buddy, then this isn’t an important feature. But, if you are managing a project with more contributors, this is a good focus.
You want the entire team to have a clear vision of what work needs to be done. You want everyone to see the things created by the other team members, so that the ideas can cross-pollinate and positively shape the project. You want everyone to be in the project together, with shared incentives.
Those are really good things. Teams that work well together deliver better results and have a lot more fun doing it. This is a way to bring a lot of humanity into a project.
What you want to avoid in a project is having people work on stuff in isolation. You want to avoid communication gaps, motivation gaps, and vision gaps. This is one of the great things that Scrum encourages, and it’s a useful paradigm no matter how you run your projects.
Bad Result: Scrum Masters
While it’s good to have knowledgeable team members who can help manage the project, it’s potentially dangerous to have someone whose key role is to ensure the team follows Scrum by the book.
Everyone on the team should understand how the project is being managed. Everyone on the team should have skin the game.
It’s dangerous to have someone who isn’t involved in delivering the project on the project team since, in practice, they are often more interested in making pretty reports than in helping the project succeed.
Just as no middle-managers are needed for a project to thrive, there is a fine line around dedicated project management roles and mentalities. Any project manager whose #1 goal and responsibility isn’t delivering the project is either deadweight or a threat to the project.
It’s a tough tension to resolve.
The focus should always be on delivering the project, not on tools/charts/experts/reports.
A successful project is the best testament to a methodology.
I’ve seen many projects fail due to an overreliance on Project Management Experts at the project’s expense.
As you can see from my thoughts here, Scrum is a mixed bag. It’s got some great elements and some considerable pitfalls.
What are some things you can take from Scrum that will help you deliver projects?
- Incorporate planning, demos, and periods of reflection as you go
- Consider harnessing the incredible power of Sprints to get ahead
- Make sure the whole team is included and has a shared vision
Chapter Review Question
- What is the key tool in Scrum?
- What are the four big Scrum rituals?
- What are three positive results of the Scrum methodology?