Let me guess - your team is struggling with Scrum, so you are thinking about implementing
Kanban.
That might be a solution 🤷‍♂️.
But that might also lead to just many more problems.
If you are thinking about switching to Kanban, then watch this video to understand what you
absolutely have to consider beforehand.
Hey there, it’s Daria.
One of the very common problems I see with new Agile teams is that as soon as they start
struggling with a certain framework, their natural response is to completely change their
process.
I understand the sentiment - they want to make the process much easier.
For whatever reason, Kanban is seen as an easier framework to implement compared to
Scrum.
Unfortunately, that’s not actually true if you want to implement Kanban the right
way.
Here’s the big reveal - Kanban is NOT just a board with columns like Todo, In progress,
and Done.
This workflow board is just part of what Kanban is.
I mean, that’s why there are whole classes you can attend and certifications you can
get in this area!
So if your team is considering to implement Kanban, you need to have some basic understanding
around it.
I will use this book by David J. Anderson as my reference guide for this short video.
If you want to get this book, I will link it in the description.
You can also find it in the recommended reading in my store.
Btw, if you haven’t seen it, I have added a whole new section to the store to help you
build your library with great books that I recommend myself 100%.
These are the book that I read and genuinely enjoyed, but also learned so much from.
Using my affiliate links on my website to purchase these books is a great way to support
me with no additional cost to you.
Anyway, let’s dive deeper into what Kanban is actually about if it’s not about the
board itself.
Let me quote the book here: The Kanban Method introduces a complex adaptive
system that is intended to catalyze a Lean outcome within an organization…
Kanban uses five core properties to create an emergent set of Lean behaviors in organizations.
I will refer to those five properties as rules, because that is essentially what they are
in simple terms.
They are: 1.
Visualize workflow 2.
Limit Work-in-Progress 3.
Measure and Manage Flow 4. Make Process Policies Explicit
5.
Use Models to Recognize Improvement Opportunities.
Let’s look into each of these in details.
If you like this content and you learn something new from it, consider subscribing, liking
this video and leaving a comment.
This really helps my channel and allows me to create more educational and fun videos
for you.
Troubles with limiting work-in-progress Many teams and organizations without proper
understanding of the Kanban approach stop after implementing the very first rule: visualize
workflow.
This one is fairly easy, isn’t it?
Practically any project management tool has a “Kanban” board integrated in it.
So once we have the workflow visualized, we need to go to rule two and limit work-in-progress.
Alas, this is where the trouble usually comes in.
Many teams are struggling to limit how much work they have in progress at any given time.
Why?
Well, because there are always changes in priorities, something new coming that is absolutely
urgent and has to be done yesterday, then there are usually dependencies on all the
levels that stop teams’ from progressing.
So what happens is that the team gets stuck, and instead of working on getting unstuck,
they just take the next work item in, completely blowing off their work-in-progress limits.
“We can’t limit the work because we have lots of priorities”…
But here’s the thing - the whole purpose of the Kanban method is to identify those
bottlenecks and work on removing them.
And the only way to do it is to fully follow the work-in-progress limit rule.
There is an amazing business novel called “The Goal” by Eliyahu M. Goldratt and
Jeff Cox that I highly recommend you read to understand these systems better in practice
example.
This is another book you can find in the recommended section in my store.
Metrics to collect Rule number three is also difficult to implement
as it requires extra time to be spent on collecting and reporting new metrics.
And to have proper metrics, your workflow and Kanban board has to be updated regularly
to reflect the most recent information, otherwise, your metrics will be skewed.
A little quote from my reference book: …Kanban needs to report slightly different
metrics than you may be used to…
Kanban’s continuous-flow system means that we are less interested in reporting on whether
a project is “on-time” or whether a specific plan is being followed.
What’s important is to show: that the Kanban system is predictable and is operating as
designed, that the organization exhibits business agility, that there is a focus on flow, and
that there is a clear development of continuous improvement.
A few examples of the metrics to collect and report are Lead and Cycle Time, Throughput,
Flow Efficiency, Failure Load, Issues & Blocked Work Items.
Cumulative Flow Diagram is a great tool to implement here as well.
As you can see, there are lots of new things that need to be introduced and tracked as
part of your Kanban implementation Not only that, these metrics need to be reviewed
regularly and used in making decisions.
That’s one more task to add to your Kanban implementation.
Make Process Policies Explicit Oooouwwww, I love this one.
What does it mean to make process policies explicit?
It’s about creating transparency around your workflow and processes which will include
creating alignment across teams and departments, documenting them, and actually following them.
Have you ever asked someone how a certain process works in an organization?
How many times have you received a clear answer that describes those processes step-by-step?
And how many times this description actually matched how it was done in the company in
real-life?
As organizations grow, it is becoming more and more difficult to understand the processes.
Often they become so complex, that no one actually knows how it works.
When you decide to implement Kanban, you will need to get to an agreement and document those
policies and processes.
Example?
Say, the process for a new feature request: where is it documented, who approves, it,
what are the prioritization criteria, who has the final say, and more.
What about your support and defect management processes?
This is another rule I find very difficult for many teams to implement as it requires
them to spend additional time at the beginning to make it transparent and create alignment
across the organization.
And, of course, to follow through with it later on.
Recognize Improvement Opportunities This one is for those who think retrospectives
are a waste of time.
You technically still have them in Kanban.
Kanban is closely associated with kaizen culture.
‘Kaizen’ in Japanese literally means “continuous improvement”.
The whole point is to actively inspect and adapt your work and look for ways to make
it more effective and efficient.
So if your team is trying to run away from having to do retrospectives every sprint,
here is the downer - you still need to do it in Kanban if you want it to be successful.
It’s just done in a different way.
So, we’ve seen that Kanban is not simply a board with columns representing your workflow.
There is much more to that system and if you decided to move towards it, you’ll need
to work on it the same as you would on implementing any other system.
Kanban can be extremely beneficial to any Agile team.
And yes, a Scrum team can use it on top of running Sprints as well.
As of posting of this video, I am working on a practical guide that walks you through
a simple Kanban implementation for your team step-by-step.
Subscribe to my newsletter to get notified and get access to exclusive launch offers
for when the guide comes out.
To summarize, Kanban requires the implementation of five core properties to be successful:
1.
Visualizing workflow, 2.
Limiting Work-in-Progress, 3.
Measuring and Managing Flow, 4.
Making Process Policies Explicit, and 5.
Recognizing Improvement Opportunities.
This, of course, is a very simplified explanation of the Kanban method, so I highly encourage
you to read more about it.
The two books I mentioned in the video are “Kanban: Successful Evolutionary Change
for Your Technology Business” by David J. Anderson and “The Goal” by Eliyahu M.
Goldratt and Jeff Cox.
You can find both of them in my recommended reading section at shop.scrummastered.com
Thank you for watching this video.
I hope to see you next time!
Cheers and Scrum on