Pawel Brodzinski on Leadership in Technology

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

Tag: kanban board

  • 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.

  • The Kanban Story: Small Tricks Do the Job

    On my AgileCE presentation on Kaban I said that if your Kanban board doesn’t evolve over time you should treat it as a warning sign. It possibly means you don’t improve workflow. And since there’s no by-the-book implementation of Kanban you should experiment all the time.

    So what has changed on our board recently?

    I can start with things which remain the same – this time we didn’t change structure of workflow. Columns are exactly the same. Limits stand still. But you shouldn’t consider at Kanban board being just a list of stations with appropriate limits attached. Kanban board is a single most important tool you use in Kanban. You look at the board a number of times daily. The more you see there the better is the board. This doesn’t mean we should make our boards completely cluttered. After all, if there’s too much in one place you stop seeing anything but clutter.

    OK, you already know we added something to the board. A few things actually.

    • Different sticky note colors. At the beginning we were working mainly on a single project. Recently we forked our efforts and now we work on 3 different applications. Getting separate color of sticky notes for each project was no-brainer.
    • Blocker flag. Visual mark of blocked feature is a small red sticky note attached to the main card. This is another obvious trick. We added it when we faced the first issue being blocked by external source.
    • Color magnets. We use whiteboard as our board. To make it visible who actually works on specific feature we put color magnets on sticky notes. Each team member has their own color. (Mine is white since I’m such an innocent guy.) Magnets give us quick information about load of each of us at any given moment. Besides, they keep cards from falling down.
    • Dates. We write two dates down on sticky notes. First when we start working on feature and another when we’re finished with the task. We keep forgetting about these dates, since this is pretty fresh idea, but that’s not a problem to fill them after a couple of days when we still remember well when we started/finished work on MMF. This trick helps me to report retroactively cycle time. Earlier I had to dig for information in task management system.
    • Numbers. Each sticky note has its own unique number. This makes it easy to link anything with MMF. A bug? We start with a number and everyone instantly knows which feature is defective. A task? We start with a number and we know which development tasks are related with MMF so we can tell how much work is remaining. We even use them in discussions: “Have you finished ninety seven yet?”
    • Excel sheet as backup. One day I thought what would happen if our cleaning lady would, well, cleaned our board. Man, we would be doomed. So I made simple sheet where I add information about every sticky note, which makes its way to the board. It is also a place where I store information about cycle time etc so it serves as reporting tool too.

    None of these improvements is significant. A few are pretty obvious. Yet when we were starting with Kanban we didn’t use any of these small tricks. They emerged as tiny improvements of the board and the process. And these small tricks do the job. Even though neither of them brings much value on its own they add up and make the board significantly better.

    As additional reading learn how our Kanban board evolved. Check out the whole Kanban Story too.

  • The Kanban Story: When and Why We Abuse Limits

    We have limits on our Kanban board. This isn’t really a news. Sometimes we abuse them. Since Kanban doesn’t force you to stick to the limits always-and-by-all-means it shouldn’t surprise you much either. However the interesting thing is when, why, how and how often we do it.

    I think I should start with stating that our limits are rather loose. It is technically possible to have as many as 15 MMFs in progress across the board. It never happened and it won’t ever happen, but still it is technically feasible. That’s crazy huge workload for 5-person team.

    But we happen to have limits like that and it’s not without a reason. If you recall our pseudo-iterations triggered by VCS issues you know we ship our software in packages of few (typically 2 or 3, sometimes 4) features. This means we sometimes move a group of 4 features across the board. For example it happens after deployment when we move features from testing complete to live stage. OK, enough of introduction about our limits.

    When do we abuse limits?

    It sometimes happens we change content of our deployment package on the fly. For example we have a package of 4 features in testing (either ongoing or completed) and then our crazy product owner (aka me) comes with an idea to add another tiny but super-important and super-urgent feature. Of course we could wait till another pseudo-iteration is deployed but sometimes it just makes more sense to add it to the old package instead of waiting another 13 days for another deployment package.

    We also had a painful MMF blocked for long weeks by our subcontractor. This practically reduced our limit in development by 1 for a longer time. It happened once that we decided to break this reduced limit acknowledging the fact we can do nothing more about blocked feature.

    Why do we abuse limits?

    Two words: common sense. If it is more reasonable to break the limit than to adjust whole work to our board we don’t try to perform some artificial actions just to be compliant with the process.

    We aren’t here for the board. The board is here for us.

    How do we abuse limits?

    First we all discuss the decision. Breaking the limit shouldn’t be treated as a normal thing. It is an extraordinary situation. So we collectively decide whether in this very situation breaking the limit is a better solution or we should rather stick to our constraints.

    This serves two purposes: one, we make this decision very consciously and two, we stress that it isn’t a typical and easy-to-accept situation.

    It happened once when I found the board with a broken limit with no discussion whatsoever about the fact. I fired two third of the team and burned whole office… Well, maybe not really, but man, I wasn’t happy. I wasn’t happy at all.

    How often do we abuse limits?

    This is the question you were waiting for, weren’t you? Pretty rarely I’d say – thrice a year. Well, describing it as an average result is a bit of abuse itself since it was our first year with Kanban. But you can see this is an extraordinary situation.

    To summarize, limits on our Kanban board aren’t a sacred cow. We break them if it does make sense and we decide it is a better solution than sticking to them at all cost. On the other hand we try to make breaking the limit an uncomfortable situation (you know, all this discussion, talking with each other… yikes) so we aren’t tempted to do this very often.

    So far it works pretty well.

    Read the rest of the Kanban Story.

  • The Kanban Story: Measuring Lead Time

    During AgileCE conference I had a discussion with Robert Dempsey about measuring lead time. I never really thought much about the way we count lead time in our team and talk with Robert triggered some doubts.

    What We Measure

    As you already know on our Kanban board we have backlog, todo queue, several steps describing our development and deployment process and finally done station.

    OK, so when do we stamp the starting date for the feature? We do it when the card goes from todo queue into design station, which is the very first column in our development process.

    When do we stamp ending date then? You may take your best guess and um… you’ll be wrong. No, not when the sticky note is moved to done column. Actually we mark ending date when a feature makes its way to live column which is third station from the right.

    And this is different from what you may have heard from Kanban gurus out there. Don’t blame me, I’ve already told you thought-leaders don’t know it all.

    What we measure is time which passes before we start actual work on feature to the moment it goes live.

    What We Don’t Measure

    What is left behind then? First and the most important thing is the time feature spends in todo queue waiting for some developer to become free and start working on it. If you were trained by the father of Kanban – David Anderson – you’ve probably heard something different but stay with me, I have a good explanation. Or so I guess.

    Another thing which is left outside is the last part of our process. There is documentation station where we (surprise, surprise) update documentation. This is done after pushing new version to production.

    It looks like we cut something on both ends to make our lead times look better, doesn’t it? Anyway what we gather as lead time doesn’t really describe time which passes from the moment of decision to build the feature to the moment it is done-done. Thus another question arises.

    Why, Oh Why?

    The way we measure lead time came in natural way but chat with Robert forced me to make some explanation up to justify our practice.

    Time Spent in Todo Queue

    We left time spent in todo queue out basically because content of this station is changing pretty often. Sometimes feature lives there just for a day or so just to go back to backlog when priorities change. And believe me they do change every now and then. Sometimes a feature stays in todo queue for a longer time as it is always pushed to the second or third place because, well, priorities change.

    There is another reason too. The basic reasoning for adding time spent in todo queue to lead time is that you should be able to tell your customer how long it would take from the day 0 (when they tell you they want the feature) to the moment they get it in production. It is pretty rare case when developers are able to start working on a new feature immediately so it is natural that some delay will appear when feature is waiting for a free developer.

    I’m not convinced though. Actually very much depends on additional circumstances. The feature the client is asking for may be the only high priority thing to do at the moment but it is pretty unlikely. If the client asks just for one feature lead time will be different than if they asked about a list of ten features. If you have limit of 3 in todo queue you would need to put 7 features in backlog anyway and time they spend in backlog won’t be measured.

    If you have a few clients and you need to balance your workload among them it becomes even more complicated since product owner (or whoever is your priority setter) has to decide which feature can be put on the top of the todo queue, which can occupy second or third place and which has to go into backlog.

    Basically in any situation but the simplest measuring time spent in todo queue wouldn’t help us much and that’s why we decided to exclude it from lead time.

    Time Spent on Documentation

    With documentation the situation is a bit different. Documentation isn’t a real part of our product. We create it for our internal reasons – to make life of our sys admin easier and to avoid problems if he was hit by the bus. This means that, from client perspective, our product is complete as soon as it goes live. Even though we have to do some housekeeping later it doesn’t affect our ability to deliver.

    Theoretically it might be a problem if documentation phase would be time-consuming and would steal time we’d prefer to spend for something else, namely deployment or testing. However looking at the past in the team it isn’t a problem so we may safely throw documentation out of lead time.

    The next thing is using lead time to create some estimates but that’s the subject for another post.

    If you liked this post you should like the whole Kanban Story too.

  • The Kanban Story: Kanban Board Revisited

    Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.

    We decided to start with something simple and then adjust things as we go. We redesigned Kanban Board because it is meant to be changed. But even then it wasn’t the final shape.

    When we left the board last time it looked like that.


    What was the problem?

    On a general level we switched to more frequent deployments. At the beginning we didn’t have any system in production but it has changed. Sort of. Anyway our endpoint was no longer “ready to ship” – we wanted to see new features live.

    Before the change we were marking MMFs as “in production” by throwing sticky notes out. The problem was there was no limit for “ready to ship” station, so features could wait there on a huge stack waiting for deployment. Something rather opposite to what we’d like to see.

    The other thing which pinched me was documentation. We had a stage for this purpose but it appeared we were documenting after we’d pushed feature into production. This was perfectly fine since we don’t sell boxes with up-to-date documentation inside and it was no problem at all to have documentation updated a couple of days after deployment. The problem was our Kanban board didn’t correspond with this.

    After playing with some ideas we came with version 3.0 of our Kanban Board.


    What has changed?

    The left part hasn’t changed at all. We were happy with it.

    The first change was merging “test” and “ready to ship” columns into one under the name of the former. What we got was testing stage which was separated into ongoing and completed phases. When a feature was tested it was ready to ship. We no longer expected documentation to be updated before shipping since we weren’t working like this anyway.

    Another thing was adding “live” column which means feature was successfully deployed. I didn’t like the idea of adding another “deployment” station since deployment is very fast in our case.

    Documentation was left as the last but one column and at the end “done” station emerged. After all it is such a nice name for a column.

    Limits

    Redesigned part of the Kanban Board reflected our workflow much better but required also limits adjustments. Instead of rethinking whether we should add 1 here and subtract one there I wiped out all limits and rethought them from the beginning.

    Limits of 3 for “todo” and 4 for “development” had worked well so they got their way back to the board.

    The next one, and the hard part, was limit for “live” station. Remember our pseudo-iterations? Because of this approach we deploy a few features at once. So far there were two or three in each package. However it happened a couple of times that an emergency feature was added during a pseudo-iteration. Since this kind of feature was meant be included in the same deployment package this made a maximum of 4 MMFs possibly being shipped at once. That’s how “live” stage got its limit.

    The same reasoning applied to “test” station. Since it was possible to move 4 sticky notes at once to “live” column, they all had to be taken from the previous one, thus we couldn’t set there anything less than 4. We didn’t want to set anything more either, so the lucky number was exactly this: 4.

    “Documentation” got a limit of 2 since it’s often convenient to document 2 corresponding features at the same time.

    Looks like we get more and more columns over time. I just wonder whether that’s a good thing.

    If you liked the post you may want to read the whole Kanban Story.

  • The Kanban Story: Kanban Board Evolution

    Our initial Kanban board was pretty simple. It looked like that.


    From the beginning we were set up to experiment and adjust it on the way. Here’s what we have changed.

    1. Documentation

    First thing was documentation. I know that’s not even trendy anymore to write documentations but yes, we do it. It helps us and if you add that we’re considering selling our products for the big companies which require documentations it isn’t even a matter of choice. Anyway, this was the part of our process and was usually started during testing and finished after testing was done.

    The problem was documentation was sometimes omitted and specific features could go live undocumented. The answer was another column which appeared between Test and RTS. We set limit to 2.

    To be honest after some time I’m not very happy with the column, or rather the way we incorporated documentation to the Kanban board, but for the time being it’s here. If it changes I’ll definitely let you know.

    2. Design

    Another issue which appeared was connected with research we sometimes did. That time it was about choosing a framework to support web application development in Java. It wasn’t development of a specific feature, but rather a prerequisite to do one. However we wanted to see some kind of representation of the fact on the board.

    So we added Design sub-column for Dev column. During design stage we split sticky-note feature to development tasks, adjusted architecture when needed and did research in cases like mentioned one. Usually sticky note made its way through Design stage very fast, but occasion it stood there for a few days so we knew what’s actually happening.

    Design didn’t get its own limit but was incorporated into Dev limit since it more an early part of development or preparation for development than a separate stage which result in some kind of formal design document or something.

    3. Testing limit

    After clearing initial overload in test stage limit of 4 seemed to be a bit too loose. I also believed it gave too little incentive to push our post-its to the right side of the board as fast as possible. We changed a limit to 3 and it appeared as a good decision since only once there was a threat to break this limit, but quick reaction allowed us to avoid that.

    After all these changes our board looked like that.


    This is definitely not the final shape of our Kanban board, but we aren’t in hurry when it comes to adjusting it. It is much better to do just one change at time and see how it affects your work. Then you decide whether the change was good or not. That’s how above adjustments were done – incrementally one after another. And if you do your changes I encourage you to choose the same approach.

    Check out the previous and the next version of our Kanban Board as well as the whole Kanban story.

  • The Kanban Story: Kanban Board

    One of stages of one-afternoon Kanban setup we did was creating our own Kanban Board. We just discussed what we wanted on the board adding columns which appeared reasonable for everyone.

    This is what we came up with.


    To describe stages:

    • Backlog is a big bag where I willingly throw in anything anyone wants our project to have. Now we have the best product around. It will virtually have every feature in the world. I would also be a best Product Owner around. The guy agrees on every feature idea you could possible come up with. Unfortunately he can’t say when the product will have all these features.

    • Todo is a short list of current top priority tasks which aren’t yet started. It usually changes every time I come back from a meeting with one of our customers or partners. I keep the rule that whatever is on the top of this column is also the most important at the moment.

    • Dev, which comes from development, is a group of two columns: one is ambiguously named Dev, which comes from “in development” and another one states CC from “code complete.” The former groups tasks which are under active development. They make their way to the latter after developer’s tests. This couple is grouped since code complete is just a technical stage to tell us specific functionality is ready.

    • Test is what it sounds it is. Testing. Checking whether we could deploy version if we wanted to. Finding bugs and fixing them. On and on.

    • RTS comes from ready to ship. For the moment we set up the Kanban Board we weren’t planning to have regular deployments in production environment so we just wanted to have versions which would be possible to ship if we needed that. Whenever something reaches RTS column the work is considered to be done.

    Then, we wrote down all tasks which weren’t yet completed, including these being under development and these which were in plans only. Every task was written on a single post-it note and was posted under relevant column.

    We ended up with a post-it in Todo, two in Dev, one in CC and six in Test. The overwhelming rest was in Backlog. And yes, long Test column made our problem with finishing tasks painfully visible.

    When we were done playing with sticky notes it was time to set limits for each column.

    • Backlog doesn’t have any limits. That’s natural. Hey, I don’t want our product to lack any feature. Give me all of them. And I mean all.

    • Todo column was limited to 3. I think this is good maximum queue length – it makes clear short-term perspective. As it appeared later quite often it was hard to decide which sticky notes would make their way to Todo column and which would not. And it wasn’t rare when something was going back to Backlog before guys here were able to start working on this.

    • Dev was limited to 4. This included sum of both Dev-Dev column and Dev-CC. Basically we came up with the number assuming it’s still acceptable that each developer has one task completed (CC) and another one started (Dev).

    • Test was a biggest problem. We finally set the limit at 4. We knew 6, which we had in Test at that moment, was too much. On the other hand we didn’t have any clue what should it be. I was far from setting there a number which is too low and supporting fiction. So we used some guesstimation and use 4 as our lucky number. And it created an instant incentive to work hard on cutting this queue a bit.

    Finally our first version of Kanban Board looked like that:


    This is by the way much simpler board than Henrik Kniberg proposes as a kick-start example. Personally I encourage you to start as simple as possible. You’d adjust things later on. Henrik’s proposition is too complex for the team which isn’t familiar with Kanban. It pushes too much detail to the board which makes it hard to read.

    Read the whole story from its boring beginning up to this point, where things hopefully become interesting enough to keep you irresistibly waiting for the next chapter. Check also version 2.0 and version 3.0 of our Kanban Board.