David Anderson

Kanban Patterns and Organizational Maturity

March 1, 2016 by David Anderson

This is part 3 of at least 4 parts in a series studying kanban system and board designs and relating these to organizational maturity as a core coaching tool. If you need to catch up, read Part 1: Organizational Maturity & the J-Curve Effect and Part 2: Patterns of Kanban Maturity. In part 3 I take all the kanban board and system designs from part 2 and map them to the organizational maturity assessment framework from part 1. The value of this is that a quick and effective method of assessing organizational maturity and a small pattern catalog of deepening maturity kanban board and system designs, provides Kanban Coaching Professionals with a consistent set of starting designs likely to be successful. In other words, we’re matching the sophistication of the design to the sophistication of the organization. In Part 4, I will look at what it takes to move up the organizational maturity ladder with evolutionary change.

Mapping Kanban Designs to Organizational Maturity Levels

Throughout this post the mapping is shown at the lowest viable level. An example of a board design will work at higher level of maturity. In some cases it may be necessary and the only available design. For example, if we create an Executive Kanban to encourage executive leadership to take actions to help with service delivery or evolutionary change then that would be a personal kanban system but most likely implemented in a level 4 or 5 organization. It may also be true that while we can implement some designs at higher levels, the effectiveness is diminished because the board and kanban system is a sufficiently powerful stressor to catalyze further evolutionary change. This is discussed in detail in part 4.

Personal Kanban

Figure 1 maps Personal Kanban to its lowest viable level. In a nascent organization with no discernable structure or processes, personal kanban will still help individuals get work done and have an impact on organizational effectiveness. It may be the only viable option at such a low maturity level.

Figure 1. Personal Kanban & Organizational Maturity

Aggregated Personal Kanban

With aggregated personal kanban we see the emergence of collaboration, or at least some value in knowing what others in a team are doing. So we see some organizational behavior emerging and hence the organizational maturity is a little higher. Figure 2 shows that aggregated personal kanban kicks in a little higher up with maturity level 1. It is likely to be a starting kanban choice in very low maturity organizations – very emergent or chaotic circumstances and where there is an inability to form a wider service-oriented view of operations.

Figure 2 Aggregated Personal Kanban & Organizational Maturity

Team Kanban

Team kanban demonstrates that we have overt collaboration happening at a team level – typically 2 to 6 people but perhaps up to 12 people. The team may provide a discrete service, but more often than not they are part of longer workflow. There is typically a lack of service orientation at this level. Team kanban systems remain inwardly focused providing relief from over-burdening and are typically task focused rather than customer-valued work centric. When the tickets do represent customer-valued work and a customer is identifiable then it is a sign that the team provides a discrete service and some service-oriented thinking is emerging in the organization. Figure 3 shows that team kanban emerges in maturity level one as we start to see a transition from a focus on individuals to a focus on group collabobration. Team kanban is likely to be successful even while there is a reliance on individual heroics and some amount of luck in delivering within customer expectations.

Figure 3. Team Kanban & Organizational Maturity

Emergent Workflows

What separates an emergent workflow kanban form a team kanban is the overt understanding that there is a workflow and hence the provision of a service. There is by defintion a customer making service requests. The tickets on an emerenty workflow board tend to be customer requested and hence represent customer-valued work. With this design we see the emergence of service-orientation. While the workflow isn’t (yet) well understood, there is a customer focus. More of the values and principles of the Kanban Method are evident. For this reason, emergent workflow boards are shown as requiring greater organizational maturity than team kanban boards. We are still very much within the scope of maturity level 1, as shown in Figure 4, as we can’t define a service delivery workflow but the seeds of growing maturity have been planted.

Figure 4. Emergent Workflow & Organizational Maturity

Per Person WIP Limit

With a “per person WIP limit” board, we have a defined workflow for the first time. We are now border line on maturity level 2, as shown in Figure 5. The organization is ready for the stress of a pull system with end-to-end WIP limits but we do have service-orientation, a defined workflow and a board visualizing customer-valued work items. We arre seeing a deeper implementation of the Kanban Method with more of the values and practices present.

Figure 5. Per Person WIP Limit & Organizational Maturity

CONWIP & Decoupled Cadences

The ability to decouple the cadence of planning, committing or selecting work, from the cadence of delivery shows growing organizational maturity and an ability to coordinate activities with selective audiences. It is unusual for the audience at a replenishment meeting to be the same audience required for a delivery planning meeting and hence, decoupling these in terms of invited participants and frequency of occurence is a sign of growing maturity. In addition, having the ability to allow work to continue in-progress while a delivery is being made shows some additional technical capabilities – for software development, it requires a capability in confirguration management with an ability to use relabeling or branching in a version control system, or to embed code for dynamic code switches (or toggles) to render partially complete features inactive on delivery. Configuration management is a maturity level 2 process area in the CMMI. Together with a defined workflow and an actual pull system, we are now solidly in maturity level 2 territory. This style of board is shown as borderline maturity level 2 in Figure 6 as the workflow may be shallow. We may be dealing with a team kanban that has been decoupled or a team level batch process such as Scrum which has been decoupled. It is not essential that a board of this design is part of a customer-focused, service-oriented workflow and hence there may be fewer of the Kanban Method values and principles present in an organization adopting a CONWIP as shown in Figure 6 than a “per person WIP limit” as shown in Figure 5. I’ve chosen to show it as slightly higher maturity because of the emergence of a proper pull system for the first time and hence it is a borderline proper kanban system. We are leaving proto-kanban behind with this design.

Figure 6 CONWIP with Decoupled Cadences & Organizational Maturity

Aggregated Team Kanban

We are solidly in maturity level 2 territory, as shown in Figure 7. We have a defined service-oriented, customer-focused workflow. We have team level kanban systems with localized pull and relief form overburdening. The quality delivered to the customer will almost certainly improve even though other aspects of service delivery such as lead time and predictability may still be suffering. The organization isn’t ready for the stress of a proper pull system. The concept of a workflow level replenishment meetings and delivery planning meetings may not yet have occurred. We may have a push system from the customer perspective with localized pull at each team level. It is likely there is no customer involvement in pull decisions and very little collaboration between the service delivery workforce and the customer. So collaboration is still local to the service delivery organization but the emergence of a board like this shows that there is value in transparency, visualization and collaboration between teams within the workflow. This is evidence that there is some focus on customer service and delivering to customer expectations. The work will reflect that and the tickets will be customer-valued work items rather than team level tasks.

Figure 7. Aggregated Team Kanban & Organizational Maturity

Physical Space Kanban Boards

At this point, we have a kanban pull system. It is likely, though not essential, that we have customer involvement in replenishment meetings, and that delivery planning meetings are also emerging as necessary element in the process. We are now beginning to manage flow as we focus on shorter lead times and improved predictability. The WIP limits are now the overt stressor in the system and we will see the emergence of behavior to manage the flow of tickets and some effort to optimize the liquidity within the system. As shown in Figure 8, we are moving up towards maturity level 3. We probably haven’t reach level 3 as we are choosing a kanban board designed to work with less disciplined organizations. We would expect a solid level 3 organization to have the discipline not to abuse WIP limits and to understand when to break them for tactical reasons and when to change them as a systemic adjustment.

Figure 8. Physical Space Kanban Boards & Organizational Maturity

Physical Token Kanban Boards

With the adoption of a physical token style kanban board, where the tokens such as magnets on a magnetic white board are now the kanban in the system and represent the WIP limit, we have matured to level where we trust ourselves to manage the flow through a defined workflow. The organization doesn’t panic under slight stresses such as hitting a WIP limit. It holds its discipline and reacts by attempting to improve when given slight stress. We are solidly maturity level 3 as shown in Figure 9. We have the discipline not to abuse the WIP limit by adding tokens in response to tactical challenges and slight discomfort from enforcing the workflow. We have a customer-focused, service-oriented, full workflow, kanban pull system. We have well and truly left the world of proto-kanban behind us. At this level we would expect replenishment meetings to involve the customer, delivery planning to involve the downstream recipients of the product or service, and for service delivery reviews to emerge along with metrics for quantitatively managing flow. If these attributes of the Kanban Method are present then we are on our way to maturity level 4.

Figure 9. Physical Token Kanban Boards & Organizational Maturity

Virtual Kanban Boards

As shown in Figure 10, we are now mid-level 3 on our maturity ladder. The organization has the discpline to stick with WIP limits and respond to slight stresses with improvements. We like virtual kanban boards because they lend themselves to rapid and easy changes. We have a customer-focused, service-oriented, full workflow, kanban pull system. We have well and truly left the world of proto-kanban behind us. At this level we would expect replenishment meetings to involve the customer, delivery planning to involve the downstream recipients of the product or service, and for service delivery reviews to emerge along with metrics for quantitatively managing flow. If these attributes of the Kanban Method are present then we are on our way to maturity level 4.

Figure 10. Virtual Kanban Boards & Organizational Maturity

Classes of Service

There is now an overt understanding of customer needs, expectations and emergence of an understanding of the risks the customer is managing. To facilitate better customer service and service that is appropriate to the risks the customer is managing, we offer classes of service, separatin out lead time and predictability expectations by class and allowing the customer to request an offered class of service based on a business risk justification. Replenishment meetings must now involve the customer directly. We would also expect delivery planning meetings to involve customers and stakeholders responsible for using the delivered item. We may also see emergence of risk hedging capacity allocation by class of service and hence, emergence of maturity level 4 quantitative management techniques. Figure 11 shows that service delivery workflow kanban systems with classes of service are borderline maturity level 4.

Figure 11. Classes of Service & Organizational Maturity

Aggregated Service Kanban Boards

Figure 12 shows a larger system which provides multiple services, or services multiple work item types using the same pool of people and flowing the different types of work through an indentical or almost identical workflow. Aggregation provides greater liquidity and provides the ability to manage flow as demand for different types of work ebbs and flows. By utilizing a capacity allocation, creating a WIP limit on the rows of the kanban board, we can shape the demand for a given type of work and also regulate the averae delivery rate of work of a given type. We are showing the ability to manage flow and the introduction of some quantitative techniques to insure customerr expectations are met consistently. We now have the discipline to shape demand across different types of work. This is solid maturity level 4 behavior as shown in Figure 12. It is also possible to include the use of classes of service within the provision of each service and hence, demand can be shaped in two dimensions and the kanban pull signal is now 3 dimensional. It is possible to decouple the replenishment and delivery planning cadences for different types of work (rows on the board) if this is desirable. The level of sophistication of collaboration and risk management is improving all the time in comparison to lower maturity, shallower kanban implementations.

Figure 12. Capacity Allocation Across Aggregated Services & Organizational Maturity

Liquidity Optimization Kanban Boards

Figure 13 shows that by adding a workforce layer to our kanban board, we take it up a notch in maturity. We are now mapping customer concerns such as having a consistent collaboration interface and integrating our need to manage flow and utilize a flexible workforce to adjust to ebb and flow in demand for work of a given type. We have now integrated staff development and training into our explicit policies and our own risk management strategy. These behaviors will tighten the social cohesion of our workforce, improve collaboration and help us manage flow at the most effective of levels. Kanban systems such as these are likely to be larger and involve greater numbers of people – typically 25 to 50 though as many as 75 has been observed. If most other aspects of the Kanban Method are now present such as quantitative metrics togethert with Operations and Risk Reviews then it is likely we have an emerging maturity level 5 organization. If Strategy Review enters the mix and metrics in use are explicitly fitness criteria based on understanding what makes our services “fit for purpose” in the eys of the customer then we have a solid maturity level 5 organization that is now optimizing its economic performance and insuring its survivability through a continual focus on fitness for purpose and customer satisfaction.

Figure 13. Liquidity Optimization Kanban Board & Organizational Maturity

Conclusions

So what have we learned from understanding how kanban board and system designs map to organizational maturity levels?

The first observation is that with the publication of the Kanban Method in 2010 based on work from 2007, we started with maturity level 4 designs. Even though I and others described how to implement Kanban in an incremental fashion and to start with simpler designs, the simpler versions were still borderline maturity level 3.

The reality is that most of the adopting audience is at a much lower level of organizational maturity, and many people adopting were not the middle-manager target audience similar to me or Mike Burrows. When we saw lower level, grass roots, bottom-up adoption, it was inevitable that this was at a lower level of organizational maturity. It was therefore inevitable that proto-kanban emerged in the market. It is a tribute to the deliberate choices that I, and others made, to define the method in somewhat loose and ambiguous terms, such as “limit WIP” rather than the explicit and unambiguous, “implement a virtial kanban system,” that we got an explosion of diversity and mutations of kanban implementations – an entire ecosystem of variants emerged from Personal Kanban upwards. Had the method been rigorously defined in unambiguous terms then we wouldn’t have this diversity and we wouldn’t have solutions capable of helping significant portions of the market.

The leaders of the Scrum community have liked to position Kanban as “only for experts” and “only for high maturity organizations.” Many have advised their clients that they “aren’t ready for Kanban.” This is because they’ve viewed Kanban through their own lens. A lens where the method is rigorously and unambiguously defined. Ken Schwaber makes it quite clear that Scrum is a defined method designed to be implemented as written. Scrum works – and of this I have no doubt – in a particular context, and your challenge is to change your context so that Scrum works for you. Kanban has always been the antithesis of this. Kanban has always been about “starting where you are now” and evolving. If you are going to promote an evolutionary method, you cannot promote a rigorously defined method and defend its definition overtly. It is necessary to label “Scrum-but” and, in Ken Schwaber’s case to label those deviating from the precise prescription as “Scrum-butts” when you take a “change your context approach” to improving service delivery outcomes. When you take the opposite approach, a tune your workflow processes to enalbe better customer satisfaction, within your existing context, then you have to embrace variation and mutation.

When people started asking, in 2008, “are we doing Kanban or not?” my answer was always to say, it isn’t a question of practice adoption, it is a question of intent. If you have the intent to “start with what you do now” and improve in an evolutionary manner using visualization and WIP limits as the catalysts for change, then, “yes, you are doing Kanban!.” If you mere have some boards on the wall, with sticky notes visualizin tasks and there is no intent to drive evolutionary change then “no, you are not doing Kanban.”

In part 4, I will examine, what it takes beyond a kanban board and system design to enable evolutionary change and improvement inorganizational maturity. For now, it is important to understand that Kanban coaches embrace proto-kanban and shallow implementations as a necessary tool to fit Kanban implementations to existing levels of organizational maturity. In a method that is truly focused on “start with what you do now,” we need to embrace techniques that enable us to do that with minimal resistance or disruption to existing processes and practices.

Figure 14. Benefits of Improving Maturity

Not only is the Kanban Method designed to enable evolutionary change in your organization, it was defined in a manner that enables evolutionary change of the method itself. As such, we’ve seen a lot of diversity and mutation over the past 9 years. This has enabled Kanban to address a much wider set of circumstances. It isn’t true that “Kanban is only for experts,” or “Kanban is only for high maturity organizations.” Kanban is flexible enough, that in the hands of a professionally trained coach, it can be for any organization, at any level, and it has been shown that again in the hands of a professionally trained coach, Kanban is capable of facilitating accelerated improvement in organizational maturity with the corresponding benefits or better customer satisfaction and better economic performance through consistency of outcome and quantitative risk management for consistency of economic results. Figure 14 shows that organizations at maturity level 1 benefit from relief from overburdening. This has the effect of making the workforce happier and generally leads to improved product or service quality. Customer satisfaction does improve to this degree. At levels 2 and 3 we see a switch to a focus on flow and improving the service delivery and meeting customer expectations for lead time and predictability. At level 4, there is a focus on risk management both internally and servicing the customer in a way that facilitates their own risk management. We see risk hedging strategies emerging as a way of improving the consistency of economic outcomes. With a full implementation of the Kanban Method and achievement of level 5, the benefit is continual fitness for purpose, survivability in the face of fickle, uncertain market, political and economic conditions.

Driving Evolutionary Change with the Kanban Method

February 28, 2016 by David Anderson

This is part 4 of my series looking at Kanban, organizational maturity and evolutionary change. If you haven’t yet read parts 1 to 3, you can catch up here: Part 1: Organizational Maturity & the J-Curve Effect; Part 2: Patterns of Kanban Maturity; Part 3 – Kanban Patterns & Organizational Maturity.This series is intended to highlight the skills and expertise of Kanban Coaching Professionals (KCPs) who have completed their education through the Kanban Coaching Professional Masterclass, then completed a period of field experience, submitted an essay describing their experiences and change initiatives in which they’ve played a leadership role, finally, they’ve submitted to a panel interview of existing KCPs in order to complete the program and be nominated as a new KCP by their peers. We correlate strong improvement results and successful change initiatives with the involvement of KCPs. Success isn’t an accident, KCPs deploy a number of models in their engagements with clients and have access to the broad community of peers through online forums and face-to-face events such as the Kanban Leadership Retreat global series of consultants’ camp format conferences. If you seek to improve your organization in an evolutionary fashion consider training your change leaders as KCPs or bringing an existing KCP into your team to coach your change initiative.

Introduction

So far in this series, we’ve sought to understand how to assess organizational maturity, different styles of kanban boards and kanban systems, and we’ve seen how different styles of proto-Kanban or Kanban systems are more suitalbe for different levels of organizational maturity. From this understanding, it is evident why we have so much diversity in the market and how initial Kanban implementations were at maturity levels 3 through 5 while much of the market is at levels 1 and 2. This explains the 80%+ of market adoption at, in some cases, very simplistic levels of proto-Kanban. We also looked at why organizational maturity matters and its benefits – predictability, risk management, rorbustness and anti-fragility. This post looks at how you move up the maturity ladder and how you deepen your Kanban implementation in order to gain the benefits of higher levels. Like anything worth achieving, gaining higher levels of organizational maturity requires a little stress. The coaching skill is to know how much stress and of which type to produce effective results. Each time we invoke a little stress we invoke a small j-curve effect. The trick is for the stress to be enough to motivate the change without it being too much to result in a regression. Figure 1 is taken from the first post in the series and acts as a remind on the 5 levels of organizational maturity.

Figure 1. Organizational Maturity Model

Catalyzing Evolutionary Change

Figure 2 shows the cartoon form the cover of Kanban: Successful Evolutionary Change for your Technology Business. The cartoon was intended to communicate the essence of the Kanban Method in a single picture. It contains all the elements required to catalyze improvements.

Figure 2. “Kanban In Action” from the cover of Kanban: Successful Evolutionary Change for your Technology Business

In the cartoon, in figure 2, a team is meeting in front of their Kanban board. It is evident from the conversation and the image of tickets on the bboard behind them that not everything is going well for them. Something is creating stress for them, the meeting is a means for them to reflect together on what is happening, and the fourth character shows an act of leadership and suggests that they “do something about it.” The cartoon contains all three elements we require for evolutionary improvement: a stressor; a reflection mechanism; and leadership.

Formula to Drive Evolutionary Improvement

Figure 3 shows the organizational maturity model, together with the formula to drive evolutionary improvements and some indications of how the elements manifest differently as the organization matures and their Kanban implementation deepens.

Formula to drive evolutionary change:

a stressor
a reflection mechanism
leadership

Figure 3. Driving Evolutionary Change Across Maturity Levels

The most commonly understood concept of a stressor with Kanban is a WIP limit which causes stress when workers find themselves idle, often for many reasons beyond their own control, reasons that can by systemic and just chance, or reasons that are external and assignable to a specific root cause. Regardless, idleness, or “slack”, creates stress.

The most commonly understood concept of a reflection mechanism is the Kanban Meeting. Kanban meetings are as a default recommendation held daily in front of the board. The specific cadence of the meeting is contextual. The frequency affects the number of opportunities for process changes and hence evolutionary action. What is not material to the mechanism of evolution. It is that the meeting happens at all that matters. The effectiveness of evolutionary change will be affected by frequency and it is important to tune it to the environment – often enough to make a difference – seldom enough to insure new information is available since the last meeting.

The 3rd Change Management Principle of the Kanban Method is to “encourage acts of leadership at every level.” It is important that acts of leadership can and do happen at reflection opportunities. A Kanban Meeting where there is no leadership because the attendees do not feel empowered to make changes is a poorly designed meeting – a poorly designed reflection mechanism. It falls partly to the coach to encourage acts of leadership and to work with middle and senior management to insure that reflection mechanisms are adequately designed so that leadership can and does happen.

As a general rule, if improvement suggestions are not coming out of your reflection mechanisms then they are poorly designed – consider working with a Kanban Coaching Professional to improve them.

Driving Up Organizational Maturity Through Evolutionary Change

The choice of stressor and reflection mechanism must be tuned to the organizational maturity and the context.

Maturity Level 1

In the depths of maturity level 1, where you essentially have little organization, or collaborative effort, individuals can use both the visualization of their personal kanban boards and their WIP limits as their personal stressors. It is important individuals take time to reflect on how well things are working for them and consider personal improvements.

Often, for many low maturity organizations and contexts with difficult political situations, visualization and increased transparency is a stressor. There is no need for a WIP limit to create stress – just shine a light on the current issues with visualization. This will create stress, engage people emotionally and motivate changes.

What if and form of visualization will create too much stress?

There are circumstances where visualization is not an easy or possible choice. This can happen in more mature but dysfunctional organizations. We have seen examples of Vice Presidents of PMOs rippin down Portfolio Kanban boards in a rage. Some insecure middle-managers do not appreciate transparency. Often their self-esteem is rooted in the power of controlling information. Too much transparency weakens their power base, diminishes their self-esteem, attacks their self-image, and fills them with fear that things are out-of-control. They exist in a personally-framed world where controlling information flow, represents the concept that things are under control.

For Kanban coaches facing the circumstance where visualization represents too much stress, the recommendation is to start with other aspects and practices of the Kanban Method. Specifically, the recommendation is to starrt with “make policies explicit.”

Are there known side-effects of “making policies explicit?”

Not every organization is ready to have their policies made explicit. Sometimes making a policy explicit is a matter of visualizing it. If they aren’t ready for visualization then they aren’t ready too many policies becoming explicit. Explicit policies are also an enabler of empowerment. In general we want this. Explicit policies raise the social capital of the organization. There is a trust dividend: more explicit policies, more empowerment, faster, better decisions, less delay, avoided cost of delay, better economic performance. However, again some managers, view empowering subordinates as dangerous, or an outright attack on their own identities that diminishes their self-esteem and undermines their self-image. There are counter-measures for this: encourage senior leadership to intervene as mentors for managers who must create more empowerment; create a culture where reward comes from “work yourself out of a job”; balance empowering explicit policies with metrics and feedback loops demonstrating that things are working within agreed boundaries.

“Making policies explicit” is also known, from some results in behavioural economics, to encourage diversity of opportunity. Explicit policies are a social leveling mechanism. In any social structure, where there is a hierarchy, even if implicit, more explicit policies will create a leveling. There will be winners and losers. Gneezy and List have shown that employers with more explicit policies on pay, benefits and obligations, have greater diversity or opportunity – for example, fairer, more equal pay for women, and more women in higher positions. So when you play with a mechanism that creates broader, more equal opportunity, it is inevitable their will be losers. Those who lose out socially may not buy into the greater goals enabled by equal opportunity and diversity of contribution. If you run into this level of resistance, we have to view it as beyond the scope of the Kanban Method and venturing into broader cultural issues most likely beyond the parameters of the individual firm or employer into the broader society it is part of.

It is always difficult to give broad coaching guidance on Kanban and change leadership for a global audience because of societal variations. Some elements of the human condition are invariant – if someone may lose social status from a change, they are likely to resist. This is a global truth. However, whether a particular attribute of an existing system or culture gives someone an advantage is a starting condition which needs to be assessed on a case-by-case basis, by the coach, in situ.

The case, of the VP of PMO in a rage pulling down a Portfolio Kanban board, happened in an otherwise extremely liberal rapidly growing startup on the West Coast of the USA. Knowing the company culture, you wouldn’t predict the outcome and the resistance. This was a matter for the individual and not the wider business. It’s really impossible to give coaches a universal toolobx for avoiding and overcoming resistance to change.

Visualization, Kanban Meetings & Personal WIP Limits

The most common stressor and reflection mechanisms at maturity level 1 are the use of a board to visualize work and workflow, a Kanban meeting often at a team level, though perhaps at a wider, workflow level, in the higher reaches of maturity level 1, and the use of per person WIP limits. To be honest, I am not convinced the per person WIP Limits are a stressor, in fact they have the opposite effect, the provide relief. The relief from overr-burdening creates the opportunity for reflection. So at maturity level 1 we are relying mostly on visualization and perhaps explicit policies to create stress, while a regular meeting in front of board, coupled to per person WIP limits creates the reflection necessary to drive improvements.

Maturity Level 2

At maturity level 2, we now have predictability of process. We have a concept of a customer, customer requested work, and a workflow. We now have a chain of knowledge workers collaborating on a series of activities. The stressor is now the kanban system – the WIP limits on the columns on the board. While the Kanban Meeting continues as a core element of the method and is clearly a reflection mechanism and feedback loop, we now see direct interaction with the customer and the people who take delivery and perhaps operate the finished product in a production or field environment, as part of the process. The replenishment meetings and delivery planning meetings now act both as stressors and reflection mechanisms. We should start to see improvement suggestions and process changes happening as a result of these meetings. This becomes even more true as we move up through maturity levels 3 and 4. However, even at maturity level 2, we have a pull system for the first time. This creates a positive tension with the requesters – the customers. Now, they must decide what to work on now, what to leave until later, how much later, and what should be discarded altogether as theirs isn’t sufficient bandwidth to do everything. Equally our ability to deliver frequently should start stressing the downstream operations. We should see external changes being catalyzed as a result of our choice to adopt Kanban on our service delivery workflow.

Maturity Level 3

At maturity level 3, metrics become much more important. We now have a formal understanding of customer expectations, and perhaps formal agreements on delivery expectations such as SLAs. We will see the emergence of classes of service in the kanban systems. There is a strong argument that customer expectations, expressed as SLE (service level expectations) or formal SLA (service level agreements) now become a stressor. They will certainly affect, day-to-day operational decisions, on what to pull and where to assign workers and other resources. If you have specific stories describing where you saw metrics drive process evolution, we’d like to hear them. The reflection mechanisms begin to get more advanced with the use of service delivery reviews looking at externally facing capability metrics, and risk reviews looking at things that affect delivery and capability internally. The scale tends to be at the level of independent service delivery workflows thought we may begin to see the use of coupling of service workflows as a new form of stressor.

Maturity Level 4

Typically two workflows where one services dependent items from the other are decoupled with an unconstrained buffer, or parking lot. As an organization matures and the Kanban implementation scales, these unconstrained buffers are constrained with WIP limits. This creates stress between Kanban systems and necessitates the use of an organization level feedback and reflection mechanism, the Operations Review.

At maturity level 4, buffer sizing on dependent workflows and capacity allocation across work item types and classes of service becomes the important stressor driving organizational improvements and overall improvements in customer service and fitness for purpose. Risk hedging strategies chosen for quite sensible reasons will create stress. For example, there will be pressure to pursue many tactical opportunities at the expense of strategic initiatives. It becomes important for the organization to hold its nerve on row WIP limits. Being able to do so, is an indication of the instuitutionalization of maturity level 4.

Maturity Level 5

At Maturity Level 5, to provoke further and grander evolutionary change at the business level, we begin to move beyond the scope of the Kanban Method and utilize elements of the Enterprise Services Planning body of knowledge and class curriculum: the comparison of strategy with capability; and the use of strategy reviews as the reflection mechanism to drive change.

At this level, the stressor is a combination of business strategy and business goals. It is important that strategy is balanced to capability and stretches it only just enough that it acts as a positive driver of change, improvement and innovation, rather than simply breaking the organization. Military leaders have understood for centuries that you pick a strategy based on your capability if you wish to be successful. If their is gap between the desired outcome, the strategy required to archive it, and current capabilities, then they invest in capability first. They do not allow politicians to set them up for failure by recklessly pursuing strategies that cannot be achieved with existing capability. Corporate leaders often do not have this training. They often choose, “big hairy audacious goals”, and believe that doing so, acts as a stressor to drive change. These moonshots are generally never as well resourced and supported as the Apollo program, however. It is much more likely that the operational level management are left clueless as to how they might achieve the requests from their senior leadership. So they simply crack the whip, expect more from an organization not capable of it. What follows is over-burdening, over-reaching, and over-stretching. The result is often a catastrophic failure and perhaps a regression back to maturity level 1 or 2.

Currently, coaching corporate goals and strategy as a reflection of service delivery capabilities is beyond the scope of the Kanban Coaching Professional program. If you are interested in how we use Enterprise Services Planning and the concept of “continually fit for purpose” with our clients, please inquire to Lean Kanban Services for direct consultation and private training.

How far can a coach take us?

A Kanban Coaching Professional (KCP) perhaps working with an Accredited Kanban Trainer (AKT) can take you from mid maturity level 1 all the way to maturity level 5. The higher reaches of maturity level 5 require familiarity with Enterprise Services Planning and specifically the strategy and fitness for purpose subjects in the curriculum. At this time, there are only a small subset of KCPs with this knowledge and experience.

How far can our local Agile coach take us?

Based on the evidence we see in the market, where an Agile coach has not had any specific Kanban training but has some exposure to the method through the community, Agile conferences and perhaps has read some books – most typically a very thin, free book published in 2008, which offers little depth and carries a number of myths and inaccuracies in it – then our observation is that such an Agile coach can start you at the depths of maturity level 1 with Personal Kanban, and take you up to mid maturity level 1 with Team Kanban. Some Agile coaches are capable of taking you to Maturity Level 2 with an Aggregated Team Kanban, proto-Kanban implementation, perhaps exhibiting a few attributes of level 3 or 4 implementations such as rudimentary classes of service and some metrics.

Agile coaches who can take you further will have specific training and experience and are likely to share that with you as part of their marketing materials. They will view themselves as Kanban Coaches.

When evaluating a Kanban coach, ask them what training or certificates they have explicitly in Kanban. Ask them which Lean Kanban conferences they have attended and whether they have ever been a speaker. Ask them which Kanban Leadership Retreat events they have attended and what they learned from the experience. Ask them to show you their community contributions, whether articles on line or in print media or community organization such as Limited WIP Society or Lean Coffee organization in their region. Kanban coaches who can deliver results, can show you this material. Agile coaches who are bluffing and won’t be able to take you where you need to go, will not.

Conclusion

Achieving the benefits for higher levels of organizational maturity, can be achieved using the Kanban Method as an approach to improved service delivery and evolutionary change. Someone leading a Kanban initiative needs to be cognizant of the organizational maturity level when choosing the mechanism to drive evolutionary improvement. As the organization matures and the Kanban implementation deepens, the important stressors and reflection mechanisms needed to take the organization further will change. The scope and the scale will change. The personnel involved will change and the pay grades of those affected will rise until eventually we are all the way at the top. Kanban Coaching Professionals are trained to have the skills to design kanban systems and boards that are tuned to the level of organizational maturity and have the correct stressors to catalyze improvement without overstressing the organization and causing a failure of the kanban system and a regression in organizational maturity.

There is a lot of subtelty to coaching Kanban and using it to drive change. There is a reason why there is 10 to 15 days of training plus months or years of field experience required to become effective as a Kanban coach. If you want to succeed at evolutionary change, work with a professional – choose someone with a history of involvement in the Lean Kanban community, someone who has attended the Kanban Coaching Masterclass, someone who is a speaker at Lean Kanban conferences, and someone who attends Kanban Leadership Retreats to share and learn from their peers. We correlate successful results with knowledge and experience.

Learn more…

If you would like to know more about becoming a kanban coach take a look at Kanban University and consider attending our Kanban Coaching Professional training.

Kanban’s Service Delivery Principles

January 24, 2016 by David Anderson

This is the second post outlining the 6 principles of The Kanban Method. This one explores the 3 Service Delivery Principles. While service delivery has been core to Kanban since 2004, the emphasis on it in our literature is recent and this text is new and still emergent. This is another extract from forthcoming book, “Essential Kanban: The Guide” co-authored with Andy Carmichael.

Kanban’s Service Delivery Principles

The Kanban Method is rooted in the premise that we can learn to cope with abundant complexity of the modern workplace by thinking of it as an ecosystem of interdependent services and learning to manage and organize in a service-oriented fashion. This provides us with a massive simplification that we can think of an organization as a network of services where each node in the network represents a service, even if that service spans across functions within the organizational hierarchy. This enables us to manage the business allowing each service (each node in the network) to evolve independently through evolutionary change driven by fitness criteria metrics that model the desired level of service the customers of each service need in order to meet their own needs. Hence, external customer needs and expectations can cascade through the corporate ecosystem of interdependent services and large scale, holistic improvements can emerge from localized improvements driven at level of each service.

Fundamentally, Kanban is an approach to improving service delivery. It was first introduced (in 2004) within Microsoft’s IT department as an approach to improved service delivery. The change management benefits were not realized or appreciated until 2007 with the implementation at Bill Gates’ photography archive and intellectual property rights management business, Corbis. A choice was made in 2009, to emphasize evolutionary change as the unique aspect of Kanban. In more recent years, the original service delivery benefits have come back into vogue.

Service Delivery Principles

Your organization is an ecosystem of interdependent services. Kanban acknowledges this with three service delivery principles, applicable not just to one service but to the whole network:

Focus on the customer
Understand and focus on your customers’ needs and expectations
Manage the work; let people self-organize around it
Evolve policies to improve customer and business outcomes
Policies determine the characteristics of your service delivery system; evolve policies so that customer satisfaction and business outcomes improve

Let’s look at each principle in more detail.

Focus on the customer

Why do we want to improve? What is it we are trying to improve? And at a higher level, recognizing that our service is just one amongst an interconnected ecosystem, what changes can we make that will enable survivability – robustness, resilience, and adaptability?

Ultimately, it is our customers that decide whether our service is “fit for purpose” and it is their dissatisfaction that should drive our need for improvement.

Even when we are a monopoly (internal) supplier, if we share the value of customer focus, there will be motivation for change – those changes should, equally, be customer focused. Focusing on the customer means we need to understand customer needs. We need to segment our customer base, based on their needs and expectations. We need to view our customers based on the criteria they use to evaluate whether they are satisfied with our service and whether they would recommend us or speak highly of us. These criteria are known as Fitness Criteria and we should adopt them as the metrics which drive our improvement initiative.

We need a clear understanding of who our customers are, what they ask us for, and what their expectations are in terms of service levels. By taking a customer focus we will design a kanban system with suitable capacity, capacity allocation and classes of service that can meet their needs – or least the needs we are prepared to fulfill within our economic constraints and risk tolerance.

Manage the work; let people self-organize around it

Throughout the 20th Century, the management of professional services where the goods are intangible has focused on the people and the time those people have to perform work. In other words, management has focused on what it can see – the people – and what it can measure – the time those people have available. Unlike tangible goods businesses, there has been little to no attempt to focus on and manage inventory levels and the “movement” of unfinished work through the organization. The Kanban Method posits that this has been a fundamental mistake!

By visualizing invisible work – intangible goods – we enable an ability to manage more like we do with physical environments. Counting how many user stories are in-progress in a software development team can be established as a fact. Counting how many ad campaigns are in development at an advertising agency can be established as a fact. Counting how many graphic design jobs are in progress in a visual design department can be established as a fact. While trying to guess how long any one of these tasks will take and how much “capacity” individuals have, based on how many hours they are available to work, has been pure guess work. The reason for this is that the duration of such creative knowledge work tasks is a non-deterministic problem. We’ve been using an inappropriate method for managing modern work producing intangible goods.

By visualizing the invisible, we enable an ability to manage with facts rather than guesses and speculation. It appears to work more effectively!

The customer asked for something, even though that something is an intangible good – think of it like something physical like ordering an omelet from the short order chef at breakfast, or a cup of coffee in a self-service face such as Starbucks. Managers in such businesses are not trying to estimate how long the item will take, allocate a worker, and calculate how many such tasks can be performed in a given time period. Instead, they manage the work, the workers pick up the job requests, produce what was requested, deliver it to the customer and move on to the next job. In a physical environment they have it easy – there are physical constraints that create obvious work-in-progress limits and queues are deterministic. For knowledge work we need to create virtual limits to work-in-progress and learn to cope with non-deterministic buffers where we pick items based on suitability of matching work to a worker’s skills and experience, or based on the required class of service of items waiting. Once we’ve learned to cope with these differences, managing work in order to focus on the customer, becomes second nature. To do it, we need to unlearn a behavior that we should never have learned in the first place – managing people and time. It’s better to manage work while visualizing the goals for workers – let them understand the customer, their needs, their expectations, the risks they are managing, what they’ve asked for and why they need it. Kanban boards enable us to visualize us this and enable a new way of managing. As a result, customer service improves because the whole system is designed around the customer and their requests – the intangible goods we must create.

Evolve policies to improve customer and business outcomes

Processes can be reduced to the concept that they are simply a set of policies which lay out how work should be done, who should do what, and in which order or sequence. They define how decisions should be frame and made. They provide governance rules and audit check points. When you encounter a sign by the mirror, in the restroom of your local café stating “Employees must wash their hands.” This is a policy. It is a policy which is also a regulatory requirement. It trades off hygiene, health and safety, against how much time the employees spend in the restroom and how quickly they can return to work. Most policies represent decisions which trade off one aspect of risk against another. “all code must have unit tests” trades off functional quality, and future maintainability against initial development time. The fourth practice of the Kanban Method asks us to “make policies explicit.” Instead of viewing our processes as a sequence of activities, workflow, roles and responsibilities, we want you to view your existing processes as sets of policies and those policies should be defined explicitly. This doesn’t mean you need a large catalog of policies. Some policies can be encoded into Kanban Board designs while others can be encoded into meeting formats.

Making policies explicit makes them discussable. It opens them up for review by a wide audience and it usually makes the reason for the policy self-evident. The risks the policy trades are understood. As a result, the policy can be challenged and changed if risks change. The appropriateness of the policy and the outcome it produces can be challenged – are we too risk averse? Are we taking too much risk?

Classes of service are sets of policies. A class of service is a set of policies that describe how an item of work should be treated. Classes of service should be directly aligned to customer expectations and the fitness criteria with which the customer evaluates our performance. Thinking in policies enables us to serve the customer better.

Thinking in policies can help us align with the change management principles. By moving away from viewing a process as a methodology consisting of defined workflow, roles and responsibilities, and thinking of it as a set of policies for deciding how work is treated, we focus on the work, and not the w

orkers, and we are less likely to invoke identity related resistance to changes even when changing a policy, changes the responsibilities or accountability of an individual.

A full exploration of this topic is beyond the scope of Essential Kanban and is covered in the Kanban Coaching Professional curriculum.

Kanban’s Change Management Principles

January 23, 2016 by David Anderson

In 2016, we are extending the Kanban Principles to specifically break out Service Delivery from Change Management as two sets of three. In the first of two posts on this I lay out the 2nd Edition of The Kanban Method, Change Management Principles.

Change Management Principles

Your organization is a network of individuals, psychologically and sociologically wired to resist change to their identities, social structures and means of deriving self-esteem and social status. Resistance to change in the workplace often stems from how the changes affect individuals psychologically and sociologically. Kanban acknowledges these human aspects with its three change management principles:

Start with what you do now
- understanding current processes, as actually practiced
- respecting existing roles, responsibilties and job titles

Agree to pursue improvement through evolutionary change
Encourage acts of leadership at every level
- from individual contributor to senior management

Kanban Pillar

These principles represent The Kanban Method’s approach to change. An approach which has been adopted as a response to the complexity of the modern professional services workplace where workers perform knowledge work, producing intangible goods – a workplace where people are paid to think for their living and make decisions as opposed to carrying out manual activities under direction and supervision of a manager. In a knowledge worker workplace, management responsibility simply communicates authority to make decisions containing greater risk. In a knowledge worker workplace everyone makes decisions regardless of any supervisory responsibilities. These modern workplaces are inherently non-deterministic in nature. The system is complex and the outcomes it produces are emergent. 20th Century deterministic methods are outmoded. Kanban provides one new approach to process improvement and management for 21st Century businesses.

Start with what you do now

Most change management is based on a model introduced by the McKinsey consulting firm. This model became prevalent in the 20^th Century and has two main flavors: replace what you are doing now with a defined process, prescribed from a catalog; design a replacement process customized to the dynamics of your environment. There is a variant of the second type where the design is based off the existing process as a baseline. There are several variants of these including Value Stream Mapping from the Lean body of knowledge, and the Thinking Processes approach from the Theory of Constraints. The Kanban Method rejects all of these approaches on the basis that they typically introduce too much change all at once, and they suppose that the process designer is somehow smarter than the workforce and smart enough to understand all the complexities of the domain and the dynamics of the workflow. This approach of designing solutions or selecting them from a pattern catalog seems to have worked fairly well in deterministic domains and physical environments. The Kanban Method is based on the assumption that such an approach is problematic in complex, non-deterministic domains such as professional services, knowledge work and creative pursuits. In other words, 21^st Century businesses need a 21^st Century model for change management. This model should be based on evolutionary theory as it is compatible with and robust to the complexity, emergent and non-deterministic outcomes of modern work producing intangible goods.

Specifically, “start with what you do now” is intended to reduce resistance to change from the people involved. Resistance to change is rooted in the identities of the individuals and the social groups to which they belong. Identity has psychology, social-psychological and sociological components to it. Identity and social position are often derived from practices performed. When we change these, we risk resistance. When we change the role and responsibilities of an individual or group of individuals, we risk resistance. If our goal is to make changes in order to improve service delivery, then we wish to avoid resistance to change.

Strategies for change are beyond the scope of Essential Kanban but we should recognize that our first strategy for managing change is always to avoid it when possible. So Ideally no one gets a new (professional) identity as part of a Kanban initiative. There are exceptions to this, if we introduce Service Delivery Manager or Service Request Manager roles but these are exceptions, not the rule.

Agree to pursue improvement through evolutionary change

Because The Kanban Method’s approach to change is so different from the 20^th Century approaches involving defined or designed processes and defined transition initiatives in order to adopt the new way of working, it is important to gain agreement and understanding of the decision to pursue an evolutionary approach and agreement on what that means.

Evolutionary change means that in terms of a process definition, we are never done! There is no concept of “we have arrived” because we have adopted a set of practices and people are now behaving according to new role definitions and embracing new responsibilities. Instead, things will change little-by-little in response to need.

We understand those needs by understanding what makes a service “fit for purpose”. We define meaning metrics with threshold levels to reflect what represents “fit for purpose” in the eyes of the customer. Fitness criteria metrics define our desired capability. A gap between our current capability and the desired capability represent a driver for change. We can use analysis and modeling of our current processes to suggest changes. In this way we view Kanban as a model-driven and scientific approach to evolutionary change. It is directed evolution rather than random mutation of existing processes.

The concept of randomly mutating our existing processes would be compatible with The Kanban Method and is likely to resemble lower maturity, opinion-based change where gut feel rather than analysis and modeling are used to suggest the changes.

With Kanban we evaluate whether a change delivered an improvement by comparing the outcome against the desired fitness thresholds. If our capability has improved towards the desired levels then the change was an improvement and we should stick with it and probably amplify it. If the change resulted in a step back in capability then may consider rolling the change back or implementing another change, a roll forward of our process, in order to get back on track.

Encourage acts of leadership at every level

Change doesn’t happen unless someone cares, unless someone stimulates it to happen. The cover of the book, Kanban – Successful Evolutionary Change for your Technology Business features a cartoon with a character saying “Let’s do something about it.” This is an act of leadership!

Fundamentally what drives Kanban is the value of Customer Focus and the resultant leadership that comes from caring about improved service delivery and the resultant improvement in customer satisfaction.

Just as Kanban adopts a 21^st Century evolutionary approach to change, because the domains are too complex, emergent and non-deterministic compared to 20^th Century physical workplaces, equally Kanban believes that to drive change you need leadership at all levels. Seeing the opportunities for improvements and holding dissatisfaction about current capability should rightly be everyone’s business. The complexities of modern workplaces mean that it is unreasonable to delegate responsibility for process design and change management to a single person, department or representatives of a consulting firm. The Toyota culture of “kaizen” meaning “continuous improvement” is achieved by creating a culture where acts of leadership are encouraged and rewarded at all levels.

To encourage acts of leadership at all levels, leaders must lead by example. They must suggest changes. They must show the courage to speak up and experiment with changes. The culture must become experimental. There must be tolerance of the notion that not all changes are improvements. And that each change is an experiment until its results can be observed and analyzed. Failed experiments are not failures if the organization learned from it. If people fear being held accountable for failure then they will not show leadership. So to encourage acts of leadership at all levels not only must you lead by example, but you must create a culture of tolerance, understanding and patient, thoughtful inquiry.

Changing the culture isn’t a pre-requisite of Kanban, it should be part of the emergent outcome from practicing Kanban. The value gained, depth and maturity of your Kanban implementation will be constrained by your ability to embrace tolerance of failure, through thoughtful, patient, scientific inquiry and the ability of your workforce regardless of pay grade to feel safe making acts of leadership. Ultimately, there needs to be collective responsibility and accountability for service delivery and customer satisfaction, if you are to reach the highest levels of Kanban and reap its benefits.

What We Know About Duration: Individual Activities

January 19, 2016 by David Anderson

The latest fad in the Agile software development community is to promote the use of Cost of Delay for prioritization. Many readers will know that I have been an advocate of Cost of Delay style prioritization and my 2003 book, Agile Management for Software Engineering contained several Cost of Delay related algorithms. However, I feel there is a lot of misinformed, simplistic and potentially dangerous guidance floating around on Cost of Delay and it is time to provide some clarity.

Most of the Cost of Delay material in the Agile space has focused on referencing and modifying the WSJF (Weighted Shortest Job First) equation from Donald G. Reinertsen’s most recent book, The Principles of Product Development Flow: Second Generation Lean Product Development.

The essence of the WSJF equation is total lifetime profits divided by duration of the product development project.

In the first few posts in this series, I want to look at what we know about the denominator in this equation – the duration of the project. WSJF is also being applied in some frameworks to the prioritization of user stories, features and so forth. I don’t believe this is remotely appropriate and I want to start there by explaining what we know about duration of such user stories or features and illustrating why use of duration on the denominator of the WSJF equation is not appropriate for comparative assessment, sequencing and prioritization of fine-grained work items such as user stories.

What We Know About Duration: Individual Activities

On February 24, 2001, I first published my 5 point power law scale for assessing the size and effort of Features in the Feature-driven Development method, on my uidesign.net blog.

Comparing my data later with some well known XP advocates such as Tim McKinnon I realized that the London school of User Story writing was producing user stories of similar size and complexity. This scale appeared formally in my 2003 book, Agile Management for Software Engineering. I first used it on a project in Dublin, Ireland in the summer of 1999.

Figure 1 – Idealistic Normal Distribution for Features analyzed into 5 size & complexity categories

Figure 1 illustrates the scale. It isn’t a random thing. It isn’t based on “estimation” or conversations. It is based on analysis. In other words, it is entirely deterministic. The controlled sentence structure for writing features in FDD enables someone skilled in the art to quickly assess how that feature will impact the code. The sentence contains clues to the method name, the class the method will be coded within and the return value from the method. Given knowledge of the return value, someone skilled in this technique, can almost at a glance make an assessment of how many classes will need to be navigated to produce the desired output. The assessor isn’t doing a design just using their judgment to assess what the design is likely to entail, in terms of classes accessed and method calls.

So I created a 5 point scale: features of sizes 1 through five. I assessed that the average level of effort for such features would rise in a power 2 function: 0.5 days; 1 day; 2 days; 4 days; 8 days or more.

Assuming we’ve made a correct sizing – which is a reasonable assumption as more than 90% of features are likely to be correctly sized using this technique, it is still unlikely that a task duration such as design and coding the feature – actually writing all the method calls and all the unit tests – will take precisely the average time. In fact, it is likely to be random and reasonably evenly spread.

If we had enough data points – a few hundred – and we have a situation where there is no multi-tasking, no delay or blocking on other dependencies and no disruption during the task, then we might expect a properly normal distribution with a scale of about 50% above and below the average. So Size 2 features taking on average 1 day should take something between 0.5 and 1.5 days to complete.

There is a degenerate case where multi-tasking does not skew the shape of the of the normal distribution. This is where the rate of task switching is twice or more as fast as the shortest possible task duration, i.e. if we have a 31 minute task and we switch tasks every 15 minutes then there is an equally random chance that all tasks will be interrupted and hence the distribution will remain Normal. Of course, such rapid task switching would mean the process was massively inefficient and the whole distribution would be right shifted and scaled to the right as a consequence. This is why it is a generate case: it exists in mathematical theory but in reality it never exists.

If we consider now that the smallest task might take 30 minutes (0.5 hours) and the longest might take 12 days (96 hours) we have a spread of variation for Feature effort that spans 200x the smallest duration. The 200 multiple is right in line with reports from Reinertsen. It is probably reasonable to assume that task completion times will span at least 50 times the minimum size regardless of the process used. Again this data is “level of effort” and is still assuming no task switching, no delays and disruptions in service.

Now let us consider the spread of variation of Feature sizes in a given project…

Figure 2 – Even distribution of features and a more typical mix weighted to small and medium sized Features

Figure 2 shows how the distribution of task duration might vary as we sum the distributions for each feature size. In other words, if we treated all features, simply as features, how long might they take to complete? The upper diagram shows a multi-model distribution for an evenly spread distribution of features, i.e. we have approximately the same number of size 1s, as we do, size 2, size 3, size 4, size 5. I have never seen such an even spread. More typical is a skew towards small and medium size with size 2 being the most common. This produces a distribution more like the lower example.

What do multi-tasking, delay and disruption do to the distribution shape?

Figure 3 – Multi-tasking, delay, and disruption right shape and left shape the distribution

If there is less than an even chance of something being delayed then the tail of the distribution gradually gets pulled to the right. Therefore, long duration tasks have more chance of being delayed and things which are delayed have more chance of being delayed further. This is what produces the long tail to the right.

Mathematically, as we pull the tail to the right, the shape parameter in the Weibull equation shrinks. We refer to this as left-shaping or left-skewing the distribution. The whole distribution has been physically shifted to the right. Note carefully that I have placed a scale on the x-axis. The mode|median|mean in the Normal distribution is at 4.0 while the lower curve has a mode of 11, a medium of approximately 11 and a mean of approximately 12. So the mean task duration has increased 3 fold because of delay and multi-tasking.

Averages are easily explained but it is the tail on the distribution which represents much of the risk. In the normally distributed ideal situation the task is being completed in a maximum of 8 while after we introduce multi-tasking, delay and disruption of service the maximum has grown to 38.

Figure 3 showed the skew in the distribution for a size 4 feature where some multi-tasking and delay due to dependency and disruption of service (i.e. unavailability of the worker through for example illness or jury duty) occurs. You can imagine when we model this for all five sizes and then roll it into a single distribution similar to figure two that we get an even more pronounced long tail effect.

All of this is a for a single activity. We haven’t even started to look at a workflow of multiple activities with delays waiting between activities in the workflow. I will cover that in the second post in this series.

So What Do We Know About Task Durations?

In summary then, if and only if you have a deterministic analysis technique to quickly and cheaply asses size and complexity you may be able to break your task durations into a taxonomy of categories.

As Jurgen Appelo pointed out in his book Management 3.0, Fibonacci series so beloved of Agilists does not in fact appear in nature. Also it’s index isn’t sufficiently sparse: a story assessed as a 3 on a Fibonacci scale is likely to be a 1, 2, 4, or 5, while the alternatives above and below are 2 and 5 and hence, it is quite random whether a user story is a 2, 3, or 5. If you use user story points as a proxy for duration there is a high likelihood that the assessed size is wrong. This makes it useless as a means of comparative assessment and prioritization in an equation such as WSJF. As a consequence of this there is little to know information value in the sizing and for the purposes of calculating duration we may as well assume all user stories are the same size. This would eliminate user story size as a usable parameter in the WSJF equation.

On the other hand, power laws and Weibull distributions including (k=4.0) Normal distribution and (k=1.0) Exponential distribution do exist in nature. So it is much more likely that sizing for user stories follows a power law. Jurgen discovered in 2009 that I had published such a power law, and the earliest online reference is February 24th, 2001. Even with a power law scale there is some, but less chance of the actual duration overlapping with an item of a different size or complexity. Hopefully, figure 1 was sufficient to persuade you that a point sizing scale assessing size and complexity is not meaningful in assessing task duration for the purposes of comparative assessment and prioritization? If not perhaps the second article in this series will get you to the conclusion that estimating duration for the purpose of using it as the denominator in the WSJF equation is not useful at the granularity of stories, features or epics.

We know from other reports that task durations typically have a spread of up to 200x and the FDD power law scale I developed demonstrates that quite readily – if we assume an 8 hour working day. In my 2003 book, I assumed only 5.5 productive hours in the day and hence we would have merely a multiple of 132 from smallest to largest feature.

So we understand that the problem of estimating task durations such as user story development is non-linear, but we also understand that it is non-deterministic. If we know for example, for certain, from deterministic analysis, that this feature involves 3 classes and 5 method class, we still cannot say with deterministic precision how long it will take. The duration is a Weibull distributed random variable.

So, in summary, for an individual activity in a workflow, the task duration to complete the activity, varies non-linearly, in non-deterministic, is approximately Weibull distributed with a shape in the range 1.0 < k < 4.0 and most likely in the range 1.3 < k < 2.0 and can have a spread from shortest to longest that can be up to 200 times the shortest value.

If you are trying to “estimate” the duration of a task such as designing, coding, testing a user story, you are basically guessing. You are rolling the dice, making a stab in the dark. The actual time-on-task duration for the activity is likely to be wildly different from your “estimate.”

In the next post in this series I will look at what happens when we have a chain of activities put together as a workflow. What do we know about lead time through a workflow?

Your KPIs Probably Aren’t! But What Are They?

January 19, 2016 by David Anderson

This is the 2nd part of my post following Defining KPIs in Enterprise Services Planning.

Running our classroom exercises with private clients this past 18 months has shown me that most businesses have KPIs which really aren’t Fitness Criteria Metrics. In other words, their KPIs are not indicators of performance and certainly not key indicators or indicators of key performance. What I see as KPIs are really what should be classified as general health indicators and in some cases metrics driving specific improvements.

So what are general health indicators? Read more…

General Health Indicators

If we were to talk about individuals as people general health indicators are their pulse, their weight, their blood pressure, their cholesterol levels. If the individual was an athlete, they wouldn’t be setting goals based on achieving a certain blood pressure or a certain pulse rate but they would have expected ranges for these and they would monitor them. They might also monitor, for example, recovery time – the time it takes an accelerated heart rate to recover to a more normal level after stress.

Whether customers walk through your door is a health indicator. It is like having a pulse. Whether they buy something is also a health indicator and whether you had a positive margin in that sale and free cash flow are also health indicators.

In comparison, whether your customer is satisfied and whether they are likely to place repeat business and recommend you to a friend or colleague is a performance indicator. There are plenty of profitable businesses with lackluster stock price performance while others with growth but negative free cash enjoy elevated P/E ratios. They can always raise capital because their performance in the market is improving.

In Agile software development, velocity is a health indicator – you’d rather have some than not – but it is unlikely to be a performance indicator. The reason for this is that the volume or rate of production is not a fitness criteria for your customers and it is rarely a valued criteria even for internal stakeholders. Customers value things like delivery time, quality, useful functionality. You may believe velocity is a proxy for delivery time but it may not be. You may have a lot of velocity but a chronic, systemic problem with growing work-in-progress and ever longer delivery times. You are like a patient with a pulse but your blood pressure is trending the wrong way, your cholesterol is rising and your ability to get day-to-day tasks completed is being impacted. It could be your liver isn’t performing as it should be? If you set a target for your blood pressure you might be able to hit it by taking drugs – this is known as a symptomic fix which allieviates the symptom but fails to get to the root cause, as a result the problems persist and you end up back where you were again, a few months later. The same is true for companies. Many health indicators can be “vanity metrics” like boasting about your “at rest” heart rate – it isn’t always a fitness indicator!

Sure enough if you don’t have sufficient working capital, if you don’t have margin and profits and free cash, your corporate health is in danger, but as Richard Branson said, “People think companies exist to make profits. Wrong! They make profits in order to exist!” When you change to a mindset like Branson’s you start to see general health indicators for what they are, and you stop calling them “Key Performance Indicators.”

Metrics Which Drive Improvements?

While less common, it isn’t unusual to find a manager with a KPI on their scorecard which should rightly be classified as an Improvement Guiding Metric.

For example, we have poor customer satisfaction and a low Net Promoter Score because our delivery times are too long. In other words, the customer views lead time as a key selection criteria. Lead time is a fitness criteria metric and consequently lead time should be one of our KPIs.

In order to improve lead time, we decide that we want to automate testing because after analysis we discovered a significant portion of lead time is delay waiting for manual testing.

So we create an improvement goal to automate the testing of 85% of our application. We want 85% automated test coverage. So we start measuring and reporting the percentage of code covered by automated tests. We may even have placed this metric on the SMART goals for a manager. Despite all of this, it doesn’t make it a “Key Performance Indicator”. Instead it is a derivative of a KPI. The true KPI is lead time. We believe that by improving automated testing we will improve lead time. We may have causation to determine this or it may simply be a postulation and an experiment. The true KPI remains the customers’ fitness criteria – the lead time. So automated code coverage percentage is an Improvement Guide Metric.

Classifying Your Metrics

In our Enterprise Services Planning workshops, we have a series of exercises on metrics and the specific exercise on classifying existing KPIs is particularly enlightening for clients. They discover that most, if not all of their existing KPIs, are in fact health indicators and some improvement guides. Often the clients are not measuring anything which affects customer satisfaction. It is no wonder then that they aren’t happy with the NPS results.

What About Metrics That Aren’t in Any Of The Categories?

During the exercise, clients often find existing metrics they are measuring and reporting which can’t be classified as Fitness Criteria Metrics, Improvement Guides or General Health Indicators. The reality is these are metrics they probably don’t need and should drop. Often these are legacy metrics – metrics that were guiding earlier improvements, or perhaps fitness criteria that no longer apply because the company doesn’t serve that market segment any longer, or the customers in that segment have changed their opinion about what is acceptable and what represents “fit for purpose.” In some cases, the metrics are simply things the business could see and was capable of measuring. They serve no useful purpose.

To discover if a metric has a useful purpose ask yourself, “What decisions does this metric affect?” “What would we do differently if this metric rose or fell or hit some threshold value?” If you can’t identify an action or outcome you expect as a consequence of reporting a metric then you don’t need it.

When clients complete our Enterprise Services Planning workshop they often find they need far fewer metrics than they were already capturing and reporting but equally they need new instrumentation in order to capture the fitness criteria they’ve discovered from thinking about market segments in a new way and seeing their product or service through the customers’ eyes.

David Anderson

Mapping Kanban Designs to Organizational Maturity Levels

Personal Kanban

Aggregated Personal Kanban

Team Kanban

Emergent Workflows

Per Person WIP Limit

CONWIP & Decoupled Cadences

Aggregated Team Kanban

Physical Space Kanban Boards

Physical Token Kanban Boards

Virtual Kanban Boards

Classes of Service

Aggregated Service Kanban Boards

Liquidity Optimization Kanban Boards

Conclusions

Read more…

Introduction

Catalyzing Evolutionary Change

Formula to Drive Evolutionary Improvement

Driving Up Organizational Maturity Through Evolutionary Change

Maturity Level 1

What if and form of visualization will create too much stress?

Are there known side-effects of “making policies explicit?”

Visualization, Kanban Meetings & Personal WIP Limits

Maturity Level 2

Maturity Level 3

Maturity Level 4

Maturity Level 5

How far can a coach take us?

How far can our local Agile coach take us?

Conclusion

Learn more…

Kanban’s Service Delivery Principles

Service Delivery Principles

Focus on the customer

Manage the work; let people self-organize around it

Evolve policies to improve customer and business outcomes

Change Management Principles

Start with what you do now

Agree to pursue improvement through evolutionary change

Encourage acts of leadership at every level

What We Know About Duration: Individual Activities

So What Do We Know About Task Durations?

General Health Indicators

Metrics Which Drive Improvements?

Classifying Your Metrics

What About Metrics That Aren’t in Any Of The Categories?

Footer