I’ve had a great discussion recently. A starting point was information from Kanban board – basing on my knowledge it wasn’t up to date and, as it appeared later, it wasn’t without a reason. A way of visualizing how situation looked like in a team was sort of tricky.

We used the situation to discuss in details what is happening and how we should visualize it. Anyway, one thing struck me in retrospect – the less visualization changes the fewer chances we have to start such discussions.

A good (or rather a bad) example is my portfolio Kanban board. Considering I try to visualize there projects of different sizes it’s not that uncommon when, in the long run, there are few changes on the board. On one hand, this is acceptable and even expected. On the other, there aren’t enough “call for action” situations when people are expected to do something, like moving stickies etc. Those situations that trigger important discussions.

This is also why I prefer Kanban boards that are built of rather small-sized work items than those that are filled with huge tasks. They just aren’t that lively. They tend to stall.

And when visualization stalls its value diminishes. People tend to develop a specific kind of blindness. They start treating their information radiator just like another piece of furniture, which results in the board being exactly that – a piece of furniture. Not useful in terms of improving team’s work.

So remember this: as long as you expect visualization to generate value, it should live. If it doesn’t, think how you can make livelier. You won’t regret.

I’m not a native English speaker, which basically means my English is far from perfect. Not a surprise, eh? Anyway, it happens sometimes when one of natives I’m talking with corrects me or specifically points one of mistakes I keep making.

And I’m really thankful for that.

I’m thankful most of the time such feedback happens instantly so I can refer to the mistake and at least try to correct it somehow.

This is what happened recently when one of my friends pointed one of pronunciation mistakes I keep making. It worked. It did because feedback loop was short. It worked even better because it was critical feedback. I didn’t get support for all the words I pronounce correctly. It was just a short message: “you’re doing this wrong.”

Of course it is my thing to decide whether I want to do something about this. Nevertheless I can hardly think of positive feedback I could receive that would be that helpful.

When you think about this, it is contradictory to what we often hear about delivering feedback. It isn’t uncommon that we are thought how we should focus on positives because this is how we “build” people and not “destroy” them. Even more, delivering positive feedback is way more pleasant and for most people easier as well. It is tempting to avoid the critical part.

When we are on feedback loops I have one obvious association. Agile in its core is about feedback loops, and short ones. We have iterations so we deliver working software fast and receive feedback from clients. Or even better, we have steady flow so we don’t wait till the end of sprint to get this knowledge about the very next feature we complete. We build (and possibly deploy too) continuously so we know whether what we’ve build is even working. And of course we have unit tests that tell us how our code works against predefined criteria.

It is all about feedback loops, right?

Of course we expect to learn that whatever we’ve built is the thing clients wanted, our code hasn’t broken the build and all the tests are green. However, on occasion, something will be less than perfect. A feature will work not exactly the way a client expected, a build will explode, a bunch of tests will go red or pronunciation of a word will be creepy.

Are we offended by this feedback?

Didn’t think so. What more, it helps us improve. It is timely, specific and… critical. So why, oh why are we that reluctant to share critical feedback?

It would be way more harmful strategy to wait long before closing a feedback loop, no matter what the feedback is. Would it really tell you something if I pointed you this two-line change in code you did 4 months ago, that broke a couple of unit tests? Meaningless, isn’t it? By the way: this is why I don’t fancy performance reviews, even though I see the point of doing them in specific environments.

Whenever you think of sharing feedback with people think about feedback you get from your build process or tests – it doesn’t matter that much whether it is positive or critical; what makes the difference is the fact it is quick and factual.

You can hardly go wrong with timely and factual feedback, no matter whether it is supportive or not.

I find it pretty common that teams who adopt Kanban try to draw the ideal process on their boards. Not exactly the one they really follow, but the one they’d like to. It is thinking taken from prescriptive methods – since we have this ideal process we want to implement let’s just draw it so we know where we are heading to.

Bad news is that Kanban in general, and Kanban board specifically, doesn’t work that way. You may draw pretty much any process on your Kanban board, a better or a worse one, too detailed or too generic, or just simply different. However in each case data you get from the board won’t reflect reality.

The end result is pretty simple as with the board that is not up to date people will be making their everyday project decisions basing on a lie.

What more, drawing the ideal process on the board instead of one that team really follows brings additional pains. People are confused when it comes to work with the board, e.g. I’m supposed to do code review but I haven’t and won’t do it but hey, I should put an index card here because our process on the board says so.

As a result it is way harder to show value of Kanban board, people lose interest in updating it and whole Kanban implementation quickly deteriorates.

The first step to deal with the problem is admitting your process is less-than-ideal. Pretty often it means admitting your process is simply crappy. As funny as it may sound teams find it really hard to go past this step. We wish we were better and this wishful thinking blinds us.

Then it’s time to adjust the board so it reflects the way team works. It may be painful. I saw teams throwing out code review stage. I saw those throwing out all the testing stages. That didn’t mean they didn’t want to review code or test. That meant they weren’t able to do it consequently for majority of features they built.

Note: at this stage a pressure from the top may appear. How come that you aren’t testing? That’s outrageous! That just cannot be! Well, it is, so better get used to it for a time being because drawing the ideal process on the Kanban board is almost as useful as drawing unicorns there. If such pressure appears, you definitely want to resist it.

The final stage is continuous evolutionary improvement. If you track down root causes of suboptimal process you will likely find that your flow is unbalanced. If you want to balance the flow slack time and WIP limits should be your best friends. Treat them seriously. Don’t violate limits; don’t get tempted to use slack time to build new features.

This change won’t be fast but at least odds are it will be successful. Drawing results of your wishful thinking on the Kanban board will fail for sure.

Read the whole Kanban Pitfalls series.

One of my favorite and yet most surprising things I learned about Kanban over the years is how it steers change of behavior among mature teams. It shouldn’t be a surprise that at Kanban Leadership Retreat (#klrat) I ended up facilitating a session covering this area.

Those of you familiar with #klrat format would understand me when I say I didn’t have any specific expected outcome of the session. I wanted to start with exchanging stories and see how it goes. Maybe we would be able to observe some patterns of behavioral changes steered by Kanban and learn from that.

Fast forward to what we ended up with. For me it is still work in progress, so will see more on the subject soon. Anyway I pushed my thinking forward in terms of how we can stimulate our teams to improve.

One thing you instantly notice on the picture with the session summary (click to enlarge) is that there despite the fact we were gathering unrelated stories we started building a chain of dependencies. Another observation is how frequently visualization pops up in different examples.

What I believe we will be able to build is sort of a graph showing what kind of behavioral changes can be influenced or even incentivized with adopting specific practices. What more, I don’t want to keep it purely about Kanban. Although at #klrat Kanban context was set by design I’m pretty sure we can, and should, go beyond this context.

A few highlight from the session, basing on stories we’ve shared:

• Visualization combined with WIP limits and daily meetings around the board improve general team-wide knowledge about what’s happening. In short term this influence how people deal everyday tasks, encouraging them to get involved in work done by others, thus removing personal queues. As a result it pulls people toward generalization as they’re involved in many different tasks.

• Visualization and measuring flow improves understanding of work. It makes people to focus on pain points and incentivize them to improve problematic areas. As a result a team takes more responsibility for how the work is done.

• Rich visualization along with slack available to people results in better decisions and better use of slack time. It bases on a notion that rich visualization derives more meaningful data so whenever people decide what to do, especially when they aren’t constrained, e.g. when they’re using slack, improves the quality or potential outcome of these decisions. The final effect is building team’s collective intelligence both in terms of what they do and how they do it.

• Making visualization fun fuels viral adoption of the method. It bases on a fact that people like having fun with tools they use. More fun means more people trying to find out what this cool thing is and how to use it. Eventually you get more people willing to introduce the method and better attitude toward the adoption.

• Measuring flow (again) and understanding and visualizing (again) the nature of work can have impact in a multiple ways: creating incentive to change, building trust to a team and getting rid of 100% utilization. A simple fact that we were able to address so many effects to improved understanding how we work is a strong indicator that we do have problems with that. We might be onto something here.

• Avoiding 100% utilization and slack time, which is generated this way, may be a tool to build leadership among the team (people are free to make decisions on what’s being done) and at the same time can improve fun factor (people can choose to work on fun stuff). In both cases we strengthen our teams and develop people.

By the way: if you add a real story to each of these highlights you may imagine the experience we exposed ourselves to.

In retrospect, one thing that is definitely worth stressing is how little we seem to know about nature of our work. Actually if you think about it, Kanban deals with this issue in a very comprehensive way.

Visualization vastly improves information availability so we know better what is happening. Explicit policies force us to define, or agree on, the way we do work. Without explicit discussions on that we often believe we know how exactly how the work is done even when it’s clearly not true. Then we have flow management with a focus on measures that can change our perception of work highly. It’s a common situation when, being an outsider basing on a handful of simple measures, you can surprise a team showing them specifics of their work.

If that wasn’t enough we get WIP limits that steer changes in the nature of work and give us an important lesson about nature of work in general.

Anyway, leaving tools aside the lesson is to invest more effort to understanding how we work. It will pay off.

We are professionals, we take pride of our work and we pursue continuous improvement. Most of all we learn.

One thing we’ve learned is that pursuing 100% utilization is a myth and a harmful one. Another thing we’ve learned is value of slack time. Building on that, hereby we declare ourselves Slackers.

And here is our Manifesto (you can sign it by leaving a comment if you like to).

Slacker Manifesto

On occasions we do nothing. Or something different. Or else.

Because this means that our teams are more effective.

It also means that we are freaking awesome.

Signatories:
Full list of signatories can be found here — in a stand-alone copy of Slacker Manifesto.

Big thanks to Kate Terlecka and Andrzej Lorenz who influenced creation of this masterpiece highly.

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.

As a manager of 130-something people I often have these chats on what opportunities people have to grow within the organization. You know, with such crowd you can pretty safely assume that people do want to grow, to change their role, to get promoted. So they eventually land on a sofa in my office to discuss their future.

On one hand these discussions are always challenging. I mean we’re discussing here one’s future. That’s a serious matter. On the other most of the time I find it easy to share a flurry of ideas on where someone could push their career.

The context of organization is pretty much set – we know what we do, we roughly know how we do it and we definitely know how, in general, we want to improve it. And yet people often need a lot of guidance to show them what they can do in a couple years from now.

One thing is people often constrain themselves to just the lowest hanging fruit. I’m a developer so the next step is senior developer. Then a tech lead and then a software development manager. Oh so creative. How about business analysis, project management, product management, quality assurance (yes, this one too) or what have you?

While we are going beyond mental constraints, why not running a startup, consulting or freelancing?

Or simply doing the same thing you do and rightshifting at the same time? Do you really need a new title on a business card to feel fulfilled? Maybe you just like what you already do and the fun comes when you shift toward improved effectiveness?

One could say that having much power it’s easy to come up with different ideas but I do as I preach. I mean I consider myself a leader. My current team has, at the moment, 130ish people. The previous one had 4. Another 35. In each and every of them I was self-developing like crazy. In each role I could imagine myself in a year being in any of others as well as doing a bunch of different things. I didn’t feel constrained either by the current situation or by current organization. These things change very rapidly in IT.

When you are asked a question what you want to do in two year time (and believe me, I ask this question a lot) it’s not a question about current options in your organization but it’s a challenge to your mental constraints.

As simple as that. No one is going to offer you a project management position or their biggest software development division unless they’re convinced you will manage. You won’t convince them using your will solely. You need to know what it takes to do the job, understand different approaches and have a vision of your own path.

My wild-ass guess is that you don’t know all that at the moment. That’s great. Because I’m not going to judge anyone on their current knowledge. I’m going to judge them on their potential and their urge to learn.

With such attitude you render your mental constraints irrelevant and you don’t need to ask anyone about your options anymore. You know the answer.

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.

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.