The Value Impact

The impact of value is difficult to quantify, and putting a currency number is not as simple as it is with cost. The challenge is even greater for organisations which are not selling products, such as governments or charities. However, there are a number of approaches which can be used to help understand the value that is being delivered such that we can maximise across the whole system. Some of these I have already covered when I wrote about the science of kanban from an economic point of view, but it is worth including them again.

Customer Delight

Steve Denning suggests that ultimately value is in delighting customers. I agree with this, using a broad definition of customer which is not limited to the end user, but can be anyone with an interest in the outcome. That could include people interested in the user experience, architecture or operational aspects, for example. Having said that, the end user is generally the customer who ultimately determines success.

Value Horizons

In his recent book Escape Velocity, Geoffrey Moore draws heavily on the The Horizons Model developed at McKinsey and published in The Alchemy of Growth. Using this model, Horizon 1 features are intended to have an immediate impact in the current financial year. Horizon 2 features are considered to be investments which are intended to have an impact in the medium term, probably the next financial year. Horizon 3 features are options which have the potential to have an impact in the long term, and not until subsequent financial years. It is very easy to be drawn into focussing on Horizon 1 features due to the anticipated immediate return. However, when that wave peaks and crashes, it is important to be ready for the next wave. Therefore, explicitly spreading the allocation of investment in features across the horizons can mitigate this short term thinking and lead to longer term success.
IMG_0019

Life Cycle Profits

Looking at value over the longer term is a form of considering total life cycle profits. Investing in Horizon 2 and Horizon 3 features is a way of looking at overall life cycle of a product, and of prolonging the profit period.
IMG_0020

Revenue and Expenditure

Another way of looking at value is something I picked up off Chris Matts. He suggests that there are 4 types of value based on revenue and expenditure. The first is in increasing revenue, for example by adding functionality which attract more customers. The second is in protecting revenue, for example by adding functionality which keeps existing customers. The third is in reducing expenditure, for example by adding functionality which improves development efficiencies. Finally, the fourth is in avoiding expenditure, for example by adding functionality which is required to avoid regulatory fines.

Competitive Landscape

The perspective of the competitive landscape is also a way of classifying features, this time as either MVP (Minimal Viable Product), neutralising, differentiating or optimising. MVP features are those which have to be completed to even enter the market. Neutralising features are those which attack a competitors dominance by eliminating any advantage they have with unique capability.  Differentiating features are those which create market dominance by providing new unique capability which the market demands and no competitor can provide. Finally, optimising features are those which don’t add any new capability, but improve the performance if existing functionality in some way. While MVP features are clearly essential, only working on those can be a high risk strategy, and a portfolio of features which includes a mix of all four types can be lower risk.

Cost of Delay

The value of a feature is often dependant on when it is delivered. Using cost of delay as a model can help understand when to schedule features in order to maximise value. Four common patterns are Expedite, Standard, Fixed Date and Intangible. Expedited features are ones where the cost of delay is high and immediate. These items are genuinely urgent and should be scheduled immediately. Standard features are ones where the cost of delay rises linearly. Examples are items with an opportunity cost, where the later the delivery, the more opportunity for gain is lost. Fixed Date features are ones where the cost of delay rises sharply at a specific date. Examples are regulatory dates at which fines may be imposed, or seasonal dates such as Christmas or trade-shows. Delivering these features early creates little or no extra value. Intangible features are ones where the cost of delay is likely to happen in future, but the exact nature is unpredictable. Examples are technical debt or infrastructure work.

Scheduling

Cost of Delay helps with making effective scheduling decisions by prioritising features against each other. Don Reinertsen describes a number of algorithms in his book Principles of Product Development Flow. Principles F15, F16, and F17, can be summarised as follows. When two features have an equivalent cost of delay, schedule the shortest one first. When two features require equivalent time, schedule the one with the highest cost of delay first. When two features require different times and have different costs of delay, then schedule the one with the weighted shortest time first, where the weighting is calculated by dividing the cost of delay by the time. Dean Leffingwell has a great blog post about prioritising features describing this in more detail.

Feature Injection

Having these models is all very well, but how do we know what to actually build? Feature Injection can provide some guidance. With Feature Injection, we start with a vision, decide what goals meet that vision, what capabilities enable those goals, what features deliver those capabilities, what scenarios exemplify those features and finally, what stories make up those scenarios. Thus by starting with the vision, the details can be ‘injected’ just-in-time, incrementing and iterating based on feedback. Liz Keogh describes this well in a recent blog post about BDD in the large.

Experimentation

Feature Injection is designed to deal with the fact that even when we have some idea of the capabilities we want to create, we still have little idea about the precise functionality to build. In these cases experimentation is important. Lean Startup, with its Build, Measure, Learn cycle is a great means of achieving this. It is also a good example of running safe-to-fail probes within the probe-sense-respond approach the Cynefin recommends in the complex domain. I’m also curious about how the software community can apply set-based design ideas such as trade-off curves to better learn and create knowledge about what to build. When running these sorts of experiments, the value is more in the information generated, and the learning experienced, than in any financial return or saving.

And More

There are many more ideas which can be used to help us understand value. These are the ones I use most. For example, I know Tom Gilb has done a lot of thinking on the subject, which I have yet to explore. Eli Goldratt’s work with theory of constraints is another area of potential, which Bob Marshall explored recently in a post asking what is value.

What else is missing? Let me know in the comments.

Linking Flow, Value and Capability

I wrote recently that I have come to think about Flow, Value and Capability as the primary impacts I hope a Kanban System will have. Flow, Value and Capability are not independent entities, however, with Capability being the link between Flow and Value. We can think of Flow as “doing the thing right”, where good flow is the result of a good process. Similarly, we can think of Value as “doing the right thing”, where high value is the result of good outputs from the process. We want both, however, and we can think of Capability as “doing the right thing right”, where a good process delivers good outputs.

Flow Value Capability

Here’s another way of looking at it…

A common scenario is creating projects, and assigning people to those projects to form a project team. This is great for the project in isolation, but when the project finishes the team is usually disbanded, and all the capability that was created as tacit knowledge in the team is lost.

Project Team

A further challenge (amongst many) with this approach is that when another project comes along – and then another – people get assigned to multiple project teams, at which point they’re not really teams any more. This might seem efficient, but it is not effective, and is not good for the people or the work. In the diagram below, the person in the middle on three projects is not in a good place!

Multiple Teams

An alternative idea is to form teams around organisational capabilities – things which will enable the business to make an impact. Small pieces of valuable work which enhance this capability can then be individually pulled by these teams, creating flow. This is what I call a Capability Team.

Capability Team

Pursuing this approach, the notion of the project goes away, replaced by a Flow of Value through Capability teams who are able to “do the right thing right”. These teams can stay together for as long as the capability is important, building knowledge about all aspects of what they are building, and how they build it.

What is Capability?

I recently gave talk at the London Scrum User Group (LSUG) describing Kanban Thinking and had a very interesting conversation about what I mean by the impact on capability. I realised I needed to think it through in a bit more detail, and this is an attempt to articulate it better.

Defining Capability

In his book Rethink: A Business Manifesto for Cutting Costs and Boosting Innovation, Ric Merrifield used the term capability to define the outcomes which drive business performance. One of the dictionary.com definitions is that a capability is a quality, ability or feature which can be used or developed. Additionally, to be capable of something is to be predisposed to, or inclined to, which ties in with the idea that complex systems have disposition. Putting all these together, we can say that a systems capability is its degree of disposition, which can be used and developed, towards create a business outcome.

Doing the Right Thing and Doing the Thing Right

We can think of capability in two ways – that of the business, and that of the people. The business’s capability is its ability to do the right thing, while its people’s capability is their ability to do the thing right. This can be visualised in a 2×2 matrix, where ideally we want to be in the top right quadrant where we are aligning business capability with human capability.

Capability

Developing Capability

When I first described Kanban Thinking, I said that “to build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems”. Capability is more than just how good the flow of value is. It is also how well the flow and value can be sustained and improved over time. Simply swapping in and out different people to an existing process (flow) with existing requirements (value) will not work. Businesses are social and cognitive systems where people have tacit knowledge, and they share and use that tacit knowledge to deliver the work. That is why teams are such as core part of making an agile approach work.

Capability Teams

Feature teams are a great example of how to build capability, collaborating to delivering customer value directly. A more debatable approach, however, is the use of component teams, and the idea of capability can provide guidance on when this may be appropriate.  Where a component or architectural layer provides some direct impact on organisational capability, then it may be worth having its own team. The decision on team structure becomes one of whether the team is a Capability Team. Taking a cue from “Rethink”, a Capability Team as one whose outcomes have a resultant improvement on the business performance, as opposed to one whose activities are needed to achieve a business outcome.

An Example

A financial services organisation had a team dedicated to developing an SOA capability which would be used by a variety customer facing applications to access a common data repository. The ability to effectively manage customer data was a key capability for the organisation, and development of the data repository was a business outcome which enabled a better customer experience by providing cross-application consistency. The same organisation also had a QA team. This is not a capability because on its own it does not deliver a business outcome. Rather, it is an skill or activity required to deliver quality, and which should be built into the work performed by capability teams delivering business outcomes.

Even with the notion of Capability Teams, its not necessarily a simple black or white decision, hence the interesting conversation at LSUG. When unsure about what team structure to go with, I think the more interesting question is “how will I know if the structure is having a positive impact?” As I mentioned at the end of the post on Impact, Outcome and Output, I believe Geoffrey Moore’s hierarchy of powers offers some insights here, which I hope to expand on in a future post.  I’d also be interested in hearing of any other interesting examples of Capability Teams. Please leave a comment if you have one!

Impact, Outcome and Output

As I alluded to in the previous post, one of the changes in thinking, and in particular language, for me recently is the idea of impact. Specifically that impact is different from outcome which is itself different from output. I’ve differentiated outcome from output for some time, as have others, but I believe impact is a further step in understanding how we approach change.

To relate the three ideas to each other, I would say that:

Outputs create outcomes which have impact.

This mapping also ties in nicely to Simon Sinek’s Golden Circle model that I have referenced before.

Outputs (or sometimes activities) are the things that we do in order to achieve something. They provide the details about what gets done, such as specific practices or implementation details. In the Golden Circle, they are the WHAT.

Outcomes are the future state we hope to achieve by completing the outputs. They provide the details about what goals we hope to achieve, such as end results or behaviours. In the Golden Circle, they are the HOW.

Impacts are the tendencies or dispositions of an outcome. They give an indication of whether the future state is a positive or negative one, without limiting the scope of what that future state might be.  In the Golden Circle, they are the WHY.

As Simon Sinek recommends with the Golden Circle, we should always Start with Why, and thus when implementing any process or product it is useful to know what impact we want to have. I have realised that the notions of Flow, Value and Capability that I refer to as part of Kanban Thinking are actually the primary impacts that I hope that a Kanban System will achieve.

  • A positive impact on flow might be one which results in earlier and smoother delivery and might be seen in a reduction in lead time or variability.
  • A positive impact in value might be one which results in a better return on investment or improved margins and might be seen in improved economic outcomes
  • A positive impact in capability might be one which results in better business performance and might be seen in improved quality, throughput, or customer and employee satisfaction.

Another recent and related influence has been Geoffrey Moore’s Escape Velocity, where he talks about a hierarchy of powers.

  • Category Power relates to the relative demand for a class of product.
  • Company Power relates to the organisation’s relative position within a category.
  • Market Power relates to the relative company power within a specific market segment.
  • Offer Power relates to the relative demand for a specific product.
  • Execution Power relates to the relative ability to outperform competition.

This has got me thinking about how impact might be the effect a change has on one or more of these powers. While flow is more aligned with execution power, value and capability are aligned to the other powers.