I have a problem with the way many people talk about Scrum. They say “agile/Scrum,” as though they’re the same thing.
No, no, no. Scrum is just one way to approach agile. It’s a terrific project management framework, especially for cross-functional teams that work on one project at a time.
Scrum does not say anything about the technical practices. The team is supposed to retrospect to determine which practices they need to add, subtract, or change. The team is also supposed to remove its impediments as it proceeds.
Agile works because it manages the work in progress and focuses on delivering finished value. Scrum manages the work in progress with iterations. Kanban manages the work in progress with an explicit board. Extreme Programming manages the work in progress by focusing on technical excellence.
I have seen teams do what they call Scrum. They don’t finish features in an iteration, and they don’t use the technical practices. Then they say, “Agile/Scrum doesn’t work for us.” Well, it can’t work if you don’t use it right.
I happen to be a fan of all three approaches for a collocated cross-functional team. I like one- or two-week iterations using Extreme Programming technical practices so we deliver finished products incrementally each week or two. I like using kanban boards to see where the work is and to limit the team’s work in progress.
If you look at the way I like to work, it could fit into Scrum. It could fit into kanban. It could be XP. And that’s just for collocated teams.
I happen to like more project management to deal with impediments for a distributed team. Teams that started as distributed or dispersed agile teams might not need the help of a project manager-type person to remove impediments. They might need servant-leader managers to build and maintain the agile environment for the team.
In my experience, teams who started as distributed or dispersed waterfall teams have trouble using agile, especially Scrum. Scrum has several real-time rituals: iteration planning, the daily standup, the demo, and the retrospective. Many teams accustomed to working out of sync find these practices difficult to manage.
In that case, I like using timeboxes for focus, but maybe not one- or two-week timeboxes. (I like four- to six-hour timeboxes for stories.) Kanban is good for helping you keep track of the work and limit the work in progress. When the team can make smaller stories, it has options for how to deliver value often.
Agile is broader than just Scrum. Scrum, for some teams, is a straightjacket that doesn’t fit. Agile, assuming you can see past the Scrum rituals, might fit quite well.
Let’s choose our words carefully. If you only know about Scrum, consider learning about kanban and Extreme Programming too. You might discover there is a wealth of possibility for improving your team’s process.
