Kanban in Development Teams
Everyone’s agile. Especially when you talk to modern teams doing software development. If you dig a little deeper, you will often find that lots of these agile people can’t define what agile means but most of them have done Scrum in a project. Don’t worry. That’s just me 2 years ago, too!
In this post I will try to show that there is more to Agile than Scrum and how Kanban can optimize and accelerate your development workflow in a team.
Why Agile?
Agile - or better Agile Software Development - means a certain set of software development methodologies. These methodologies circle arount an iterative process through the collaboration of a cross-functional and self-organizing team. The requirements and the correlating solutions change and evolve can change over time.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is the starting principle behind the Manifesto for Agile Software Development and it states clearly what the goal of Agile is. All of the other principles can be seen as ideas on how the main goal an be achieved.
There are different ways on how to do Agile Software Development and Scrum is most used one for sure!
Is Scrum the holy grail?
Some teams would definitely sing that song. And for their personal situations they might be 100% correct. Good for them. No, really, that’s great!
Scrum provides a framework with roles and rules and meetings and if everyone knows all of that and is okay with complying to that, Scrum works really well. Teams that move to Scrum often praise how they have time to focus on developing. Finally! That’s because at the beginning of a Sprint (which can be seen as a defined period of time with defined goals) everything, that should be done in that sprint, is broken down to tasks to see what’s really going on with that feature. Questions are discussed and therefore in a perfect scenario the developers can focus on doing the work afterwards.
But there are numerous other advantages when moving from traditional ways of doing the work to Scrum as there are of course some disadvantages. For now I don’t want to go any deeper on talking about pros and cons. One thing needs to be stated none the less: Scrum is not for everyone! There are various reasons: Teams that change very dynamically, multiple projects and customers that require the developers attention on a daily basis, a management that does not want to follow these strict rules.
But thank God there are other ways of working in an agile way.
How can Kanban help?
Kanban itself has no explicit rules on how the work should be done. But Kanban has rules on how to find your own rules. Sounds confusing? It isn’t. Saying it in a cheesy way:
Kanban is not the solution. Kanban is the way to find your solution.
What is a CIP?
Working guided by the Kanban methodology enforces a CIP - a continuous improvement process. This means: Kanban will not tell you “do this, do that: ready, now your doing Kanban”. Kanban will ask you to start exactly where you currently are. Starting from that ground Kanban methodology will tweak your process in small steps. The goal is to improve your process continuously.
It is important to note, that these changes are small, evolutionary ones; not big revolutionary ones. Change is always hard. Sceptics will pop up and doubt what you are trying to change. But what makes change easier, is breaking it down to small chewable chunks. These are the evolutionary changes to improve our process.
And even though, if it turns out a piece of change, a small tweak, intended to make something better, is to hard to chew or does not work out as it was planned, we can just roll back. As it was no big revolutionary change the effort will be not that big of a deal.
This is something, that might help arguing with skeptics!
Our Situation
Before I want to take a look at some of the guidelines of Kanban, I wanted to explain a little bit what the starting point of my team was, when we picked Kanban to help us.
Our team is a development team of 6 (we are more now since we have grown, but at the time we started we were 6). Looking a the level of skill there were big differences and varying specialties. A very standard team setting, I guess. We are serving multiple customers at ones. Most of the time we are doing projects with these customers. And those projects can be very different in their setting as well: Does the customer already know what he wants? Does the customer want us to do Scrum or any other methodology? Is a named team of developers needed, who work in the project exclusively?
We experienced a lack of cross-project communication and visibility. Often we had no clear idea what someone else on the team was doing. The named team for many projects had resulted in splitting the original development team up into several micro-teams. Each of these was on its own. Pressure couldn’t be compensated through the big team. But even knowledge transfer was hard. What is my team-mate doing? Is that interesting for me? Can I help because I had the exact same task or problem in the past? We were one development team on paper but the reality was very different!
Our team lead’s plan was to change this. Make us a team again that is able to help each other and talk to each other and celebrate wins together. She picked Kanban.
Let’s see how Kanban can help in this situation.
Key Lessons of Kanban
My plan here is not to give you the big round house kick on all there is to Kanban. It is too much anyways. But I want to talk about a few of the key lessons I took away in my time practicing Kanban with my team.
Visualize what you are doing
Task, projects and progress should not be invisible. Kanban encourages you to visualize it. Maybe through the well known Kanban board. In fact the board really is the go-to tool for visualization of your process.
In a very basic form it’s just a table with 3 columns: To-do, Doing, Done on a whiteboard and tasks visualized by little post-it notes going from left to right.
As a task is linked to the team member(s) who is/are currently working on it, the others can see at a glance: “Ah, Peter and Suzy are setting up the CI/CD pipeline for Customer A.”. Wonderful!Based on this visualization problems in your current process are easier to identify because you can actually see, when something goes into the wrong direction.
Flow
The potential improvement possibilities of your process can be numerous. But the basic problems that should be improved are often very similar. Tasks get stuck in the middle because priorities change. Tasks pile up at a certain step of the process because there is a constraint (e.g. 6 developers, but only one tester). The opposite of having these or other problems that hinder tasks from being completed as fast as possible from to-do to done is called Flow.
You can take that literally: Kanban wants your tasks to flow as if your process is a river. Always in motion. And even if there is a barrier: water will find a way around and continue flowing down the river.
But by enforcing Flow in your system you win much more: you win predictability! As water runs at an average speed, so do your tasks (hopefully). And by having this average speed your output of completed tasks becomes predictable.
Say you have 10 tasks to do. And, by doing the math on your metrics of the past 5 months, you know your teams finished 6 tasks a week. Now you are in a spot where, if someone asks when the 10 tasks are done: “Approximately in 1.666 weeks.”
Don’t we need to estimate how big each tasks was? Of course, we could do that. Often these estimations are not very accurate. Unforeseen problems or dependencies? Statistically the average speed of your Flow include all of these variables. But of course, some tasks can easily be estimated. But while you are doing the estimations, you are not working productively on moving the tasks down the river.
This is why Kanban challenges you to put all steps of the process to the test: Does it add value?
Do estimations add value? Most of the time, they don’t!
Why rules should be explicit
You can visualize your process and find ways to optimize the flow, but all of the rules you as a team have should be written down, drawn to a board or made explicit in another way.
Why? Because it is much easier to discuss some rule does not fit anymore or that is not working as intended. You can erase the rule, change the rule or come up with new rules, that might fix this rule. If it was not explicit all of that would have become much more difficult.
Educating customers
In my experience, one thing is absolutely necessary when starting Kanban: inform your customers about what you are doing. Because as long as your team is not functioning as a black-box that pruduces code after a undefined amount of time, your customers will notice the change. And from what I see, often they are confused because some of the the improvements can seem somewhat contra-intuitive.
Let’s imagine 3 clients. All of them want something build and it’s in all 3 cases a comparable amount of work to be done. Often a team faced with this situation would start with all of the projects at the same time. Either because they have learned to do so or because they are pushed to it by the customers or their management. Afterwards they work, work, work and after some time - let’s say after 3 months - they are happy to announce that the have completed the 3 projects.
Is there a better way in which most of them will become happier but at the same time none of them gets less happy then before? Maybe ;)
What if we focused on one project first. With the complete team working on it, we should be able to complete the task in 1 month. Customer A would definitely be more happy to have the project done 2 months earlier. Afterwards we start the next project and would probably be done after another month. So even customer B would receive what was demanded 1 month faster than before. Nice! Only customer C hadn’t had luck. He only gets the work results he was desperately longing for after 3 months. But wait, that’s not later than before! We reached our goal. Most of our clients got happier, none got less happy. 🎉
What this little experiment teaches us as well is: Flow does not only apply to tasks but to whole projects as well. Start things, get things done quickly, focus and then continue with the next stuff. Or with other words:
Stop starting, start finishing.
Because what brings value to our clients (and - in the end - to us as well) is finishing things, not starting. But we need to communicate the changes in how we are working and why this can only make things better with our customers!
Lessons learned
- Kanban is a continuous improvement process
- Kanban starts right at your current situation
- Visualize what you are doing
- Find ways to optimize your Flow project
- Make rules explicit
- And make your customers come on board
Matthias Wehnert is a JavaScript-Developer from 📍Bonn. He is 32 years old and loves building beautiful things on the web 🚀! Do you want to learn more about him 👋? Or his work 👷? Or get in touch 📫?