In a previous blog post, Extreme Programming For Modern Start-ups, Pat explained from his extensive experience with XP agile methodology why XP isn't always flexible enough for our work organization here at Bizo. My own past experience is with Scrum, the other popular Agile methodology. In this post I want to show where Scrum shines, and why Kanban finally wins for the kind of work we do.
- Scrum is great but you don't use it at Bizo. Why not?
I joined Bizo six months ago after working for 5 years for a software company which uses Scrum for all its projects. This means my previous work experience with Scrum is still quite fresh while I now have a good idea of how things work here at Bizo. Both Scrum and Kanban focus on almost orthogonal aspects of Agile. If you search the Internet for scrumban or scrum-ban, you will find people who thought about mixing the two. But generally you would do one or the other, mainly because of a difference in spirit between these two methodologies.
Scrum focuses on making people work well together towards building a relevant product. Scrum is human to its core. It takes our inherent social weaknesses and strengths into account. The planning meeting and the demo at the end of a sprint provide focus on short term deadlines. The stand-ups and retrospective keep the communication channels always open. The Product Owner is the point of truth for what goes in the product, and the Scrum Master watches and organizes the backlog. Both of these people protect the team against external influences by always keeping the focus on the current sprint. In my experience Scrum is amazingly good at making people work well together. And it's also a very satisfying way to work, within some constraints.
To be a good fit for Scrum, your project must:
- have a 5 to 7 person team. Fewer people, and all this communication will feel like a useless overhead. More people, and the communication will take too long, with team members losing interest.
- target one application or system. You shouldn't have a team of people working on different subjects. The tight communication channels in the team (planning meetings, standups, demos, retrospective) become pointless if each team member can't relate to what the other members do.
- have work that can be done in parallel for everyone in the team. You don't want to have idle people waiting for each other.
- be able to protect the team members from interruptions. Other projects members and stakeholders might want to interact with the team members for their own interest.
In my previous company, I had the privilege to work with Scrum in such an environment. When the context fits the constraints, the Scrum team creates interactions that fit perfectly with the way our human brain works and socializes. But even in the company I worked for, this context didn't happen that often. When you take into account reality and modern software development, you actually need more flexibility.
At Bizo, we have close to 400 git repos maintained by an engineering team of around 25 people. All of these projects contain code executed somewhere in our services hosted in the AWS cloud. By choice, there is no Operations Team at Bizo. This means we, developers, care for our app from fleshing out the design, to its deployment and monitoring. We have great tooling to help making deployment and monitoring a small amount of our time. But these tools help dealing with interruptions, they don't avoid them. So you might have guessed, Scrum is not a good fit for the projects we have here at Bizo.
- Ok, so you guys at Bizo use Kanban. Why Kanban?
Kanban focuses on having tasks flow from inception to completion in the most efficient fashion. Human interaction is completely left to the team's culture (quick plug for our culture guide). Kanban focuses on monitoring the task flow while trusting the organization to find the best way to optimize this flow. Optimizing the flow can mean adding a certain skill to the team, automating one particular slow task, or telling your marketing team to change priorities. Anything really. And that's what's great about Kanban, you're put in front of your own responsibilities. Kanban shows you that tasks don't flow? Your job is to find a way to make it work.
At Bizo, we have an architecture of many loosely coupled services and applications. We generally have small projects involving 1 to 7 people, with deployments that could happen from several times a week to once in a blue moon. Allowing for such variations in projects is great for many reasons, but it can create potential bottlenecks, or endless work in progress. To avoid this, you need monitoring, smart scheduling and flexible organizations. You also need visibility across all the small projects. Kanban gives us the visibility and doesn't get in our way when we need to change our organization.
- So to sum up, Scrum for the perfect world, Kanban for the win.
Scrum gives you a full framework to do your project. From the size of your teams to all the meetings you'll need, you get a full fledged target for your project organization. In my experience, if you can reach the target, or at least get close to it, it works amazingly well. Now Kanban doesn't tell you what to put in your task, or how you should perform them. It just tells how you should schedule and monitor these tasks, you then have to find the organization that works best for your project. This makes Kanban fit for a much wider range of projects.
If you're interested in learning more about Scrum or Kanban:
- An introduction to Scrum by Mike Cohn (then click the "View Presentation" button)
- A nice write-up of Kanban