Pawel Brodzinski on Leadership in Technology

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

Tag: kanban board

  • 5-Minute Board Test

    I discuss different Kanban boards or task boards with their teams pretty often. It’s not uncommon for me to see a board of a team that I know nothing of. I like these moments. I typically challenge myself to make sense out the visualization as I stare at it.

    Some parts are rather obvious. Typically the process isn’t that difficult to figure out. Usually I can tell who is working on what at a glance too. On the other hand something that should be obvious, but often isn’t, are classes of service – what they are and which items are of which class. And then there are lots of small different artifacts like blockers, comments, subtasks and what have you. Those do require some additional explanations.

    One of common sins of teams adopting Kanban is making visualization too complex. We do say visualize everything, but obviously it means “as long as it adds value.” Boards tend to get more and more complex over time as we typically want to track more information as we understand better how the work gets done. We really don’t need to complicate things more than necessary on the day one.

    So what makes a board a good one? The board is good when it does its job as an information radiator. This happens only when it is easy to comprehend and understand for the team members.

    This is a core of my 5-minute test to verify whether the board is designed well. The test is simple.

    A random team member should describe what is happening on the board to an outsider – someone who neither is a part of the team nor works with it regularly. If the outsider has any questions about specific things in the board they should ask and get the answers from the team member. The whole activity is time boxed to 5 minutes (thus the name).

    The board passes the test if at the end of the task the outsider can tell what exactly is happening in the team: who works on what, what are the problems (if any), what is the progress of work, how the team knows what to do, etc.

    One could argue that for bigger, more complex boards 5 minutes is not enough. I don’t agree. When we are interacting with the boards we rarely have more than just a couple of minutes. Of course team members would know part of the design without any explanation. That is why I’m giving an outsider full 5 minutes.

    The more stuff there is to take into consideration when making routine, atomic, everyday project decisions the bigger the chance someone would misinterpret part of that. That’s the point where understanding the board, and the process, isn’t fully shared across the team anymore. That’s the point where people start acting differently despite identical input.

    This is exactly the problem we tried to address when introducing information radiators in the first place. If the board doesn’t solve that problem it simply doesn’t work.

    Would your Kanban or task board pass the 5-minute test?

  • Better Standups

    I never fancied the standard standup schema. I mean I see value in sharing what the team did yesterday what the team is going to do today and what are the problems the team has.

    Except these questions aren’t answered on a typical standup.

    The first problem is that we answer what specific individuals have done and will do. In any but smallest teams it’s the wrong focus to have. I mean if there are two or three of us it’s very likely that such updates are meaningful. With a couple more people we gradually lose track, and eventually interest, in what exactly is happening in the rest of the team.

    At the same we should be focusing on what is important for the team which may be something no one mentions because for example the biggest pain point is on a plate of someone who is absent or overwhelmed with other stuff that just doesn’t allow them to focus on the real problem.

    The second problem is that very rarely someone really answers to anything by first two questions, namely the issues part is often omitted. I like tweaking the third question, for example to something that Liz Keogh proposes: ”what I would rather be doing.” It helps only a little bit though as it’s almost as easy to avoid this question as the original one.

    The third problem is that with a bigger team a standup becomes just long and boring, and whenever a couple of people exchange a few sentences about any specific bit of work it shuts down almost all the rest of the team instantly.

    A very typical change I introduce is a standup around a board, be it a task board, a Kanban board or what have you.

    Then the discussion is mostly around important stuff that is happening right now and is visualized on the board. A typical pattern is: blockers first, expedite items second, stalled items third and then all the rest. I covered more elaborate version of this approach some time ago.

    Such an approach means that not everyone, every single day speaks up. But whenever anyone has a problem or is just trying to solve an issue too long there’s definitely an update from them on the way.

    Then, there’s always a call for action regarding important stuff, even if it just so happens that a default person for that item is unavailable.

    This means that standups around a board encourage collective ownership of work.

    In fact, there are way more call for action situations as this form of standup basically focuses on solving issues. This often means helping each other, taking over bits of work from others, etc. Whenever someone has hard time coping with all the stuff that waits for them they usually get an instant help.

    This kind of a standup is also shorter than a classic one. After all you don’t mention all the boring stuff that just goes as planned – everyone can see that on the board, so what’s the point anyway?

    It also is an occasion to catch all the inconsistencies on the board so it serves another purpose too. You don’t get that from a classic standup.

    I would also point that this approach does very good job in terms of keeping work in progress low. It simply changes the dynamics of the discussion toward everything that is in progress from a team perspective instead of work started by individuals. The latter doesn’t take into account all the waiting queues.

    Finally, it scales up pretty well. You can run such a standup with a dozen or more people and it still fits nicely 15 minute slot. It’s not rare when you need only one third of that even with such a big team.

    The impact of changing the standup pattern is almost instant. All in all, it makes standups more valuable for the team. Try this approach, especially when you struggle with the current one right now.

  • Pitfalls of Kanban Series: Stalled Board

    One of signals that something may be wrong with a Kanban implementation is when the Kanban board’s design doesn’t change over time. Of course it is more likely that rapid changes of the board will be happening during early stages of the Kanban implementation, but even in mature teams a board that looks exactly like it did a year ago is sort of a warning light. For very fresh Kanban teams I would expect that board design would differ month-to-month.

    Actually, a stalled board is more a symptom than a problem on its own. The root cause is likely the fact that the team stopped improving their process. On one hand, it is a common situation that at the beginning the potential for change is significantly higher and it diminishes over time. On the other, I’ve yet to see a perfect team that doesn’t need to improve their processes at all.

    In such cases, what can one do to catalyze opportunities to discuss the board design?

    One idea that comes in very handy is to watch for situations in which any team member takes an index card to update its status and, for whatever reasons, struggles to find the right place on the board to put the card. It may be so because there isn’t relevant stage in the value stream, or the work currently done isn’t in line with the rest of process, or a task is sort of specific, or what have you. This kind of situation is a great trigger to start a discussion on the board’s alignment to what the team really does and how the work is done.

    Another idea is to dedicate a retrospective just to discuss the board. Such a constrained retro can be a natural opportunity to look for board-related issues or improvements in this area. I think about a class of issues that might not be painful enough to be brought as biggest problems to solve on regular basis, but, at the same time, we know that tiny changes in the board design or WIP limits can introduce tremendous changes in people’s behavior.

    There is also a bigger gun – a significant board face-lift. Following the idea that Jim Benson shared during his ACE Conference keynote, teams find it easy to describe and define about 80% of processes they follow. The rest seems vague and that’s always a tricky part when you think about value stream mapping. This is, by the way, totally aligned with my experience with such exercises – I’ve yet to meet a team that can define the way they work instantly and without arguing.

    Of course, introduction of visualization helps to sort this one out although it’s not that rare that we fall into a trap of idealizing our flow or just getting used to whatever is on the board.

    Then you can always use the ultimate weapon and redesign your board from scratch. Probably people will have in mind the board you’ve just wiped out and will mimic it to some point. Anyway, odds are that if you start a discussion from the beginning – the moment when work items of different classes of services arrive to the team –some new insight will pop up, helping you to improve the board.

    On a side note: it is also a good moment to discuss what you put on an index card exactly; I treat it as an integral part of board design, as you will need a different design for standard-sized work items and different for highly-variable projects on portfolio board.

    Read the whole Kanban pitfalls series.

  • Visualization Should Be Alive

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

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

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

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

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

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

  • Pitfalls of Kanban Series: Wishful Thinking

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

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

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

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

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

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

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

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

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

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

    Read the whole Kanban Pitfalls series.

  • The Project Portfolio Kanban Story: Better Board

    When applying Kanban on project portfolio level you’re dealing with different challenges than in case of standard Kanban implementation on a team level (if there even is such a thing). Both the flow dynamics and task granularity is very different, thus you need to focus on different aspects when designing Kanban board.

    This is basically why typical Kanban board design will often be suboptimal.

    Portfolio Kanban Board 2

    At the same time the biggest challenge you face on project portfolio level is defining and applying WIP limits. For the time being my thoughts on a subject are that depending on a specific environment teams would be choosing very different measures to manage WIP on portfolio level. However, as we as a community still lack experience from addressing different scenarios I’ll focus on the path I’m following. After all the story format I chose requires that.

    In my case the most reasonable thing I was able to come up with was a number of people involved in project work. Unfortunately the scale of the team (more than 130 people) didn’t allow me to use straightforward approach and scale up WIP limits with numbers.

    Instead of continuing my struggle to find a perfect measure that suits the current board I decided to redesign it completely.

    Whenever you read about Kanban you learn that it is an evolutionary approach. Kaizen and all the stuff. However one advice I have on designing a Kanban board in general is that when you start running circles with board evolution and see little or no improvements throw the whole board out and start from scratch. From one point of view it can be considered a revolution (kaikaku) but from another: you don’t really change your way of working, you just try to visualize it differently.

    Either way I took my own advice and started from a clean whiteboard. I also remembered another advice: not to stick to standard board designs. This is what I ended up with.

    First, there is no value stream or process in a way we understand it on a team level. Since the flow of index cards wasn’t dynamic I decided this isn’t information I should focus on that much.

    Second, on horizontal axis, instead of process there is a time line (monthly granularity). As variability of project sizes is huge I decided I need some sort of time boxes which I measure WIP against. With very few small engagements, ones that take us less than a few weeks, monthly time boxes looked reasonable.

    Third, I created swim lanes for teams. We don’t have 130 generic engineers, or Average Full-Time Equivalents, or whatever other inhumane label you can think of. We have teams that we strive to protect and teams do have specializations. It means the context of a team is very important and if it is important it goes to the board, thus swim lanes.

    Fourth, having such board construction I had to change my approach to index cards. Instead of having a single index card representing single project I ended up with territory-driven approach. A project covers a territory both in terms of team(s) and time. Looking at index cards with a project name you can instantly guess which team is working on the project and how long it’s going to take them. And the best part: a size of index card in any given month represents roughly how big part of a team would be involved in work on a project. This way we can easily show a few smaller projects as well as on big or any combination of those two.

    Fifth, as one of Kanban base concepts is pull it is represented by backlog area – green cards on the left side of the board. These are projects that aren’t yet started. The specific swim lane they are neighboring show preferable team to work on a project. However, it rarely is such a direct dependency: this team will do the project as there is no other one suitable to do the job. Most of the time we assume that another team can build the project too. Each time a project goes into development we decide, at last responsible moment, which team will take it.

    Of course there are some nice additional flavors here as well. Violet and yellow index cards differentiate maintenance projects from new ones. Green card are for projects that aren’t yet started and once they are we switch to yellow. Red index cards represent overrun in projects that are late. As we work on fixed price, fixed time projects we roughly know up front how much time and people we want to invest into a project. When something bad happens and this plan changes we show that. After all we put more attention to challenged projects.

    A simple fact that we are working on fixed time, fixed price projects doesn’t mean our arrangements never change. They do. Any time something changes we just update it on the board, same as we’d do with any other board. We just keep the board updated as other way its value would diminish.

    This Kanban board design definitely tells more than the initial one but I started this whole revolution to deal with WIP limits. What with them?

    Well, there still aren’t explicit WIP limits. However at this moment there are implicit WIP limits and information about them can be pretty easily extracted. Considering that I use territory-driven approach to index cards WIP limit is show by vertical axis of the board. Each team has a limit of one full-sized sticky note (representing whole team) per month which can be split in any way.

    In other words we won’t start another project unless there’s some white space that this project would fit into as white space represents our spare capabilities. Actually, it may be a bit of simplification as on rare occasions there are project we just start, no matter what. But even then we either can make such project fit the white space in a reasonable way or we need to make some more white space for it.

    Even though such WIP limits aren’t explicit, after some time of working with the board I can tell you they do the job. They do, not only in pulling new projects into development but also, and more importantly, in long-term planning as we have visibility a year ahead and can confront our capabilities with planned sales etc.

    With this board, for the first time from the beginning of my journey with project portfolio Kanban I felt satisfied.

    See how we come up to this point – read the whole story.

    Advertisement: Infragistics® NetAdvantage® for Windows Phone gives you rich, innovative mobile UI controls to build high-end mobile user experiences for Microsoft® Windows Phone®. Their high performance, eye-catching data visualizations, mobile form factor optimization, touch gesture support, and alignment with Metro usability guidelines take your social media connected mobile applications to the next level.

     

  • Pitfalls of Kanban Series: Kanban Board Not Up To Date

    This is something I see very often and at least in a couple of flavors. The problem can be a team member who haven’t really bought the whole thing and see little value in updating all these stickies on the board every time something changes. It can be more a whole team’s thing – Kanban implementation has its leader, or a champion, and when they have a day off suddenly the board starts to deteriorate as people don’t feel pushed or obligated to update anything.

    On a side note: I would put it on the same shelf in my mind as when Scrum teams don’t do daily stand-ups when a leader is out.

    This issue is tricky as it doesn’t seem to be much harmful but, if tolerated, it basically renders the whole Kanban implementation useless. The first step we do with Kanban is we visualize all the work. Basing on that we make informed project decisions every single day (with help of WIP limits, explicit policies etc.)

    Now, if the board isn’t up to date these decisions are made on a basis which doesn’t reflect the reality. We may violate the limits or cease to help a colleague with a critical issue not even knowing about that. This way, not only do we make suboptimal everyday decisions but we also cripple the biggest power of Kanban – its improvement mechanism.

    Potential solutions of this problem depend on what flavor of the problem you face. If it is a single person you can work with them to convince them there is value in updated board for them too. You can also ask them to give everyone in the team a credit of trust and give a method a try for a few weeks or a couple of months. It usually is enough to turn them back into the light side of the force.

    However, in the worst case scenario you last resort may be setting up a proxy who updates the board instead of a problematic person. It will be a hit on team’s morale (“we have someone who is treated differently”) but it’s a tradeoff some teams are willing to make. Especially that, eventually such person either changes their behavior or leaves a team.

    If we think of a whole group not updating the board it is a signal that there’s little or no buy-in for the idea. Unless this can be changed most likely the Kanban implementation is doomed.

    The way of getting team’s buy-in will of course depend on people. However, I find it pretty successful to ask the group to give the method a try. Of course considering there is a problem I believe Kanban can help to fix quickly. Thanks to simplicity of Kanban it doesn’t cost much hassle to “try it” and pretty often first results are rather quick as almost always teams have some low-hanging fruits in terms of improvements they can make – quick wins they just aren’t aware of.

    Read the whole Pitfalls of Kanban series.

  • The Project Portfolio Kanban Story: Why Standard Board Design Is Not a Good Choice

    When I was starting my journey with Kanban on project portfolio level I based on a classic board design I knew from my work with Kanban within project teams. I basically tried to map value stream to the board but on a different level.

    The effect was sort of predictable.

    Portfolio Kanban Board 2

    It was also naive.

    The basic strength of such design is it’s very intuitive. Well, at least for these parts of the world that read from left to right. The same way we read the board: whatever is closer to the right edge of the board is closer to completion. The value stream we map may be a bit simplified (as me make it linear) but then it isn’t that much of a problem – after all index cards are flowing through the board pretty smoothly.

    Unless you put on single index cards “tasks” that last a year or more, which is exactly what I have done.

    When you’re looking at very long lasting projects you look for different information than in case of several hour long tasks. It isn’t that important how an index card is flowing through the board. After all you expect it to sit in one place for months. If you find out that the status of the index card has changed a few days late it likely isn’t a problem at all.

    It is way more important, and interesting at the same time, to see teams’ capabilities in terms of undertaking new projects, i.e. how much more we can commit to our clients. Note: we aren’t talking about a single team of 7 (plus or minus 2). What we have here is 100+ people working on a couple dozen different projects concurrently. At this level capabilities are pretty damn difficult to estimate, especially given ever-changing business surroundings.

    This is a huge weakness of the common board design: it doesn’t really help you with estimating free capabilities. It would help if we were able to set reasonable WIP limits on such board. Unfortunately, it is (close to) impossible.

    A number of projects isn’t a good candidate to measure WIP, as projects differ in size hugely. If you use time-boxing you could try using a number of time-boxes as a measure. However in this case you don’t want to have a random team working on thirteenth iteration of a project that was build so far by the other team. With WIP limits measured by the number of iterations you would likely end up this way. Another idea was using money-related measures. This brings a question whether you sell all your work for the same prices. I guess that is true in very few cases and definitely mine is not one of them.

    The longer I thought about it the more often I was coming back to people. I mean a team could start another project if they had some free people who could deal with it in planned/expected time frame. I even thought for a moment of setting base WIP limit around 130 (roughly a number of people working on projects represented on the board) and having each index card to weigh as much as there were people involved in a project at the time. The problem was the hassle needed to manage such board would be horrifying.

    On the other hand measuring WIP in number of teams was way too coarse-grained as we had anything from multiple projects covered by a single team to multiple teams working on a single project.

    All in all I ended up with a belief that, in terms of project portfolio Kanban, standard board design isn’t a good choice. I was ready to redesign the board completely.

    If I piqued your interest read the whole project portfolio Kanban story.

  • The Project Portfolio Kanban Story: First Changes

    Those of you who remember my Kanban Story probably remember how important experimentation mindset was for me since the beginning of my journey with the method. On project portfolio level the only difference was that I was well aware that such attitude is crucial even before I started doing anything at all. In other words I planned to adopt such attitude.

    With this kind of approach you should expect changes in the process and, as a result, changes on Kanban board as well.

    OK, let’s start with what I had on the day one:

    What was wrong with it?

    Well, maybe not really wrong, but it soon appeared I needed more information from the board than I’d already had.

    First thing, which became clear and actually could have been predicted, was that throwing all future projects into a single “planned” bucket was an oversimplification. Actually a planned project was pretty much any project which wasn’t yet signed, meaning that there were still many bad things which could potentially happen before we were 100% sure we would be doing it.

    Soon enough I had two groups of planned projects: these which were still expected to be built in near future and those which were in doubt for whatever reasons. Once I realized it I just added another column to the board. Since it was very unlikely that a project “in doubt” would automatically go into development and most probably it would go back to “planned” stage before, I added the column on the very left and index cards could freely go between “planned” and “in doubt” back and forth as I was learning new facts on the projects.

    Second problem was related with general status of projects. As I needed to pay more attention to challenged projects than to these which were doing perfectly fine this information was crucial to have it at hand. I decided to go with a simple green-yellow-red statuses, meaning respectively that project was going as planned, wasn’t going as planned but changes could be absorbed by project team or agreed upon with clients or wasn’t going as planned and unless something was done we were likely to fail.

    Technically I just grabbed a bunch of color magnets and attached them to all projects in “ongoing” phase. I was changing magnets to different colors whenever a project changed its status according to above definitions. Once I clearly saw which projects are at risk, and I saw that a dozen or more times a day, I could easily ask for more information on a project, look for risk reduction actions, set a higher priority to a project or whatever I felt could help to bring it back to the right track.

    After changes the board slightly changed:

    Portfolio Kanban Board 2

    However that wasn’t all. Third issue I was facing was that I couldn’t tell looking at the board when we were expected to deliver a project. It was super-important information as without knowing the dates it was hard to say whether project was going according to the plan or not. After all without dates I could hardly say I even knew the plan. It was also very difficult to plan future projects as I couldn’t really tell when this or the other team would be free.

    And this is why my index cards started evolving as well. At the very beginning an index card for a project was very simple:

    As process described on the board wouldn’t tell me anything about dates I decided to add this information to index cards. I wrote any key dates we knew for a project. It could be stage deadlines if we had multiple stage deliveries or deadlines for delivery, user acceptance testing and project closure, etc.

    Then, as you may easily guess, these dates started changing, either in controlled or uncontrolled manner. Either way I ended up crossing out the old dates and adding new ones. Despite the fact that index cards started looking a bit cluttered I realized that the fact that dates had changed was important to me as well so decided to keep it this way.

    And then I had all the discussions on budgets. I mean one thing is to deliver on time, another one is to keep a project within budget. So yes, I was having these budget-related chats pretty regularly. Of course I could refer to budgeting application, but then I wanted to work on the data which is up to date. This disqualified the budgeting app as sometimes we had old data there. What more, there was a number of different reasons why we had it this way, be it anything from preserving initial budget estimates to bug in the system.

    Anyway, I ended up writing budgets on index cards. And again, whenever budget was changing I was crossing the old number out and adding a new one.

    A new index card looked like this:

    Besides the initial information, which was project name and team or teams working on a project, I had project status and a sort of notebook for important facts regarding the project (dates, budgets). Why do I say that it was a notebook? Well, after some time handful of index cards looked not-that-clean:

    Anyway, I had the information I needed.

    Of course all these improvements didn’t happen in a single day. It was more of a constant process of small adjustments and tweaks spread over a longer time span.

    There’s also one approach I used, which you may find useful. When I was adding dates or budgets to index notes, I didn’t checked them for each and every project which was on the board already. I just set the policy that each new index note which makes it to “ongoing” column had to have the data filled. In terms of projects which were already in development I was adding this information slowly over time, usually whenever I was discussing the very project and somehow dates or budget became important in the conversation.

    It meant that eventually I’d have had complete information either because I gradually updated all the index cards in “ongoing” column or because projects were finished and the cards were moved to “maintenance.”

    After all these evolutionary changes I was still kind of unhappy with the board. I still didn’t feel I had any explicit limits and, what even worse, I didn’t see any simple method to add them. I also noted that sometimes I found it hard to keep all the information updated, as the board was still fully owned and managed by myself. However I decided not to go with it to the outside world unless I was sure it was going to work.

    So no, that’s not the end of the story. However, I encourage you to read it from the beginning.

    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 Project Portfolio Kanban Story: A Basic Approach

    You already know why I decided to try out Kanban as a tool to organize our project portfolio. To be honest I didn’t spend much time on considering the initial Kanban board design. Remembering about experimentation mindset you should have when using Kanban I decided to start with anything which seemed sort of reasonable and adjust the whole thing on the way.

    One of observations I made recently is how we stick to standard Kanban board designs. It seems that this is a path of least resistance – to use what we already know and are familiar with. I pretty much did the same. I started with a design that I used when I was applying Kanban on a team level. I just tried to map a process in a very generic way to a list of stages, and then track projects as they go from the left side of the board to the right.

    This is what I started with:

    As you can see I started on a pretty high level. We had projects we expected to start soon, and most of them eventually were started. Then we had whole ongoing phase separated only to three, very generic stages.

    As our clients are typically rather big companies most of the time we have pretty formalized analysis phase at the beginning of a project. This stage was worth separating as it there are significant differences, both in terms of effort we invest and people involved, between analysis and building stages.

    Then there was generic building phase. I didn’t try to track details for example in projects where we had iterations. I didn’t try to show specific stages in projects where we could define them. One reason was that the development process isn’t homogenous – depending on a client, a size and a type of a project, a development team and a few other criteria this process can look differently. Another reason was I didn’t want to go into deep details, especially not with the first version of the board. After all it was expected to be changed.

    The last building stage sub-column was representing projects which went into user acceptance tests. Similarly to analysis, pretty typical stage, even for clients that get iterative deliveries. And again, a part of a process we wanted to distinguish as it usually is a pretty specific in terms of team’s involvement.

    Finally, there was maintenance column which is sort of done column on steroids. On a typical Kanban board done column is a way to say that we don’t plan to do anything with an item which made it way there. Eventually, we remove an index card or a sticky note from the column to make a room for incoming ones. On a project portfolio level moving cards into the last column is sort of double blessing. Not only do we know that we are done with building a project but we also switch into maintenance mode, which is usually the most profitable stage of a project lifecycle.

    A pretty natural move to make was attaching team names to project index cards. Even though we were changing teams responsible for projects very, very rarely I decided to go with small stickies attached to index cards as sometimes it happens that a couple of teams are working on a single project.

    Now, a couple of things which weren’t that intuitive with this project portfolio Kanban board. First, there were no limits whatsoever. I played with the idea of adding some but eventually, I came to a point that it’s not only a number of projects that matters but the size of them is equally important. In other words one team can cope with a single big project or a few smaller ones concurrently and both are perfectly acceptable scenarios. I just decided to see how it goes and make up my mind about limits later on.

    Second, the board wasn’t really co-owned by everyone in the team. OK, in a team of almost 150 people it would be sort of difficult to have a board co-owned by everyone. However, considering there are just about a dozen project teams we could have one representative of each team and we all could perfectly work on a single board. Well, we theoretically could, if not the fact that we were spread over the whole building. Also, I didn’t want to enforce on each and every team a new duty which might well change pretty soon.

    I decided to start with this project portfolio Kanban board treating it like a personal Kanban board. It was owned, updated and changed only by myself; although anytime I was learning a new fact on any of projects I was updating the board. Soon enough I started having visits not because I was in the room, but because the board was there.

    A nice side-effect of such approach was that I could have my project portfolio Kanban board on one of whiteboards in my room which meant it was always at hand.

    Either way, I knew it was sort of temporary state. The goal was either to move toward co-ownership of the board or dropping the tool all along. As later appeared I pursued this goal soon, but that’s a subject for another chapter of The Project Portfolio Kanban Story.

    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.