Pawel Brodzinski on Leadership in Technology

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

Tag: kanban board

  • Alternative Kanban Board Design

    It started with Twitter discussion. Then I followed with a post on standard Kanban board designs. Dominica DeGrandis added her perspective as well. By the way, there’s one lesson I have to take from Dominica and from discussion on Twitter – we need to show people different Kanban board designs so they don’t get fixated on a standard and just stick with it.

    In the meantime I was selling Kanban to my wife, as we both believed it may help her in coordinating projects, which is what she does at her workplace. An interesting part is that she works in land surveying industry – something completely different than our everyday reality in software development business.

    And after the discussion she comes back home and tells me that she has to show me something. It appears that it is a picture of her very first Kanban board. Out of curiosity I’m asking her about meaning of different artifacts on her board and it strikes me that she’s done exactly what we want people adopting Kanban to do: she’s used Kanban board examples I drew as, well, just examples. And then she’s come up with her original design reflecting her own constraints, which are pretty different than in typical software projects.

    First, the board.

    Now, that you ask, no, it doesn’t seem like a “standard Kanban board” whatsoever. Where is the process? Where are the limits? If these questions are your first thoughts than you are fixated at least a bit.

    You should rather ask how the process looks like. It’s a bit tricky as for each big task there are a few stages. There are these which have to go one after another, but there also are those which can be done in parallel. In short: process isn’t linear.

    What more, depending on a task process can be built out of different stages. Imagine that for one task you do the whole production, from idea definition to deployment, for other you do only development, and for another only testing and deployment. OK, now you have an idea how it looks like. In short: process isn’t homogenous.

    So the basic idea is that process is defined per task. It can be safely assumed that project manager, or whoever coordinates the work, knows how to cope with each task. What is the role of columns then? Priorities! The old idea of classes of service. The closer the task is to the left side of the board the more important, or urgent, it is to deal with the task.

    Different colors of index cards are used to mark different clients as it is somehow important.

    Then, we have a trick, which I like the most. As process depends on a task it is defined on the fly for each task separately and represented by small stickies attached to index cards.

    Stickies show stages, subtasks, you-name-it which have to be done to complete a task. Green one means the subtask is completed, yellow marks ongoing one, while red color is used for blocked work (which is sort of typical situation). Labels on stickies say what kind of stage/subtask it refers to. In other words they define the process.

    Instead of defining complex graph of all possible states with dedicated Kanban board for each state we just add needed stages as we go. Isn’t that agile?

    Another nice thing about this board is how limiting work in progress can be handled here. We neither have old-school homogenous process where we limit number of tasks per stage nor dedicated boards assigned to different people where limiting WIP is done per board. However we can easily say which tasks/subtasks are ongoing: yellow stickies tell us that!

    We can limit WIP by limiting the number of yellow stickies which are on the board. In a given situation it is actually something which comes very handy, as a number of people involved in doing work is changing pretty rapidly and limits can be adjusted on the fly depending on the current situation.

    What I really like about this Kanban board design is that is addresses all the specifics of the situation in a neat way, yet it is perfectly aligned with all the Kanban principles.

    And this is why I love to work on Kanban with people from outside of IT industry. Since their constraints are so different than ours they come up with fresh Kanban board designs as our standard solutions just don’t work for them.

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

     

  • Don’t Stick to Standard Kanban Board Designs

    As I’m lagging a bit with my reader I read recent Jurgen Appelo’s article on networked Kanban yesterday. An interesting reading, especially that it ignited a few thoughts (and a great discussion on Twitter with Jabe Bloom, Jim Benson and a few others).

    First, Jurgen’s experiments with Kanban boards are perfectly coherent with Kanban principles. We are told to visualize workflow, not to use a specific Kanban board design.

    Second, value stream mapping, which is used as one of the basic techniques by many Kanban proponents, is limiting and it brings you back to a standard Kanban board design. David Anderson avoided using the term in his writings and it wasn’t without a reason.

    Third, we use examples of typical board designs as it is so hard to explain the whole thing without showing these examples, yet it makes people fixated on typical boards and eventually their board designs are suboptimal.

    Finally, I sometimes feel we actively harm people showing them standard Kanban board designs. We prompt them to use one of our well-done solutions instead of looking for the one which is adjusted to their context and reflects their process well.

    Now, this is tricky, we’d like people to start with a clean whiteboard and totally open mind and to come up with something which reflects the way they work, presents important information in accessible and understandable way. It is pretty open-ended task, isn’t it? Unfortunately also the one which may make people totally confused.

    I’m not sure if I’d even be on the Kanban land now if I was starting with such task. I was more than happy to use the most common board design as a starting point. Now I don’t have problems using uncommon designs (just wait to see my portfolio level Kanban boards) but yes, it took some time to get here.

    Either way, my message is: no matter whether you’re just starting with Kanban or are rather advanced don’t stick to standard Kanban board designs. If you have no better idea, use them – that’s what they are for. But please, please, please, don’t treat them as the one and the only way to visualize workflow.

    On a side note: I find it amusing working on visualization with people from industries different than software development. They aren’t constrained with the good old process of building things, which was being hammered into our heads for years, namely: analyze, design, build, test, deploy. And they often come up with uncommon designs on the very first approach. Quite a lesson for us I would say.

  • When Kanban Fails

    In my story from Lean Kanban Central Europe 2011 I promised I will elaborate more on my session there, titled Kanban Weak Spots. The starting point to the session was analysis of a number of situations where Kanban didn’t really work, finding out a root cause and then trying to build a bunch recurring patterns from that.

    By the way I have an interesting observation. Whenever I called for Kanban failure stories I heard almost perfect silence as an answer. It seems everyone is so damn good with adopting Kanban that it virtually never fails.

    Except I’ve personally seen a bunch of failed Kanban implementations. Either I’m the most unlucky person in the world and saw all of Kanban failures out there or for some reason we, the Kanban crowd, are still sharing just success stories and not putting enough attention to our failures.

    Actually, when I was discussing the session with fellow presenters we quickly came to the point that basically every time we think about Kanban failures it can be boiled down to people. However, and it is one of recurring lessons from lkce11, we should address vast majority of ineffectiveness to the system, not to the people. In other words, yes, Kanban fails because of people, but we change the system and only this way we influence people behavior.

    This is exactly the short version of the presentation, inspired by Katherine Kirk and Bob Marshall.

    There is the long version too. Symptoms, which show you that something isn’t working, and if you do nothing about them you’re basically asking for failure. I have good news though. Most of the time you will look for these symptoms in just one place – on your Kanban board.

    Probably the most common issue I see among Kanban teams is not keeping the board up to date. In short, it means that the board doesn’t reflect the reality and your team is making their everyday project decisions basing on a lie. A very simple example: given that there is a bottleneck in testing but it isn’t shown on a Kanban board, a developer would come to the board to see what’s next and they would decide to start building a new feature instead of helping to sort bottleneck out. Instead of making things better they would make them even worse, thanks to the board which isn’t up to date.

    I face the same problem but on a different level, whenever a team tries to make a board showing the way they’d like to work, and not the way they really work. Actually this one is even worse – not only do you make your everyday decisions basing on a lie again but it’s also more difficult to get things back on the right track again. This time it’s not enough to update the sticky notes – you need to fix the design of the board too.

    Another board-related issue would be forgetting about a good old rule: KISS. When people learn all these nice tricks they can use on their boards they’re inclined to use a lot of them. Often way too many. They end up over-engineering the board, which means that they bury important information under the pile of meaningless data. Soon, people aren’t able to tell what means what and which visual represent which situation. Eventually, they stop to care to update the board because they’re basically lost, so they’re back to the square one.

    Violating limits has its own place in hell. Of course it is a matter of your policies whether you allow abusing limits at all. However it is pretty common situation that it is generally acceptable that limits are violated very often, or even all the time. Now, let me stress this: limits in Kanban are the fuel of improvements; if you don’t treat your limits seriously you don’t treat improvement seriously either. Limiting work in progress is a mechanism, which makes people act differently than they normally would. When a developer, instead of starting to build another feature, goes to help with a blocker in testing it is usually because limits told them so. Eventually they learn to predict such situations and act even earlier, before they fill up the work queue. Anyway it all starts with simple actions, which are triggered by limiting WIP.

    The interesting thing is that all these problems can be seen on a Kanban board. The reason is pretty simple: the board should reflect the reality, no matter how sad the reality is. You deal with lousy process the same way as you deal with alcoholism: the first step is admitting you have a problem. Even if your process looks like a piece of crap show it on your Kanban board. Otherwise you’re just cheating yourself and you aren’t even starting your journey with continuous evolution toward perfection.

    There is however one driver of Kanban failure, which won’t be seen on a Kanban board. It’s also my recent pet peeve. Treating Kanban as a project management or a software development approach is basically begging for failure. It is asking Kanban to deal with something which it wasn’t designed for. It’s using a banana to hammer a nail. Seems funny indeed, but if you care about a success, well, then good luck – you’re going to need a lot of it.

    Kanban can be called change management approach or process-driving tool or even improvement vehicle but it doesn’t say a word on how you should manage your projects or build your software. If you don’t build Kanban on a top of something, be it a set of best engineering practices or project management method of your choice, you’re likely to fail miserably. And then you will be telling everyone that you need to have experienced team to start using Kanban and that it wouldn’t work otherwise.

    So here it is – a handful of risks you should take into consideration whenever adopting Kanban in your team. A bunch of situations observed by the most unlucky guy in the world, who actually sees Kanban failures on occasions. However, what I want to achieve with this post is not to discourage you to try Kanban out. Pretty much the opposite. I want you to think of this list and actively work to avoid the traps. I just want you to succeed.

    And this is why you will hear me writing and speaking about Kanban weak spots again.

    Now, even though I teased much of the content from my lkce11 session above, here are my slides.

    Kanban Weak Spots

    By the way, if you happened to be on my session in Munich please rate it.

    If you’d like to see some more content on the subject, fear not. As I’m very passionate about that I will definitely write more on this soon.

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

     

  • Kanban Story: Kanban Board Should Reflect the Reality

    The other day I had a discussion over a Kanban board design. A team has realized the board doesn’t reflect the way they work ideally. We started analyzing what happened. What did actually introduce a disconnection between the reality and the board? We ended up with quite an interesting conclusion. It appeared that the board showed the process as we’d like to see it. Unfortunately in reality the situation was far from optimal. The team wasn’t able to follow the “ideal” process even though they would like to do so.

    A natural reaction was asking a question: should we keep the board as it is and try hard to adjust the way we work to the “right” way, or we should sort of degrade the board to sad reality.

    First of all, I understand why this question pops up. We naturally want to keep the board “better” so as to help us improve our process. We expect the board to be the sign pointing toward the ideal.

    Except Kanban improvements don’t happen this way.

    Yes, you’ve already have my answer in the post title so you shouldn’t be surprised. The board should reflect the reality no matter how sad it is. The reason is simple: when you work with Kanban you make everyday decisions basing on what you see on Kanban board. Now, if the board lies you are likely to make wrong decisions.

    We probably discuss decisions like “whether I should start building another feature or maybe help with testing the other one” or “are we ready to deploy it into production yet?” However, if such wrong decisions stack up they don’t do any good to you, your team or your project.

    Not only is there hardly any improvements at all but you actively harm the project.

    Kanban improvements work differently. People change their behavior or attitude basing on what they see on the board and constraints the board enforces on them and not because the board shows the ideal world. So first, there should be a change in the way the team works and only then we should adjust the board.

    In other words the board should always reflect the reality.

    If you liked this post you may also like the whole Kanban Story series, which is a documentary of one team’s adventure with Kanban.

  • Pull and Push in Kanban

    Kanban is a pull system. Period. In Kanban everyone pulls the task from the previous stage to another. Developers pull tasks which are ready, quality engineers pull tasks which are built, release managers pull those which are tested, and so on, and so forth. Basically every operation on the board happens that way.

    Well, almost.

    There is one interesting thing I realized talking some time ago with Nadia Zemskova in Copenhagen. In one situation we usually have push instead of pull operation. When? Consider a typical Kanban board where a backlog is split into two columns: long-term backlog where you put everything you’re going to build and short-term ready column or to do queue where you put just a few tasks of highest priority at that moment. The board which looks like that:

    Now, what is happening here is usually a part of job of product owner or product manager: they have to choose what the most important thing to be build at the moment is and push them into production process. Um, have I just used the word push?

    But that’s exactly what happens. When working with backlog we don’t just pull first thing from because first we have to decide what is going to the top. When we prioritize features we look though all of them as we theoretically have to compare every possible pair of features and say which one is more important or more urgent. We actually decide what exactly will be built in the first place. We push a bunch of features into to the top of the queue or, in other words, into production process.

    From this point the whole process is pull but the first stage works the other way round. There are two differences between first stage and the rest.

    First, when prioritizing features we usually work on big pool of them – actually all of them which are in the backlog. Later we usually don’t have more than just few features to choose among and very often we can pretty safely assume all of them will be completed soon enough.

    Second, at the beginning prioritization is crucial part of our activity – we make conscious decisions what should go first and what should go next. Later in vast majority of situations we can use simple mechanisms like first in first out and it would work well. At the beginning we can’t go with something like that as we’d be building our software in rather random manner. And that doesn’t sound like a great idea if you ask me.

    That is why we retreat to the good old push to manage backlog.

  • Kanban: When It Is Hard to Map a Process to a Kanban Board

    I was asked for an advice the other day:

    “We have a problem with mapping testing stage into our Kanban board. In ideal world we would test a feature once it is developed, and deploy it on client’s testing environment if and only if every bug we find in the feature is fixed and verified. Unfortunately the reality isn’t that nice – pretty often we deploy a feature even though testing isn’t finished or some bugs aren’t fixed. Sometimes the feature passes user acceptance tests (UAT) even though there are known, sometimes even major, bugs on our side. It introduces a mess into the Kanban board as we have features shown as under testing even though they are already deployed so basing on the board it is hard to say what exactly is happening with a specific feature.”

    One of answers could be: fix your damn development process and bagger off. However I don’t count it as a good answer really. I mean yes, it is broken process which generates mess so we should work on that as well although it’s a longish discussion and it’s definitely not my point here.

    My point basically is: if your process doesn’t suit your Kanban board, adjust the board otherwise every time you look at the board trying to make a decision you will stare at fiction. You don’t want to make decisions basing on fiction, do you?

    OK, in this case a starting point looked something like that:

    The basic problem was that in reality testing was done throughout testing, deployment and UAT phases. Even worse, given that it’s a client who says the feature passed UAT, meaning the exit criteria is acceptance from the client, it was possible that testing was still ongoing while the feature formally was at the right edge of the board (UAT done).

    In short: when looking at the board it was impossible to say which features have been tested, which are being tested and which are yet to be tested.

    A question: how to map such situation into linear process, which we usually have on Kanban board? Well, you basically can’t do it. Fortunately, and correct me if I’m wrong, we were never told that we need to map everything into a linear process. Actually we weren’t even told we need a Kanban board. We were just told to visualize workflow.

    Coming back to the point, we ended up with a conclusion that in this case testing is an ongoing activity happening concurrently during a big part of the whole process. Digging deeper we decided that basically there are only two types of bugs related to any feature: these which would block us to use the application in production and those which wouldn’t. It doesn’t really matter whether a bug is minor but the client insist on fixing it or an issue wasn’t found by the client but from our perspective it is a major problem – we just wouldn’t push the application with this feature into production.

    What struck us at that point was that such information can be easily attached to a feature: we potentially could use a feature safely or not. It’s not a stage of the process – it is a status of a feature. Why shouldn’t we show it as a feature status though? Say, a small red sticky note attached to a feature when it isn’t good to go and a green one when it is.

    To be perfectly compliant with Kanban rules we should make the policies explicit – what does it mean that a feature is or is not good to go? At this point, it was pretty easy. A feature isn’t good to go either when its testing wasn’t completed or we have at least one unfixed blocking bug submitted to this feature. In such situation we should have a small red sticky attached to the feature. On the other hand, a feature is good to go when its testing was completed and there are no open blocking bugs. In this case we attach a small green sticky to the feature.

    One more tweak which was pretty obvious: as we want to distinguish features which we’ve started testing from those we haven’t, we attach small red sticky exactly at the moment when testing starts.

    The board after changes looks like that:

    Looking at the board you can tell that feature C went through internal tests and there are no known blocking bugs. On the other hand, feature D which is at the same stage of the process (UAT) isn’t good to go, for whatever reasons. We also have a situation where feature B, which passed user acceptance tests (UAT) have a red sticky attached to it, which means there is still something wrong with it – most likely a bug found internally but the one which is important enough that it has to be fixed before we consider a feature done-done.

    We can also easily distinguish features which are being tested from those which aren’t. Features F and H are of the former group and features E and G are of the latter. Note that feature E is on the later stage of the process than feature H and yet is wasn’t touched by a quality engineer even though the feature H was. By the way: it may be perfectly reasonable decision when you have to make constant tradeoffs what is more important and goes first and what is less important and waits for its turn.

    To summarize: what we basically did was we came back to roots. When teams start playing with Kanban one of the first things they do is mapping their current process into a Kanban board. It seems this activity isn’t exclusive for the first day only. On occasions we notice that our Kanban boards don’t precisely describe the process we follow and this is exactly the moment to review and improve the board.

    Another lesson here is that you shouldn’t try to adjust your process to simple constraints the basic board sets. If your approach is: the reality should suit my board and if it doesn’t so much the worse for reality, your board will quickly become irrelevant and you will get no value from it whatsoever. If the most basic methods can’t help to map your process into the board look for methods which work, even if it takes some more effort and creativity. The board itself is as flexible as it is physically possible. Given that you use the physical board that is. Use this power.

    And then, once you solved your own problem, don’t forget to improve constantly. In this case I have at least a couple of ideas for improvements but there’s no point in applying all the new ideas unless you validate the older ones. With the right mindset there will be a lot of occasions to try out new concepts with no doubt.

    If you liked the article check out The Kanban Story – a documentary of discovery and implementation of Kanban in one team.

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

     

  • The Kanban Story: Skipping Part of Process

    The more complex your process, and your Kanban board, becomes the more likely it is you’re familiar with the following situation: you work on a task which doesn’t go through each and every stage of the process so you’d like to skip one of two of them.

    Consider a very simple board.

    What happens when we build a feature (feature E) where there’s nothing to be documented? What to do with a sticky note on the board? Should the process be changed?

    What happens when we have research task (feature H), which we don’t know outcome of, and we want to put it on the board? What if after research (development) we decide that it’s not going anywhere to a product? I mean we’re done with development but we don’t plan to do anything more about the task: neither testing, nor documentation, nor deployment.

    Before we go further I have another question: does this specific situation happen frequently? If not then don’t even bother. If it is an exception then treat it like exception. You don’t get points for following the process religiously.

    However, if it happens at least from time to time you should probably stop and think. One idea is redesigning the board in a way which incorporates such situation. Except you’ll likely end with conclusion that you have two different processes out there: one for regular development and another for research (or no-documentation development). So we come back to a question what to do with that?

    Well, you can split tasks into two boards but this way you either loosen your limits, e.g. additional limit for one research task, or you lose some flexibility, e.g. splitting your current limits among two boards. Either way I’m not a fan of the approach.

    What we ended up with in such situations was just skipping parts of the process which were irrelevant. No documentation? The sticky note goes directly to documentation done column instead of testing done. No follow-up after research whatsoever? Um, seems like we’re done done with this one so we should probably put the sticky note in the last column.

    Again, we don’t get points for being ideally adjusted to the process. The board should reflect the way we really work and it shouldn’t constrain us too much. If this is how things really look like why shouldn’t we just show it?

    Skipping parts of the process on the board for specific tasks is an option to consider. One advice though: as with any other movement happening on the board, make transition criteria explicit. If something goes directly from development to done column everyone in the team should be able to tell precisely what it means. And of course the answer should be basically the same each time.

    If you liked this story make sure you check the whole Kanban Story series.

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

     

  • Visualization: Don’t Get Attached to a Specific Tool

    If we are in Kanban world when we think visualization we see a Kanban board. We see a process mapped into columns with limits attached to them. We see sticky notes, which represent minimal marketable features. We see additional visuals which help to show priorities, blockers, people who are responsible for a task etc.

    We mentally substitute visualization with the Kanban board.

    To some point it works great. Well, after all it’s not without the reason that a Kanban board, or more generally a task board, became a tool of choice of so many teams.

    However, it was never written that one of few Kanban rules is using Kanban board. Please point me to such advice if I’m wrong. Anyway, the rule is about visualization and Kanban board is only one of possible means to this end.

    One of great lessons from Kanban Leadership Retreat was how many different approaches are possible in terms of visualizing work. Actually typical Kanban board looked kind of boring among that bunch of great folks as basically everyone had at least a couple of ideas how it can be done differently, depending on a specific situation of course.

    The message is: it doesn’t really matter how you visualize your work as long as you are successful at that. Task board or Kanban board is fine, and it usually is very intuitive to use by a team, but quite often there are better ways to do it.

    Consider a situation where you deal with a lot of small tasks. Do you really need to put each and every 5-minute-long tasks onto a post-it? Maybe there are more efficient ways to deal with them?

    On the other hand, what about tasks which last long months? As I’m playing with project portfolio level Kanban it is a very timely question for me.

    A classic form of the board, which I currently use, isn’t likely the best possible approach. I have at least a couple of ideas how to change it. And yes, now that you asked, I was totally inspired on Iceland event to improve my project portfolio Kanban board.

    Probably it won’t be a Kanban board as we know it any more. I will still use stickies and whiteboard but it’s not going to look like any other board I’ve had so far. And that’s the real lesson I got on Kanban Leadership Retreat.

    Don’t get attached to a specific tool. Kanban board is just a tool. Visualization is way, way more than that.

    It’s kind of funny to realize how we learn to treat some things as obvious, like having Kanban board as a part of introducing Kanban. Fortunately, at some point of time we just realize it’s only a tool and we should use it as long as it is useful. If it’s not it’s better to use another one.

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

     

  • Visualize Everything

    One of Kanban rules is visualization. This is one I like the most since I just can’t sit at ease next the the clear whiteboard. I have that urge to grab a marker, a bunch of sticky notes and make the board a little less white.

    Anyway, visualization isn’t the concept unique for Kanban (what is after all?) and recently you probably hear about it very often. It was one of returning messages across this year’s ACE Conference and it was very similar at GOTO Copenhagen – Dave Thomas pointed it as one of key factors of successful teams. And then of course there was all-day long Kanban track which, as you may guess, was covering visualization over and over again.

    So the message is: visualize it! Show what you’re doing on the board. Make it visible for everyone in the team. Make it visible so everyone knows what’s happening. Make it visible so it’s hard to ignore that, especially when things go wrong.

    We are inevitably heading toward the question: what “it” is?

    Well, “it” is pretty much anything. Because it’s not just “visualize it” – it’s “visualize everything.”

    Stages of your process? Checked. Limits? Checked. Who does what? Checked. Blockers? Checked. Cycle time? Checked. Priority? Checked. Area or module of a project? Checked. Emergency state? Checked. And this is only the beginning. These are actually the most obvious examples. Add to your sticky notes any information a team will need. Put it on the board. Visualize it! It is a way of communication. And the one which isn’t intrusive.

    It may sound a bit counterintuitive but it works miracles. My recent playground is project portfolio level Kanban and the interesting observation I’ve made already is how the board helps me every time I need to plan new projects or make a tradeoff to respond to changing situation. It even tells me when I need more people faster than our budgeting software, which we typically use for this purpose.

    The reason is simple: visualization just works. So go, visualize everything!

    Advertisement: Want to have gorgeous Kanban boards in your PowerPoint presentations? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

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