Foundations

Fitness For Purpose Score and Net Fitness Score

January 11, 2016 by David Anderson

Regular followers of my work will know that I have expressed dissatisfaction with Net Promoter Score (NPS). Steve Denning in his book Radical Management suggested NPS was “the only metric you’ll ever need.” Steve is a writer for Forbes, an investment magazine. High NPS scores correlate with high stock prices and hence from an investor’s point of view NPS is an important metric. If you are a CEO of a public company, who receives a large portion of your salary as bonuses based on changes in the stock price then NPS is an important metric. However, many of my clients who collect NPS data report to me that it isn’t an actionable metric. NPS merely tells you whether you are winning or losing. It doesn’t tell you what to do!

There are some antidotes to NPS’ failings. The second question asking reviewers to “tell us why you gave the rating in the previous question?” provides the opportunity for short narratives. These micro-narratives can be clustered using a tool such as Sensemaker and useful information can be extracted. There may be actionable information hidden in the clustering of narratives. This advanced use of NPS information is very much still in its infancy and not readily available to many or most businesses.

I’ve decided to introduce a new metric into our own surveys. I call this Fitness For Purpose Score. I am hopeful this will become a key strategic planning tool in Enterprise Services Planning.

Fitness For Purpose Score

It is often true that businesses do not know the purpose with which a customer consumes their product or service. A product or service designed for a specific purpose may get used for something else. Some of the more famous examples, are washing machines used to make lassi yoghurt drinks for Indian restaurants. In evolutionary science this is known as an exaptation: where something designed for one purpose is adapted for use with another purpose. To have actionable metrics for product or service delivery improvement, you need to understand the customer’s purpose for consuming your offering. When you understand this purpose, you can create the appropriate fitness criteria metrics. With Enterprise Services Planning (and Kanban) we use fitness criteria metrics to drive improvements. Fitness criteria metrics are used at all levels to compare capability with expectations. Fitness for Purpose Score is intended to help us understand purpose and whether or not our current capability meets expectations. If it doesn’t we can probe for thresholds to establish new fitness criteria metrics.

This is how our sales and marketing team will be using Fitness For Purpose Score in our own surveys in 2016.

Question 1: What was your purpose [in attending our training class? What did you hope to learn, take away, or do differently after the class?]

Question 2: Please indicate how “fit for purpose” you found [this class]?

Extremely – I got everything I needed and more
Highly – I got everything I needed
Mostly – I got most of what I needed but some of my needs were not met
Partially – some of my purpose was met but significant & important elements were missing
Slightly – I took some value from it but most of what I was looking for was missing
Not at all – I got nothing useful

Question 3: Please state specifically why you gave your rating for question 2

Questions 1 and 3 specifically ask for short narrative answers. These micro-narratives can be clustered. Question 1 will provide clusters of purpose which can be validated against our existing market segmentation and may reveal new segments, while question 3 will provide clusters of actionable information for improvements and possibly new fitness criteria metrics or threshold value for existing metrics. We can decide whether or not to pursue specific clusters and whether we are likely to be able to achieve adequate fitness levels to satisfy our customers during our Strategy Review meeting.

For example, our own product is management training, though we also have an event planning and publishing business. We position and sell our intellectual property as management training and we deliver it as training classes and mentoring. We know that a significant segment exists for software process improvement and for process engineers and coaches who consume our products and services in order to help them in their coaching practice. We know this segment exists but we specifically and intentionally don’t cater to it. We feel it would be a strategic distraction and undermine our overall message that managers need to be accountable, to take responsibility, to make better decisions and to take action where and when necessary to improve service delivery. The return-on-investment in our products and services is realized when existing managers change their behavior as a result of our training. And hence, while we appreciate the patronage of process engineers and coaches, we do not specifically cater for their needs.

Net Fitness Score

I purposefully moved away from the NPS use of an eleven point numerical scale [0 thru 10]. My background in human factors, psychology and user experience design, taught me that humans have problems with categorization beyond 6 categories without a specific taxonomy to guide them. This isn’t a result of Miller’s “Magic Number 7” rather the work of Bousfield W.A. & A.K, and Cohen, B.H. between 1952 and 1966 on clustering. For example, if you ask humans to rate something 1 to 10 they will struggle to create 10 distinct categories in their mind. When asked to devise their own taxonomy, or clusters, as lay people to the domain, they will tend to create no more than 6 categories. Hence, a scale of 0 through 5 is most appropriate for general consumption. I believe the NPS people tried this but discovered that in some cultures, such as Finland, people never give the top score on principle. They always choose one below the best. Hence, the NPS reaction to this was to double the scale using 0 through 10 so that people could give a 9 when they are really giving a 4.5. My feeling on this is that it highlights the issues with numerical scales and undeclared taxonomies. The solution of doubling the scale, however, creates a randomness in the system and generates noise in the data reducing the signal strength, because of the general human issue of modeling categories against the scale. Fixing one problem, the cultural propensity never to give top ranking, creates another problem, a cognitive issue in the general population to struggle with more than 6 undeclared categories. Hence, to avoid both problems, I am declaring the categories with narrative.

Scores of 4 and 5 are intended to indicate that someone is satisfied and the product or service was fit for their purpose.

Score of 3 is intended to indicate a neutral person. They didn’t get everything they needed to be delighted with the service but they got something acceptable for their investment in time and money.

Scores of 2 or below are intended to show dissatisfied customers who felt their purpose was unfulfilled by the product or service. This may be because the product is poor or it may be because the purpose was previously unknown or represents a segment that the business has strategically decided to ignore. Not all dissatisfied customers need to be serviced fully and satisfied: some customers, you simply don’t want – they represents segments you aren’t interested in pursuing.

Net Fitness Score [NFS] = % satisfied customers – % dissatisfied customers

NFS can be improved through better marketing communications that direct the right audience to your business and dissuade the wrong audience. So NFS can be used to drive excellence in marketing as well as used to explore new segments and the fitness criteria metrics that light them up as viable and profitable businesses.

Proto-Replenishment Semi-Push System

January 7, 2016 by David Anderson

There is a class of replenishment meeting which I believe we need to call out and name separately. In these replenishment meetings the backlog is already committed and often already prioritized. I am proposing we label these proto-replenishment meetings. This post explains why and asks whether the name proto-replenishment is appropriate or not…

Emerging Roles in Kanban – SDM and SRM

January 6, 2016 by David Anderson

Kanban has always been the “start with what you do now” method, and no one gets a “new role, responsibilities, or job titles” at least not initially. However, it is now clear that some roles are emerging in the field with some implementations. So, it is valuable to report this, while they remain suggestions, options, or ideas, rather than prescribed roles for a Kanban implementation. This post follows my previous one that Kanban doesn’t share Agile’s cross-functional team reogranization agenda, and has always been a cross team, cross function solution for service delivery workflows. What follows is in the context of a service delivery workflow which spans functions or teams and is (most likely) orthogonal to the organizational structure of the enterprise, business or product unit.

Service Delivery Manager

From the early days of Kanban, we talked about the need for a manager to take on responsibility for flow of work. Perhaps, echoing the concept of scrummaster, in some implementations the role of person responsible for flow has been nicknamed flow manager or sometimes “flowmaster”. It’s a sticky, if arcane and tribal, title. For our official literature, I wanted something more corporate friendly, and something that is more outwardly facing. “Flow manager” is inwardly facing and focused on process problems. I prefer names that are outwardly focused and address customer needs. This is in line with the Kanban value of “Customer Focus.”

There is precedent for renaming concepts in Kanban to give them more customer focus. Inspired by the Improvement Kata in Toyota Kata, we defined and named, the System Capability Review meeting in 2012. This was later renamed to Service Delivery Review (SDR). The name change was to give the meeting an outward focus on customer needs, rather than an inward focus on process performance. By keeping the naming, the language, and the values, externally focused, we insure that the right metrics are used to drive relevant, valuable improvements. An outward focus is vital to insure “fitness for purpose” and to deliver on the Kanban agenda of survivability.

So, the “flow manager” concept is called the Service Delivery Manager. It is primarily intended to be a role played by an existing member of staff and not a new job title or position. So, by creating Service Delivery Manager, we do weaken the message that no one gets new responsibilities – actually someone does, the someone who takes on the SDM role.

The SDM role existed in 2007 in our first full scale Kanban Method implementation. It was usually played by a project manager from the PMO. The SDM carried responsibility for the Replenishment Meeting, the Delivery Planning Meeting, escalating blocker tickets, and what we would now call Risk Review. Replenishment, Delivery Planning and Risk Review are 3 of the Kanban Cadences.

In more recent implementations the SDM also facilitates the daily Kanban Meeting. In 2007, this role was taken by one of the function managers in the workflow. The SDM role was usually played by someone from the PMO.

Service Request Manager

For some number of years, the question has existed, what do you do with middle-men in the workflow? As a general rule, we wish to remove non-value-adding middle-men positions from the workflow. However, we also wish to avoid resistance to change. These are two core tenets of Kanban coaching and general goals we might have for change management when deploying Kanban in an organization. And the following guidance has existed since 2009: we seek to elevate the role of the middle-man, above the workflow, out of the value stream. The most common example of this is shown in the diagram, “What do you do with the Product Owners?”

The goal is to reposition the role of product owner as a risk manager and facilitator: someone who owns the policies for the system which frame decisions together with facilitating the decision making mechanism. This role is of higher value, is transparent and open to scrutiny and relieves us of the risk of the “hero product owner” who magically understand where the best business value is to be found. This elevated risk management and policy owning position improves corporate governance, improves consistency of process, and reduces personnel risk associated with a single individual.

Nevertheless, an individual with a “hero product owner” self-image will resist such a change. Kanban Coaching Professionals are trained to manage this resistance as part of their training in the Kanban Coaching Masterclass.

When the product owner is successfully repositioned above the workflow as the owner of the policies for risk assessment, scheduling, sequencing and selection, they have successfully transitioned into the Service Request Manager (SRM) role.

Again, we are weakening the “no one gets new responsibilities” principle, but this transition is generally managed over a period of time and isn’t necessarily thrust upon individuals at the start of Kanban adoption.

When the SRM role exists, the SRM usually takes responsibility for the Replenishment Meeting and will play a role in the Strategy Review and Risk Review.

When Do We Need SDM & SRM Roles With Kanban?

January 6, 2016 by David Anderson

With the emergence of the SDM & SRM roles with Kanban, we need to ask the questions, when do we need these roles? When do we need both? And are they merely roles an existing member of staff takes on as new responsibilities, or might they be new positions for which we need to hire? This post provides guidance based on what we’ve seen in the field so far.

rolesandservicedeliveryworkflow

When do we need a Service Delivery Manager?

I genuinely believe you always need a service delivery manager. This role has existed since the first Kanban at Microsoft in 2005. In the early days the SDM role was always played by a project manager. So it isn’t a new position but a refinement of existing responsibilities for an existing member of the staff. The SDM is therefore a role played by someone external to the value stream or workflow.

In the upper diagram, a service delivery workflow is shown spanning a functionally silo’d organization. The SDM facilitates the Replenishment Meeting receiving customer requests and facilitating a collaborative decision making process to select, sequence and schedule work to flow through to delivery. The SDM will collaborate with the functional manager or team leads and play a reasonably active part in the day-to-day operation of the kanban system, definitely attending and perhaps facilitating the Kanban Meeting.

It’s been reported to me that in some organizations, the concept of a service delivery workflow is very weak, while the functional silos and structure are very strong. Usually, such companies lack any significant focus on customer satisfaction or any service-orientation in their thinking, mindset or value system. I’ve specifically had this reported to me from a large Swedish industrial company and several companies in China in the technology or finance sectors. In these instances, the change agents, usually process coaches or members of the PMO, felt it was necessary to create the Service Delivery Manager role as a specific position within the firm. The act of doing so, is actually making a very clear commitment to service delivery and customer satisfaction. In other words, the bar for the change initiative is raised – senior leaders are being asked to acknowledge that service delivery and customer satisfaction are important. They are being asked to explicitly put customer focus in the spotlight and make it part of the corporate value system. This is a non-trivial but hugely important step.

So where there is a current lack of customer focus and a lack of understanding of existing service delivery workflows, where the concept is weak, you need to create a position for SDMs.

When do we need a Service Request Manager?

A Service Request Manager is likely to be needed when contact with the customers, or service requestors is weak or distant. The SRM becomes a proxy or advocate for the customers. However, it is important that we don’t place the SRM in a decision making role. We don’t want them becoming a dysfunctional proxy for the customer, showing bias towards one over the others. We always want the SRM as the facilitator of selection not the person doing the selection. In organizations, where contact with the customers is weak, there is often already an intermediary possibly a sales engineer, an account manager, a product manager or in Agile adopting organizations a product owner. So we want to elevate that person’s role into the role of SRM. It is a set of new responsibilities, not a new position.

When the SRM role exists, the SRM will take on the responsibility for the Replenishment Meeting and will play roles in the Strategy Review and Risk Review.

When might we need SRM as a new position? If the SDM is the “flow manager” for service delivery, then the SRM is the “flow manager” for ideation or discovery. So we might expect to see SRM emerge as a specific role when we have an upstream or discovery kanban system. The more focus we have on ideation, option validation and discard, and discovery and validation of concepts (or minimum viable products, MVPs) the more likely we are to need a SRM as a specific position in our organization.

discoverydeliverywithroles

The SRM role is described as “marshalling options”. This is the act of facilitating flow, and discard or upstream kanban work.

When might we need both roles?

In discussing this amongst my colleagues and with leaders in the Kanban community, Mike Burrows commented, “I have seen the need for one or the other but never both.” And that is probably a fair statement, we have seen firms adopting SDM or SRM roles but so far we haven’t seen both, at least not explicitly. With larger scale ESP implementations, we do see a lot of SRMs. One client advertised for SRMs by placing job advertisements for Product Owners. This makes sense. You recruit for a title that people are familiar with, then you mold them into what you need. That client has a strong sense of service delivery and without doubt function managers or team leads are playing the role of SDM. It just hasn’t been made explicit in that company.

So I suspect that as we see greater emphasis on the use of Kanban upstream and the growth of Enterprise Services Planning, with business emerging where ESP/Kanban is _the_ way that they manage their professional services company then we will see strong growth and use of both SRM and SDM roles.

At smaller scale and where there is little ideation, option development and discard, and a strong connection to the customer together with a strong sense of service delivery, in these cases, I expect only one role, SDM, played by an existing member of the staff. So Kanban as we knew it in 2005-2008 doesn’t involve new positions or additional headcount, but the future with Enterprise Services Planning, particularly in organizations with a weak sense of service delivery and a lack of customer focus, we are likely to see the new job title of Service Delivery Manager emerge. In companies that do a lot of innovation and act as a market leader in an uncertain and emerging market, we are likely to see the emergence of Service Request Manager as a new position. Where both circumstances exist, we’ll see both roles in use, perhaps both as new positions and additional headcount.

The Meaning of Kanban From the Inside

March 11, 2015 by David Anderson

Kanban from the inside! What does that mean?

Perhaps it’s about practicing Kanban and it is written by a practitioner? And that would be true!

Perhaps it’s about understanding Kanban and its community of followers from a community insider? And that would be true too!

Or perhaps it is about something deeper, something truly “from the inside”, from inside the author? Kanban from the heart? Kanban from the soul? Kanban expressed by a deeply spiritual person with a strong sense of self and a deeply held set of values?

Mike Burrows was an early adopter of Kanban and an early member of our online community. It helped him do his job. It helped his organization get work done, manage risk better and improve their performance. It was a solid and effective management technique. It was a useful professional tool for a middle manager with operational responsibilities.

In 2010, Mike Burrows attended the Kanban coaching masterclass and like others before him and who’ve come since he described it as “life changing.” He left with the ephinany that the Kanban guidance he’d been following was rooted in a set of values – values that I wasn’t communicating explicitly. They were values that resonated with someone who quietly follows his religious beliefs. In many ways a private person, Kanban had touched him in a way he didn’t expect.

Since then Mike has dedicated his professional career to the development of Kanban and significantly to makinge its underlying values explicit. Mike has helped to expand the “Why” of Kanban. He’s helped to humanize it and to explain how it represents “change that is humane.” He’s become a highly respected leader in our community. I’m proud to know him and proud to call him a colleague. It gives me great pleasure that we could publish his book, Kanban from the Inside. I know how much it all means to him.

Kanban from the Inside will help you understand why you should care about Kanban and how Kanban and its community care about you. It is also packed with much of the latest guidance, teaching tools, explanations and experience that otherwise you can only access through training classes.

Yes, Kanban is a useful management method for delivering creative and knowledge work services. Yes, Kanban is an effective way to drive improvement in an evolutionary way. Yes, the techniques in this book will help improve the operational performance of your business. Kanban is all of those things and Mike shows you how to make it happen. But let Mike take you further. Discover the soul of Kanban. Discover what is inside! Get Kanban from the Inside! It’s a great read and well worth your investment. Discover a new deeper way to connect with the concepts in the Kanban Method.

Principles and General Practices of the Kanban Method

September 5, 2014 by Kanban University

As time goes by, I learn a lot about articulating my ideas. I’ve recently updated how I communicate the core principles of the Kanban Method.

The Kanban Method defines my approach to incremental, evolutionary change for technology development/operations organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to improve the system. One example of such a pull system is a kanban system, and it is after this popular form of WIP limited pull system that the method is named.

In my book, Kanban – Successful Evolutionary Change for your Technology Business, I identified what I called the “5 core properties” that I’d observed to be present in each successful implementation of Kanban.

Since the book was published we’ve expanded this list and they are now known as the Principles and General Practices of Kanban.

Principles of the Kanban Method …

Start with what you do now
Agree to pursue incremental, evolutionary change
Respect the current process, roles, responsibilities & titles

Encourage acts of leadership at all levels in your organization

General Practices of the Kanban Method …

1. Visualize (the work, workflow and business risks)
2. Limit WIP
3. Manage Flow
4. Make Process Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

Let’s examine these elements one-by-one

Start with what you do now
The Kanban Method does not ask you to change your process. It is based on the concept that you evolve your current process. There is no sweeping, engineered change to a new process definition or style of working. There is no such thing as the Kanban Software Development Process or the Kanban Project Management Method.

Agree to pursue incremental, evolutionary change
The organization (or team) must agree that their current circumstances warrant a gentle, evolutionary approach to improvement. Perhaps a sweeping engineered change has recently failed due to resistance from team members, or perhaps the politics of the organization make it too risky for managers to propose and implement sweeping changes? Without agreement that a slow, gentle, evolutionary, incremental approach is the right way forward then there won’t be the right environment or management support for a Kanban initiative.

Respect the current process, roles, responsibilities and job titles
It is likely that, what the organization currently does, has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.

Encourage acts of leadership at all levels in your organization
Without leadership to catalyze change things will not improve. Information about where improvements are possible can appear at any level in an organization and most often at the individual contributor level. If changes are to be made quickly and effectively individuals who believe improvement is possible must feel empowered to enact it. A culture of safety, must exist, to take action without fear of retribution providing changes can be defended based on logical explanation using models and data.

Visualize (the work, the workflow, and the business risks)
As a general rule, seek to make that which is invisible, visible. Once invisible work, workflows, and business risks can be seen, it is possible to manage them better and to do so collaboratively and with consensus. Understand how to define and capture requests for work. Visualize each request with a card on a kanban board. Visualize the sequence of knowledge discovery activities performed from when the request is first received until it is completed and ready for delivery to the customer. We call this sequence of knowledge discovery activities, the workflow. Capture significant business risks associated with a piece of work such as cost of delay, importance of the requesting customer, confidence in the definition of the requirements, likelihood of requirements changing or the request being obviated before it is delivered, and visualize those perhaps using color of the tickets, or decorators on the ticket such as shapes, tags or icons.

Limit WIP
Limiting WIP implies that we implement a pull system on part or all of the workflow. The pull system can be a kanban system, a CONWIP system, a DBR system, or some other variant. Specifically with Kanban we are typically using a kanban system, though other pull systems do appear in some real world examples. The choice of pull system isn’t important, the critical elements are that work-in-progress at each state in the workflow is limited and that new work in “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.

Manage Flow
The flow of work items through each state in the workflow should be monitored and reported – often referred to as Measuring Flow. By flow we mean movement. We are interested in the speed of movement and the smoothness of that movement. Ideally we want fast smooth flow. Fast smooth flow means our system is both creating value quickly, which is minimizing risk and avoiding (opportunity) cost of delay, and is also doing so in a predictable fashion.

Make Policies Explicit
Until the rules for how we perform a creative knowledge work activity such as software development or IT services, are made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.

Implement Feedback Loops
An evolutionary process cannot work without feedback loops. When implemented at a service delivery level in organizations, Kanban, uses four specific practices for feedback: the standup meeting; the service delivery review; the operations review; and the risk review. The purpose of feedback loops is to be able to compare expected outcomes with actual outcomes and make adjustments. Specifically, we want to make process and policy adjustments as a result of the feedback and understanding the current outcomes in comparison with our expectations or desires.

Improve Collaboratively, Evolve Experimentally (using models/scientific method)
It is the WIP limit that ultimately stimulates conversations about process problems. Things which impede flow, or introduce perturbations that mean flow is inconsistent or ragged, often result in a challenge to the WIP limit. The team has the option to break the limit, ignore the problem and carry on, or to face up to the issue, discuss it and suggest a change.

When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus. In my book, I suggested three models which are useful: The Theory of Constraints (the study of bottlenecks); The Theory of Profound Knowledge (a study of variation and how it affects processes); and the Lean Economic Model (based on the concepts of “waste” (or muda, muri and mura)). Other models are possible such as Real Option Theory.

The use of models allows a team to make a prediction about the affect of a change (or intervention). After the change is implemented the outcome can be observed by measuring the flow and examining the data. The outcome can be compared to the prediction expected from the model and the change can be assessed as an improvement, or not. This process of evaluating an empirical observation with a model, suggesting an intervention and predicting the outcome based on the model, then observing what really happens and comparing with the prediction, is use of the scientific method in its fundamental sense. This scientific approach, is I believe, more likely to lead to learning at both the individual and organizational level. Hence the use of the scientific approach in Kanban will lead directly to the emergence of learning organizations.

Complex Environments and Adaptive Capability
The Principles and General Practices of the Kanban Method are designed to lay the foundation for an adaptive capability with an organization. Adaptive capability is how organizations cope with and respond to complex environments. Adapative capability is required for resilience in complex environments. The improvements to workflow processes represent emergent behavior. The outcome cannot be predicted far in advance or several steps in advance. The future processes of the organization emerge rather than are designed.