If you’re using Kanban board as a process tool in software development, you must know that Kanban is mainly about letting the work flow through the production states.
Pull some work from backlog, get it through the pipeline and on it goes.
Kanban is great, but it desperately lacks one thing which matters a lot in this world plagued by time constraints. This thing is called a sense of time. If a team does some cross-project work, as they pull smaller items from a support requests backlog, they will likely want to be informed not only of a current state of a work item. They will want to know when it is safe to assume that this work item will be done, or passed over to another department, etc. Trying a workaround to include this sense of time to a physical Kanban board on a wall might be a cumbersome task. Take a look:
This board has a mention of a milestone, Nov 9. The stickers are to-do items. This workaround just informs of a fixed milestone, and doesn’t take the production dynamics into account. There’s no way to give a forecast from this board, if the team will complete whatever their work is by November 9, judging by the pace with which they progress. Not to mention that there’s no way to see at which pace are they progressing. There are some Kanban reports that can help predict that, but they will not be available in a whiteboard, obviously. This might work for this team, but some other hypothetical team will want their Kanban board tailored to their time-sensitive objectives in a different way. And they would need to sweat and invent specific workarounds, if they need more than just a date written on a board.
We’ve always wanted to help our brothers sweat less at work :) .. and we’ve been well aware of this need, that timelines should be somehow intertwined with Kanban boards. The project management tool that we develop supports Kanban along with other dev processes, and our on-going goal is to make the tool still more convenient. That’s why we’ve implemented timelines that can now be used in combination with a digital Kanban board. We used to have a paper timeline on the wall, too, but this visual roadmap is more of a thing that creates the spirit of common purpose, than a hands-on tool. The Kanban+timelines combination can be used to see how teams are doing with their work, and in what time they expect to complete it. That’s how this Kanban+timeline board might look (click to enlarge):
There are two projects on this board, and there’s a backlog for each of them. Alternatively, there can be a shared backlog (our tool supports that as well). What goes next are work items laid over a stretch of time. Where the strips end is the current forecast for “Done”. The timeline can accompany the traditional Open-In Progress states on a Kanban board as well, if that’s what someone needs. Again, no sweat here, one can quickly set up a custom timeline+Kanban combination in our tool.
Having a timeline available as another option on top, or instead of a Kanban board, helps make sense of what’s going on with the projects in less time, pun intended. Besides, timelines keep the sense of time always present with a team (which they might be missing if they only look at a plain Kanban board). It surely is less hassle to maintain the digital Kanban+timeline board, and any stakeholder who is not immediately involved with the team’s work will quickly get an idea of what’s going on with the projects. There’s no limit to this digital timeline, and as to how it can be fit into a screen. Just make sure your screen is big enough for it :) For smaller screens, the scroller — at the bottom right on the screen above — will navigate you through unlimited sands of time.
It looks to me that adding a timeline to Kanban board is more of a burning need, than a luxury. If you want to try timelines combined with the Kanban board, click on the circle on the right.
Visual Management Software
How Timelines Help Project Managers Track Progress
How Visualize: Board, List or Timeline?
Take 5 Visual Reports for Kanban
The more I explore how IT organizations work, the more I see how strikingly diverse they are. They are as unique as human beings. Each organization has its unique process, unique culture and unique service or product that they deliver. On the surface, it might seem that businesses can be broken down into categories, e.g. a small or a large, a production or a service company, and there’s indeed a certain similarity. The big “but” comes into play when an organization wants to achieve some outstanding goal, e.g. increase sales by 300%, or cut down the time to production by 50%. There’s no such thing as similarity then. Small things in which companies differ then gain the last-drop power for a breakthrough to happen. The uniqueness lies in custom mixes of organizational culture and production process. Unique goals require unique ways to achieve them. I will use software development industry as an example to illustrate one striking phenomenon that holds they key, the Holy Grail to getting things done efficiently in unique organizational contexts.
Solve a Unique Problem by Copy-Pasting a Solution? No way.
At various phases of their lifecycles, organizations have to address their unique challenges. What do stakeholders usually do first as they encounter a problem? One disturbing commonplace trend that I’ve noticed is to replace addressing the root of a problem with a trendy buzzword model or management technique, and rely on it thinking: “Once we implement this super thing in our company, all our problems will be resolved.” Or, if the Super A..buzzword technique is implemented, and brings no results, stakeholders keep staying in the limited stalls of prescribed buzzwords, and then that’s what they think: “Hmm, the Super A.. thing is not working. How about we try a Super K… thing?” I’ve written about that in my previous articles on agile, Kanban and Big Data, as I looked at their origin, and on how they play out in the long run. It could all be very well if this approach with sticking, or switching, to one coined technique or another helped in 100% of cases. That’s not true, however. It seems that most organizations have slid from the ruthless clarity of a simple “why?” to juggling boxes filled with loud labels for what some time worked for someone. Thinking is the hardest job, and with the amount of cognitive loads that we, Homo Sapiens, experience these days, organizational stakeholders are tempted to use shortcuts and grab the leash of what a mega-guru has said should be done. *Totally forgetting that the mega guru probably used this technique or a tip for an organization that is completely different from yours*.
Which consequences does this habit have on a larger scale? Trying to fit a unique context of an organizational challenge to a limited set of Super A.. or Super K… techniques is an attempt in futility. If there’s some fat on the belly, that is, if this organization can afford paying for such abstract things as “measuring agility” (???), then the stakeholders would hire a consultant to translate the language of how things work in their organization to a lingo of a Super A.. technique, and/or will send their employees to be certified in this new religion, and/or introduce some ridiculous measurements that would serve it. Such reality shows are ubiquitous, and the following lame syllogism crowns them: “We are going Super A.. now, so we need a tool to call ourselves truly Super A…” or ” Hmmm… Super A.. does not work for us. The sales are not higher, and we do not have faster turnaround times, and Super A… is not helping us find out if what we are doing is actually right or wrong for our organization if we want to hit this target. Hmm. They now say a lot about the Super K.. technique. Yes! Let’s try it. Let’s switch to Super K.. and, of course, we want to be truly Super K.. so we need a tool for that!”
The Health Check: 5 Why’s and 6 W’s
The quickest health check is to ask the 5 Why’s. Why are we doing this? If the name of the Super A.. will still linger in the answer to your very last 5th “why”, you can probably throw the super A.. to the trash bin. Your organization needs to deal with real things. Not with the labels in a toy store. The other health check is the 6 W questions technique (What? Why? Where? Who? When? Which?) applied to what you have in plan for projects and processes. As a side note, I don’t care from which buzz management Super XYZ lingo the 6 W’s and 5 Why’s originate (and, yes, I do know of Six Sigma). These are the simplest bulls..it detectors to verify the actual worth of an approach to management.
It breaks my heart to read articles and blogs on software development written exactly with the Super Whatever shallow mindset. I can’t stand looking at how limited thinking prevents people from grasping the uniqueness of their challenges and addressing them effectively. I can’t stand looking at how the loud name of “methodology” is haphazardly glued to the how-to techniques and practices that worked only for certain organizations. And, I’ve explored the reasons for that thing happening in one of my previous articles. The education that IT professionals receive is too narrow. It doesn’t allow them to look beyond how-to’s too much, as they are not even trained to look beyond the how-to’s. The how-to approach works for coding, or for dealing with mechanisms, but it doesn’t work for organization/product/project management. I’m humbly hoping that my articles help to provide broader and deeper perspective, a perspective that someone might need to fix things gone wrong in their organizations.
Back to my intolerance to the evil reign of how-to’s and to the habit of their copy-pasting. This habit is even more dangerous than smoking or drinking, because with these everyone knows they are bad habits, while with the how-to’s abuse, people keep thinking that if everyone else does it, then that’s OK.
Pragmatism is Dead, Long Live Pragmatism!
It’s time to regain justice and call things their true names. Let’s retrieve one precious treasure from the chest of eternal wisdom and blow the dust off of it. The treasure that lies there abandoned has this written on its plate:
A methodology is a school of thought, and a method is a way of doing something.
In other words, practice is the only criterion for truth. On the meta-level, this reasoning is backed up by the philosophy of pragmatism. However, there can be a shallow pragmatism and a smart pragmatism. A shallow pragmatism, briefly, is a short-sighted plan and course of actions, while smart pragmatism is something that I’ve written about in the article Visualization: Why the Fusion of Arts and Tech Matters.
The smart pragmatism, for software development, occurs when the blind sages touching various parts of an elephant recover their sight and realize that all of its parts function as a whole. Often organizations held their internal mini-wars, especially as they grow, between marketing teams and production teams, as they divide the spheres of responsibility between many decision-making groups, and when those parts have to merge, it feels like flying through the rough air. The head does not know what legs and arms are doing, something of that nature.
I want to make null and void any methodologies except “use your guts”. There’s no such thing as a success of a one part. Success comes as a whole, and for that success to happen, unfortunately (or fortunately), there’s no other way as to think outside-the-box, sometimes even forcefully blocking the trendy how-to’s. One can read tons of books, or follow gurus, or “best practices”, but these activities are secondary as compared to independent thinking. Sometimes, it’s a surprising and a pleasant side-effect to discover that you have arrived to the same conclusion as some renowned guru did, but by yourself, in your practical context. And this is a lot more precious and effective than copy-pasting a technique with no deeper understanding. That’s why, if you have no guts — grow them. If you have guts, but you’re too tired, get some rest and restore your ability to think independently and clearly.
No Need for Ninjas, but Let’s Call This Thing Somehow
The use-your-guts pragmatic methodology does require a method (a way of doing). I’ve checked on most of the methods used in software development. Some of them have common sense in-mixed with limiting prescribed practices (see my article Stuck with Kanban? Consider Multiban). As you might have guessed, I have invented a method that is based on Kanban, but differentiates from it in the core “way of doing “. And, although I’m quite skeptical about using new names for what appears to be clear, I still have a name for that method: Multiban. This word is a Japanese-English mixture, and means something along the lines of many boards, many views and many perspectives. This name will stick in the memory, as it implies connection with Kanban method, with one important update. While Kanban uses cards as static signs for work items only, Multiban uses cards as dynamic signs for any abstract or concrete entity. Multiban is a visual management method (see and use your guts) that has no prescribed practices. All Multiban wants are custom visual representations, multiple 2D views of crossed rows and columns, that support whichever perspective to power your thinking. Why I deemed Kanban a good method to build on further? It’s because of the “visualize” part. That’s about the only thing that is unquestionable about the Kanban method: visualization. Nothing else supports the pragmatic, use-your-guts thinking better than visualizing. Indeed, when things are brought from heads to paper (or to screens), that’s a huge aide. Pragmatic stakeholders need more ways to look at what happens with their projects and processes, than with static Kanban cards that signify work items.
Now, as I’ve identified this method, for free-thinkers who want unlimited help and unlimited freedom with their unique ways of thinking, let’s see which digital tools might support this. Most of the Kanban tools are limiting. They lack versatile visualizations. Here’s a write-up about one such pretty decent Kanban tool that, however, fails to deliver many views and many perspectives. Quite predictable, I found out that so far only Targetprocess 3, our visual management software, supports the unlimited thinking and free-from-the-leash no-nonsense work — and the Multiban method — as it brings to the table unlimited 2D views for any dataset. No strings attached, the tool also allows to exercise agile, Scrum, Kanban and other SUPER ABC things. But the most important part about Targetprocess 3 is that it supports your own unique way of thinking and decision-making, be it on micro-level with bug fixing, or work items management, or on macro-level with managing portfolios of projects, or with roadmaps, in ERP or wherever.
I’m probably trying to squeeze too many things in one article. Each of the aspects I’ve touched upon deserves an article by itself. I’m certain that what this world lacks most is insightful out-of-the-box thinking. People are stuck in prescribed patterns on many levels in their lives, their work in software development, or organization/product/project management being one of them. I want to tackle this, and that’s why I will persistently champion the smart pragmatism and the Multiban method in my writings.
If you want to learn more about how Multiban stands out as a method and as a technique for visual management, check the related articles.
Kanban as Multiban
Stuck with Kanban? Consider Multiban
Our Evolution of Visual Process Management
What’s Wrong With My Kanban Board?
… no matter if it’s agile, Scrum, Kanban, SAFe, lean, XP or some mix of these methodologies.
Project managers want to track progress in any software development project, small or large. Sometimes they want to track progress not only in one, but in many projects at a time, and they want to be able to do this fast and conveniently. A timeline is a a visual management tool that helps accomplish this. Let’s take a closer look in which way.
Regardless of the software development methodology used, projects are meant to be completed. Always. However, at times project managers feel tied to by-the-book canons of Kanban (which is viewed by many as the best visual management system there is, but allows no time-boxing), or of Scrum (which has time-boxed iterations and releases but falls short with the visual part). What if a project manager wants to get the best both of Kanban, as a visual board, and of Scrum? Obviously, if projects have deadlines, one can not live by the classical pull and flow formula of Kanban only.
For progress tracking, Scrum allows only one visual report, called the burn down chart. When we want to keep an eye only on one project, such a report would probably be enough:
However, if many projects need a watchful eye of this one person, squeezing many burn down charts on one screen will not make the job any easier. Imagine how hard it would be to make sense of those charts arranged in a grid-like fashion. A project manager will likely want to see how projects correlate with each other, as it might be that the timing in one project affects the other projects. In this case, it would be sensible to drift away from the prescribed tool set of Scrum, and venture into the unknown land, fearlessly mixing sense of time (Scrum) with a neat visual representation (Kanban). That’s how this stylized mix looks as a timeline view for 2 projects (click to enlarge):
Work items in several projects on a timeline in Targetprocess 3
Such a visualization will fit a dozen projects into one screen, showing a project manager how all of them correlate with each other. This timeline has something more in store, than merely registering projects’ health in terms of time. Unlike in the burn down chart, one will be able to zoom in on any work item in any project and see what’s going on. This timeline bears a certain resemblance to Kanban board, because bugs, user stories and features are presented as cards stretched over time. At the same time, as in Scrum, the forecast will update depending on velocity (if one needs it done that way), and the timeline will show the latest status. If a project manager is in charge of several teams, that do several projects, this timeline will show when one can expect these projects to be completed:
A teams/projects timeline in Targetprocess3
A yet another snapshot of tracking progress with timeline. Here we have Features and User Stories (as in Scrum):
User Stories inside Features on a timeline in Targetprocess 3
When someone pledges allegiance to Scrum, timelines offer a way to track progress with many iterations. Same for many releases, as opposed to clicking through single release and iteration plans one by one.
Tracking progress/status for several iterations on a timeline in Targetprocess 3
As we can see, it pays off when we forget about practices that seem to be rigidly prescribed by a methodology. A methodology is nothing, unless it works for our purposes, and helps us do the work better and faster. These timelines can not be, scholastically, classified as belonging solely to Scrum as a method, or to Kanban. While classical Scrum only offers burn down charts for progress tracking, this is not enough when people work with many projects and want to keep their hand on the pulse of all of them. Classical Kanban, in its turn, allows no time tracking as a methodology (and as a visual board). I’m not even sure if what they call “Scrumban” would accommodate this representation with timelines. Frankly, I don’t care how it’s called. I only care if it works for project managers or product owners, or any other folks in charge of projects, and helps them do their work well. And I wish that people were more of a freethinkers, unpinning themselves from the methodology labels.
Care to take a look where one can afford being a freethinker and still work as a project manager? With no strings attached to Kanban, or Scrum, sticking only to common sense and convenience of work? It’s here.
How Visualize: Board, List or Timeline?
Having work visualized is the most obvious benefit of using Kanban boards for project management. Nothing else captures so well what a team is doing , as the work is retrieved from the hidden virtual closets of our minds (or, rather, databases), and externalized on a Kanban board. Especially if this board can be seen not only on a desktop computer but on a large wall-mounted screen. The more our office environment is saturated with all kinds of visual reminders, subtly incorporated in the surroundings, Kanban board being one of such reminders, the more likely we are to keep focus on our work and to perform better.
I don’t want to keep dwelling on how great Kanban is, though. I’d rather look into some of the reasons why we at times feel that something is wrong with the electronic Kanban board. Putting it in words will help see how to tune this “digital equipment” to our particular needs.
I have soo many cards on the Kanban board.. How do I make sense of all of them?
This feeling will most likely beget companies that experience rapid growth from 10 to 20 to 50 people and beyond, and need to work with more and more cards in their Kanban boards. All is fine, until your backlog and work in progress is covered by 50-70, or 100 cards at most. Having any more cards shown on a board in a snapshot would be a no-no. The clogged board space rather hinders your work, than facilitates it. What would the solution be, then? Your Kanban board needs to be able to zoom in/out, with the ability to collapse cards in any given state, as on the screen below:
I need to visualize milestones. My Kanban board does not do that :(
This could be a real showstopper. While we appreciate the visual flow that Kanban provides, we are not working in car production, like Toyota. They didn’t have this need to pay attention to time. Assembly line process goes in circles. In software production, though, projects are time-sensitive in 99% cases. It’s quite rare, if not totally utopian, for a company to operate without looking at their watch. The clock is ticking, and if a Kanban board has no way of showing “what time is it?” for a project, this could be a huge source of discomfort. Ideally, we want our Kanban both to keep looking like a board and to convey the sense of time. Like that:
I want my Kanban board updated real-time on any screen in the world that has it open!
This is not a crazy perk. Some companies work with several distributed teams. Even teams located in one office building and in different rooms need such live updates to track their work items real-time. If you are not looking to clear a mess with some un-synced updates (hardly you are), you will want your Kanban board to show the updates like this:
I’ve covered just 3 common cases in this write-up. Any further look into the “what’s wrongs” will depend on what you need to see, to do your work, in your company.
Look into the peephole on the right, if you want to explore how 99% of all possible Kanban “what’s wrongs” can be successfully tackled in a visual project management tool.
Stuck with Kanban? Consider Multiban
Our Evolution of Visual Process Management
Kanban as Multiban?
I’ve poked around the subject of visual process management in my previous articles, accentuating the complexity and non-linearity of software production process, and how a traditional Kanban board fails to visualize the diversity of organizational contexts and workflows. With that in mind, I’ve introduced a concept for a universal visual process management system that is capable to embrace this diversity and linearity on one screen, with flexible zoom-ins and switches, and called it Multiban.
The Limitations of Kanban Board
Many software development teams suffer the limitations of Kanban board, at one point of their evolution or another. When a company grows, the scope of work grows as well, the structure of the company and of the teams, that it is comprised of, are changing, and what if one Kanban board is not capable to accommodate those changes? What if a large company is working on a suite of products, and a 1 team-only Kanban board cannot show the bottlenecks that are out-of-the scope for this team, but still influence its work? Or, what if the 1 team-only WIP’s are not relevant, because a suite of products is a sum of components, where each team’s work is a component of the whole product, and WIP’s and value streams have to be balanced on a wider scale, beyond the scope of one team-one project board?
We had to find answers to such questions. In 2012, Michael Dubakov published the Our Development Process: 50 Months of Evolution article. The changes that have occurred over 2012-14 are not covered there, but it still shows how our needs in visual process management were addressed in parallel with the changes in our company setup. Keep in mind that we are a very special company. We develop Targetprocess, agile project management software, since 2004, and we have an advantage because we are free to choose how to shape our product to make it respond to the changing needs and structure of our organization better. Over the last 5 years, we’ve been consistently working to make our tool more visual and more powerful. I will single out the major landmarks.
2009: Switch from Scrum to Kanban
In 2009, we switched from Scrum to Kanban. By 2009, we’d been doing iterations for 3 years, and iteration development worked great when Targetprocess was a young product that needed to gain the critical mass and stay alive. Then, we realized — and that coincided in time with the uprise of Kanban — that we’d be better off reaching our goals as an organization if we practice development with Kanban. If you’re interested, here’s an in-depth story of the reasons and the production context that we had back in 2009. With our hands-on attitude, we didn’t linger with it, and implemented Kanban support in our project management tool. That’s how our Kanban board looked back in 2009 (one team-one project):
We implemented this Kanban board to cater both to our own needs, and to the needs of our customers.
2010-11: Kanban is not enough. How about TeamsBoard?
While the major reason for our move to Kanban in 2009 was the change in the product development dynamics (the product matured, and we needed to switch to the “add features” mode), the major change in 2010-11 was the switch from one team to many teams, as we realized that this setup works better for the “add features” mode. The count of feature teams is not fixed, it changes depending on which features we’re doing at the moment. So, we felt the need to visualize the work of many teams on one board. Hmm. That’s not what a simple Kanban board was able to offer us. That’s why, as hands-on as we are, we poked around and came up with what we can now call the forefather of Targetprocess 3. Take a look at TeamsBoard, edition 2010:
This board doesn’t look too fancy now, in 2014, but back then it was surely a step ahead compared to a simple Kanban board. One can see backlog, and work in progress for many teams. If some states had their WIP limit exceeded, the TeamsBoard would show it. In the screen above one can see that WS team had the bottleneck with 3 bugs and 1 user story resting in the Coded state. Then this work of testing could be shared with the other two teams. The TeamsBoard also allowed zooming in on each team, and what they do, by person.
2012-14: Targetprocess 3 and Fine-Tuning Process Visualization
Then, as we realized that sky is the limit, and visualization has enormous potential for project management, and for our own needs, we moved forward with the concept of the tool where anything can be visualized, depending on the changing dynamics and goals of a company. The fundamental idea is to offer a flexible tool that adapts to any process and follows any organizational changes. The other fundamental principle is the switchability of visualizations. We do not have stakeholders who tell us what to do and what to implement next. Our feature teams and our customers are the stakeholders. They tell us where else they need flexibility, and our backlog is formed based on those needs. We run recurring UX Process Visualization sessions, to see where else do we have yet to make room for more visual flexibility. We stepped aside from the traditional Kanban as the visual process management system long ago, and what we are now having is Multiban a visual process management system that supports any development process, for any number of teams and any number of projects, with cross-team and cross-project planning, using timelines for roadmapping, views as reports, etc. This screen from Targetprocess 3 is related to the good old Kanban of 2009 only by its board-ish looks, while in reality it is a switchable slate of views, zooms and perspectives.
Why Multiban makes sense?
It’s time to say a few words about Multiban now. Perhaps, the fastest way to explain how Multiban differs from Kanban is to use a metaphor. Multiban can be compared to the 17-inch interactive screen as in Tesla luxury electric cars. This awesome screen is a one-spot customizable dashboard for media, navigation, communications, cabin controls and vehicle data. Multiple Kanban boards for one suite of products (or a related suite of features, as in our case) can be compared to putting many touchscreens in the car, or even to using plastic controls for each of those functions. Would a driver feel more comfortable using one smart touchscreen? Or many simple screens? Or many knobs? It depends. For one thing, no doubt, the super-fancy touchscreen would require a learning curve. If a driver is OK with various controls, and if they do not depend on each other, then probably the car and the driving will be OK. Switching back to knowledge work: too many things are interrelated in software development, and losing track of those connections can have a bad impact on the way the work is done . It’s hard to keep everything in mind, and use visual board as a polished parade version of a development process. Multiban, as the visual process management system, is presented by a set of views, reports, controls and boards that comply with any diversity, and any complexity of workflow, or organizational structure. Targetprocess 3 is the only digital tool that supports Multiban at the moment. The concept of Multiban is the by-product of our organizational evolution, which dictated the need for evolutionary changes in our visual process management. Now we are ready to share what we’ve learned and implemented with other organizations that have been evolving, or will be evolving, in a similar fashion.
Kanban as Multiban?
Stuck with Kanban? Consider Multiban
A couple months ago in the article Kanban as Multiban? I questioned the applicability of simple Kanban boards for managing complex software development projects, and suggested the concept of Multiban. This short word inherits the practice of visual project management with boards taking the baton from Kanban, and looks like a good coin term for this innovative concept to me. “Ban” stands for “board” in Japanese, Kanban is a “signboard”, and Multiban is a Japanese-English mix which means “many boards”. In this article I will tell more about the use of “many boards” for visual project management, showing how Multiban differs from Kanban, and when it’s better to use Multiban instead of Kanban. Shortly, a Kanban will work well for a small company with only so much of work items, and with a straightforward development process. For a larger organization with many teams and many projects, a traditional Kanban board will not be enough. If you want to get the best of all the project Big Data in your organization, it’s time to consider Multiban. It doesn’t matter if your development process is Kanban, or Scrum, or any other lean or agile or whichever process. The Multiban covers everything.
There are 2 basic entities that Kanban and Multiban have in common: a card and a board. Let’s look in to the differences.
How a card in Kanban is different from a card in Multiban?
A Kanban card can be pinned only to one board. No matter if the Kanban board is a physical or an electronic one, the card is tied to it and can’t live anywhere else. Besides, a Kanban card usually signifies work items only. Now take a look at the list of Multiban cards:
Pretty impressive, huh? Apart from being impressive this diversity of cards powers the very ability to visualize project work in many different ways. Here’s another crucial point of difference: one and the same Multiban card can live on many boards. If cards are available only for work items, as in Kanban, one can visualize how work streams through development states, pretty much as in material production. Software development, however, dictates the need to take many ad hoc factors into account. Big IT projects in a large enterprise company can be anything, but straightforward, unlike a car assembly line. If someone wants to control this complexity, without too much extra effort and time, a set of various cards visualized on many boards looks like a must-have gear .
How a board in Kanban is different from a board in Multiban?
With Kanban, a board is just one board to which the cards are pinned. With Multiban, a board is a slate of switchable data axes (or lanes), with custom intersections. This slate can also be converted to a list view, or a timeline view, or a card details view. Actually, it’s for that reason that one and the same Multiban card lives on many boards. With switchable lanes, it can appear in various contexts. A Multiban tool has the switcher of those axes and perspectives (see the full list of available combinations) that allows to set up any board as a custom 2D data grid in no time:
Next, given that we deal with one digital screen, the single option of using board as a pinboard will not be enough. If all you have is a visualization with a board and cards only, this will pose a limit on the versatility of visualizations. What if you need to see work items and other entities as a list? Or as a timeline? Or what if you want to zoom in on just one entity? With Multiban, the electronic slate can be tweaked. It’s now rather not a board, but a flat white space that turns into a list, or a timeline, or a board with cards. Check the purple arrows on that screen. They highlight the 3 basic switchers that are used to set up any board.
This image gives an excellent summary of the Multiban approach:
The “see data” stage is where you configure a custom visualization of any data entered to your project management tool that supports Multiban. You will want to ask yourself: “How do I need to see this?” instead of “What will this board allow me to see?” All those many boards are available, waiting to be picked by you.
Too many cards, too many boards… Do I need this?
It might seem that it’s so easy to get lost in this versatility of cards and boards. Sometimes, freedom of choice is more intimidating than no choice at all. It does take some time to get used to the switchability of everything in Multiban. Too many cards can be sorted, filtered, paginated, zoomed in or out. Too many boards can be stored in folders, as in a file management system. It might seem an overkill to use Multiban if you’re happy with a simple Kanban board for one project, with < 100 cards, and with a straightforward development process. But, for example, a fixed Kanban board will not be able to showcase a portfolio of projects like that:
If you want to learn more on when and how it’s best to work with Multiban, check out these use cases… or look into the peephole in the fence on the right.
Kanban as Multiban?
I’ve been contemplating recently about agile movement as something that has risen from software developers who felt that the challenges of their work are not addressed by the waterfall approaches of the industrial production, and shared my thoughts in the Back to the Future of Agile Development essay. Then, as another layer of this thinking paradigm, I saw that Kanban as a method in agile software development stems from the human need to get rid of deadlines (check out the article Kanban as Multiban?) Now, there’s another concept in project management that falls into the same pattern. I’m talking of what is known as “project portfolio management” in the enterprise lingo, and what we call “multi-project prioritization” for smaller agile companies. So, this time I want to look deeper into prioritization, and give one more example of how a promising new trend stems nowhere else as from human nature.
On to project portfolio management. Just as waterfall was copy-pasted from industrial production, and turned into the Rational Unified Process for the sake of software development, in the same fashion, project portfolio management has its roots in the financial investment industry. As always, there’s a human need behind it. Someone must have been tired of looking for the ways to manage risks in software development projects, and resorted to what seemed the closest available counterpart — financial investment. But if we look deeper, would there be any difference between financial investment and following through many projects to completion in an organization? For sure, yes. First of all, projects are not shares or stocks, and in investment management one is looking to lower the risks, and compile the investment portfolio in such a way, so as to mitigate them, and optimize the financial gain. Only that and nothing else. It’s not that this person is concerned with being strategically involved with a public company whose stocks or shares they’re buying.
It’s far more complicated when we deal with projects, and especially with software development projects. One key difference is that the projects are meant to be followed through to completion. Of course, a lot depends on the organization. I figure that IT and software development projects could be shuffled as investment stocks — the closest match — in budgeted research fields, like in the military or in the government projects. Most IT companies, though, have nothing to do with picking up or giving up on projects. While in the finance industry the only value indicator is financial gain, there are many more value indicators in software development. Usually, the question is not if the project should be picked up or given up. The questions are:
1. Are we fitting in the budget? Do we need to secure a leeway to complete our projects?
2. Are we lax in terms of time? Do we need to sacrifice some parts of the project, and skip them, in order to ship some workable software in time?
3. How about people? Are they all balanced well in the projects? Have we made sure that the team’s collective energy is sent in the right direction?
4. This one is the closest to where we might come at portfolio management. Let’s say you work in a large organization and you have many projects, as an IT director, to supervise and to report on their health to someone standing higher. Or, in a smaller product dev company, one might have this multitude not with the projects per se, but with what we call “product features”. Ironically, for a smaller organization, this would seem the closest approximation to portfolio management. We have to prioritize and decide, whether we skip this feature, or follow through.
On all of those 4 levels, it’s about prioritization. That’s what it’s all about. Prioritization is the toughest job of all in the world, be it in personal life, or at work. Sacrificing is the most daunting challenge, and it imposes a huge load on a person or a group of people who are supposed to decide and prioritize. By now, the buzz in the industry says that the concept of “project portfolio management” has something missing in it. The tools for multi-project prioritization are not universal, and they don’t do the magic instead of this tired human being. Either the tools have to be customized (at big costs), or they miss some instrument that is crucial for this particular organization. In a nutshell, the project portfolio management concept has outlived itself for effective prioritization, just as RUP had outlived itself previously, and was replaced by agile as a methodology in software development. But still, as a product owner, or a project manager you need to have a birds-eye view on all the risks. Still, you want to get this burden off of your shoulders, and finally get a tool do the bulk of the prioritization for you, as this is the hardest job in the world. What happens usually when some methodology is not working out as expected for those human beings? Right. They’re on the lookout for new, better — and what’s most important — easier ways to prioritize.
Voila: enter Big Data. There’s much talk going on about it now. This is the next big thing coming, as it is supposed to make a productivity breakthrough in prioritization and decision-making. If we draw a parallel with the previous occurrences of groundbreaking phenomena (like, the way agile appeared in software development, or how people resorted to Kanban within the agile paradigm, or how they looked to use investment portfolio methods for project management), this prioritization seems to be the hardest job that IT professionals want to make easier for themselves, intrinsically.
Big Data is a trend that can be briefly described as follows: all the huge data about past performance and work is stored, and can be retrieved then to see how past trends can recur in the current trends, thus helping decide and prioritize. Considering the meta-law of things developing in cycles, this might work, to some extent. There is a certain probability that past trends would help one prioritize efficiently in the present. There’s some financial software developed that calculates those trends. But, from what I’ve been able to see, the big fish and the big gain in stocks usually come at random. This all boils down to the intuitive feeling. Something outside data and calculations. This is not to diminish the importance of data analysis. Any data is a huge asset. Even more this is an asset as we live in the age of information, and we need to learn to get the best of those assets. But, just as the term “project portfolio” has the trace of hope instilled in copying this practice from financial investment to software development, in that it would set us free from prioritization problems, there’s something to watch out with the Big Data trend. Yes, we always strive to put burdens off of our shoulders, as Homo Sapiens, and that’s why we started with sticks as tools, then shovels, and on. Same with the heavy duty prioritization and Big Data. To a certain extent, we can be sure that it would help us move forward, and give more sophisticated tooling for effective prioritization. But ultimately, there’s something even beyond Big Data. Some other infotech miracle. All in all, not that we should lose hope in freeing ourselves from prioritization work altogether, but I don’t think that even Big Data would become the silver bullet for the IT professionals in prioritizing their project choices. We will have to carry personal responsibility all the same. But this would definitely be a step ahead in the evolution of methods and tools for effective prioritization across many projects and initiatives.
Back to the Future of Agile Software Development
Kanban as Multiban?
We’ve been working for several years with Kanban process, and there’s quite a bit of experience about it that we’ve shared (see the posts tagged with “kanban”). I’ve contemplated things around Kanban recently, and here’s another interesting perspective. It might help make more sense of the Kanban method as a method for managing knowledge work, and software development work, in particular.
If we look into the 6 core Kanban practices, as identified by David J. Anderson in his fundamental book “Kanban — Successful Evolutionary Change for your Technology Business“, the first practice is “visualize“. While the other 5 practices (Limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively) are very important, the visualization practice is the key to all of them. Taking a flashback into how Kanban evolved historically, first it was a system “to control the logistical chain from a production point of view“. Seems like Kanban as a method for software development differs from Kanban as a scheduling system for the material production in the following 2 things (mainly): non-linearity of the production process, and diversity of concepts and workflows.
I can imagine what the first sparkle that inspired software development folks about Kanban was. Some of us have this special relationship with the concept of “deadlines”, and probably Kanban — on a purely human, maybe even subconscious, level — has been seen as an opportunity to break away from deadlines and estimates. Well, might be that Kanban came later than Scrum due to the fact that people got tired of the time-boxed iterations. And there it goes, a trendy new method for software development, that says: no time-boxing! Do your work at your own pace, and don’t worry about deadlines!
That’s the most obvious advantage that laid on the surface, and that’s why software folks were so glad to switch to Kanban, intrinsically. The Kanban movement started back in ’09-10, and the 5 Wrong Reasons to Apply Kanban and 5 Right Reasons to Apply Kanban posts in our blog are the evergreens that can provide some practical advice even now (especially as they resonate with the current NoEstimates movement).
Now, if the flow and no estimates aspect is a woo in Kanban as copy-pasted from the material logistics model, we’re having a bumpy issue with the visualization core practice. The easiest way to go would be to copy-paste the visual production flow from logistics, as a stock of parts in the warehouse (the backlog) reduces, and then sequentially goes through the In Progress and Done states:
Looks as easy as a pie, right? But, remember, software development is a knowledge work. While some part of it, such as work items (user stories, tasks and bugs) can indeed go through this simplistic flow sequentially, there’s a bunch of non-material related concepts and dependencies that those work items carry along with them. They are the non-linear “sticky fish” that might hinder the movements of this big whale called “software production’. Visualizing this knowledge work is not something confined solely to workflow and limiting WIP. Working with Kanban as a method implies visualizing various concepts about processes. Kanban is ultimately a “signboard”. One straightforward Kanban board often lacks all those multiple perspectives that we need to monitor processes and to make them explicit. Obviously, a part of this limitation can well be addressed by swimlanes, when Kanban is not a board with just columns, but a grid of switchable columns+swimlanes. It’s quite hard to get such a level of visualization on a physical board, too cumbersome to maintain. Fixed swimlanes on an electronic board (or, even switchable swimlanes but with some limitations) would not be enough. Kanban in the context of knowledge work requires unlimited columns+swimlanes combinations, with a plethora of custom 2D data grids. And we need to switch them fast, in a few clicks. Well, we can use tags to add another optional dimension for work items, but sometimes tags are not enough.
What we need from our Kanban boards for software development projects would look like this:
Any data from the project could be extracted from the database and visualized in an instant. The teams-work items grid above is just one example. This sketch implies fast swapping of the vertical and horizontal lanes and visualizing the same data in a different way, with even more sophisticated filtering for the lanes available, if required. For example, you’ve created a 2D grid that shows user stories grouped by features. You only need to see the stories from the “open” features, to unclog the grid (features are represented by the horizontal lanes):
Here’s the list of possible properties (“the sticky fish”) that can go along with a user story:
- Iteration: if you see the upcoming iterations, you can move the stories to the grid cells, and create an iteration plan.
- Release: same as above, for a release.
- State: this would be a classical Kanban board.
- Priority: user stories can be prioritized similarly to how the states are changed.
- Effort: same as above, but for effort.
- Feature: that would be a story map backlog.
- Person: a work-by-person grid.
- Project: user stories broken down by projects.
- Team: user stories broken down by teams.
- Tags: even more flexibility.
- Custom fields: same as above.
That’s the diversity of 2D visualizations that we could have with just one swimlane. But it’s not only about swimlanes. Both the horizontal and vertical lanes could be tuned in the same fashion, unveiling thousands of custom 2D views.
So, what we would have here is not just one Kanban. It’s a “Multiban” — many boards on one screen, where boards are switchable 2D data grids, and the data itself remains intact. Another example of such a data view is this:
Imagine this freedom. With such unlimited ability to visualize anything, the Kanban method would make much more sense. Any concepts, any perspective that you need could be visualized. If we have the first visualization core practice for Kanban handled that well, we would be able to take advantage of the 5 other Kanban core practices, mentioned above, and utilize Kanban as a process to manage software production (the knowledge work) more fully. That’s what we are coming up with in the next version of our project management tool, and in this post I tried to provide some “behind the scenes” reasons for that.
Stuck with Kanban? Consider Multiban
Experienced agile practitioners probably all know that process goes first, and tool goes next. This principle is vital for the teams that are just starting out with agile adoption. They might grab a PM tool thinking that it’s all they need to keep their newly born “agility”. If that’s the case with your company, read this memo:
Once an agile team has matured, and come up with their custom dev process, there comes a time for another major checkpoint:
Copy-paste your process as is to a project management tool
Surprisingly, quite many teams neglect this step, and I want to write about its implications, and why it’s so important.
Here’s an example of the task at hand if you want to replicate the process of 2 teams working on one project. You can consider this as a brain teaser, instead of a sudoku puzzle, and see if you can copy-paste this to the project management tool that you’re using.
That’s the whole point. If the process is reproduced accurately in the tool, you can use it as a full-gear device not only for tracking and reporting, but for making sensible corrections. If not, the reports and data make no sense, as well as the retrospective analysis, and you’re unable to make good decisions to correct what’s wrong. An extreme case would be if there’s a dichotomy, and the tool is used for the “deluxe” version, while the real dev process is different. That’s an extreme case, but it might happen in some teams, if they’re compelled to use a tool that their management has chosen for them, and the tool does not do what is really needed. It’s the same as when people buy new furniture. You’ve got your lifestyle habits, and if you decide that you’re buying this table because now you will sit and work there, while you still prefer to work on a cozy couch, this would only mean that this new table will get all dusty, and you will end up not knowing what to do with it. You need to fit a piece of furniture to your lifestyle, not the other way around. Buying a table and tying yourself to it would not improve your creative flow and your work experience. You’d still find it uncomfortable. This looks simple but surprisingly people do such things not only with tables, but with project management tools, too.
The third checkpoint is: replicate any changes that you make to your dev process in the tool, and do this when the time is right. I will outline several meta-principles for any changes of that kind:
1. Set clear boundaries between Backlog and Work In Progress. Yes, it might be hard at times, as the concept of backlog is blurred in software development, due to its very nature. Decide about the thresholds, maybe it’s a ready specification, a kick-start meeting, a meeting with stakeholders. Find this exact ridge where a backlog item becomes a WIP item. This is even more important if we leverage this principle against the general “limit work in progress” guideline of a flow-based process. Obviously, outlining clear thresholds would save you from the pumped up WIP. As an example, sometimes bugs would retreat back to the backlog, while they’re nothing else than stale work in progress OR a part of user stories that are considered Done:
2. Outline all possible transitions for your Work In Progress states in your project management tool. Identify which state can follow which, which state is final, who is allowed to switch states.
3. Set clear boundaries between Work In Progress and Done. This meta-principle transcends to many rules that any team can define for their particular needs and preferences. If there’s a slightest implication that something that is “not done” sneaks to done, this will mess up the reporting and corrections.
Finally, you need to know the right time to adjust the process, and its replica in the tool. If a team decides to update the process in the middle of a release, they won’t get a good coverage. Setting up the times for the dumps from real process to go to the tool is important. Like, after a major release. Or at any other point that makes sense to this team. You might even want to assign a Process Police role for that one :) Seriously, someone has to take on this responsibility, and the easier it is to set any possible boundaries and state transitions in the tool— the better. That’s something I’ve covered in the post The Paradigm of Project Management Tools.
Summing up, there would be 3 checkpoints in this cycle:
1. Process first, tool next.
2. Replicate your dev process in an agile project management tool
3. Make corrections to the replica.
(Repeat as needed.)
In this installment of the dataviz series, I will tell about some visual reports that might be of interest for Kanban practitioners.
We all know Kanban as a process that has production flow visualized on a board. The to-dos (or work) get started in Backlog (or in the Planned or Open state), then they get to In Progress (or to any other variety thereof), and end up in Done.
So, yes, we all know about Kanban, but some of you might be less familiar with the reports that go along with it. If Scrum comes with only 2 visual reports (the iteration and release burn down charts), Kanban has several of them, and you will see now how those visual reports can be of help.
Cumulative Flow Diagram
…is the first and foremost report. It shows how work “accumulates in flow” (hence the name) with time.
What can you get out of this visual? First, the correlation between the ToDo (or Planned) work, the In Progress work, and the Done work broken down by weeks. The diagnosis for the team that has such a sleek CFD is nothing short of utopian, by the way. The light blue layer is ToDo, the green layer is Done, the beige layer in the middle is Work In Progress. You can see that if the blue To Do layer gets too thick, this means that the backlog needs good grooming (maybe some part of it shouldn’t be in the ToDo state, but in some other pre-production state, similarly to what I’ve described in my recent 3D Backlog Management post). If the beige In Progress layer gets too thick, someone has to set reasonable Work In Progress limits. Well, the only layer of those three that looks good when it’s fat is the green one. A point to note about CFDs: they work well if you want the bottomline diagnostics report for only 3 states. If your Kanban process includes some sub-varieties of them, the report would get too clogged and would make no sense.
CFD reminds me of the tectonic layers and the Earth formation process. An easy way to memorize the logic of this report would be this: the more rugged the outline of the layers is, the more turbulent the process, the more bottlenecks it has. Ideally, this report would have all the surfaces even, where the blue layer (the ocean surface) remains serene and almost untouched, this means just a few to do’s are added, the seabed layer (the work in progress) is reasonably thin, and the solid baseline layer of the Done work (the Earth crust) is getting thicker and thicker (but that’s utopian…).
Lead and Cycle Time Report
… is another visual report that is so vital for Kanban. Actually, the lead time report is not that helpful for software product development, as it covers the time that work seats in pre-production state (read, in any of the backlog states), whereas the cycle time is a pure “work in progress” span. The lead time would have more meaning for hardware production, where people look at it as the measure of how long the storage space is occupied with the parts, for instance, and they need to adjust their process accordingly. For software development, no warehouses and storage spaces are needed, that’s why only the cycle time report would matter *unless the work items are requests that come from customers. In this case, a short lead time would suggest that those requests are implemented fast.
The cycle time report above shows an abrupt spike of completed user stories in November. This probably means that the team worked full gear to get as much as possible done for some major milestone. Later on it went back to a rather even development flow. Besides, the correlation between completed stories and bugs is supposed to show, ideally, if it was a quality work. April looks very well, as it had 12.4 user stories completed with only 3 bugs. You get the idea.
Process Control Chart
… feeds on lead and cycle time reports. It shows if the development process is healthy and under control. Take a look:
If most user stories are scattered around the median line, it means that all is well with the process, and most of the user stories are done within the average time to complete. You can also identify any “odd sheep”, like the story that took 34 days to complete, or even 80. At this point, the process control chart has nothing more to say, and we need to click this odd bubble to find out the reasons for its oddity. This is our next report:
It indeed uncovers some of the reasons, as you can see from the screen above (the red boxes at the bottom are bugs). This story has been thrown back and forth from state to state, it had a suite of bugs, and not all of them were fixed… what an unfortunate user story.
Lead and Cycle Time Distribution
Finally, there’s one visual report for Kanban that can give a forecast. While all the other reports just diagnose how things were going in the past, this one predicts how likely it is that some user story will be released in any given amount of days. If we look under the hood, this report is powered by the historical data from lead and cycle time reports:
You can read more about some practical uses for lead and cycle time distribution chart here.
If you need those reports for your work, feel free to look into the peephole on the right :)