As much as I love visualization as a technique that gives pretty much any team handful of quick wins, I do consider limiting work in progress the bit that makes or breaks team’s long-term ability to improve. Introducing, fine tuning and maintaining WIP limits is arguably the most difficult part of Kanban implementation, yet the one that pays of big time in a longer run.

Shouldn’t limiting WIP be a no-brainer then?

No, not really.

Introducing work in progress limits is an investment. A long-term one. If a team isn’t ready to make long-term commitment to limit WIP it may not be their time yet. I mean, would you expect that a pretty much chaotic team would understand their process, let alone shape the process using WIP limits? They have quite a few prerequisite steps to make so let them start with that.

OK, but this is the case of teams I often dub immature. But then there are teams that I’m working with and that most definitely are mature enough and we still don’t introduce WIP limits.

Why?

Introducing work in progress limits is an investment. A long-term one. Have I already said that? Oh… Anyway, if we are talking about sort of temporary team working on short-term arrangements investment into making WIP limits work may not be worthwhile.

Let me give you an example. One of my recent project lasted 7 weeks, including first couple of weeks to get things running. Over the course of the project team setup has changed twice. Our environment was far from stability.

Instead of setting up explicit WIP limits we just paid attention to what was happening on the board and were reacting whenever needed, using a couple rules of thumbs:

• Whatever is closer to completion (further down the flow) it has priority over stuff that is on earlier stages.

• We finish what we’ve started before moving on to another task, unless we encounter a blocker.

Thanks to that we naturally limited work in progress and context switching despite lack of work in progress limits. Probably it wasn’t that strict and aggressive as it would be with explicit WIP limits, but I still think we’ve done decent job.

The interesting thing is that I doubt we’d be able to fine-tune the WIP limits before the end of the project, even knowing everything we know once we are done. The situation was evolving very rapidly; bottlenecks were in 4 different places throughout these few weeks. We’ve made a couple of gut calls deciding who should do what, like developers helping with testing or design. In fact, we didn’t need explicit WIP limits to make these calls, although definitely understanding how the work was done was a crucial bit.

If the project was supposed to last a few more weeks we would already have WIP limits on our board. But now the situation has changed; people are working in different setup, so limiting work in progress has to start from scratch.

There are two lessons in the story. One is about WIP limits – they are a long-term investment and every team adopting WIP limits should understand that before they start. Another one is that even if you don’t have explicit WIP limits understanding how the work is done and reducing how much work is started helps. In some way it is limiting work in progress too.

You don’t have to use fancy techniques to limit WIP. As I often repeat: read the board from right to left and start with the stuff that is more to the right. To be precise, this should be: read the board from where the flow ends to where the flow starts, as there are many non-standard board designs, but the idea is basically the same.

You don’t have to work hard to start more stuff – it happens almost without any conscious effort. You have to work hard to finish more stuff. And this is what WIP limits help you with.

I’m not a fan of estimation. I try to avoid it when I can. However, I’m not orthodox. I won’t be telling everyone that refusing to estimate is the way to go.

I admit that I’m now in a comfortable land of time and material contracts that give more flexibility to the clients and more safety to the vendors at the price of mutual trust. At the same time Lunar Logic is the first of my jobs that works this way, so I’m more than familiar with fixed everything sort of contracts too. In that world estimate is a king. A lousy king though.

Despite the fact, that fixed price projects are a nightmare from my past life, we can’t forget about estimation at all. Even those awesome folks we started working with recently started with asking us to deliver estimate in story points or other abstract measure of our choice.

I intended to track progress in the project with Cumulative Flow Diagram (CFD) that counts only a number of tasks completed. However, having individual estimates for all the stories in backlog it’s easy to have two CFDs: one tracking a number of stories and tasks and the other that refers to initial estimates.

One might suppose that it would be basically the same data on both charts. And one would be wrong.

Let’s start with the charts. Here’s standard CFD for the first few weeks.

And here’s CFD that bases on estimates in story points.

What’s the difference? In fact, there are quite a few of them.

For the starters, the scope changed only on the first chart. What does it mean? Simply that despite no change in total points there were new tasks. In this case almost all of them were non-functional tasks like setting up the environment, design pre-processing and adjustments in existing code that enables integration with the new part of an application.

There was also a split of one of stories to a couple of them for the convenience. The total estimate didn’t change although there was a new story to build.

Another thing you may notice is that on the second chart we’ve finished anything pretty late in the project, while the standard CFD shows completion of a couple of features early. Again it is connected with non-value-adding and non-functional features that had to be completed to get the team running.

Finally, and most interestingly, try to judge amount of work in progress and size of stories in progress looking at the charts. A hint: you will find the answer to the former in the first and to the latter on the second chart.

Standard CFD tells you that we care about limiting WIP and avoid starting too much. The story point-driven chart shares a different story. Steepness of the coding curve indicates that we’ve started with heavy features. In this case heaviness was mostly driven by risks – the heaviest features were most risky ones. We decided to start with them to address risks pretty early in the process so if there’s a screw up on the way we know it as soon as possible.

By the way, I don’t focus here on the data that you specifically get from CFD. You could draw exactly the same conclusions if you used burnup charts, which are gateway drug to Cumulative Flow Diagrams.

Obviously, CFD can tell you a bit more, e.g. about the awesomeness of the client, as they don’t ever have anything stacked in approval. Whatever is ready it gets verified and accepted.

Anyway, the point is that despite I don’t feel that detailed estimates in this project really pushed us further (maybe despite building trust relationship, but that’s a different story) we can still use the work invested in estimation to learn something.

And, as you see, you can learn quite a bit using very simple tools.

There’s one thing about me that virtually every boss I’ve had so far has tried to correct. If you look at me all my emotions are painted on my face. You just can’t fail guessing whether I’m happy, worried, tired, excited, etc. I’ve heard so many times that I should do something about that since having people see my negative emotions definitely isn’t a good thing.

You know, they see you worried so they instantly start worrying too and you don’t want to have worried people.

I think I’ve even tried to change that. Fortunately, I’ve failed. Not that I don’t see how leader’s emotions can influence team’s behaviors. I do. And I know that sometimes I’m not helping, sorry for that.

On the other hand, I’m honest and transparent this way. I’m all for honesty. I believe that transparency is a crucial ingredient for building a healthy team or a strong organization. In the worst case this attitude is a mixed blessing.

But that’s not why I won’t try to change the behavior any more. I won’t do it because it’s who I am.

One doesn’t have to like it. Such attitude doesn’t fit every organizational culture (and I learned it the hard way). But you aren’t a leader if you aren’t authentic.

I was reminded that recently by Gwyn Teatro with her story about what leadership is. One bit I really loved:

The man was successful because he did not pretend to be anyone else. His communication style included fun, laughter and humility. It worked for him simply because it is who he is.

More than about anything else it’s about authenticity. People catch false tones sooner than you think. Then, they start guessing what really happens under the mask. It’s likely that their guesses are worse than the truth that one tries to hide. After all we are a creative bunch, aren’t we? It soon becomes worse: they don’t listen to the truth, even when it bites their butts. They just know better thanks to the gossips and far-fetched hunches. Their “leader” hasn’t been authentic so what’s the point of trusting him?

So no, I’m not trading my authenticity for anything. Not worth it.

I’ve read and heard a lot advice on running better retrospectives. I’d even go that far to say that if you speak at agile event and you want an instant hit “how to run a good retro” should be very high on your list of potential topics.

After all, this whole “getting better” thing seems really important to everyone and improvement is almost always a struggle for teams. A retrospective is a nice package; it’s pretty self-explanatory, it has a good name and it’s open-ended enough that you can adjust it to your needs.

It’s not a new concept though. I was doing post mortems back then when agile was just a word in a dictionary. Same goal, different package. Well, maybe not that sexy, and that’s exactly why you should rather jump on a retro bandwagon to win the crowds.

Anyway, the problem with vast majority of stuff I’ve heard or seen about running better retrospectives is simple: they are all recipes. You may apply them and they either work or not. Even if you’re lucky and they happen to work once, they quickly wear out. After all, how many times do we laugh at the same old gig?

Then, we’re back to the square one. How to revive the next retro one more time?

It’s because we get the wrong advice on retrospectives over and over again. It shouldn’t be “try this” or “try that.” The real magic happens when the thing you do during a retro is fresh and everyone gets involved.

Both things are often surprisingly easy. You can count on people’s engagement when you don’t push them out of their comfort zones too far, e.g. I would say that singing in front of the team probably isn’t the best choice you might make. But all sorts of drawing are usually safe.

And being fresh? Just think about all these funny ideas you discuss by the water-cooler. Playing an act, recording own version of movie classics, a concert, a cooking event, or cleaning a randomly chosen car on a parking lot are all such concepts. People were enthusiastic to sign up for such things. Wouldn’t they be so if it was a part of a retro?

However, if you’re going to use a cooking event as an awesome idea for the next retro you understood nothing. Go, read the post again from the beginning. I don’t want to give you any recipe. I’m going to simply point the fact that every goddamn team on the planet Earth has a ton of fresh ideas for their next retro. It’s enough if you retrieve a single one of them.

In fact, it’s even better. If you use one of those crazy ideas your team discussed a couple of days ago during lunch, odds are they will eagerly sign up for it.

This is why I’m not going to be stunned with the next “better retros” session. Because, you know, I have such a session a few times a week. I just pay attention.

One of Kanban practices is introducing explicit policies. It is the policy that probably gets least publicity. I mean I could talk hours about visualization and don’t even let me started with WIP limits thing. Managing flow gives me a great starting point for the whole debate on measuring work and using the data to learn how the work is done. Finally, continuous improvement is the axis that the whole thing spins around and a link place to all sorts of beyond Kanban discussions.

Note; I put introducing feedback loops aside for the sake of this discussion as it is still new kid on the block and thus it isn’t covered that well in different sources.

On this background explicit policies look like a poor relative of the other Kanban practices. Seriously, I sometimes wonder why David Anderson put it on the original list back then when he was defining what Kanban method is. Not that explicit policies are unimportant, but their power is somewhat obscure.

After all what does it mean that we have explicit policies? What does it take to have such a thing? When I’m training or coaching I like to use this example: if I take any member of the team ask what random things on Kanban board mean they should all answer the same. I ask about things like, what exactly is represented by a sticky in a specific place of the board or what the meaning of a specific visual signal is, e.g. pins, magnets, different marks on stickies etc.

I don’t subscribe to a common advice that you have to write policies down and stick them to the board to make them explicit. I mean, this usually helps but it is hardly enough to start. Explicit policies are all about common understanding of how the work is done.

And this is where real fun starts. If we are talking about common understanding we should rather talk about discovery process and not compliancy enforcement. If it is about discovery process we may safely assume two things:

1. It has to be a common effort of the whole team. One person, a leader or not, just won’t know everything, as it is about how everyone works.
2. It’s not one time effort. As the team approaches new situations they are essentially introducing new behaviors and new rules.

This is a real challenge with explicit policies. Unless you get the whole team involved and make it a continuous process you’re doing suboptimal job with policies.

What you aim for is to have emergent explicit policies. Any time that a team encounters a new situation that calls for a new rule you can add it to the list of policies you follow.

By the way, this is where having policies written down proves useful. I would, however, argue that printed sheet rather discourages people to add something, while a set of handwritten sticky notes or a hand writing on a whiteboard does the opposite. This is why you may want to use more sketchy method of storing the list of explicit policies.

Another thing is what should make it to the list. As a rule of thumb: the fewer, the better. I mean, who would read, and remember, a wall of text. Personally I would put there things which either prove to be repeatedly problematic or those that are especially important for the team.

After all, your policies are emergent so if you missed something the team would add it soon, right? In fact, this is another thing to remember. The last thing a leader might want is to be considered the only person who is allowed to change the list of policies. Personally, I couldn’t be happier when I saw a new policy on the board that was scribbled there by someone else. It is a signal that people understand the whole thing. Not only do they understand, but they do give a damn too.

Without this your policies are going to be like all those corporate rules, like a mission statement or a company vision or a quality policy. You know, all that meaningless crap introduced by company leaders, that has no impact whatsoever on how people really work.

You wouldn’t like this to happen in your team, would you?

I’ve been working as a manager for the vast majority of my career. Teams I led consisted between a couple to 150 people, most of them being bigger than 20. Throughout that time I’ve had my own office once. And I don’t think it’s been a good idea.

I decided to move to the office as I didn’t really see any reasonable setup that would work with a team spread across 40 rooms. It was then, when I first thought about the idea of sitting with one team for a week or two before moving to another office to join another team. I didn’t decide to pursue the idea though.

The thing that kept me from doing that was the organizational culture. I was a parachute boss for everyone and the division hadn’t existed before as a single entity, thus there was very little to no trust to me, or between teams.

If I’d popped one day in a random office stating that I’d been planning to sit in for a couple of weeks it would have been interpreted as spying on the team (or some other, more sophisticated form of repression).

Fortunately, this time the situation is different. The organizational culture in Lunar Logic is way more open. No one assumes that the boss has bad intentions. In fact, I’ve had first discussions with people being concerned about my actions just a couple of weeks after I joined.

It takes courage to go to your new boss and interrogate them about their plans and intentions. Such an attitude means that people voluntarily become vulnerable. It also sets up a completely different environment a leader acts in.

So this time I’m not going to have a private office, not a chance. After just a few weeks spent in a neutral place I fetched myself a flying office. What’s that? A bean bag, a laptop table and a cardboard box.

A bean bag works extremely well as a sitting device. It is extra-comfortable for short periods of time. On the other hand it would be painful, and unhealthy, to sit there for 8 hours. The latter reminds me that leader’s place isn’t on their butt but on their feet – running around, removing obstacles and solving problems.

A laptop table solves a problem with keeping a laptop on, well, you lap, which, despite its name, isn’t the most convenient way of working.

And I use a recycled cardboard box to store all my office belongings, which is simply a handful of sticky notes and a couple of pens and markers.

This way I can grab my flying office to my hands and move it to the place where I’m needed or I feel like I can be helpful. I need just a bit of space in a corner or by the wall and done – a new office set up.

Surprisingly, sitting in the corner and almost on the floor has a few unexpected advantages . First, you need very little physical space, which means you will fit to almost any room (unless it is already packed beyond any healthy limits). Second, this way you become almost invisible, which definitely helps if your goal is to understand how the team functions, and not just scratch the surface.

Third, and arguably most importantly, you strip yourself from status symbols. Instead of a huge desk dubbed by your colleagues as the airstrip, a leather armchair and a locker just the simplest set that does the job.

All in all, you’re way more accessible and much less intimidating. Isn’t that something every single leader should strive for?

The flying office isn’t only very mobile; it also renders quite a few barriers that leaders often face irrelevant. Bringing oneself to a floor level is a challenge for ego though, but I’d say it is a good thing too.

All you need to start it is just a bit of trust.

Honestly, I regret I didn’t try it, despite the odds, when the only other option was a private office. I can hardly think of a different setup now, that I potentially have half a dozen more common solutions.

How about you? Given that your team doesn’t work in a single room, are you courageous enough to try?

I’ve always had a love-hate relationship with Gemba walk. On one hand I just love the idea to go and see. In fact, whenever I have an issue to solve or a question to ask I prefer to move my butt and go meet someone instead of writing an email, chatting on IM or calling. I just use any pretext I have to meet people face to face.

On the other hand, the idea of the Gemba walk, in its roots, goes way beyond simply solving issues. Just think about all those stories where leaders had their epiphanies when they randomly walked through a factory floor. Gemba walk isn’t just supposed to be an issue solving tool. Its main function is issue discovery, whatever an issue might mean.

And this is where the hate part of my love-hate relationship starts. My previous professional life was leading 150 people. It meant that most of the time I was alienated. In a situation like that, you just don’t go into a team’s room as if nothing happened as almost certainly the observer effect kicks in and you experience something more like a play than reality.

Not to mention that if you happen to be an introvert the whole activity can be insanely difficult for you.

Obviously, it may be a very different experience if the organizational culture of a company is open and people generally trust each other. One, it isn’t that painful. Two, there is less acting and more honest and open discussions.

It is still only halfway through though. As long as someone is willing to become vulnerable and open themselves you will learn something new. There is, however, the whole black mass of issues no one is really aware of so chances that you learn about them during a discussion are non-existent.

In a plant you might spot something just by watching how stuff is arranged on a factory floor. In software development you don’t get even that. And, by the way, even if you brought your Gemba to the level of looking at things, e.g. code review, you still miss the point.

No matter what the problem is, it’s always a people problem.

~Gerald M. Weinberg

Following this advice, you shouldn’t look at things; you should look at people, their characters, behaviors and interactions. That’s where Gemba walk fails.

You can’t make meaningful observations in the meantime, while you walk around and ask about everyone’s wellbeing spending just a while here before going there and then coming back to your own stuff. You can’t make meaningful observations of team dynamics during a chat with everyone.

You have to be there. You have to breath the same air, share the same stories and see the same everyday routine. You have to become familiar and friendly enough that they stop playing. Or be there long enough so they get tired playing and become real.

It doesn’t happen in fifteen minutes. It takes days. Weeks maybe. On the other hand you may expect a few low hanging fruits, which you spot pretty quickly, e.g. the way people address themselves in a discussion. Either way it doesn’t happen when Mr. Leader enters a room for his whatever-he-calls-it thing. It happens when a leader becomes almost invisible, sitting there in a corner, minding their own business and using those occasional bursts of action to learn something about their team.

And this is why Gemba walk isn’t enough. It’s just scratching the surface hoping for luck.

“Price has no meaning without a measure of the quality being purchased.”

~W. Edwards Deming

It always fascinated me how price was the main axis of the game of closing software development deals. Unfortunately, in the vast majority of cases, pricing is used in total isolation from any other criteria, especially quality.

It was like this when I worked on off-the-shelf ERP software. In this case it was, to some point, understandable. You can’t universally define functionality-to-price and quality-to-price factors if you sell the same product to thousands customers. It will be different in many cases.

In such a case the question is what you deliver for the price you put on the tag attached to your product. Is it of high quality? And more importantly: do you keep, or even improve, the quality consistently?

As a matter of fact, we didn’t. We didn’t think in such terms. It was more of a chase for more functionality to satisfy new customers than a conscious effort to keep the quality of software stable. You may guess how that affected the quality. Let me just say I’m not proud of the end result.

It was still much better than what I experienced later, which was building custom projects for big clients. As a leader of software development and project management divisions I was often involved in the sales process. I was always asked how much time and people we need to build a thing. I was often asked about features the thing had or was going to have. I was never, ever, asked about the quality of the product or the tools we’d had in place to ensure this quality. Ever. Not a single time.

It isn’t an industry-specific observation. I went through a few industries, including banking, insurance and telecommunications, and it was always the same.

I’m compassionate for these poor chaps that were the decision makers. They followed their fears represented by the “nobody ever got fired for buying IBM” attitude. They just played it safe. In fact, I blame the system.

I blame the system that disconnects the price from the quality of purchased goods or services. In such a case price is almost meaningless, yet it is almost always used as a deciding factor.

The question I often wanted to ask the decision makers was: if they were buying the product with their own money would they be choosing the same? Obviously not. In fact, when we refer to our everyday lives, which I like doing, we never forget the relationship between quality and price.

When I buy sticky notes to use on whiteboards I choose 3M even though they are pretty expensive when compared to alternatives. Actually, given a choice, I take 3M Super Stickies, which are even more expensive. It’s just the quality I need and I’m willing to pay for.

When you think about the slow food movement being more and more popular over the course of the past 20 years, it follows the same pattern. Most of the premium products exploit the same behavior. Heck, how many of you, my dear readers, bought one of those overpriced smartphones or tablets? Apple fans, anyone? What is it if not paying for quality? And how do you choose a new car I wonder? By price tag only?

So why, the hell, do you become Mr. Hydes when you return to your workplace and you choose a vendor? Oh, the system, I forgot.

The system is, in fact, bigger than just an organization choosing a vendor. It spreads across most, if not all, of the vendors, too. A good picture of this would be a story my friend told me about the tender process in Romania in which he was involved as a representative of one of the bidders.

When all the offers were formally submitted, the client organized a meeting with all the potential vendors, announced what the lowest bid was and asked everyone to reconsider their offers giving them half an hour to resubmit proposals with new pricing.

When they had all the discounted bids re-submitted they did it again.

It’s just spreading a sick behavior throughout the whole ecosystem. Optimizing solely for price means cutting corners on quality. Heavy price optimizations mean painful quality tradeoffs.

And we know that low quality means a lot of rework and, as a result, higher overall cost.

Now, that I’ve changed jobs, I’m more directly involved in the sales process. And I couldn’t be happier to learn that we don’t take part in this game. We are (relatively) expensive. Don’t expect the lowest bid from us. We understand what it takes to build high quality software and are ready to walk away if someone expects us to drive the price down to the point when we compromise the quality.

Because, at the end of the day, low price is costly for both: a client and a vendor.

You just can’t consider price in isolation from quality.

Rightshifting is a nice idea. In its origin it says about improving effectiveness of organizations. When an organization rightshifts it becomes aware of different approaches, methods and techniques that can be used to work better. Eventually, the company adopts some of them and starts treating them as non-optional. Oftentimes, it means that the organization refuses to work “the old ways” as it is clearly considered suboptimal.

I do like to think about rightshifting in terms of personal development. Every one of us can (arguably should) learn new approaches, methods and techniques. With such an attitude we eventually learn how to work better. Oftentimes, we’d love to reject to work differently, on occasions we even do, although this time the case is more complex.

Being a part of a bigger entity, we rarely have comfort do fully decide how work is being done. If you ever heard “do we really need to write unit tests (a client won’t pay for this)” discussion you know exactly what I mean.

What happens then? Well, usually we develop our frustrations regarding lack of workmanship. Some leave in pursuit to find another job that suits better their expectations and skills. Some stay and try to change the organization from the inside. Sometimes they even succeed, although more often a success is local (a team level) than global (an organization level). Anyway, besides these rare successful cases usually much frustration is involved.

Bad news is that a scenario involving frustration is a frequent one when we personally rightshift. More often than not, the pace of our personal improvements is better than the one of organizational improvements. On one hand it means that personal rightshifting introduces at least some dissatisfaction. On the other it should open new opportunities.

Yes, of course. The problem is that there are fewer and fewer of them, the further to the “right” you are. There aren’t enough great companies, or I should say mature enough companies. I mean, maybe there are, globally. But few of us operate on a fully global job market and jobs in general, and jobs at great companies specifically, aren’t distributed evenly across the world.

So sorry, in most places on earth “there’s no shortage of talent, only a shortage of companies that talent wants to work for” isn’t true. Even less so, when one has high expectations for craftsmanship and organizational standards.

In other words, in theory, you can rightshift yourself to the point where you’re practically unemployable because you aren’t willing to accept anything but your impossible-to-meet standards of work. I’m pretty sure it’s not only theory and quite a few folks out there could tell by their own experience.

I know by mine that definitely the more to the “right” you are the fewer companies you want to work for.

So my advice would be: don’t rightshift… too fast.

Be aware that rightshifting closes a few options here and there. Rapid rightshifting may close the option you’re exploiting at the moment too (also known as a current job). I wouldn’t call rightshifting a career-limiting move, although in some ways it might be considered this way.

Is it different when we look from a perspective of an organization? A bit. When the company rightshifts faster than individuals working there, there is frustration too. However, people tend to adjust to the way their company works. After all, it is one of conclusion that may be drawn from famous Deming’s work (95% of variability is caused by the system). In other words, improving the system (the organization) we naturally pull people to the “right” too. Most of them at least.

Unfortunately, raising standards means that there are fewer people that you’re willing to hire. It limits company’s pace of growth. It makes hiring people’s work way more difficult. Of course you can always fall back to good old growing people from basics but you can afford to have only that many of them.

So again, don’t rightshift… too fast.