Ah yes, a new year, and fresh chance to simplify things. And isn’t that what we all want? A clear and simple path forward, both easy to see, and easy to understand. This is what thrills me about agile approaches, they provide a clear path forward. However, they must be implemented properly and with attention to detail. I love my work as an agile coach, and helping teams deliver great business results. I work with teams from all around the world and have helped agile teams both large and small while they navigate sometimes rough seas of software development. As we move into the new year, I’m sharing my thoughts on some common hang-ups and faulty misconceptions for teams utilizing Kanban.
First off, Kanban is a fantastic, lightweight agile process, with no prescribed roles, and very simple to learn and implement. I use it both in my personal life and to collaborate with teams on projects. But the more I use Kanban with teams, the more I realize that despite being easy to learn, it’s not always easy to achieve the agile benefits of the Kanban process. For Kanban to do what it’s really designed to do, it requires some time for a team to mature along with some to-be-expected trial and error.
If Kanban seems to not be working well for your team, then start by looking at why it was selected in the first place. Perhaps it was adopted for the wrong reasons? I see this all the time; leaders decide too quickly that Kanban is right for their team once they realize the simplicity and no new roles like ScrumMaster, for instance. The key to a good fit for Kanban is looking closely at the type of work your team is doing. If your team has a constant flow of items to address like a Production Support team or a Helpdesk, then Kanban is likely a great fit.
Ok, so your work fits Kanban but the team is still not improving the speed of delivery? Well now it’s time to dig a little deeper. Let’s look to the Principles from the Agile Manifesto for some insight:
How are we doing on this one? Do you know what your customers are thinking about your software products? If not, you need to ask! When using Kanban the burden is on you as a leader. Scrum framework has the Sprint Review along with the role of Product Owner to gather these insights, but when using Kanban it’s your responsibility as leader.
Let’s be honest, most of us don’t like change. When a lot of time and energy is spent planning, change is hard. Kanban doesn’t require a lot of upfront planning so when you change your mind it’s often not so painful. If you find change is hard, then look at your intake process and reconsider using Scrum.
If your team is unable to deliver valuable software to your customer on a weekly basis, or even more often, then you are not using Kanban correctly. Kanban will give you the data you need to find bottlenecks in your process and methodically remove them. However, you need to actually be using the data and looking for improvements.
Many of the teams I work with are using Kanban to improve the “management” of their backlog. It helps them organize their to-do list and that’s great, but it’s crucial to ask if it’s improving the delivery of value. Without your business partners in the room every day, the team will naturally do what you see as the most important. Often not what the business would consider important. Having your team include both business and techies together every day, will improve your value delivery.
Give them the environment and support they need, and trust them to get the job done. If you can’t tolerate a mistake from time-to-time, Kanban or Scrum won’t work for you. Perfection is not the goal! Speed to market and fast learning feedback cycles is what makes this work.
If you don’t include the entire team in your daily stand-ups you are not doing Kanban. It’s that important.
Thereis nothing more important for team morale and customer satisfaction than pushing changes out to the customer. If you don’t already measure this then you should start today.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The newer teams I work with often look at the WIP limit as a cute idea. Experienced teams however, learn that by sticking with the limits set by WIP they accomplish more over time and their quality is superior. Again, if you are not already measuring your delivery and quality you should start today.
You need the software to be free of technical debt. If not, the team will need to devote more time on defects and stability problems. Always think of the full cost of ownership of software, not just the cost to add the new feature.
If Kanban is not simple, then you should look at what processes you added that make it complex.
If you believe your team needs lots of management attention, then it’s time to step away. You are not using Kanban if someone is telling your team what to do and how to do it.
As I mentioned above, you will need to work at this, but it may be the most important practice a Kanban team will do. They should be looking for improvements on a daily basis. I think scheduling a time every couple weeks or monthly for an extended retrospective with the team to look at your trend data, lead time, cycle time, defect trends, and customer feedback is helpful. Based on these data points you can always find room for improvement.
Remember, good things often take time. Kanban is one of these good things. The Kanban process itself doesn’t take time, rather it takes teams time to mature into using Kanban properly. Keeping this concept clear in the minds of all parties involved will lead to a grounded understanding of when Kanban truly isn’t a fit, vs. when the team just isn’t fully matured into using it properly. As you’re working with your teams deciding whether Kanban is the best choice, think about team maturity, and consider this quote from legendary UCLA Basketball coach, John Wooden, “If you don't have time to do it right, when will you have the time to do it over?” Until next time, friends, I hope this new year brings you clarity in everything worthwhile.