Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Category: kanban

  • Ball Flow Game

    If you visit Software Project Management on occasions you likely know that 100% utilization is a myth. A nice and simple experiment that shows impact of full utilization on effectiveness and at the same time presents value of WIP limits is a ball flow game.

    The rules are simple:

    • You get a group of people to process 20 balls.
    • Processing is just throwing a ball from one person to another.
    • The person who starts throwing the balls in is also a person who is last to touch the ball.
    • The ball should have at least minimal air time when changing its woner, i.e. it should be thrown not passed.
    • Everyone in the group should touch each ball.
    • The ball shouldn’t be thrown to any of two closest persons (the one on the left and the one on the right).

    The rest is pretty much team’s self-organization.

    The goal of the team is to process 20 balls as fast as possible.

    The team can arrange themselves in a way that is convenient for them, which most of the time means standing in circle. Then they set up the sequence: who is throwing to whom. And then, the fun begins.

    Following data is from the game I run with a group of 10 people.

    The first approach was no WIP limits at all, meaning that balls were thrown in as soon as the first person was idle. With this approach it’s not even the data that is most interesting but the looks of what’s happening. Balls are flying all over the place. People barely cope with coordination of passing the ball to the next person and coming back to the previous one to receive the next ball. Pretty often balls are dropped and left forgotten as new balls are waiting. It’s all chaos.

    And the clock is ticking.

    Simply by looking at the situation you may safely guess it is suboptimal organization. However it is how many teams still work these days. We decided to use it as a reference point.

    Cycle time for each processed ball looked like this.

    One thing is that it could be as much as 32 seconds to process a ball. Almost 3 seconds per person for something as simple as passing a ball. Another thing is that variability of cycle times was high – anything between 13 and 32 seconds meant that worst case scenario was 2,5 times longer than the best case. This left us in a place when we were hardly predictable in terms of time needed to process the next ball.

    One quick look at Cumulative Flow Diagram (measures were taken every 10 seconds) will show one of typical problems I see in teams: as the project goes further cycle times become worse (green part of the diagram becomes wider).

    Processing time of all the balls was 83 seconds.

    With the second round the team decided to limit work in progress. With no idea what WIP limit they should go they decided to try WIP limit of 5 balls, for the team of 10 people. Considering that processing time was very short – no one was expected to do anything special with balls – the crucial thing were handoffs. In ideal case each handoff requires 2 people, one passing the ball and another one receiving it, thus limit of 5. It also meant that for the processing time one of every two persons will be idle.

    First, the whole task was done in 63 seconds. Almost 25% improvement.

    Second, the way the group worked looked way better. Little chaos, no dropped balls, no collisions in flight, etc.

    Third, cycle time went down and became more predictable. This time it was anything between 9 and 15 seconds. Yay! We shortened our time to market.

    Cumulative Flow Diagram also looked better. Steeper curves mean better throughput and green part width (cycle times) are kept under control.

    With such good results a natural consequence is a discussion about the optimum. We know that WIP limit of 5 is better than infinity but should we test WIP limit of 4 or rather of 6? The group decided to go with WIP limit of 4 in round 3 and results were interesting.

    The end to end time was 61 seconds. Basically no change at all as I could potentially address 2 second difference to fluency with throwing balls.

    Was it simply the same as in round 2 then? Pretty much the opposite.

    The most interesting thing was what happened with cycle times.

    There was only one ball that was processed faster than in 9 seconds, which was the best result in round 2. However this time variability of cycle times was reduced hugely (8 to 10 seconds). The team became highly predictable.

    Considering that we were processing identical tasks, this was something we should expect, but it didn’t happen unless we introduced strict WIP limit. By the way, this predictability is neatly shown in CFD, which now looks very stable.

    There’s one more thing hidden here too. With more strict WIP limit we introduced more slack time. This time, even in ideal situation when every ball is passed we still have two people idle. Yet the end effect is still the same. The difference is that this additional slack time can be invested to improve the process or automate the part of it so eventually the team becomes even more effective.

    In short: considering that we have the same end to end team performance more strict WIP limit is better than looser one as it sets us on a better path toward improvement.

    A natural next step would be probably trying WIP limit of 3. However having chance to play in controlled environment the team did an experiment with limit of 2 to see what would happen.

    Basing on results so far outcome of round 4 could be somewhat predictable. Best cycle times went down even more with top result of 6 seconds.

    However it came at cost of bigger variability as worst cycle time remained the same (10 seconds). We drove predictability down.

    Cumulative Flow Diagram, again, looked neatly – nothing to worry about.

    From CFD you can guess the key statistic here. Overall processing time went up. 85 seconds. A tiny bit worse than without limits at all.

    However, again, comparing only rounds 1 and 4 I believe that the one with WIP limits is a way to go. Considering that the whole task was completed in the same time we had a lot of slack time that could be invested in improvements, there was less pressure and significantly less chaos. In other words: short-term results are similar, long-term ones should be better with WIP limits.

    Now, why am I telling you all this? First, to show you the mechanism. You should be doing exactly the same thing with your real Kanban implementation tweaking WIP limits and measuring outcome of these changes to find local optimum.

    Second, there’s underlying assumption made here. One that is super-important. You need to measure how you’re doing otherwise you won’t be able to tell whether after changes you are doing any better than you’ve done before. If you don’t have meaningful measures already in use then start with this, before you play with your WIP limits.

    And now that you asked, no, I don’t consider your gut feeling “a measure.”

    Big thanks to Karl Scotland, who I learned the idea from. If you want to play the game I strongly recommend using spreadsheets Karl kindly shared.

  • Slack Time

    It often comes to me as a surprise that people misunderstand different concepts or definitions that we use in our writings or presentations. Actually, it shouldn’t. I have to remind myself over and over again that I do exactly the same thing – I start playing with different ideas and only eventually learn that I misused or misunderstood some definitions.

    Anyway, the context that brought me to these thoughts is slack time. When talking about WIP (Work In Progress) limits we often mention slack time and usually even (vaguely) point what slack time is for. However, basing on different conversations I’m having, people rarely get what slack time is when they first hear about it.

    How Slack Time Works

    Let’s start with basics. Imagine a very simple development process: we have backlog which we draw features from, then development and testing and after that we are done. For my convenience I split development stage into two sub-columns: ongoing and done, so we know which task is still under development and which can be pulled to testing.

    As you might notice we also have WIP limits that will trigger slack time in our process.

    In ideal situation a quality engineer would pull tasks from development done sub-column as soon as anything pops there and even if it won’t happen immediately we have a buffer for one feature in development (two developers and WIP limit of 3 in the column). I have a surprise for you: we don’t live in ideal world and ideal situations happen pretty rarely.

    There are two scenarios possible here. One is that developers won’t be able to feed quality engineer with features at rate high enough to keep him busy.

    In this situation quality engineer is idle. He just face slack time. He can’t pull another task from queue because it is empty so he needs to find a different task. He may try to help developers with their work (if possible) but he may also learn something new using slack time to sharpen his saw. He can also use this time to automate some of his work (and believe me: vast majority apps I saw would benefit heavily from automating some tests) so that the whole process is more effective in future.

    Another situation, and the one that is more interesting, would happen when the quality engineer is a bottleneck. It means that he can’t deal with features built by developers at the same rate they are flowing through development.

    In this case one of developers who just finished working on a feature has slack time. It is possible that another will soon finish his feature as well and both will be in the same situation. And again, they can use slack time, e.g. to do some refactoring or learn something new or help quality engineer doing his work. However, probably most valuable and at the same moment most desirable thing to do would be finding a way to improve the part of the process that is bottlenecked; here: testing.

    The effect might be some kind of automated test suite that reduces effort needed to test any single feature or maybe improvements in code quality policies that result in fewer bugs, thus less rework for each feature.

    What Slack Time Is

    By this point you should already understand when slack time happens and what it is roughly. Let’s try to pack it into some kind of definition then. Slack time happens when any team member for whatever reasons restrains to do the task they would typically do, e.g. a developer doesn’t develop new features. It is used to do other tasks, that usually result in improvements of all sorts.

    That’s a bit simplified definition of course. You may ask what if a developer has a learning task every once in a while put into their queue. Well, I would dare to say that it is just planning for learning and not introducing slack time, but we don’t deal here with strict definitions so I could totally agree if others interpret it differently.

    Note: we went through two different root causes for slack time emergence. One is when there aren’t enough tasks to feed one of roles. This is something that happens pretty naturally in many teams. If one of roles further downstream is able to process more tasks than roles upstream (in other words: bottleneck is somewhere upstream) they will naturally have moments of slack time.

    Some people may argue that this is not slack time and again I can perfectly accept such point of view. However, for me it suits the definition.

    Another root cause is when we intentionally limit throughput upstream to protect bottleneck that is somewhere downstream. This case is way more interesting for a couple of reasons. First, it doesn’t happen naturally so conscious action is required to introduce such slack time. Second, for many people introducing slack time there is counterintuitive, thus they resist to do it.

    A result of not limiting throughput before a bottleneck is a huge queue of work waiting for availability of bottleneck role, which makes the whole thing only worse. The team has to juggle more tasks at the same time introducing a lot of context switching and crippling own productivity.

    Nature of Slack Time

    One of specific properties of slack time is its emergent nature. We don’t carefully plan slack time as we don’t exactly know when exactly it’s going to happen. It appears whenever our flow becomes unbalanced, which sometimes means all the time.

    You can say that slack time is some sort of flow self-balancing mechanism. Whenever team members happen to have this time while they don’t do regular work they are encouraged to do something that improves the flow in future, usually balancing it better. At the same time the more unbalanced the team and the flow are the more slack time there will be.

    Remember though that in software development business our flow won’t be stable. Even when you reach equilibrium in one moment it will likely be ruined a moment later when you’re dealing with a special case, be it a non-standard feature, a team member taking a few days off or whatever else.

    It means that even in environment which is almost perfectly balanced slack time will be happening. Even better, such state means that you don’t have a fixed bottleneck – it will be flowing between two or more roles, meaning that every role in the team would have slack time on occasions.

    Another specific of slack time is that usually we aren’t told what exactly we should do in it. It doesn’t have to be that way in each and every case, however since slack time itself isn’t planned we can hardly plan to complete something during slack time in a reasonable manner. On the other hand there may be some guidance which activities are more desirable.

    It means that slack time seems to be a tool for teams that trust each other and are trusted by their leaders. It is true as slack time, thanks to its emergent nature, can’t be managed in command and control manner.

    However, for those of you who are control freaks, considering you have sensible WIP limits even if your people do nothing during slack time (and I mean virtually nothing) it should still have positive impact on team’s productivity. This is because 100% utilization is a myth. Note that in this case you lose self-balancing property of slack time – you don’t improve your flow. You just keep your efficiency on a bit higher level than you would otherwise.

    What Slack Time Is For

    I’ve already mentioned a few ideas what to use slack time for. Let’s try to generalize a bit here. Slack time, by definition, isn’t dedicated to do regular stuff, whatever “regular stuff” might mean in your case. If you think about examples I used and try to find a common part these all are important things: learning, improving team’s toolbox, balancing the flow or improving quality.

    At the same time none of them seems to be urgent. It is usually more urgent to complete a project on time (or as soon as possible) than to tweak tools team uses or introduce new quality policies.

    In short, slack time is for important and not urgent stuff. If something is urgent it likely is in the plan anyway and if something isn’t important what’s the point of doing it.

    If you’re interested in more elaborate version of that please read the post: what slack time is for.

    Other Flavors of Slack Time

    When talking about slack time it is easy to notice that there is some ambiguity around this concept. Why unplanned slack time is OK and planned time slots dedicated to the very same tasks are not?

    Personally I’m far from being orthodox over definitions. For me the key is understanding why and how slack time works and why it is valuable, so you can achieve similar effects using adjusted or completely different methods.

    Considering that a general goal of slack time is improvement you can introduce dedicated time slots for that or include improvement features in your backlog. The effect might be pretty similar and you may feel that you have more control over a process.

    What more, you may want to plan for improvement activities not leaving it to the random nature of slack time. Again, that’s fine for me even though personally I wouldn’t call that slack time.

    We may argue over naming, whether something already can be called slack time or not, but I’m not going to die for that really. Especially if we agree on purpose of these activities.

    I hope this helps to understand the concept of slack time – what it is, how it works and why it is valuable. Should you have any ideas what is missing or wrong here please leave a comment below. I’ll update the post.

  • Pitfalls of Kanban Series: Abusing WIP Limits

    This is another problem that comes in different colors. It’s either simple acceptation of WIP limits violation, no matter how commonly it happens, or setting WIP limits so high that a team never gets even close.

    Now, I don’t say that violating WIP limits should be forbidden at all. Pretty far from that. I just say that if it is a common thing it basically means that you have no limits at all. The same is with too loose WIP limits – it means no limits at all. It’s always a matter of balance: when and why you accept to violate WIP limits.

    I point this issue high on my list as basically not using WIP limits means that you voluntarily resign from the biggest gain you can get out of introducing Kanban – the rate of improvements and changes you introduce in the team is way slower. It is so because WIP limits are a mechanism that incentivize people to change their behavior (they would normally do one thing but they can’t as it would mean violating WIP limit so they do another). Without changing behaviors most changes are quickly rolled back to what people know and feel comfortable with.

    When you start thinking about the issue it may be a very complex one and as such may be approached from different directions. One thing which is pretty obvious: make abusing WIP limits painful. I don’t mean here physically painful of course, but add enough hassle that people would think twice before doing it.

    A neat trick I used was that every time someone wanted to violate WIP limit they had to organize a meeting with a team and tell everyone why they’re doing so. First, organizing a meeting, even an ad-hoc one, takes some time which you may use to rethink whether this is really needed. Second, you want to have pretty damn good reason to share as everyone will like to know why you’re breaking the rule. Actually, if you could come up with good argument you probably had a point in violating a limit anyway. You can use other similar methods as well, but basically the goal would be the same – to make abusing limits reasonably uncomfortable.

    Different approach will be needed to deal with unreasonably high WIP limits. A thing that may come handy in such case is measuring WIP over a period of time. It is an interesting observation but some teams believe that they actually have more WIP than they really do. In such case once you’ve measured your work in progress you shouldn’t be scared of limits. Even more, your initial decisions on WIP limits will be informed.

    Another idea is to reduce WIP limits periodically to see what will happen. Eventually the team would find their sweet spots, where limits are tight enough so that they’re incentivized to improve but loose enough that the inconvenience of having WIP limits is acceptable. It is like playing ball flow game, but on the real work done in a real team.

    Check the other pitfalls of Kanban as well.

    Advertisement: Infragistics® NetAdvantage® for Windows Forms provides developers with flexible, advanced controls to rapidly build high-fidelity Windows Forms application user interfaces “IN” style with the look and feel of Microsoft® Office® 2010 and Windows® 7. It Features every control developers need to deliver superior user experiences with stability, performance and robustness.

     

  • The Project Portfolio Kanban Story: Better Board

    When applying Kanban on project portfolio level you’re dealing with different challenges than in case of standard Kanban implementation on a team level (if there even is such a thing). Both the flow dynamics and task granularity is very different, thus you need to focus on different aspects when designing Kanban board.

    This is basically why typical Kanban board design will often be suboptimal.

    Portfolio Kanban Board 2

    At the same time the biggest challenge you face on project portfolio level is defining and applying WIP limits. For the time being my thoughts on a subject are that depending on a specific environment teams would be choosing very different measures to manage WIP on portfolio level. However, as we as a community still lack experience from addressing different scenarios I’ll focus on the path I’m following. After all the story format I chose requires that.

    In my case the most reasonable thing I was able to come up with was a number of people involved in project work. Unfortunately the scale of the team (more than 130 people) didn’t allow me to use straightforward approach and scale up WIP limits with numbers.

    Instead of continuing my struggle to find a perfect measure that suits the current board I decided to redesign it completely.

    Whenever you read about Kanban you learn that it is an evolutionary approach. Kaizen and all the stuff. However one advice I have on designing a Kanban board in general is that when you start running circles with board evolution and see little or no improvements throw the whole board out and start from scratch. From one point of view it can be considered a revolution (kaikaku) but from another: you don’t really change your way of working, you just try to visualize it differently.

    Either way I took my own advice and started from a clean whiteboard. I also remembered another advice: not to stick to standard board designs. This is what I ended up with.

    First, there is no value stream or process in a way we understand it on a team level. Since the flow of index cards wasn’t dynamic I decided this isn’t information I should focus on that much.

    Second, on horizontal axis, instead of process there is a time line (monthly granularity). As variability of project sizes is huge I decided I need some sort of time boxes which I measure WIP against. With very few small engagements, ones that take us less than a few weeks, monthly time boxes looked reasonable.

    Third, I created swim lanes for teams. We don’t have 130 generic engineers, or Average Full-Time Equivalents, or whatever other inhumane label you can think of. We have teams that we strive to protect and teams do have specializations. It means the context of a team is very important and if it is important it goes to the board, thus swim lanes.

    Fourth, having such board construction I had to change my approach to index cards. Instead of having a single index card representing single project I ended up with territory-driven approach. A project covers a territory both in terms of team(s) and time. Looking at index cards with a project name you can instantly guess which team is working on the project and how long it’s going to take them. And the best part: a size of index card in any given month represents roughly how big part of a team would be involved in work on a project. This way we can easily show a few smaller projects as well as on big or any combination of those two.

    Fifth, as one of Kanban base concepts is pull it is represented by backlog area – green cards on the left side of the board. These are projects that aren’t yet started. The specific swim lane they are neighboring show preferable team to work on a project. However, it rarely is such a direct dependency: this team will do the project as there is no other one suitable to do the job. Most of the time we assume that another team can build the project too. Each time a project goes into development we decide, at last responsible moment, which team will take it.

    Of course there are some nice additional flavors here as well. Violet and yellow index cards differentiate maintenance projects from new ones. Green card are for projects that aren’t yet started and once they are we switch to yellow. Red index cards represent overrun in projects that are late. As we work on fixed price, fixed time projects we roughly know up front how much time and people we want to invest into a project. When something bad happens and this plan changes we show that. After all we put more attention to challenged projects.

    A simple fact that we are working on fixed time, fixed price projects doesn’t mean our arrangements never change. They do. Any time something changes we just update it on the board, same as we’d do with any other board. We just keep the board updated as other way its value would diminish.

    This Kanban board design definitely tells more than the initial one but I started this whole revolution to deal with WIP limits. What with them?

    Well, there still aren’t explicit WIP limits. However at this moment there are implicit WIP limits and information about them can be pretty easily extracted. Considering that I use territory-driven approach to index cards WIP limit is show by vertical axis of the board. Each team has a limit of one full-sized sticky note (representing whole team) per month which can be split in any way.

    In other words we won’t start another project unless there’s some white space that this project would fit into as white space represents our spare capabilities. Actually, it may be a bit of simplification as on rare occasions there are project we just start, no matter what. But even then we either can make such project fit the white space in a reasonable way or we need to make some more white space for it.

    Even though such WIP limits aren’t explicit, after some time of working with the board I can tell you they do the job. They do, not only in pulling new projects into development but also, and more importantly, in long-term planning as we have visibility a year ahead and can confront our capabilities with planned sales etc.

    With this board, for the first time from the beginning of my journey with project portfolio Kanban I felt satisfied.

    See how we come up to this point – read the whole story.

    Advertisement: Infragistics® NetAdvantage® for Windows Phone gives you rich, innovative mobile UI controls to build high-end mobile user experiences for Microsoft® Windows Phone®. Their high performance, eye-catching data visualizations, mobile form factor optimization, touch gesture support, and alignment with Metro usability guidelines take your social media connected mobile applications to the next level.

     

  • Pitfalls of Kanban Series: Kanban Board Not Up To Date

    This is something I see very often and at least in a couple of flavors. The problem can be a team member who haven’t really bought the whole thing and see little value in updating all these stickies on the board every time something changes. It can be more a whole team’s thing – Kanban implementation has its leader, or a champion, and when they have a day off suddenly the board starts to deteriorate as people don’t feel pushed or obligated to update anything.

    On a side note: I would put it on the same shelf in my mind as when Scrum teams don’t do daily stand-ups when a leader is out.

    This issue is tricky as it doesn’t seem to be much harmful but, if tolerated, it basically renders the whole Kanban implementation useless. The first step we do with Kanban is we visualize all the work. Basing on that we make informed project decisions every single day (with help of WIP limits, explicit policies etc.)

    Now, if the board isn’t up to date these decisions are made on a basis which doesn’t reflect the reality. We may violate the limits or cease to help a colleague with a critical issue not even knowing about that. This way, not only do we make suboptimal everyday decisions but we also cripple the biggest power of Kanban – its improvement mechanism.

    Potential solutions of this problem depend on what flavor of the problem you face. If it is a single person you can work with them to convince them there is value in updated board for them too. You can also ask them to give everyone in the team a credit of trust and give a method a try for a few weeks or a couple of months. It usually is enough to turn them back into the light side of the force.

    However, in the worst case scenario you last resort may be setting up a proxy who updates the board instead of a problematic person. It will be a hit on team’s morale (“we have someone who is treated differently”) but it’s a tradeoff some teams are willing to make. Especially that, eventually such person either changes their behavior or leaves a team.

    If we think of a whole group not updating the board it is a signal that there’s little or no buy-in for the idea. Unless this can be changed most likely the Kanban implementation is doomed.

    The way of getting team’s buy-in will of course depend on people. However, I find it pretty successful to ask the group to give the method a try. Of course considering there is a problem I believe Kanban can help to fix quickly. Thanks to simplicity of Kanban it doesn’t cost much hassle to “try it” and pretty often first results are rather quick as almost always teams have some low-hanging fruits in terms of improvements they can make – quick wins they just aren’t aware of.

    Read the whole Pitfalls of Kanban series.

  • Pitfalls of Kanban Series

    One of tricks I sometimes use when coaching teams that are starting with Kanban is I tell them why they shouldn’t adopt it. Challenging the team in such way helps me to indicate whether there is buy in as this is crucial thing to deal with issues the team will face.

    I do that knowing that, thanks to its flexibility, Kanban is pretty vulnerable and even a single team member may cripple Kanban implementation, thus vastly reducing value the whole team gets from adopting the method. Besides getting buy in having knowledge of these potential vulnerabilities can be a game-changer as then the team can avoid them.

    This was the idea which stood behind my session titled Kanban weak spots which I presented at Lean Kanban Central Europe last year.

    Recently David Anderson started an email discussion that inspired me to write a follow-up on the subject. As I was typing an answer to David’s questions I realized that it would be worthwhile to discuss each and every pitfall in details, covering reasons why it may appear and tools that can be used to deal with it.

    And this is how the idea of this series was born. You can expect a number of posts covering just a single Kanban weak spot. The whole list will be gathered here:

  • The Project Portfolio Kanban Story: Why Standard Board Design Is Not a Good Choice

    When I was starting my journey with Kanban on project portfolio level I based on a classic board design I knew from my work with Kanban within project teams. I basically tried to map value stream to the board but on a different level.

    The effect was sort of predictable.

    Portfolio Kanban Board 2

    It was also naive.

    The basic strength of such design is it’s very intuitive. Well, at least for these parts of the world that read from left to right. The same way we read the board: whatever is closer to the right edge of the board is closer to completion. The value stream we map may be a bit simplified (as me make it linear) but then it isn’t that much of a problem – after all index cards are flowing through the board pretty smoothly.

    Unless you put on single index cards “tasks” that last a year or more, which is exactly what I have done.

    When you’re looking at very long lasting projects you look for different information than in case of several hour long tasks. It isn’t that important how an index card is flowing through the board. After all you expect it to sit in one place for months. If you find out that the status of the index card has changed a few days late it likely isn’t a problem at all.

    It is way more important, and interesting at the same time, to see teams’ capabilities in terms of undertaking new projects, i.e. how much more we can commit to our clients. Note: we aren’t talking about a single team of 7 (plus or minus 2). What we have here is 100+ people working on a couple dozen different projects concurrently. At this level capabilities are pretty damn difficult to estimate, especially given ever-changing business surroundings.

    This is a huge weakness of the common board design: it doesn’t really help you with estimating free capabilities. It would help if we were able to set reasonable WIP limits on such board. Unfortunately, it is (close to) impossible.

    A number of projects isn’t a good candidate to measure WIP, as projects differ in size hugely. If you use time-boxing you could try using a number of time-boxes as a measure. However in this case you don’t want to have a random team working on thirteenth iteration of a project that was build so far by the other team. With WIP limits measured by the number of iterations you would likely end up this way. Another idea was using money-related measures. This brings a question whether you sell all your work for the same prices. I guess that is true in very few cases and definitely mine is not one of them.

    The longer I thought about it the more often I was coming back to people. I mean a team could start another project if they had some free people who could deal with it in planned/expected time frame. I even thought for a moment of setting base WIP limit around 130 (roughly a number of people working on projects represented on the board) and having each index card to weigh as much as there were people involved in a project at the time. The problem was the hassle needed to manage such board would be horrifying.

    On the other hand measuring WIP in number of teams was way too coarse-grained as we had anything from multiple projects covered by a single team to multiple teams working on a single project.

    All in all I ended up with a belief that, in terms of project portfolio Kanban, standard board design isn’t a good choice. I was ready to redesign the board completely.

    If I piqued your interest read the whole project portfolio Kanban story.

  • How Much Work In Progress Do You Have?

    One of common patterns of adopting Kanban is that teams start just with visualization and, for whatever reasons, resist applying Work In Progress limits at the very beginning. While, and let me stress it, resignation from introducing WIP limits means drawing most of improvement power out of the system I understand that many teams feel safe to start this way.

    If you are in such point, or even a step earlier, when you’re just considering Kanban but haven’t yet started, and you are basically afraid of limits I have a challenge for you. Well, even if you use WIP I have the very same challenge.

    First, think of limits you might want to have.

    Second, measure how the tasks flow through your process. It’s enough to write down the date when you start working on a task and the date when you’re done with it – the difference would give you a cycle time.

    Third, after some time, check how many tasks in progress you really had every day. In other words: check what your WIP was.

    Odds are you will be surprised.

    One of my teams followed the “let’s just start with visualization and we’ll see how it goes” path. We even discussed WIP limits but eventually they weren’t applied. It is a functional team of 4 that juggles tasks which are pretty often blocked by their “clients,” i.e. beyond team’s control. The process, besides backlog and done bucket, is very simple: there’s only one column – ongoing.

    The discussion ended up with the idea of limit of 8, considering there are some rather longish tasks mixed with quite a few short but urgent tasks, e.g. “needs to be done today” sort, and of course there are frequent blockers. In other words rough limits two tasks per person should account for all the potential issues.

    As I’ve mentioned, WIP limits weren’t initially set. Even the WIP limit of 8 looked too scary at that point. After a few months we came back to the discussion. Fortunately, this time we had hard data from a hundred days.

    Guess what the worst WIP was.

    Seven. Over the course of a hundred days there wasn’t a single case that the scary limit of 8 was reached, let alone violated. What more, there were only 5 days where limit was higher than 6. In other words setting the limit of 6 and keeping it would be no sweat. A challenge starts at 5, which sounds very reasonable for such team.

    All of that considering that each and every blocked item was counted within the limit as at the moment the team doesn’t gather the data to show how long a task remains blocked.

    The lesson I got was that we can and should challenge our WIP limits basing on historical data. How often we hit WIP limits. How often we violate them. If it appears that we have enough padding that we barely scratch the ceiling on rare occasions it is a time to discuss reducing WIP limits. After all, it might mean that we are pursuing 100% utilization, which is bad.

    If WIP limits are barely and rarely painful, they aren’t working.

  • The Project Portfolio Kanban Story: First Changes

    Those of you who remember my Kanban Story probably remember how important experimentation mindset was for me since the beginning of my journey with the method. On project portfolio level the only difference was that I was well aware that such attitude is crucial even before I started doing anything at all. In other words I planned to adopt such attitude.

    With this kind of approach you should expect changes in the process and, as a result, changes on Kanban board as well.

    OK, let’s start with what I had on the day one:

    What was wrong with it?

    Well, maybe not really wrong, but it soon appeared I needed more information from the board than I’d already had.

    First thing, which became clear and actually could have been predicted, was that throwing all future projects into a single “planned” bucket was an oversimplification. Actually a planned project was pretty much any project which wasn’t yet signed, meaning that there were still many bad things which could potentially happen before we were 100% sure we would be doing it.

    Soon enough I had two groups of planned projects: these which were still expected to be built in near future and those which were in doubt for whatever reasons. Once I realized it I just added another column to the board. Since it was very unlikely that a project “in doubt” would automatically go into development and most probably it would go back to “planned” stage before, I added the column on the very left and index cards could freely go between “planned” and “in doubt” back and forth as I was learning new facts on the projects.

    Second problem was related with general status of projects. As I needed to pay more attention to challenged projects than to these which were doing perfectly fine this information was crucial to have it at hand. I decided to go with a simple green-yellow-red statuses, meaning respectively that project was going as planned, wasn’t going as planned but changes could be absorbed by project team or agreed upon with clients or wasn’t going as planned and unless something was done we were likely to fail.

    Technically I just grabbed a bunch of color magnets and attached them to all projects in “ongoing” phase. I was changing magnets to different colors whenever a project changed its status according to above definitions. Once I clearly saw which projects are at risk, and I saw that a dozen or more times a day, I could easily ask for more information on a project, look for risk reduction actions, set a higher priority to a project or whatever I felt could help to bring it back to the right track.

    After changes the board slightly changed:

    Portfolio Kanban Board 2

    However that wasn’t all. Third issue I was facing was that I couldn’t tell looking at the board when we were expected to deliver a project. It was super-important information as without knowing the dates it was hard to say whether project was going according to the plan or not. After all without dates I could hardly say I even knew the plan. It was also very difficult to plan future projects as I couldn’t really tell when this or the other team would be free.

    And this is why my index cards started evolving as well. At the very beginning an index card for a project was very simple:

    As process described on the board wouldn’t tell me anything about dates I decided to add this information to index cards. I wrote any key dates we knew for a project. It could be stage deadlines if we had multiple stage deliveries or deadlines for delivery, user acceptance testing and project closure, etc.

    Then, as you may easily guess, these dates started changing, either in controlled or uncontrolled manner. Either way I ended up crossing out the old dates and adding new ones. Despite the fact that index cards started looking a bit cluttered I realized that the fact that dates had changed was important to me as well so decided to keep it this way.

    And then I had all the discussions on budgets. I mean one thing is to deliver on time, another one is to keep a project within budget. So yes, I was having these budget-related chats pretty regularly. Of course I could refer to budgeting application, but then I wanted to work on the data which is up to date. This disqualified the budgeting app as sometimes we had old data there. What more, there was a number of different reasons why we had it this way, be it anything from preserving initial budget estimates to bug in the system.

    Anyway, I ended up writing budgets on index cards. And again, whenever budget was changing I was crossing the old number out and adding a new one.

    A new index card looked like this:

    Besides the initial information, which was project name and team or teams working on a project, I had project status and a sort of notebook for important facts regarding the project (dates, budgets). Why do I say that it was a notebook? Well, after some time handful of index cards looked not-that-clean:

    Anyway, I had the information I needed.

    Of course all these improvements didn’t happen in a single day. It was more of a constant process of small adjustments and tweaks spread over a longer time span.

    There’s also one approach I used, which you may find useful. When I was adding dates or budgets to index notes, I didn’t checked them for each and every project which was on the board already. I just set the policy that each new index note which makes it to “ongoing” column had to have the data filled. In terms of projects which were already in development I was adding this information slowly over time, usually whenever I was discussing the very project and somehow dates or budget became important in the conversation.

    It meant that eventually I’d have had complete information either because I gradually updated all the index cards in “ongoing” column or because projects were finished and the cards were moved to “maintenance.”

    After all these evolutionary changes I was still kind of unhappy with the board. I still didn’t feel I had any explicit limits and, what even worse, I didn’t see any simple method to add them. I also noted that sometimes I found it hard to keep all the information updated, as the board was still fully owned and managed by myself. However I decided not to go with it to the outside world unless I was sure it was going to work.

    So no, that’s not the end of the story. However, I encourage you to read it from the beginning.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Effective Standups around Kanban Board

    You can hear here and there that Kanban scales up pretty well. Actually one of Scrum issues, and I believe one that isn’t addressed neatly, is what to do in projects that take more people than a single Scrum team can accommodate. Definitely one thing which is surfaced pretty soon as Scrum team grows is standup meetings.

    As you go with three standard questions through growing team it naturally takes more and more time. Soon it can be a problem to fit into short time-box you have for such meetings.

    When team are adopting Kanban they usually leave standup unchanged. However it means that, at some point, they face the same issue as Scrum teams do – 15 minutes is not enough anymore.

    Recently Jorn Hunskaar shared such story on his blog. It prompted me to combine a bunch of ideas into a single answer that can be a guide how to improve standups organized around Kanban board. I left a lengthy comment on Jorn’s blog although I believe it is worth to share the idea here as well.

    Instead of running typical round-the-table with answers about what happened yesterday, what is going to happen today and what issues are there you may try to redesign the pattern you follow on standup.

    • First, go through all the blockers (if there are any). These are definitely your pain points at any given moment. It means that you definitely want to invest precious standup time on blockers. This is no-brainer.
    • Second, discuss expedite or emergency items (again, if there are any). This is top priority work from the perspective of the whole team. This is something you really need to get done even at cost of delaying other work. Again, something which is worth investing scarce resource into.
    • Third, go through items that hasn’t moved since last standup. These are items which may be risky. Maybe they weren’t supposed to move but in this case it would be a quickie – not much discussion needed. Otherwise it is worth to have a brief analysis what happened that prevented moving cards forward. By the way, it means that you should have some kind of mechanism to mark index cards which aren’t moving, which is usually tricky.
    • Fourth, go through everything else. One more guidance you can have is discussing items of one class of service after another in order of priorities. In other words you start with highest priority class of service (bugs, critical features or what have you) and discuss all items of this class of service. Then you move to another one. Well, at least this can work considering that you can tell which class of service is more important than other.

    One more rule would definitely be reasonable: within each of these groups you start from the right side of the board and go to the left. This shows that the closer an item is to being done the more you want to discuss it as you are closer to complete it, thus bring value to your users, clients and stakeholders.

    Now, up to this point there is little difference – you still go through every single work item which is on the board. There is different focus on issues and you may skip discussing obvious pieces of completed work but still, a lot of stuff to go through.

    However, given that you’ve just sorted topics to discuss by priority you can just use a simple trick and just finish discussion when the time of the meeting has elapsed, no matter if you were able to finish all the things. It likely means that you’ve covered all the items from first three groups, and definitely all of them from first two, and whatever leftovers you have are items which require least discussion or no discussion at all.

    It also means that on a good day you can cover all things, or more things than on worse day, but that’s perfectly OK. What you basically need is to ensure that most important stuff doesn’t go unmentioned.
    Going a step further means that you can skip a discussion over a specific groups or sub-groups of items, e.g. a specific class of service, when you see it doesn’t really add any value. If you aren’t sure try to cover it during standups and see what outcome you get. Then you can start experimenting with the plan of the meeting.

    Ideally, after some time, you will end up discussing only important stuff, say, blockers, expedited and stalled items and maybe others which are brought by any team member for an important reason and just skip regular work which needs no more attention than a silent confirmation that everything is perfectly fine.