Kanban training compared to lean training

Kanban is at the core of lean practices

Why get kanban training? Taiichi Ohno, one of the founding spirits of the Toyota Production System (TPS), called kanban the "operating method" of the TPS.1 Insofar as TPS is the basis for what we call lean management, kanban is of central importance to lean. I would go so far as to say that it is the foundation that enables all other lean practices. If you want to use lean practices on a daily basis, then you need to understand and use kanban.

Taiichi Ohno
Fig. 1: Taiichi Ohno

Impressive, immediate, sustainable

I have worked with organizations to develop lean practices and to use kanban. I have done lean training and I offer a variety of kanban training courses, both Kanban eLearning and face-to-face training. Therefore, I am not a disinterested party. In my professional services, I have chosen to focus on kanban training because I find the results to be much more impressive, immediate and sustainable.

Feel the flow

So it is with learning how to manage work in a lean way. The best way to learn lean is by being lean, by doing your daily work in a lean way. And the way to be lean every day is to use kanban.

It's OK to learn a list of types of waste, but you are really empowered to remove waste when you see it in your daily, kanban practices. It is better for a team to be at ease with identifying its own problems and finding their solutions, rather than having the finger pointed at them by someone else. Can you put your own workplace in order and make it shine in a durable way if you do not do it yourself? And when a team takes responsibility for the quality of the work it performs, it can succeed in delivering that quality if it limits its work in progress, avoiding the intolerable pressure of management to do more and work faster. Using kanban makes the theory real.

Fig. 2: Do you learn to drive by studying a diagram of the automobile's motor?

You learn to drive a car by driving a car. You cannot learn to drive by studying the theory of transmissions and horsepower. But the driver has an intuitive understanding of them. He or she feels the difference between passing in 5th gear and passing in 3rd gear. An animated view of an internal combustion engine might be cool. It might even help you understand why your car has broken down and how to repair it by yourself, but it does nothing to teach you how to operate the vehicle.

You learn to play a piano by playing the piano. Do you think you can learn to play by watching someone else play the instrument? The way to Carnegie Hall is via practice! And how many budding musicians fall by the wayside because they are forced to take a year of music theory before they can experience the joy of making sounds and feeling rhythms they create themselves?

Learning to play the piano
Fig. 3: Which student do you think is getting the most out of the lesson?

Existing training programs give kanban short shrift

How much time do existing lean training courses allocate to kanban? In one course, kanban is only one of nine topics in a section that is only 10% of the syllabus. That works out to barely 10 minutes during a two day course! That's just enough time to learn that the concept exists, but no time to learn how you will really use kanban on a daily basis. Guess how long it takes to forget what you learn in such courses.

Now, I do not mean to say that these syllabuses contain unimportant information and I would not suggest eliminating any of the topics they cover. Nor would I recommend lengthening the courses. But the result is that there is just enough time to briefly mention the principle of limiting work in progress, without seeing it in action. How can you believe in the effectiveness of WIP limits unless you see it for yourself?

A few minutes might be delegated to explaining the principle of pulling work, as opposed to pushing work. But this theory makes little sense if you are accustomed to having managers expediting much of your work. Explaining these basic kanban principles leaves no time for discussing bottlenecks and how to manage them. It leaves no time for understanding the principles of replenishing a team's queues. It leaves no time for presenting the concept of options in work and the benefits of delaying work until the last responsible moment.

Learn kanban first

Suppose you take lean management training and cover all the main topics, except kanban. You simply cannot derive how kanban works from the rest of lean, because kanban is based on principles that seem to be anti-intuitive, at first. The result is that you learn a lot of theory, but you do not learn how that theory is applied in the course of your daily work! When you learn without doing, you quickly forget.

But if you learn kanban first, you have a perfect framework for understanding the other lean practices. Kanban helps you see for yourself the different types of waste and provides the techniques for eliminating waste. The Voice of the Customer is a living voice, replenishing your input queue and receiving your output. Kanban is the dynamic, visual demonstration of customer value and the value stream. Do you want to use to 5 S approach to reduce mistakes, increase efficiency and improve continually? Kanban provides a structured approach to help you sort, systematically arrange, shine, standardize and sustain those improvements. It makes kaizen everyone's job on a daily basis.

Reasons for kanban training

  1. Practical rather than theoretical
    Lean training syllabuses cover a lot of information, but they focus principally on communicating theory. Kanban training can be directly implemented by the participants. You can work according to the kanban method during the training and you leave the training with deliverables directly usable by your team.
  2. Continual improvement rather than one-off projects
    With lean training, there is the risk that you use the training to support an improvement project, rather than starting the cultural transformation of continual improvement.
  3. Bottom-up rather than top-down
    Kanban training is best suited to help teams transform their own way of working. Lean training tends to create a cadre of lean specialists or internal consultants. Kanban supports better buy-in to waste elimination and more lasting improvements, because a team identifies and eliminates its own wasteful practices.

Interested in kanban training?

Interested in getting kanban training? We offer all the benefits of Kanban eLearning:

  • Short lessons
  • Learn at your rhythm
  • All you need to get started with kanban
  • Live Q&A sessions
Horizontal bar

Creative Commons License The article Kanban training compared to lean training by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

1See, for example, Taiichi Ohno, Toyota Production System. Beyond Large-Scale Production. CRC Press, 1988. p. 27.

Fig. 1: Downloaded from http://s3.amazonaws.com/s3.timetoast.com/public/uploads/photos/6371703/taiichi_ohno.jpg?1424969336

Fig. 2: Downloaded from https://flickr.com/photos/95717549@N07/9370854744 No reuse restrictions.

Fig. 3: By Y_tambe [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons https://commons.wikimedia.org/wiki/File%3AWankel_Cycle_anim_en.gif

Posted in Kanban | Tagged , , | Leave a comment

How to select kanban tools

I am often asked what software tools are available to support the use of kanban. Many lists of such kanban tools already exist (see the end of this article) and I do not intend to repeat the same information here. Instead, I would like to explain my view of the architecture of kanban tools and provide some advice for selecting those tools.

General information about selecting kanban tools

In this discussion, I will build on the information that I have published in my book, IT Tools for the Business when the Business is IT. Although that book talks specifically about IT and about service management, virtually all the information about how to select and implement tools remains valid for kanban tools.

Here are some of the key messages in that book:

  • Select tools based on their value to your organization, not based on the breadth of their functionality
  • Organizational structure is often the most important constraint to finding appropriate tools
  • Building a relationship with a tool vendor is, unfortunately, mostly an exercise in managing downside risk
  • No single tool vendor is likely to provide a single integrated solution that provides your organization with the most value

Select kanban tools based on value

Often, organizations make the mistake of confusing a wealth of functionality with value. Unfortunately, it has been my experience that many organizations simply cannot be bothered to think about the real problems they want to solve and the desired value of the tools they acquire. As a result, they tend to select tools based on extraneous, largely irrelevant criteria. Even worse are the organizations that create elaborate evaluation methods with arbitrarily weighted comparisons of tools—an approach that I have likened to voodoo.

Software tools are popular or are used by others in your network of acquaintances for many reasons, few of which concern the value the tools will provide you. But, if you are planning to use kanban, you are probably making a commitment to work in a more lean way. Think about evaluating tools in the same way that you would assess a value stream for value-adding and non-value adding activities. In the same way, you should distinguish between what is value adding in a tool and what is non-value adding.

Organizational issues

The ability to support organizational complexity is one of the biggest differentiators among software tools. If you are looking for a tool to support a single team, this point is probably not important. But modeling the organizational structure in your tool becomes extremely important if you are trying to scale up kanban to the enterprise level, where the links among kanban boards may be very useful or if you have to address issues of confidentiality. Remember that not all tools are created equal in this regard.

Managing vendor risk

Most organizations either completely ignore the issue of vendor risk or get their assessments very wrong. They often assume that vendor risk is inversely proportional to the vendor's size and age. Yet, those factors have only a minor effect on vendor risk. Indeed, risk may also increase with the age and size of the vendor.

Remember that the more a market space is immature and volatile, the more there will be vendor risk. When most solutions are provided by young startups, the vast majority of those startups will disappear in a year or two. You will see this in the lists mentioned at the end of this article, where many of the vendors or products no longer exist.

Furthermore, those companies that are quick to gain large market share are often the ones that are bought up by yet larger companies. Those larger companies often have strategies that are not aligned with those of the software's creator. Such changes in strategy may have a direct impact on the attractiveness of a product for a given customer.

I have seen organizations invest large sums in a market leading product, only to find two years later that that product is to be phased out. There is the too common phenomenon among large companies that may be called "serial acquisition". The company buys a smaller company to get its product. It develops that product during a few years, making it more stable but innovating little. Then it buys yet another small company to acquire a different product that is more innovative and has shown good promise in the marketplace. The older product is phased out of production with varying amounts of grace. So the customers that really preferred the previous product are left holding the bag.

In short, the risk of dealing with young companies is that they and/or their products might soon disappear. With large companies, the organization itself might last longer than a small one, but their products can change too rapidly as they flounder about trying to find good strategies in an ever-changing market. I have a strong prejudice in favor of small companies that stay highly focused on developing their products, jealously guarding their independence and building long term relationships with their customers.

A factor mitigating vendor risk, especially for simple kanban board tools, is the simplicity with which they work. Anyone with a basic understanding of kanban can easily and quickly configure most of these tools. Thus, in the worst case, it would only take a few hours to switch over to a completely different tool. The main issue in case of vendor failure concerns the conservation of historical data. A user may wish to consider this issue when choosing a solution and when determining the operational process by which that data is handled.

Integrated solutions

There is no universal answer to the question of whether it is better to integrate separate, best of breed tools, or better to rely on a single vendor to provide an integrated solution. This issue highlights the importance of understanding the logical architecture of the tools, which I will address below.

Kanban tools functionality

Let us consider the types of functionality that software tools might provide for managing work using kanban. Some functionality is specific to the management of flow and to kanban:

  • make the status of work items easily visible
  • implement the pull approach to flow
  • automatically indicate blockages and bottlenecks
  • support ready queue replenishment
  • integrate input and output from multiple kanban boards

Other functionality is generic to software, such as helping to:

  • easily display different views of the state of flow
  • passively capture data about flow
  • enforce organizational standards for data formatting and data display
  • improve data integrity
  • provide access to data at a distance
  • automatically generate analytical reports
  • operationalize the analysis of option value and risk

Make work visible with kanban tools

Often, teams starting to use kanban make use of a whiteboard, cards and markers to make their work visible. Simple, inexpensive and fostering collaboration, such kanban boards are excellent tools for a single team whose members are all co-located.

Frequently, however, a single team might have members located at different sites, or perhaps some team members might work, on occasion, from home or while traveling. In such cases, a virtual, software-based kanban board can easily provide a centralized focus for visualizing work, even though not all team members are grouped together.

Kanban tools used to implement the pulling of work

It is critical to distinguish between the simple display of data in the format of a kanban board and the use of a kanban board to implement the pull principle in managing the flow of work. It is becoming increasingly common for ticketing tools to display tickets and their statuses in a card board format. However, most of these ticketing tools continue to require that work be pushed, rather than pulled. In simple terms, they call for workers to assign tickets to others and to update ticket status when they have completed their own work, thereby queuing up work elsewhere. This is what we mean by pushing work. In a pull system, work in progress is limited, thereby fostering a just in time approach to flow. Downstream workers pull work when they are ready, rather than having it thrust upon them.

Kanban software tools typically implement the pull approach by simulating the physical board. They allow workers to drag and drop cards in columns. But surely there is no added value in sliding a virtual card on a touch screen, as opposed to moving a physical kanban card on a physical kanban board. A kanban software tool that only emulates what you do on a physical board is merely a gadget with little added value.  However, more sophisticated tools might, for example, implement rules that constrain the movement of cards and implement the flow management policies.

Indicate blockages and bottlenecks

Identifying blockages and bottlenecks is a central task of the daily stand-up meeting. However, doing so requires a certain amount of manual data tracking. For example, some teams add dots next to each card for each day it is in a column of the kanban board. Software can easily perform the same task and highlight any issues. Teams benefit from this by reducing the time taken during the stand-up meeting in performing administrative tasks, leaving more time for getting a common understanding of the status of work items and deciding what to do about them. This small savings could be important if the team is serious about limiting the stand-up meeting to only a few minutes.

Support ready queue replenishment

In general, the ready queue at the left side of a kanban board is replenished by multiple customers. Since that queue has a WIP limit and is not the same as a backlog, a means must be determined to decide which customer has the right to replenish that queue when a slot opens.

If replenishment is done via a meeting of customers, then a tool could support the decisions in various ways, depending on the policies controlling queue replenishment. For example, a tool could provide historical information about the provider's previous work.

If replenishment is done via round robin assignment to customers, then a tool could alert the lucky customer whose turn it is to replenish, triggered by the opening of a slot in the ready queue. One might also imagine a more automated replenishment based on the output from other teams, depending on how those teams are structured in the organization.

Integrate multiple kanban boards

Depending on how your organization is structured, each team's kanban board might have input coming from the work of another team, and its own output might be input to yet a third team. Thus, there might be a certain amount of redundant work in replenishing another team's board, based on existing kanban cards. Software tools could eliminate some of this redundancy and rework. The value of automating such interfaces depends heavily on the methods used to manage board replenishment, as well as depending on how teams are structured. For example, an organization may wish to reduce the number of hand-offs of work and reorganize team structure along the lines of services, rather than according to technologies used.

Certain organizations use portfolio boards to integrate work and to provide views of aggregated work items. To the extent that such boards are intended to represent the reality, rather than simulations, it should be clear how software can help ensure the coherence of the presentations and reduce double work.

Easily display different views

A physical kanban board based on a whiteboard has the drawback of being able to display only a single view of the data. Thus, each team requires the physical space for its own kanban board. While this requirement is not necessarily a hardship, given the board's central importance to kanban, a software implementation allows for displaying a team's board anywhere there is a screen. Furthermore, it allows for selecting, filtering and formatting data however the viewer might wish to see it. In addition, a single screen might be used to display the kanban boards of multiple teams, either aggregated or one at a time.

Passively capture data

When a team member moves a kanban card from one column to another on a physical kanban board, no data is captured concerning the time of movement. The historical data about the configurations of cards at any single moment in a given column is lost. Such data can be captured automatically and historical situations reconstructed and analyzed if virtual cards are moved about using software. Software allows for easily undoing mistakes.

Assuming that each team member has a personal account on the kanban board tool, all changes can automatically record the identity of who makes changes. This sort of information can be used to analyze resource liquidity and blockages, among other identity dependent issues.

Enforce standards

 A software tool can help enforce such standards as data formatting, color coding of kanban cards, the use of avatars and other symbols, and any of the visual representations of information that are central to the kanban method. Remember, though, that while standards might help avoid miscommunication, they can also become constraints that limit a team's ability to work in the best way it knows how to do.

Improve data integrity

Whenever people must record information manually, a certain percentage of that data may be missing, erroneous or hard to decipher. Software can help eliminate these issues, albeit often at a cost of inflexibility.

Provide access to data at a distance

As mentioned above, a team distributed among several sites or the temporary displacement of team members complicate using the kanban method. Tools can provide access at a distance to data and visualizations, thereby removing certain constraints to effectively using kanban.

Consider using video conferencing as a means for sharing the non-verbal communication of team members. Simply visualizing a board on a screen together with telephony cannot communicate the all-important visual cues that strongly influence the communications of attitudes and beliefs.

Generate analytical and presentation reports

Whether you generate cumulative flow diagrams, lead time histograms, statistical control charts, Marey charts, Sankey diagrams or other types of analysis, there is no question that you will be using software tools to do so. The real question is how those tools provide added value in any of three ways:

  • reduction in manual labor
  • reduction in errors
  • improvement in decision making

Suppose you create your reports by manually copying data from physical kanban cards to a reporting tool, such as a spreadsheet manager. Or suppose you collect that data from a software kanban board but have to extract it manually and import it into that spreadsheet tool. These types of manual tasks are forms of coordination work—work that is not value adding from the customers' perspective. Integrated reporting or automated ETL tools can both reduce the amount of manual labor as well as reduce the errors that might be introduced during that manual work.

Improvements in decision making might take several forms. First, there is the issue of interpreting a report once it is generated. Suppose you create a lead time histogram. How many people are able to assess visually whether a minor bump in the histogram represents an insignificant variation in data or whether it is indicative of a multi-modal data set? For sure, this is easy if the diagram looks like a dromedary, but how often do such obvious, extreme cases occur?

Or suppose you create a control chart and apply a set of rules, such as the Nelson rules, to distinguish the common cause variation from the special cause variation. Even if the rules themselves are simple to understand, a chart with several hundred data points might require a long period of manual checking of each rule. A software tool could identify and highlight special cause variation almost instantaneously.

Evaluate options and risks

Although there is value in keeping your options for the flow of work open until a decision is truly necessary, it is extremely difficult for humans to evaluate those options and to decide when the last moment for starting work might be. This problem is compounded when the expected lead times are relatively short. The shorter the lead time, the less time you want to spend on deciding what to do and when. Software tools can help by using historical data, making Monte Carlo simulations and proposing the priorities and actions to undertake next. In principle, those decisions could be left to the software if the AI capabilities of the system are sufficiently advanced and there aren't too many black swan events.

Assessing the value of kanban tools functionality

The purpose of the above list is to suggest ways in which kanban tools might be of value to your organization. Based on your own analysis, there are likely other types of functionality that would be valuable. And perhaps some of these functions would be of no particular value to you, at least at present.

Many organizations are tempted to assess a tool, or a tool set, against a list of the tool's functionality rather than against the expected value of that functionality. The problem with such an approach is two-fold. Firstly, the weighting they often provide to the functions is arbitrary and not readily comparable from function to function. Secondly, they assess that functionality without reference to how it would be used by the organization.

Use of kanban software functionality is directly related to the maturity of the organization using it. For example, integrating kanban boards is largely useless to an organization where kanban is used by only one or a few teams. Assessing option value does not help unless a team understands why having options are valuable. Automating the creation of analytical reports is of value if the organization understands the purpose of those reports, understands how to use them to make decisions and really makes decisions on that basis.

Dubious reasoning in tool selection

There are various types of disputable reasoning used by many organizations in selecting tools. Kanban software tools are not immune to various problematic approaches. Here are some examples.


Some organizations might consider tool functionality against possible future needs. While there is value in tools that might support future needs, this approach has several traps that should be avoided.

First, do you really want to pay today for functionality that you will not use until tomorrow and that you might never use at all? This is especially problematic when the licensing fees for software depend mostly on factors other than functionality, such as on the number of users. In fact, very few kanban software tools differentiate their pricing plans based on the kanban functionality provided. A list of the typical differentiators is provided below:

Number of entitiesAn entity might be, for example, a kanban card
Number of usersTypically, plans are based on the number of defined users, not the number of simultaneous users. Some products distinguish between view-only users and view-and-update users
SupportLevels of support range from community support through support plans with varying service hours and response times
Platform locationWhile most products provide only cloud platforms, some also offer private cloud or on-site options
AuthenticationSome products offer LDAP integration for user authentication and single sign-on functionality, especially with their "enterprise" plans
StylingSome products differentiate based on the degree to which objects may be styled
Branding"Enterprise" plans often allow for the removal of the provider's logo, replaced by the customer's logo
TrainingCertain plans include various training and on-boarding options
CustomizationWhile some plans allow little or no customization, others allow for the use of web hooks, custom fields, etc.
File import/exportThere may be limits to the number of files that can be imported in a period, e.g., for attachments or data importing
Knowledge base/wiki integrationSome products provide knowledge base or wiki integration for their more expensive plans only (this being a rare example of functional differentiation)
Number of boardsCertain products limit the number of kanban boards according to the pricing plan
Storage spaceThe total storage space for data may be limited
Rules executed per dayWith products that offer rule-based automations, the number of rules or the number of times a rule may be executed might be limited in certain pricing plans
Number of metrics reportedProducts might limit the metrics reported or the complexity of dashboards and analytical reports
Access rightsWhile some products only have all or nothing access rights, others might offer different levels of granularity of those rights

As you see, while there are a few cases where different price plans provide significantly different functionality, they are exceptions that prove the rule. The differentiators are mostly constraints on the use of the product, rather than features increasing its fitness for purpose. Whether you are using a free version, a professional version or an enterprise version, very often you get the same functionality, whether they provide value to you or not.

Secondly, given the relative ease with which kanban tools can be configured, it is not really a hardship to change pricing plans or even to change tools, should the maturity of your organization evolve and other tools would provide significantly greater value.

Letting the tool structure your work

I sometimes see organizations that select a software tool on the assumption that the tool's designer knows more about the work being supported than do the people performing that work. They believe that they can benefit from the "structuring" that the tool could afford them.

Such a belief is diametrically opposed to the agile culture of which kanban is a representative. Someone deciding to use a kanban software tool, on the basis of this reason, is perhaps not yet ready to use kanban.

Allowing teams to manage flow asynchronously

Some organizations might be tempted to use software tools as a way of avoiding spending time on the various cycles of meetings used to manage flow. In particular, a team that has no culture of short, daily meetings may try to avoid spending time on those meetings, believing them to be a waste of time. Software tools do not replace these meetings, but they do allow teams to process their tasks without them.

Using software tools for this purpose indicates a misunderstanding of the purpose and the value of having a team review the status of its work, recognize improvements, identify blockages and take initial steps to unblock work and to make adjustments in the value stream.

Lists of tools

The purpose of this article is not to list available software tools, nor is it to evaluate their individual attributes. Here are some of those lists, without implying anything about their completeness or objectivity. Note that these lists are not always well maintained, containing many products that no longer exist or have been acquired by other companies and rebranded.

Tools centered around kanban boards

Agile Scout List of Kanban Tools

List.ly - Kanban Tools

List.ly - Kanban Apps

Tools centered around statistical analysis

Wikipedia - List of statistical packages

Capterra - Top Statistical Analysis Software Products

Predictive Analytics - Top 50 Free Statistical Software

L-Lists - List of Free Statistical Software

Tools centered around statistical simulations

Search engine list

How are kanban tools of value to you?

How do you find tools to be valuable? What are your thoughts on selecting and implementing them? Please leave your comments below.

Creative Commons License The article How to select kanban tools by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Posted in Kanban, Tools | Tagged , , , | Leave a comment

Using Sankey diagrams for kanban

A Sankey diagram is used to provide a visual analysis of flows. While it might be most commonly used to display the flow of materials through a distribution system, such as petroleum and its derived products, Sankey diagrams are well adapted to provide visual analysis of the flow of any type of work. Thus, they may be useful tools for any organization managing the flow of its work using kanban. This article complements my earlier article on using Marey charts.

What is the origin of Sankey diagrams?

Diagrams to which we have attached the moniker "Sankey" are known (in Western Europe) starting in the mid-19th century. Minard's 1869 diagram of Napoleon's Russian campaign is an example. Minard, being a good Frenchman, used a similar technique to document the volumes of wine exported from France to the regions of the world.

Matthew Sankey himself first used this type of diagram in 1898 to document the energy flows of a steam engine, as shown in Fig. 1.

The "original" Sankey diagram
Fig. 1: The "original" Sankey diagram

Documenting the flow of energy and of energy resources has remained a typical use of this type of chart (see an example in Fig. 2).

The flow of energy in the United States in 2004
Fig. 2: The flow of energy in the United States in 2004

What is a Sankey diagram?

A Sankey diagram consists of a set of nodes deployed on a two-dimensional array and linked together by a network of lines. Those lines, called "links", represent the flow from node to node. The width of each link reflects the relative volume of the flow between the two nodes thus linked.

In the tradition of the diagrams, when there are flows from a single node to multiple nodes, those lines branch off from each other. Similarly, they join each other when multiple flows arrive at a single destination node.

Sankey diagrams are often displayed on Cartesian planes, but this is not a necessary requirement. The vertical axis normally shows categories of nodes, with the source categories on the left and the destination categories arrayed as required by the structure of the network. This is limited only by the imagination of the diagram's designer and the need to convey information clearly and precisely.

A simple example might document the types of revenues and types of expenditures of an organization. A more complex diagram might show intermediate nodes. Some flows might be cyclic in nature, either looping directly from a node to itself, or passing via intermediate nodes.

More complex Sankey diagrams may add other analytical dimensions. For example, the horizontal axis might represent geographical locations (as in the diagram of the Russian campaign mentioned above) or time. In the latter case, the width of a line might change through time, giving a clear visual presentation of that evolution. This feature is shared with area charts, such as cumulative flow diagrams.

Sankey diagrams typically treat the elements of flow as fungible. Suppose two flows enter a node and only one flow exits that node. The diagram does not show in the exit flow the sources of that flow from the inputs. It is not possible to trace an individual element through the entire diagram. I suppose this could be possible, using various patterns or hues, but it would render the diagram and its interpretation much more complex.

Junction of the Rhône and the Arve rivers at Geneva, Switzerland
Fig. 3: Junction of the Rhône and the silt-laden Arve rivers at Geneva, Switzerland

Using Sankey diagrams with kanban

How can we profitably use Sankey diagrams to help manage the flow of work using the kanban method? First of all, note that a cumulative flow diagram (CFD) is very closely related to a Sankey diagram, insofar as the width of each region in the diagram changes over time showing the absolute volume of flow. The main difference between a CFD and a Sankey diagram is that a CFD has only one pair of nodes, showing a single flow—from the cumulative input into a value stream to the cumulative output from that value stream.

I describe below several possible uses of a Sankey diagram to support the kanban method. There are certainly many other possible uses and I encourage readers to share their experiences and ideas in the comments below.

Work item type vs. customer

We may use a Sankey diagram to show the volume of work items per the customers of those work items. An example is shown in Fig. 4. We see in that example that the chart immediately shows the relative quantities for each type of work item (incident, change, problem, service request, in this example). It shows the relative volumes by client. Finally, for each client it shows the relative quantity of requested work items. That's quite a lot of information for a single diagram.

Sometimes the visual impression, based on line thickness, is not sufficiently precise. It is easy enough to add to each work item category, each flow line and each customer the associated count. Other statistics, such as the percentage of the whole, the mean value, the standard deviation, etc., can also be documented in this way.

Sankey diagrams showing the relative quantities of work item types versus the customers of those work items
Fig. 4: A Sankey diagram showing the relative quantities of work item types versus the customers of those work items

Classes of service versus customer

The diagram in Fig. 5 shows a somewhat more complex analysis with 3 nodes per flow. It shows the relative quantity by class of service for each type of work item. It then shows the relative quantity of flows to each customer, from each class of service.

Three of the classes of service—Intangible, Standard and Fixed date— have fewer links going out than coming in. What does this mean? In this particular example, it gives an indication of the number of work items abandoned before they were completed. Note that for this type of diagram, the number of inputs to a class of service node cannot be smaller than the number of outputs. A more formally complete diagram would include an "abandoned" node in parallel with the various customers.

Three level Sankey diagrams showing counts of work items by class and by customer
Fig. 5: A Sankey diagram analyzing classes of service by customer

Fig. 5 is an interactive diagram displayed in a web browser. In Fig. 6, we see the same diagram as in Fig. 5, but the cursor hovers over the link from Intangible to Finance. A popup box shows the weight of that link. This gives an example of a tool that interactively documents the data without cluttering the diagram.

Hovering over links in Sankey diagrams to display additional data
Fig. 6: Hovering over a link to display additional data

Team handoffs

The number of hand-offs from team to team is an important factor influencing the total lead time from the initial request for a service (entry of an item into the initial Ready queue) until the delivery of the result to the customer. A Sankey diagram is a simple way of visualizing the flow of work from team to team. It is easy to quickly identify where the hand-offs occur and the relative proportion of hand-offs versus deliveries directly to the customer. The diagram may also be used to visualize the relative quantity of requests that are abandoned. An example of these uses is found in Fig. 7.

In that diagram, I assume that requests from customers may be first handled by a variety of different teams. There is no centralized filing of requests with a single point of contact. The reasons for this assumptions are explained in detail in my article, "Do we really need service desks?".

Sankey diagrams showing the volume of work items flowing from team to team
Fig. 7: Analysis of team hand-offs using a Sankey diagram

Creating Sankey diagrams

However useful a diagram in communicating information, they are practical only if they can be created and maintained easily. There are various tools available for creating these diagrams. Unfortunately, they are not easily created from standard spreadsheet and diagramming software without considerable customization of that software. To my knowledge, no current tool used to manage virtual kanban boards is capable of generating Sankey diagrams. Otherwise, there are various products available that act as plugins or macros for these tools. I do not intend to provide specific recommendations, however.

A fairly simple tool for creating Sankey diagrams is available from Google, where you may find the source code. It renders the diagram from an html page. The script proposed by Google to create diagrams is pretty basic. Unlike other scripts, it does not allow for dragging components to improve the layout. This tool was used to generate the diagrams in Figs. 5 and 6. I suppose that a similar script is also used by Google to document Users flow in their analytics tool.

This code is so simple that even I can understand and adapt it to dynamically create the desired diagram. In particular, the data array in the page can be readily derived dynamically from any tabular set of data, be it in a spreadsheet or extracted from a kanban software tool. In the worst case, the data can be formatted, copied and pasted into place.

I include in this article diagrams produced with two other tools to give an idea of the possibilities they present. Fig. 3 is creating with the drawing software Dia. It is a purely manual production, meaning that it is difficult to create and to maintain. However, such drawing tools are much more flexible than most of the more automated tools I have seen. Furthermore, if your flow needs to describe a loop (which may or may not be desirable, depending on the circumstances and what you wish to document), most automated tools with throw an error rather than draw the diagram.

Fig. 7 is created with an online tool designed to document financial budgets using a Sankey diagram. While this tool is very flexible, allowing virtually any manual re-positioning of nodes and links, as well as allowing for diagram creation from imported csv data, the labels of amounts are always in US$, which is not useful for most workflows. Thus, the diagram in Fig. 6 has been manually retouched.

For those more technically minded, various Javascript tools have been created that may be integrated into reporting tools:

Sankey diagrams from Excel

Mike Bostock's Sankey diagrams

Various other software tools

I hope you find Sankey diagrams a useful tool for visualizing flow and supporting the kanban method.

Horizontal bar

Creative Commons License The article Using Sankey diagrams for kanban by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Fig. 1: By M. H. Sankey - Minutes of Proceedings of The Institution of Civil Engineers. Vol. CXXXIV, Session 1897-98. Part IV, Public Domain, https://commons.wikimedia.org/w/index.php?curid=2734254
Fig. 2: By Energy & Environment Directorate, Lawrence Livermore National Laboratory, Public Domain, https://commons.wikimedia.org/w/index.php?curid=1782286
Fig. 3: Google Earth

Posted in Kanban | Tagged , , , | 1 Comment

How can a Marey chart help analyze the flow of work?

The type of diagram called a Marey chart might be more than a century old, but it can be a useful new addition to the arsenal of tools at the disposal of lean and kanban practitioners.

What is a Marey chart?

A Marey chart is commonly used to analyze transportation systems. It displays the times at which a vehicle, such as a train or a bus, stops at stations on its route. By plotting distance against time, the chart is essentially documenting velocity.

A single chart may typically display multiple voyages of the same route, with one line for each voyage, flight, etc. The chart is essentially an X-Y plot of the distance traveled against the time taken. The distance is represented by the station names along the Y axis and the arrival or departure time at the corresponding station along the X axis. The station names are displayed in proportion to the distance between them. An example of such a chart, created by Étienne-Jules Marey himself, is found in Fig. 1.

You will see there that the city of Dijon, which is about 60% of the distance from Paris to Lyon, is positioned about 60% down the chart from Paris. Similarly, Mâcon is about 85% of that distance and is about 85% down the chart. Since the scale of time on the X axis is linear, the slope of the line indicates average speed during each segment, or hop, of a voyage. Discontinuities indicate the stopping time of a train at a station.

A copy of one of Marey's charts analyzing trains between Paris and Lyon
Fig. 1: A copy of one of Marey's charts analyzing trains between Paris and Lyon (downloaded from http://mbostock.github.io/protovis/ex/marey-train-schedule.jpg)

Using a Marey chart to analyze the flow of work

The Marey chart may be adapted to display and analyze the flow of work by a given team in a given value stream. The route, along the X axis, is represented by the nodes, or phases, of the value stream. The time, along the Y axis, displays the starting time for each phase in the value stream. Note that I have switched the X and Y axes compared to the example in Fig. 1. The reason is to simplify the creation of such charts using standard desktop spreadsheet and charting tools. Each of the plotted data series represents an instance of executing the value stream. An example is shown in Fig. 2.

An example of a Marey Chart for analyzing the flow of work.
Fig. 2: An example of a Marey chart for analyzing the flow of work

How should one represent the equivalent to the physical distances between stations on a route? The concept of physical distance between value stream nodes, especially when performing knowledge work, is not meaningful (unless you are specifically analyzing the wastes of transportation or movement in the value stream). I recommend representing the concept of distance by using the typical touch time, that is, the duration of the actual work performed rather than the start and end times of the work, for each activity in the value stream. By so doing, the Marey chart is scaled according to that flow efficiency. It indicates variation in efficiency through the value stream and variation from work item to work item. Intuitively, a task with a higher touch time should take longer, albeit there is no necessary relation between touch time and the waste during an activity.

The difference between a Marey representation of an instance of a value stream and a plot where the stream's phases are merely listed as categories, rather than adjusted for touch time, is shown in Fig. 3. The comparison is based on the plot in Fig. 6. While the two plots look superficially similar, the dashed line gives the misleading impression of some similarity in the duration of the phases of the value stream. While this might be true for an industrial assembly line, it is rarely possible for knowledge work.

A comparison of a Marey depiction of an instance of a value stream (solid line) with a plot that is not adjusted for cumulative touch time (dashed line)
Fig. 3: A comparison of a Marey plotting of an instance of a value stream (solid line—see Card 1 in Fig. 6), with the same instance when plotted against a value stream that is not adjusted for touch time (dotted line)

One could imagine that some other vector be used to replace physical distance. For example, the size of a batch in a work item might be considered. I have not pursued that possibility, as batch size is not always a meaningful measurement or one with a consistent and repeatable metric, which is often true in knowledge work. But the vector chosen might depend very much on the value stream being analyzed.

Creating a Marey chart

Here are some suggestions for creating a Marey chart for a value stream. First, the average touch time for each phase should be calculated. Work items sitting in a buffer do not, by definition, have a touch time, so the chart should not show the time in buffers as separate nodes. On the other hand, by including buffers in the chart, it will show the waiting time in the buffers, much as the original Marey chart shows waiting times in train stations.

Next, define the sample of data to be collected. Since the chart assumes a consistent touch time, a sample including a significant change in touch time will be difficult to interpret. For each value stream instance in that sample, the start date/times for each phase should be collected. If you wish to use a spreadsheet program to prepare the chart, then each data series corresponds to a single instance of the value stream, that is, a single work item. If the sample contains a large number of instances, it may be more convenient to record the data series in rows, rather than columns. The label for each data series could come directly from the kanban card used to represent that work item, using some unique identifier. It is useful to have labels for the nodes in the value stream, but the typical spreadsheet software will not be able to use them directly. For plotting the values in the chart, the cumulative touch time should be used. An example of the resulting table may be found in Fig. 4.

An example of a table of data series for the preparation of a Marey Chart
Fig. 4: An example of a table of data series for the preparation of a Marey chart

You will note that I include "Submit" and "Done" in the table. While they are not strictly parts of the value stream, they allow the chart to neatly place submission to the value stream's input queue at the origin of the chart. Further, it allows for a simple calculation of the duration of the last phase of the value stream.

The chart itself is an X-Y plot. I find it easiest to interpret if both plot markers and lines are displayed. The lines should be left as straight, to avoid erroneous interpretation when value stream nodes are close to each other.

I do not know of a tool that can correctly display the X axis, or the cumulative touch time, automatically. This is because these tools only know how to display linear, equidistant labels or logarithmic placement of labels. This almost never corresponds to the true touch times of the work, especially for knowledge work. Of course, on a simple, automated assembly line, the goal is indeed to have equidistant nodes, however difficult that might be to realize in reality. Be that as it may, the value stream node labels may be positioned manually via the axis title feature of the software. You may wish to hide the automatically generated labels, which represent the numeric values of the cumulative touch time. An example of the resulting chart is displayed in Fig. 2.

As with any other flow analysis, preparing a Marey chart requires a certain amount of manual labor when the data is derived from physical kanban boards and cards. When using a software implementation of a kanban board, all the data required to create the chart is already captured. However, as of right now, I know of no software product that automates the creation of Marey charts from flow data. On the other hand, the captured data can easily be exported to a spreadsheet program and the chart created, as described above.

The number of different types of information expressed visually by the chart will influence the ease with which the chart may be read and the effort required to create the chart. For example, I refer below to the possibility of using different line styles to display a type of information, such as the class of service of a work item. Other types of information, such as the particular resources used to perform the work, might also be represented. However, in each case the analyst must be clear about the benefits of collecting and displaying such information. Unless those benefits clearly outstrip the cost of presenting the information, such features are best avoided.

Interpreting the Marey chart

The original Marey charts, used for transportation analysis, gave a simple, visual means for assessing the consistency of the speed of a train. They also help to analyze traffic problems by identifying parallel discontinuities in the lines. See this posting, for an example.

But our subject concerns the analysis of the flow of work. We see in the chart that each segmented line, corresponding to a single work item or kanban card, has data points corresponding to the start of the value stream phases, as seen in the X axis label.

Since time does not go backward, the lines always go up, but rarely in a linear way. This is because the amount of waste during any given instance of a value stream will value from case to case. Furthermore, the amount of waste and even the touch times are not likely to be the same from one phase of the value stream to the next. This variability is reflected directly in the changing slopes of the lines.

The slope of any segment depends on two factors: the average touch time for the work and the actual lead time for the work. The slope is inversely proportional to the average touch time and directly proportional to the actual lead time. Thus, by scaling the chart to average touch time, the lines are corrected, much like the seasonally adjusted unemployment figures calculated by economists.

The slope of a line segment combines two factors: the absolute duration of the phase and the relative proportion of waste to value-adding work during the phase. However, the chart gives no direct indication of that proportion. Instead, the chart is useful for visualizing the evolution of that proportion over time. A simplified example of such an evolution is shown in Fig. 5, where the efficiency of the Build activity increases in time, shown by the decrease in the slope of the Build segment.

Fig. 5: Visualization of increased flow efficiency, shown by change in slope of a segment
In Fig. 2, we note that the line for Card 1 crosses the other lines. What are the possible causes of these exceptions to the expected "first in, first out" behavior? There are three possibilities:
  • blockage specific to the work item that slowed down
  • expediting of the work item that by-passed other items
  • differences in batch sizes
The chart could be formatted to display different line styles in function of the class of service of the work item. This would give a visual indication of the cases of expedited work items. If the reason for crossing lines is blockage, the chart can give a visual analysis of cases were work is frequently blocked at the same point in a value stream (unless all work is always blocked at the same time). I referred above to the possibility of showing on the chart the time spent in a buffer. This could be done by adding a series in the data table for the buffer, where the cumulative touch time does not increase, but the date/time increases in function of the time spent in the buffer. In this case, the chart shows the time spent in a buffer as a vertical line segment. This is illustrated in Fig. 6. Such a segment is visually attractive, because it shows in a very intuitive way that time is spent on the work item without moving forward in the value stream—the waste of waiting. Note that there is no need to show the word "buffer" on the X axis labels. This refinement might be useful once a team becomes comfortable with using a simpler form of the chart.
Buffer time in a Marey chart may be shown as a vertical line segment.
Fig. 6: Buffer time in a Marey chart may be shown as a vertical line segment.

A Marey chart gives an indication of the volume of work in progress in a value stream at any given time. This may be seen by drawing or imagining a horizontal line across the chart at any given date. The number of lines crossed by that horizontal line indicates the count of work in progress for the value stream at that time. For example, on 20 January, such a line would only cross one line. However, on 30 January, it would cross two lines.

If all the segments of a given line had the same slope, this would indicate that the throughput at each phase of the value stream is the same. If the chart showed a series of straight, parallel lines with the same slope, this would indicate a single piece flow situation where every phase of the value stream was taking the same amount of time. In such a case, we would also expect that the data points would be equidistant along the X axis. Of course, such a situation hardly ever happens, but it helps understand what the chart indicates if the lines become less and less jagged. If a sample shows relatively jagged lines near the bottom (that is, earlier) and increasingly straight lines near the top (this is, later), this is a graphic indication of improvement in the value stream, where the mean lead time of work approaches the mode and the standard deviation of the distribution becomes ever smaller.

The chaotic performance of the team is illustrated here, much like the chaotic fibers in felt.
Fig. 7: The chaotic performance of the team is illustrated here, much like the chaotic fibers in felt.

It might be useful to compare the visual impression provided by a Marey Chart with different types of fabrics. At one extreme is a felt-like diagram that has little internal structure (see Fig. 7). At the other extreme would be an industrially woven cloth, whose warp and weft are perfectly uniform (see Fig. 8).

The perfectly straight and parallel represent a theoretical limit, like the regular weft a machine-woven cloth.
Fig. 8: The perfectly straight and parallel lines, like the regular weft a machine-woven cloth, represent a theoretical limit to flow.

In summary, four key aspects of the flow of work may be seen at a glance on a Marey Chart:

  • The lower slope of a line, the shorter the lead times
  • The straighter the overall line, the more regular the throughput throughout the value stream
  • The more the lines are parallel, the more the work is performed consistently
  • Trends in changes in slope reflect changes in flow efficiency

Comparing Marey Charts to other types of visual management

The lean and kanban approach makes rich use of visual management techniques, using such tools as value stream maps, kanban boards, cumulative flow diagrams, control charts, lead time histograms and many others. What value does the Marey Chart add to the existing charts?

In my own experience, a Marey chart is useful predominantly for the analysis of a problem. Most other lean and kanban tools display mean values and do not take into account the flow efficiency. For example, the value stream map typically shows lead times and waste for each phase of a value stream. However, it documents only a single statistic (mean values?) and gives no idea about the distribution of values, nor does it provide the details of individual cases.

A cumulative flow diagram provides mean counts of work in progress at any given moment, but provides no details for the individual work items. It is useful for managing probabilistically, but does not drill down to the detailed cases. A CFD may well indicate at the aggregate level that a problem exists at a given moment, but does not really help to analyze the causes of that problem.

A Marey chart may provide a simple synoptic view of a sample of cases, showing the corrected throughput and its evolution within a sample. However, it is very difficult for the human eye and brain to analyze the values in the aggregate. For example, can you easily calculate the average slope of the four segments between Analyze and Design? Probably not. For this purpose, a lead time histogram and the underpinning data are much more useful. The benefit of the Marey Chart, as compared to a lead time histogram, is that the latter generally displays end to end statistics, whereas the former breaks them down by value stream phase.

Control charts are similar to Marey Charts in that they show a detailed evolution of performance over time. Control charts make it very easy to visually identify special cause variation. Too, they focus on end to end lead time which, from a customer's perspective, is one of the important statistics. While Marey Charts are more difficult to use for distinguishing special cause variation from common cause variation, they do help the service provider to make a detailed analysis of flow, phase by phase. For Marey charts tell stories, both the story of what happened in handling an individual work item, as well as the story of how the team's overall handling of work items changes over time.

We may also compare the Marey chart to the kanban board itself. The kanban board shows only a synchronic view of work, at any given moment. The Marey chart has the advantage of providing a diachronic view of work, similar to control charts and CFDs.

Thus, a Marey chart does not replace any of the other, commonly used visual management tools. However, it does highlight dimensions of flow that are not easily seen in those other tools.  It is of particular value in cause analysis, when a visual diachronic display of data for the execution of a single value stream, showing all phases, may be highlight trends, patterns and exceptions.

I would be delighted if readers using the Marey chart were to share here their own experiences.

Horizontal bar


Posted in Kanban | Tagged , , , , , , | 2 Comments

Lean Release Management

What is lean release management?

“Lean release management” is an oxymoron. It refers to a set of activities that either should not be performed when managing work in a lean way, or are part of other processes. In a lean context, release management as an independent process should not exist.1

I would be begging the question were I to stop the discussion here. So, I will continue by discussing three topics:

  • Deployment management as a process distinct from release management
  • The types of waste in “traditional” release management
  • Where the truly lean activities of those traditionally attributed to release management might be performed, assuming an organization had no release management discipline, as such

I will conclude with a discussion of the product owner’s responsibilities for releases.

Release management vs. deployment management

The idea that release management and deployment management are separate has already been broached many times. It suffices to recall the reasons for keeping them separate (especially in a lean context) and the reasons why anyone ever mixed them up.

When software (or any other type of release unit) is developed in-house for internal use, the development, release and deployment of a given product version is traditionally treated as phases within a single project. I understand the word “project” to refer to a temporary organization created to deliver a fixed set of deliverables. Since such organizations have a long history of very poor performance, especially in IT, elaborate control processes and superstructures have been devised in an attempt to limit the damage they cause.

But, the process by which a system is designed, built and tested is not the same thing as a project. The distinction is not pedantic. It is perfectly feasible, indeed desirable, to create new service system components and component versions without a project organization. Which leads us to a second, increasingly common use of the term “project”. Often, a project is simply a logical container used to circumscribe the scope of work. In this use, the term implies nothing about the organization performing the work, nor does it imply any particular processes or control methods.

Thus, people often confuse a project plan or a project control methodology with one or more processes. As a result, when people think of releasing and deploying as two sides of the same coin, they are merely reflecting the habits of many years of “project” work, rather than any necessary reality. They feel that releasing and deploying belong together because they are typically contiguous parts of one and the same project plan.

The distinction between the two becomes much clearer in the case of a design and development company creating, often on speculation, a product version for use by third parties. The deployment of that product version is performed under the responsibility of an entirely separate organization, using quite different control criteria and with no necessary linkage in time. Company A releases version 1.1.4 of a product. Company X deploys it the same day; company Y waits several weeks before deploying it; and company Z decides not to deploy it at all, preferring to stay with its current version 1.1.3 of the product. In theory, company A could release a version of its product that no one deploys.

For these reasons, I prefer to treat release management separately from deployment management. Lean deployment management most certainly can and does exist. It is not an oxymoron. It can consist of a value stream of value-adding activities. But that activity is outside the scope of the following remarks. Suffice it to say that many organizations have jobs or roles entitled “release manager” where the essence of their work is in performing deployments, not in managing releases. So, in what follows, deployment is out of scope.

In “traditional” release management, what are the forms of waste that should be eliminated and what are the release-related activities that should be performed in the context of a discipline other than release management?

“Ensuring”-type activities in release management

Many of the activities attributed to release management, especially in the ITIL® framework, are described as “ensuring” that some task is performed or some outcome is achieved.2 Rather than analyze in painstaking detail all such activities, I will describe in general terms why these activities should not be performed when using a lean management approach. They are a form of waste.

In a lean approach, all activities should be value-adding from the perspective of the recipient of the output of the activity (i.e., the customer of the activity). Thus, any activity that only serves to ensure that someone else correctly performs a task should not be performed when using a lean approach. A lean approach will not perpetuate bad practices by integrating “ensuring” activities into processes or by hiring managers to “ensure” the correctness of work. Instead, it insists on analyzing the causes of those wasteful practices and improving them.

In the following table, I list those “ensure” activities, together with remarks on who should execute and improve the underlying activities in a lean context.

 Activity Possible lean execution
Ensure release package integrity Whatever does this mean as an activity? Mounting a guard around the release components? Checking them periodically to ensure that they haven’t been changed unduly? Whatever it might mean, diligence is de rigueur in the handling of the release package and its components, no matter who might perform that work. If system components have owners, then their owners should ensure their integrity.
Ensure that release packages are stored in a DML3 Ideally, to be done by the creator of the release package, or perhaps done in a largely automated way. In a somewhat less lean context, that creator might hand off the package to the owner of the DML,  who then physically stores it.
Ensure that release packages are recorded in the CMS My critique of this activity is exactly parallel to the discussion of storage in a DML.
Ensure that organizational and stakeholder change is managed Stakeholders, together with the impact of changes that a release should have, are identified very earlier in the process of deciding what should be changed. But it might be possible that certain changes in a release are identified and realized without any reference to or input from the stakeholders to be impacted. In both cases, the product owner is responsible for communicating to the product’s stakeholders what the changes are, why they will be introduced and what benefits they might bring.4
Ensure knowledge transfer Knowledge transfer requires a transferer and a transferee, that is, a person having the knowledge to be transferred and a person to whom it needs be transferred for subsequent use. Neither of those two roles are release management roles. As a footnote, one must ask whether there is even a role for a knowledge “manager” in a lean context?

 Other putative activities of release management

I continue with the same exercise regarding the other activities that have been attributed to release management

Activity  Possible lean execution
Deciding that a given product version is deployable This is the responsibility of the owner of the product. In a largely manual design value stream, that owner may require exit criteria for the version’s developers and entry criteria for the testers or deployers. In a highly automated approach, the decision criteria may be implemented in the software controlling the development cycle. But to the extent that a go/no-go decision is required, this belongs to the product owner. A service owner is a type of product owner (see below). Thus, unlike the recommendation of  ITIL®, I view the service owner as responsible for the decision and not merely a stakeholder in the decision.
Plan Planning of a release may appear to be needed if it is assumed, as per certain frameworks, that release management is a set of activities so disparate that they need tying together. However, I am arguing here that all these putative release activities are, in reality, either not needed at all or are part of other disciplines. The need for planning qua “release planning” thus disappears. If some planning is still needed, that planning is handled by the respective design, develop and test activities.
Create release packages Creating a release package is understood in ITIL as the decision regarding which release units comprise the package, how they depend on each other and what compromises might be necessary in finalizing the components of a given release. In a waterfall approach to product management, such decisions are made by a product architect early in the design phase and are approved by the product owner. In a discipline such as scrum, the contents of the release package might be planned, but the reality  is determined pragmatically, based on what can be achieved during sprints and whether the results are viable. In waterfall approaches, the product manager may be called upon to validate changes to release scope following project execution failure or the identification of defects during testing.
Test release packages  This activity belongs to the testing discipline.
Record and manage deviations, risks and issues related to the new or changed service and take necessary corrective action This is precisely the responsibility of the product or service owner (see below). If the components or services being changed by the release have an owner, then that owner should perform these tasks.
Build and test release Testing is split among the various stakeholders in the release, be they the owners, developers, users, operators or supporters. Assigning an additional testing responsibility to release management is redundant and an egregious form of waste.

Building a release is a highly technical task that can only be performed by technical specialists. Whether it refers, as in the old sense, to compiling and linking source code, or in the more modern sense of creating installation packages, developers or packagers handle these tasks as part of the development cycle. The ultimate responsibility for deciding what to build is with the product owner.

Review and close To the extent that any activities require post mortems, identifying lessons learned and future improvements, these should be performed by each team participating in the release design, creation, testing and deployment. Closing, to the extent that this is a real activity, would be done by the product owner.

The product owner and releases

I have referred several times to the role of the product owner and its responsibilities for releasing. If I portray the release manager as a redundant role in a lean context, it is largely because I would give the planning, coordinating and decision-making responsibilities to the product owner. For those raised on ITSM “best practice” frameworks, a few additional word about product ownership are apposite.

The notion of “products” in ITSM has led to considerable confusion. The role of the product manager made a brief appearance in ITIL 3 Service Strategy: “[Business Relationship Managers]  work closely with Product Managers who take responsibility for developing and managing services across the lifecycle” (§4.1.3, p. 67 – my emphasis). Product managers disappeared, for reasons that remain unstated, from the 2011 version of Service Strategy. I have chosen to speak of product owners, which would be identical to the product manager role as defined in ITIL 3, so as to align this analysis with lean approaches to service management, product development and the software life cycle. A service is merely a product offered by a service provider. In this sense, services are like the tangible, physical goods that are also offered up as products. It is in this sense that I referred above to the service owner as being a type of product owner.

What does it mean for a product owner (that is, a service owner) to take responsibility for developing and managing a service when it comes to releasing? It means that the product owner:

  • determines the strategy for developing the product
  • decides what should be in a release, in line with that strategy
  • accepts what will be in a release
  • reserves the right to approve a release candidate for deployment
  • reserves the right to cancel a release

Some ITSM diehards might proclaim that such a product owner plays the role of the release manager (at least for certain activities). I won’t try to convince such people otherwise. But for those interested in simplification, in paring down work to the essential, which is what the lean approach is trying to achieve, the release manager and release management as an independent process is a redundancy, a form of waste to be eliminated.

What about organizations where the product owner role does not exist? Such organizations, lacking a responsibility for defining and evolving the long-term strategies of its offerings and guiding those offerings to reflect those strategies, will have issues far more severe than the management of releases. They should first ensure that the product portfolio is understood and under control.

Horizontal bar


Creative Commons License The article Lean Release Management by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

1Disclaimer: By making such a categorical statement, I do not want to give the impression that I am defining a normative statement of what lean release management must be. To paraphrase Shigeo Shingo, lean is a state of mind rather than a checklist. When I use the word “should” in this article, I am expressing an opinion justified by experience. That does not mean that my opinion is the only “right” way to manage releases in a lean way.

2I am not picking on ITIL. CobiT is in similar. Interestingly, the objective of release management according to ISO 20000—”To deliver, distribute and track one or more changes in a release into the live environment”—is essentially concerned with deployment management, albeit Part 2 adds complementary information that aligns the standard with ITIL. Thus, the two parts are not entirely coherent. On the other hand, IT4IT puts release and deployment activities within the Request to Fulfill value stream. That being said, it still recognizes “release manager” as a distinct role.

3For those not familiar with the term, a DML is a “definitive media library”. This is a mechanism intended to provide a highly controlled environment, under the responsibility of a configuration manager, wherein copies of all authorized software components and related items are held.

4I would say that this activity is a responsibility of change management, but change control is just as problematic as release management in a lean context.

Posted in Release management | Tagged , , , , | 3 Comments

Lean Service Request Management

With this article on lean service request management, I continue my analyses of lean service management processes. My earlier discussion of lean incident management may be found here. Any discussion of managing service requests should take into account John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My debt to that book should be obvious in what follows. Continue reading

Posted in Uncategorized | 8 Comments

Gandhi and continual improvement

Last week I saw a film about the group Ekta Parishad.1 This group applies methods derived from Mohandas Gandhi to help dispossessed Indians to regain their land and livelihood. The film centered on one of the main activities of the group, which is the training of the dispossessed people from a certain region on how to exercise their rights and protect themselves in a non-violent way. Continue reading

Posted in Continual improvement | Tagged , , , , , | Leave a comment

Lean Incident Management

A vicious cycle in incident management

Fig. 1: The more you have people to manage and control a process, the more complex it becomes. The more complex the process, the more you think you need people to manage and control it.

Fig. 1: The more you have people to manage and control a non-lean process, the more complex it becomes. The more complex the non-lean process, the more you think you need people to manage and control it.

Lean incident management is the resolution of incidents in a manner respecting lean principles. Being lean allows us to significantly reduce the extent of the control activities in the process and the number of organizational roles created to exercise those control activities. For, I have often seen a vicious cycle in organizations having a command and control culture: quality assurance and managerial tasks are increased due to the existence of a headcount to perform those tasks, and the headcount is increased due to the imagined need to perform those QA and managerial tasks.  This vicious cycle encourages the addition of ever more layers of control—be they procedural, organizational or technical—as the process becomes increasingly complicated. Shall we attempt to play the role of Alexander and cut through this Gordian knot in one fell swoop? Continue reading

Posted in Incident Management | Tagged , , , , , , | 6 Comments

Managing People Resource Liquidity

What is resource liquidity?

There is often a lack of depth in skills in a department. There may be only one person having the knowledge or skills required to perform a task, who thereby becomes a bottleneck. The immediate availability of a person to perform a task is the liquidity of the personnel in the group concerned. How can we use kanban to improve on the “traditional” way of managing resource liquidity?1 Continue reading

Posted in Kanban, Organization Structure | Tagged , , , , , , , , , | 5 Comments

Service-oriented organizations

I have decided to gather here a list of references to organizations that organize their IT personnel according to the services delivered, and not according to the technologies supported, the geography, or yet other organizational principles. The list of service-oriented organizations should be a good source for case studies.

I invite all to add, via the comments, any other examples of which they know. Continue reading

Posted in Uncategorized | Leave a comment