So, I’ve had a few rants thoughts on process in the past.
I’d like to revisit those with my Big Boy pants on. For one thing, during my current job search process, my experience in Agile in the past 4 years always comes up, so I thought I’d parrot here what I generally say in the interviews, on why you’d choose one versus another.
If you’ll allow me, I’m going to argue that both are valuable, and both should be in your organization.
First, let’s define our terms. When I say Scrum, I generally mean the process that arose in the early 2000’s employing same-size sprints, Product Owners, Scrum Masters, and backlogs. See the wiki link for more detail. When I say Kanban, I mean the process employing same-sized units of work in a continuous delivery stream with a strong focus on Service Level Agreement (SLA) for a given team.
Things I’m explicitly not discussing:
- XP or “Extreme Programming”
- Scaled Agile Framework (SAFe)
- Any generic holy wars that generally devolve into the No True Scotsman fallacy
Let’s proceed, then, Scotty.
Why to Choose Scrum
Summary –> If you have to adopt some methodology and you can’t spell “Agile” yet, choose Scrum. It’s generic and structured enough. Just don’t let it become a religion.
Having lived through “Agile” when it was basically defined by what it wasn’t, Scrum is amazing. It’s real, tangible, and it holds water to all those people who write the checks (your bosses) and buy your products (your customers). People have a place, and defined responsibilities.
Scrum optimizes for working code always, and deliverable code at the end of each sprint. Each sprint is like a small software release encompassing design, testing, development (see what I did there?) and delivery. At the end, there’s a demo, and an opportunity for the stakeholders to adjust direction. Lather, rinse, repeat.
A key term to learn in Scrum is velocity, the # of “story points” a team can complete within an increment (2 to 4 weeks), typically. By using velocity and a well-sized backlog of work, one can do that Project Management magic of managing risk/schedule/function for a given product.
Scrum is great when…
- You’re building something big. Each ‘sprint’ is another step towards the end goal. (Keep that in mind, that’ll be a big difference for Kanban), and a chance to course-correct.
- You can leave a team alone for N weeks. A big part of Scrum is minimizing impediments and interruptions. They’re going to go through a full development cycle before your very eyes, so watch “behind the glass” so to speak.
- Someone cares to watch the demo. This is obvious when you look at it, but it must be said: Real business stakeholders often don’t care to see your results twice a month. If no one’s going to the demo, it’s a waste of time for everyone.
- You have a new team or you’ve never been agile before. As mentioned above, there’s a way to go from Zero to Scrum, and most trained Scrum Masters can get you there.
Things to watch for….
- Teams sandbagging because of the “commitment” part of Scrum
- People rolling their eyes on all the meetings required for Scrum. (Psst….they’re not required. Make the process work for you!)
- People exhibiting Stanford Prison Experiment symptoms: Because Scrum does so crisply define roles, it’s tempting to lean back into them instead of transcending. Those are just the rules, not the entire “Box” of your work responsibilities.
- Exhaustion, particularly in your Product Owners. PO’s have a “term paper” due every 2 weeks during release planning/spring planning, along with their other responsibilities.
Why to Choose Kanban
Ah, Kanban. Everyone in manufacturing or adjacent to it has learned Lean and TPS and all the theory around it. In essence, Kanban takes the opposite approach from Scrum, in that it’s fine with interruptions and odd delivery schedules. Kanban optimizes for throughput by minimizing Work in Progress. Similar to the GTD or Pomodoro philosophy, it hypothesizes that teams do best when they can concentrate on the work at hand.
Kanban is ideal for a team that has to be responsive, like a support organization. In fact, it’s nothing really that new. In an ad-hoc way you might consider a ticketing system like RT (or any queuing system) as a Kanban way of acting.
What Kanban is really good at is making everything highly visible and focusing the team on the work, not on the individuals. For example, in standup, the team reports on each item in progress, not the team member’s status. That’s subtle, but it’s important: Businesses don’t care about what Bob did yesterday, they care about Support ticket #1234 and if the customer is happy.
Kanban is great when…
- You’re any sort of support or operations group. Kanban was made for you.
- You have any sort of pre-sales or customization responsibility. Things may crop up day-to-day to close a sale. Those can work in Scrum sprints, but it’s awkward.
- You find your group always takes 3 or 5 “story point” stories anyway.
- You have more of a continuous delivery model of development, rather than a hard shutdown/regress/ship. For example, I couldn’t see a Hardware R&D organization using Kanban, because there’s little value in delivering things on different schedules–everything has to be fitted, integrated, and tested together.
Things to watch for…
- Demos. Kanban has no prescribed demo times, so you’ll look-up in 6 months without ever demonstrating the product. In a weird way, this can put you back in waterfall hell.
- Too much WIP. (insert Devo reference as you like!) It’s tempting to put too much in progress at once, such that the team is working 1 story per developer. You’ll find your productivity plummets at that point–people get territorial, they don’t pair, etc.
- You’re always working. Kanban is a continuous stream of work, but there are other things to do: Training, refactoring, onboarding, etc. Scrum makes it easy/easier to take a ‘quality’ sprint or a ’training’ sprint with crisp edges. That’s not straightforward in Kanban.
- Coaching instead of driving. Kanban is about pulling work, not jamming work through the system. Which leads me to…
- Driving to dates. Be honest with yourself–if you have something schedule driven, you don’t have ‘velocity’ to predict things like with Scrum. Kanban can be made to work in a schedule-driven shop, but it’s better in a continuous delivery shop.
That’s really about it. One final word: Scrum isn’t “basic” agile anymore than Kanban is “advanced” agile. This sets up a pecking order, and it really doesn’t exist. As I’ve said above, if you’re building something big, with milestones, and you need predictability, use Scrum. If you’re doing support, operations, or pre-sales or continuous delivery, Kanban if for you.
Thus the kicker: Most significant development shops need both. You may have some teams building the new Widget, while some teams are mostly sustaining your bread & butter. Choose whichever methodology makes sense at the team level, and work-out the reporting structure to project management from there.
The above is my considered opinion after years of Agile (before it had a name, really). Would love to understand others opinions on it.