Yes, sure. I think you are right, that it is actually important to stress that Kanban is nothing but a change method. So all you get is a set of principles that would help you change and optimize flow in your system over time. So as you said you do not get the practices, roles and stuff like that. We do however, have some emergent behaviors that I also deal with in the book, and we actually try to give people some easy steps to try to approach the Kanban method in a way where it is not just the abstracts principles but where we also have some emergent behaviors. And you can learn from what other teams have adopted in terms of practices, and ways to measuring flow and stuff like that.
I think most often it has to do with two things: like either you have a high level of specialization within the team that makes it very hard to act as a cross functional Scrum team. Or you might actually have people handling a lot of maintenance or operation. And third, actually we also deal with a lot of very, very mature Agile teams looking for some leverage in increasing their performance and their way of being Agile even further. So, it usually falls between one of those three groups.
I think that a lot of teams wanting to transfer to a more continuous delivery kind of approach to Agile see Kanban as an obvious fit because Kanban will actually make it possible for you to track your entire workflow. And I think that is one of the very great values of Kanban that you suddenly start to look at the entire software delivery system where people have tended in Agile to just focus a lot on just the development team. And one of the key principles of Kanban is that you are supposed to visualize your entire workflow. So, that means everything from a vaugue idea until it’s actually released into production. From a bug is pointed out by some user until that bug is fixed and it’s all the way there. So that is a key strategy in Kanban that you actually look at the entire delivery system. And that is why it’s such good fit for things like continuous delivery where you really want the entire deployment pipeline to be fully integrated.
Yes, it actually doesn’t take that much work. The good thing about Kanban is that it just says from the beginning change nothing. Try to visualize your flow, try to look at your system, and then you can start working in terms of optimizing it. But the first principle is just to visualize your workflow and get to understand how your current system is working. So there is a big tendency to people wanting to optimize everything in the very initial phase. And what we actually tend to recommend is that you look at your entire system and then from the knowledge you get from actually visualizing workflow, you proceed from there. So, you actually spend some time understanding how your current system is working before trying to optimize it.
What we found to be quite difficult though for some people is actually just visualizing their existing system without changing anything. Maybe they’re dealing with things in a very complicated way but we’ve also seen teams that have actually been afraid wanting to actually understand their current flow simply because they know there are things in there that are really, really broken and they would rather not expose that to the outside world. And that is where you need to start. Like before even talking about Kanban you’ve got some things to fix before even going that far.
6. You talk about strategically aligned Agility. Can you kind of explain what that is?
Yes, the reason why I mentioned that, I think it’s actually in my bio, is that I found that a lot of teams, organizations, individuals struggle with the fact that they haven’t really gotten to the point where Agile is a language of the overall business strategy. So you’ll find either top management not quite understanding the effect of Agile, you’ll see people actually within the organization working against each other because they simply got different frameworks of how they understand the system.
And if you haven’t managed to actually align Agile with your overall business strategy, if you haven’t had the chance to get to coach management and maybe even top management as well, in understanding what these things actually mean then you’ll find yourself having a hard time doing what I call "plug in Agile" - where you think Agile is something you can do at the execution level and then by some magic the rest of the organization will follow. It just doesn’t happen that way. And we find that teams are able to improve much more and much faster if they are able to actually align Agile all the way with the organizational strategy.
If you look at it from a scientific point of view or at least a mathematic point of view, Little’s Law states, your cycle time through the system is your current work in progress divided by the throughput in some unit of time. So obviously if you’ve got a lot of work in progress in there then actually your cycle time is going to be very low. And we see that just in a general transition from waterfall to Scrum or traditional Agile approaches that what you actually do there is that you limit your work in progress. Any Scrum team will start up by saying: "Ok, we will only work on this piece of the system during our sprint, we will deliver this piece of functionality within a two week sprint and then it’s out the door". So actually what Scrum does initially is exactly the same thing. Scrum will state that you have to limit your work in progress to two weeks of work. And that’s much the same as we do in a Kanban system.
There’s nothing in Kanban stating that you cannot do Scrum. So Kanban is just a way of visualizing your value chain, getting it up there, having all work visible, and from there you start to approach actually minimizing work in progress. And that’s where we have a different strategy because a regular Scrum team will limit their work in progress on a sprint level, where a Kanban team will actually limit their work in progress right down to the individual stages. And that gives you some huge benefits since you are very, very, clearly able to see where our bottle necks are starting to form. What is our current status on the individual items?
Are we actually just building up inventories someplace in the system because we can’t get things out the door? So where Scrum tends to focus on a sprint level, a Kanban system will focus much more on the individual item flowing through the system.
I think that all teams would benefit from using a lot of the XP practices, and there certainly are a lot of Agile methods out there that you can use on the Kanban framework simply because Kanban does not state how you should work in your system. It just states how you should approach optimizing your system. And a lot of teams have found Scrum to be hugely beneficial in their initial Agile transition but that does not mean they cannot adopt Kanban principles at the same time. And maybe they will even start to see things that you would not see just using a traditional Scrum approach. Maybe you can even optimize your system even further, so once you’ve actually managed to get down to two or one week sprints maybe you’ll start doing more continuous flow based approach, maybe you’ll start focusing more on actually releasing the individual item and suddenly you’ll find yourself doing actual continuous deployment where every single line of code is pushed into production.
I think no matter what approach you are using, if you are using pure waterfall, if you are using a Scrum based approach, if you are using XP, pretty much all seem to benefit from actually tracking their work in progress using a cumulative flow diagram - simply because a flow diagram will give you much more information. It will give you all the information of a traditional burn down plus you’ll be able to actually see how work is progressing through the system on the individual status. So you will be able to see bottlenecks forming very easily and very clearly.
If you put your cumulative flow diagram right next to your Kanban board or whatever strategy you are using, it will be very clear to everybody how the system is performing right at this moment. And then you get the history part as well, where you will actually see: Are things arriving faster than we are able to process them? Where are we building bottlenecks in our system? What is our average cycle time? How much work in progress do we have at any point in time? And you’ll be able to track over time: So, how is this system as a whole is performing? Are we performing in a reliable way? Is everything fluctuating a lot? What is really, really happening? And no matter what kind of approach you are using, I find that over time people come to appreciate these metrics a lot.
10. So are there any other metrics we should be gathering as we set this up?
As always, you should be very careful of not doing this context based, so of course this will depend on the individual team. If you have no clue where to start I always suggest that people choose two or three among the four I mentioned in the book which is: the cumulative flow diagram, of course, it’s cycle time, it’s defect rate, and it’s blocked items. And actually, I find that blocked items are something that people usually either misunderstand or they do not track it at all. And actually, I’ve experienced firsthand that a team’s ability to resolve blocked items quickly and effectively actually says a lot about the team’s ability to perform in general. So if over time you can get to a point where fewer items are blocked, and items are blocked for a shorter period of time, and if you actually track that evolvement during the development phase, that’s for a lot of teams a very very beneficial metric.
Yes. Actually a lot of people resolve the blocked items problem by just having some place on the board or in the room, where they will just place them. I usually actually tend to advice against that. I would like to see a blocked item sitting there actually blocking the flow to make it visible for everybody that you’ve got a problem here. And if you find yourself having to expend your work in progress limits, simply making them bigger because you’ve got a lot of blocked items in there, it will force you to make a conscious decision about that instead of having somewhere where it starts to pile up and you can kind of ignore them at all time until somebody comes in the room screaming that you promised to deliver this three weeks ago.
Actually, I have only given the one talk about Agile delivery, but I found two things that have been general for this conference that a lot of people are starting to discuss value suddenly. So are we actually producing value instead of just producing features? And the other is feedback. And that was a big part of my own presentation that I find myself focusing a lot more lately on the actual value production. So how quickly can we actually get real business value out there and how quickly can we integrate that feedback? And actually I have tried different strategies lately and so in organizations where I told them try to get to the point where you can deploy real software, with real business value, to real users and get the feedback immediately after that. And you can keep your traditional management structures if you think that’s beneficial but if you can just start by focusing on this very point you are not going to be in such a bad place. And you’ve taken a big step on your journey to become a more Agile and Lean organization.
Yes, again context is an important word here and of course that differs a lot. I think I’ve found people in general to have become much more creative in obtaining feedback lately. Like back, just a few years ago, people would insist that you have to do this face-to-face, which made the transaction cost to user, a word from Lean, a lot higher. And suddenly you’ll find teams knowing that since the business is on the other side of the country, if they have to get the business there every single time they want feedback they are not going to get it as often. And suddenly you’ve got people setting up communicators, sharing desktops, actually having real users sitting there, clinging on the same screen watching them actually use the system. And I also found another thing to be something that people are suddenly becoming aware of that you as a developer need to understand the business.
So we’ve had quite a big success getting developers actually out there watching users. And if I could I would insist that every single project kick off should start with all people from the development organization having to spend a day at the customer side, actually seeing real users try to use the software they are producing or similar software simply because it makes it a lot better and easier for them if they actually understand the situation there, developing software for.
Actually, I found that to be still one of my very best experiences implementing Kanban. We were working with two development teams on a particular project and we wanted to improve our Agile practices even more. And we wanted to try to see could we possibly gain more insight into the entire value chain on this project instead of focusing so much on the development part. Because already before adopting Kanban it was pretty clear that the problem was not only in IT, it was as much in the product owner team, integrating with the test team, actually getting things all the way out through the door. And one of the very first things we found was that when we set up that Kanban board, when we actually got the work there, we got the WIP limits in place, suddenly the team started owning the process much more than they ever had when we were working in a Scrum inspired manner. So suddenly you would see individual team members discussing with the product owner or with the tester the amount of work in progress they would allow in a specific state. Suddenly you had team members that have never been interested in Scrum and thought of it just like some kind of framework they were forced to use, suddenly they stood there and started using words like flow and how well we are approaching fixing blocked items.
And suddenly you would see a whole development organization changing to not just seeing themselves as a developer but seeing themselves as somebody who is responsible for actually getting work all the way through the system. Actually one of the very first things they ended up deciding was that each - rotating among developers they would spend time actually doing product owner work, because it turns out that one of the reasons why the product owners were not able to have stories ready for the team in appropriate detail to secure flow across the board, was that the product owner was stressed handling a lot of work that was not related to actually user stories specification and use case writing. So developers decided that each morning two developers in total would spend time helping the product owner team with whatever they could. Just to optimize flow across the board instead of having as they have done before just blaming the product owners for not being able to do things the way they expected them to. So, that was a big change for me.
15. Were there kind of measurable results coming out of that project?
Yes, definitely. We had some monitoring systems in place where we started seeing, first of all the amount of bugs in the system were quickly decreasing, simply because we were starting to visualize that in a much more clear manner. And it turned out pretty quickly that we could work with flow like we have never been able to do before when we were just using a Scrum based approach and suddenly things were actually being finished. And that’s not to blame Scrum for being a bad process, because I love Scrum and I think it’s a great way of starting with Agile development. But for these particular teams, they found out that they had a huge problem in actually getting things done. And suddenly they were starting to see the benefits of actually getting things through before staring new work. And they would start to prioritize, actually finishing work before starting new work. And be much less feature driven and much more value driven.
So that’s a huge benefit as well. So, in general just the fact that they started to own the process, and the individual developer was suddenly interested in the amount of WIP limits and different stages of the board and being much more value driven, getting the big picture. Which I find to be extremely important that people actually take an interest in the entire value chain and stop seeing themselves as a development or a test, or on the product owner silo.
I think that one aspect to really focus on when you are talking Lean, when you are talking flow based systems, is that people not experienced with it tend to see it as a kind of a manufacturing approach in software. And it just turns out that it’s not true. That is not in anyway how the individual in the system will perceive themself. Actually, they will perceive themselves as somebody that is operating the system. So actually the whole flow based approach makes people take much more interest in continuous improvement. Suddenly they become much more interested in the actual feedback loops because they can see the effect the feedback loops very very visually on the board. So I find that people arguing that it’s more of a manufacturing approach seem to just be people that haven’t experienced it first hand.