Pawel Brodzinski on Leadership in Technology

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

Category: kanban

  • Limiting WIP Is a Buzzword

    As you already know I’ve recently attended ACE Conference. By the way, if you missed the message the event was great. Anyway, the interesting thing about industry conferences is you can clearly see some cool phrases, buzzwords or examples. I was once on a conference where like every second presentation cited CHAOS Report to share the news: two third of features aren’t used.

    Um, after third time it’s not much of a news anymore.

    Anyway, one of few buzzwords I caught in Krakow was limiting Work In Progress. To be honest, I’m confused. Wasn’t it me, who told you to limit WIP in my Kanban presentation? Yup, it’s hard to deny. Am I on this damned limit-WIP-bandwagon then? Yup, it seems so. But why, oh why limiting WIP became a buzzword?

    For some reasons we need them. I think we keep attaching those buzzwords to our messages for a very simple reason – they sell. They sell whatever we have for sale. So yes, we’ll be hearing a lot about limiting WIP these days. By the way, another such thing is system thinking which follows exactly the same pattern – every cool kid on the block will tell you about system thinking.

    Despite the fact I hate one of my genuine messages became a buzzword, which makes it easier to be depreciated, there are some good points as well. No, I don’t think about being right a couple of years earlier than the rest of crowd. It definitely scratches my ego on the back but, well, my ego feels pretty comfortable anyway.

    A good thing of some good concept becoming sort of buzzword is it reaches some ears much easier. There are people who won’t adopt good things unless they’re well-known. There are organizations which hate to experiment. I have a good news for you: now, you have an excuse guys. Everyone tells you that you should limit WIP. Hard to ignore that now, ah?

    Unfortunately I know what happens then. The concept is being misused and abused and finally under the buzzword there’s hardly anything coherent. It’s like with agile. What does it mean when someone states they do agile (or are agile, for that matter)?

    Basically nothing.

    Unless you see how people work you can’t really say whether we discuss hard-core agile team which could serve as Scrum+XP implementation in Sevres or just the good old do-whatever kind of team which just wanted to get agile badge.

    It will be the same with limiting WIP at some point of the time. But until then I’m going to enjoy being the part of buzz proponents.

    So go, limit your WIP! Use Kanban! It is a goddamn silver bullet! It will make your team hyper-productive and will bring the peace to the world! And of course, in the meantime, it will remove poverty as well!

    And if you really think it might be a good idea, let’s talk seriously. Because I know it works, when applied in a reasonable way. Yes, your guess is right “reasonable way” is a key phrase here.

  • Visualization Stupid!

    Kanban is a funny animal. I started my journey with Kanban treating is as a tool. Then I realized it is more of a vehicle which improves things around. Now, I extract some ideas standing behind the method and use them independently in different situations.

    Since Kanban is as easy as possible – I use to describe it as “three rules, one tool and simple mechanics” – there aren’t many ideas you could exploit, but there’s one which is especially appealing. A contest: which one am I thinking about?

    Yes, I know. I ruined everything with the title. What a dumbass I am. Anyway yes, visualization is the concept I like so much. Generally I’m known to be attracted by every whiteboard or flipchart around. If you see me sitting peacefully in a room with a completely clean whiteboard and set of markers you can bet I suffer. I’d love to write, draw, scribble and note on the board, so we all can see some reference to what we are talking about or how others may understand what we’re talking about.

    Feel free to laugh at me because of this. It doesn’t happen without a reason. I learned how much value simple visualization can bring. I’m sure there’s some psychological gibberish which shows how our brains deal better when we can refer to a huge visual brutally presenting the core of the issue, but I don’t really care.

    I use visualization because I know it helps me. It helps to me to organize presentation, like the one I’m preparing for ACE Conference. It helps me understand the problem, like learning how many quality engineers we do need at the moment. It helps me to express my thoughts, like when we’re discussing performance appraisals.

    Next time, when you have some problem, try to draw it on the whiteboard or flipchart. I mean really. No matter what the problem is or how you choose to visualize it. It would help you to understand and chances are good you’ll find a clue how to solve it.

    If you wondered why I brought two whiteboards with me to my new room, now you know.

  • Scrum versus Kanban

    These days every blog discussing agile topics should have a big hairy article on Scrum versus Kanban, so here it is. Well, just joking. Actually many people, way wiser than me, approached that subject some time ago already presenting different arguments. If you want to hear some of the strongest opinions out there check Ken Schwaber’s post on how Scrum is good and Kanban sucks. If you look for more weighted opinion David Anderson shared one. Just recently Mike Cohn also added very reasonable two cents to the discussion even though he actually doesn’t agree with David.

    Also there’s been a lot written about Scrumbut and Scrumban. I don’t see the point in repeating once again that if something works for your team – go for it, no matter if that breaks the orthodoxy of the method of your choice.

    Note: I’m well aware that until now I just share what I’m not going to write about. Is this post is going to be just a set of links to some good articles though? No, not exactly, but please do check mentioned articles – they’re a piece of good reading. Anyway, to the point. There’s one thing which is often mentioned as one of main differences between Kanban and Scrum but I think this is the core of the whole this versus that thing.

    The point

    From pretty much every Scrum and Kanban comparison you’ll learn that introducing Scrum is a revolution while with Kanban it is rather evolution. You’ll also be pointed that both approaches foster improvement. Now, finally, after all that beating around the bush: my point here is how Scrum revolution differs from Kanban evolution in terms of introducing improvements and why it is so.

    Team model and software development process

    Let me start with something I was learning for quite a long time (no, I’m not that bright to catch it during the first class):

    Scrum proposes pretty damn good team model and process for building software.

    If you look for model team which would work in majority of situations go for a Scrum team: cross-functional, small and tightly-integrated. If you look for healthy approach to software development you can’t really go wrong with Scrum. Scrum is well-thought and well-weighted approach. No surprise it ruled the agile world.

    On the other hand Kanban tells you that your team model is good for now, no matter how it is organized. And your process of building software is OK even if it’s pretty chaotic. For now.

    Kanban doesn’t propose any specific team model or software development approach.

    It basically means that you get no hints whatsoever how the well-organized team would look like. Nil. Nothing. Find out by yourself. No help here. Well, almost.

    The difference

    When organizing Scrum team you can basically turn your thinking off. Well, sort of. It’s all in the book. Someone took the effort to propose team model which I’ve just labeled “pretty damn good.” Same with the process you’re meant to follow.

    Kanban chooses the other approach: we don’t know what optimal solution for your team is. Here’s some help but you’re going to learn it by yourself.

    The difference? Pretty damn good doesn’t automatically mean optimal. Scrum is optimized for majority of teams, not for your unique group. Yes, of course, Scrum has improvement mechanisms, retrospective being the flagship here, but in terms of general rules it stays unchanged.

    Kanban accepts that starting point may be way worse than in Scrum case but leaves you all options open. You aren’t really constrained with specific practices or models. What you’re going to end up with is totally on you and your team.

    Help you get

    You can put it in other words if you prefer. Scrum tells you how you should change, at least to some point. Scrum is like your mother-in-law – she always knows that you suck here and there and how exactly you should act to be um… better.

    Kanban on the other hand is like your friend, close but probably not the best one you have. He’ll try to show you where you could improve but won’t state it explicitly. It’s just not that kind of relationship. It will be rather a set of hints and smoke signs – it’s you who chooses to use them to change yourself or just ignore them.

    Which one is better

    Neither. Despite comparisons I’ve just use I really think there’s no winner here. And yes, I’m generally considered as a Kanban guy but I also strongly believe there’s no silver bullet.

    If you need a kick start Scrum may give you one even though it imposes some constraints on the way you work. On the other hand if you have in your team someone who is experienced with variety of different methods it may be a good idea to start with Kanban and check where it’s going to lead you.

    After all, since I’m not an orthodox, I’ll also tell you should experiment like crazy, no matter which path you choose. Heck, that’s where all those Scrumbans started – people were changing their process, people were breaking The Holy Rules of The Method just to end up with something more optimal for them.

    Final thought

    If I want you to remember one thing from this post it would be: Scrum tells you explicitly how to organize work and improve things, while Kanban tells you nothing about the ideal models and helps you find out the optimal way by yourself.

    After all, this post is big and hairy so I guess I succeeded with the task anyway.

    Advertisement: Protect your business from a surprise software audit with License Dashboard.

     

  • Mechanics of Kanban Improvements

    As I’ve already started working on my session for ACE Conference 2011 I tinker at different improvements introduced by Kanban and the way they pop out. Actually if I had to point a single, most surprising for me, feature of Kanban I’d point exactly the way it fosters improvements.

    When we were starting with Kanban I expected it to be more a very lightweight approach, which organizes the workflow and doesn’t get into way, than something which may trigger any improvements on its own. Things didn’t really work that way.

    Yes, we fixed issues we’d faced at that time but that was to be expected. Then we kept finding new issues and correcting them. For a longer time I didn’t really put much thought how it worked but I had to explain somehow specific practices we introduced in my presentation on AgileEE as I wanted to talk about the subject. I realized that we didn’t plan them. They just popped out. Somehow. Magic?

    No, not magic. After short investigation I found the one to blame – it was Kanban. Thanks to using Kanban, specific problems were unveiled and we were just fixing them, sometimes completely unconsciously.

    One of my favorite stories is when I suddenly realized we had collective code ownership. Yes, it was totally out of the blue. “Wait,” I thought “didn’t we discuss it through? Didn’t we end up with conclusion that we wouldn’t have collective code ownership? What the hell?” Actually it appeared that it was just easier to have collective code ownership in a pull system, such as Kanban, so people stopped thinking whether this is their own or someone else’s code. After some some time we had collective code ownership implemented basically effortlessly.

    That is exactly the mechanics of Kanban improvements. You introduce them because it’s just easier that way. You either see something is wrong on the board and have a quick discussion how to tackle the problem and implement a solution or people start dealing with the issue unconsciously. Either way you end up with your process slightly improved.

    And you repeat this activity. Multiple times. After some time when you compare what have you started with and what you ended up with you start thinking: how the hell this whole improvement thing in Kanban works? You can’t see it but somehow it’s happening. All the time.

    Well, it seems it just works that way. Don’t complain, just make use of it.

  • Kanban Board: Keep It Simple Stupid

    In one role or another I often help teams to try Kanban out or just to help them to create their task board or Kanban board. There is an interesting pattern I observe.

    First thing is happening when a team discusses what columns should appear on the board. It is very common, and advised, to start working with Kanban with exactly the same process you already have in place. You could expect people would know it by heart. It should be really quick: “we do this, this and that, so it goes to the board.”

    Well, it appears that “process we follow” is pretty ambiguous most of the time. There are discussions whether something is a separate stage of the process or rather a part of the bigger task etc. People find they don’t really know where to put specific tasks as they’re floating depending on a number of factors. It appears the process isn’t really defined or not everyone is on the same page or people understand their tasks differently.

    Note: it all happens without any change in the process. No wonder why many process transitions are failed. What do you expect when people don’t really get how they’re working at the moment, let alone how they’re supposed to work?

    Then there is another observation. In the long run Kanban boards tend to become more and more complex. As teams work with their boards they add something to the structure more often than they remove anything. That’s perfectly understandable. When people learn better their process and the board which should reflect the process they have more ideas how to improve it. So they do, adding things and making the board more complex over time.

    Usually later version of the board has more columns/sub-columns/lanes/you-name-it than the earlier one. Sticky note bears more information too. Well, if you compare the first version of our Kanban board with the last one you’ll exactly see exactly the pattern.

    OK, but where does it bring us?

    Considering these two things: we usually don’t really know the process we try to map with the board and the board becomes more complex over time we should avoid over-engineering the board. Start simple and keep it simple. Don’t try to map every possible issue with the initial design of the board.

    I would even say that the idea to start with a single “ongoing” column representing the whole process of doing the work is pretty good. You will split it anyway but at least you will know exactly why you’re doing that and which stages you want to make explicitly visible and separated from others.

    When crafting your board, if you have doubts whether you should add a column or lane or something or not as a rule of thumb you shouldn’t do that. You’ll do it later… if you really need it.

  • The Kanban Story: Retrospectives

    Chapters of The Kanban Story are published pretty irregularly these days but it doesn’t mean the story is over. This time, encouraged by Michael Dubakov’s great post on retrospectives, description of our retrospectives.

    The first thing is we generally don’t hold meetings. At all. This also means we don’t have retrospective meetings. At all. Also, if you asked the team about retrospectives, you’d get mixed answers. Some would answer positively others negatively. Yet I keep saying we do have retrospectives.

    The pattern is very simple: every time someone sees an issue which seems worth reviewing we start discussion. Here and now. Without waiting for a meeting or something. Then people who are interested join the discussion. We also poke people who we need feedback from and they haven’t yet joined us. We try to finish this retro with some action points, but sometimes our action point is “do nothing” as we agree we have no quick idea how to do things better than we already do.

    Doing nothing about the issue isn’t a big deal since when it is important it’s going to come back soon.

    These retrospectives are, by design, very short as they touch only one problem each. We usually finish in less than 5 minutes; hardly any of them lasted longer than 10 minutes.

    Retros are done on the fly. On one hand we don’t prepare ourselves to the discussion but on the other we start talking when the problem is fresh which compensates lack of preparation.

    Prerequisite to this approach is co-location. If you start talking and expect to be heard, everyone should be in the same place.

    Now, the tricky part: interruptions. Sometimes it happens we interrupt others when launching retro. We all know it is costly. However, an interesting thing I’ve noticed is that we’re pretty good at “turning ourselves off” when we’re in the zone. It happens over and over again that we need to poke someone to get him involved in discussion as voices in the room aren’t enough to break into the zone. This means we limit a number of interruptions only to those situations when we really need someone’s input.

    I’m not sure why it works that way. I don’t know if we worked that way from the beginning or I should attribute that to maturity of the team. The trick is it works.

    Of course this is only one of many possible approaches to retrospectives in Kanban. I recommend reading Michael’s article along with comments if you want to learn others.

    Read the whole Kanban Story as well.

  • Kanban Basics

    I often say that you can implement Kanban in your team in a single afternoon. That’s how we did that after all. So when Andy Brandt asked me to do Kanban Basics webinar I expected that preparing it would be pretty simple. How long can you talk about few-hour-long task?

    Well, it wasn’t as simple as I expected.

    Kanban itself is very simple. But telling people they should visualize workflow, limit work in progress and measure the flow isn’t really all the basic stuff they need to know. After a while it always ends up with questions how we do this and how we do that.

    What limits should be set on board?
    What happens when a bug is found during testing?
    Should sticky notes be moved back on the board at all?
    How cycle time is measured?
    What happens when the limit is reached?
    What to do when emergency task pops up?
    How to cope with multiple projects?
    Is feature-by-feature deployment mandatory?
    How estimation is done?

    That’s an interesting observation – I often deal with most of these questions at the end of my Kanban presentations, no matter if I cover basic or advanced material. After giving it some thought I decided this would be a good starting point to prepare Kanban Basics presentation.

    What I ended up is presentation below. It covers a bunch of scenarios visualized with (surprise, surprise) Kanban board. Additionally I used Scrum as the reference to make a basic Kanban description easier to understand.

    Kanban Basics

    If you have some basic questions which seem to be omitted in the presentation, please leave a comment. I’d be happy to both answer the questions and update future versions of the presentation.

    If you speak Polish feel free to watch the recording of the webinar.

    Also, check The Kanban Story series as it reveals all the details of Kanban implementation in my current team.

  • The Beauty of Kanban

    OK, I admit it. This is a biased post. But you should have known. I’m sharing our journey with Kanban for more than a year already and the journey itself is even longer. And I’m still not fed up with all that Kanban thing. But then, after days like today, I realize why I appreciate Kanban that much.

    Majority of you was in this situation before – you saw your team working on tasks as planned when someone came with that super-important, top-priority pre-sales project which totally required that your team added widget foo to some application. And it had to be done exactly then.

    What I used to do in those situations was anything between panicky search for least loaded engineer and panicky explanations why we couldn’t do that before requested deadline. Either way the word “panicky” was involved. In every situation the threat was the same: we had a lot of pre-planned work to do and needed no additional distracter so what we really hoped for was to get the salesman hell out with his damn pre-sales project.

    And now? Now I just put the task on the top of the stack. Well, I do if it is important enough of course. Then the magic happens. In vast majority of cases you get someone to start working on your damn widget tomorrow. Day after tomorrow if you’re less lucky. Glad I could help you that fast. Note: I didn’t tell you “at the beginning of the next sprint.” But now, the best part.

    It doesn’t ruin the way we work. We aren’t distracted by your drop in. It is the process we follow which allows us to deal with the issue so quickly.

    As I think about that, we hate all those unplanned tasks not because they’re unplanned (we know they’re going to happen after all) but because they force us to change our initial plans. If we had a framework which helps us to embrace those tasks in a way which is acceptable for our dear stakeholders (what a nice way to call salespeople, isn’t it?) wouldn’t that be worth trying?

    So what are you waiting for? Go try damn Kanban!

    Going to the meeting to tell business folks that you’re going to do your best adding all those crazy things they think they need to get the deal (and not lying on the same time) and then getting back to the team knowing that you aren’t going to change all their plans is priceless.

    And that’s the beauty of Kanban.

  • The Kanban Story: Moving Cards Back

    This is the question which I hear very often: should we move back cards on the Kanban board when we realize the feature isn’t that advanced as it looks like? A typical example may be about feature which has been developed and is being tested and it appears some bigger patch has to be applied. Another, more interesting one, may be about feature waiting for someone outside a team, i.e. waiting for client’s decision.

    So, coming back to the question, should we move back cards?

    I always answer that is isn’t forbidden, so it is a subject of rules agreed by the team, but I don’t think it is a good idea. Consider a simple situation:


    You have development column full and it appears one of cards from testing should be moved back, so you break the limit. On the other hand you don’t want to move the card back to todo column since it isn’t a feature which is 0% done. It just has to be changed or has to wait for something before a team can perform further tests.

    OK, the simple answer is that you should avoid moving cards back and do whatever it takes to clear the feature out of the board while the card stands where it is. As long as you have all the tools to do the job this approach works pretty well.

    However, sometimes you don’t have control over the feature anymore. One of teams I’m working with has pretty complex deployment process. To make the long story short we have to wait until the customer performs some task to be able to move further. The part of the process is out of our control. Be it waiting for clarifications regarding a bug or completing acceptance tests for a feature to give a couple of examples.

    Now if we put features we really work on along with those which were waiting for some external input in the same column we’d end up with crazy high limit. That is as long as we cared not to break them every now and then. We may have a couple features which we are actually fixing and a dozen of them which are waiting for client. And setting the limit of 15 doesn’t sound like a good idea if you ask me.

    We solved the issue by setting additional todo queue within the column. It works as priority queue, so if we look for features to work on we consider cards from the priority queue first and only then from the previous column.


    Feature B would be taken before feature D. Additional trick we needed was to visualize which features in priority queue were ready to go and which were still waiting (small sticky notes attached to cards can be used for that).

    Thanks to this approach we can have reasonable limits in every column we have control over. What more, mechanics of the board forces us to finish the older tasks first. If there is a task in priority queue which isn’t blocked anymore it we start working on it before we move to regular stuff.

    The downside is we have some hidden work in progress which isn’t limited in any way. But at least we make it visible and get rid of it as soon as possible. And we don’t move cards back which always create some mess.

    One final advice: if you face this kind of situation once a year don’t bother to rearrange the board. You will need adjustments if, and only if, it is a common issue in your team.

    Read the whole Kanban Story.

  • Implementing Change

    The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.

    A typical discussion about implementing Kanban

    Me: So where do we start?

    Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.

    Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.

    Colleague: So where do we start?

    Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.

    It isn’t about applying recipes

    The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.

    If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.

    It is OK if you just don’t know

    A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.

    What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.

    As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.

    Adjust tools for people, not the other way around

    When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.

    But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.

    That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.

    A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.

    And in case you were curious, yes, we eventually came back to Kanban.