How One Guy Mixed Scrum, Lean, Holacracy, and Kanban to Make an Unstoppable Workflow System
The generals told Hannibal, legendary Carthaginian military commander, that he’d never be able to cross the Alps with elephants. Turning a steely eye to the horizon, Hannibal had only one thing to say in response: Aut viam inveniam aut faciam! or, for those of us who aren’t up on our dead languages, “I will either find a way, or make one.”
The mild-mannered man seated across from me is Blinkist’s quality lead, Steven. He is wearing a plaid shirt, khakis, and a warm, expectant smile. He bears little resemblance to the marble bust of the conquering Carthaginian, but his bold attitude is delightfully similar. Just before he went on paternity leave, I sat down with him to learn all about HoLeBan: the hybrid of the Holacracy, Lean, and Kanban productivity and workflow systems that he created for Blinkist’s tech team. Read on to learn how you can create a system that fits your team just right so you can get things done faster, better, and smarter—together.
Caitlin Schiller: Can you give me the basics on HoLeBan? Why did you create something new versus use something old? What is it based on?
Steven Reinisch: Well, we wanted more alignment of the development and product sides of Blinkist. We tried out pure Scrum, but we found that ultimately, it didn’t work out so well. In general, when you try to put structure on an existing structure and you don’t care if they match or not, it can lead to complications.
I quickly learned that making a working process for people can never be a dictatorship—you have to fit a process to the roles they already have and the way they already like to work. This is why, on top of Scrum, I started to bring in elements of a change management framework called Kanban. Kanban is not a software development process itself, but a it’s a way to get more out of your processes. Its main principles really shaped HoLeBan. They are:
1) Respect existing roles and processes, or “start where you are.”
2) Visualize the workflow with a task board, dividing up “to do,” “doing,” and “done.”
3) Limit the work in progress. This means you try to avoid multi-tasking, and only so many projects can be open at once.
Finally, Blinkist as a business already operates with a version of a non-hierarchical system called Holacracy. I pulled in elements of that, too, because they were working for us.
CS: Can you get specific about what was working? What’s actually in the HoLeBan sausage, anyway?
SR: Sure! As I said, we used the “to do,” “doing,” “done” workflow format from Kanban, but we added a level to it by keeping the product backlog from Scrum. The backlog is a prioritized list of work. We wanted to increase development output, so being able to manage priorities with a backlog really helped. Now, all the work that’s in the “doing” stage in the Kanban model is part of a prioritized backlog list.
Another Scrum ingredient we kept was the daily meetings, which are called standups. But then we did something different, and used the structure of a Holacratic weekly tactical for our standup. As in a Holacracy tactical, we have a check-in round where everyone can say how they’re doing, if there are any administrative concerns, or anything like that. Then, you move on to the checklist of items that need to get done weekly. Here, we subbed product metrics, and then would move to project updates.
We also blended Scrum’s retrospective meeting with Holacracy’s governance meeting. Before we formulate our next actions, or what we need to do next to get a project moving, we gather data, put a timeline on the whiteboard, and give participants five minutes’ time to think about what happened in the last couple of weeks, retrospective-style. People come to the board, stick their impressions on it, and talk about what happened. Using this format, we get to think about what actually happened. We noticed greater transparency and greater communication. People were getting away from their desks and their monitors in order to talk to and work with one another to make things happen. I find that especially with developers, people rarely ask for help. Having a system this transparent allows help to be offered, in some cases, before it’s even requested.
We’ve found that using a really standardized, strict format like Holacracy’s governance, but welcoming in introspection and giving the space to raise tensions, has really helped us work better.
CS: So, this has worked for your team at Blinkist. What are 3 things you’d recommend to someone who wants to find a system that is right for them, or make their own Get-Sh!t-Done system?
SR: The first thing to do would be sit down with your team and talk about how a work item flows from spec to getting it done. Creating a Valuestream map, which is a tool from Lean processes, will help with this. As you do it, consider: what are the different states a work item can be in (like “ready” or “planning”); who is involved with getting it done; and what are the different steps that you take to get it there. A role play can help you figure out how a single task moves through an entire team’s hands.
The second thing is to think about how you can limit the work in progress, because that will really help you get clarity and focus on what needs to be done next.
And third, always use an analog whiteboard. Don’t try to use a digital too because if you use a digital tool, you’ll start thinking based on its parameters and requirements, not human needs. If you have a whiteboard, you have the most flexible planning tool you can have to design your work process. Design it analog and you’ll always put people first.
CS: What’s your best advice for a new leader, whether or not they’re designing a new system?
SR: Start with the human. Start where you’re at—then, you can build up together.
Steven’s clearly not a military general, nor is he your average technophile developer: he’s a humanist.