Lean & Kanban Southern Europe 2012 is the 1st conference of its kind in the region, being held in Madrid, May 9-10. Speakers include many who also be at LSSC12, along with local practitioners talking about their experiences and learnings such as Brickell Key nominees Erika Weiss & Oscar Garrido. There will also be a track full of Spanish language content on Day 2. I don’t speak Spanish, but I highly recommend it!

David Anderson has written a couple of good blog posts if you want more info – there’s still time to register!

• Thoughts on LSSC12
• Lean Camp New England May 13

I have a session on Wednesday May 16, 4:20pm – 5:00pm @ Harborview 2 with my Rallt colleague Larry Maccherone where we’ll be introducing some of the great work Larry has been doing with metrics and data visualisations.

I hope I’ll see you there – let the Boston Lean Party begin! This is what I expect I’ll be doing the rest of the time.

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.

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!

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.

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.

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.

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!

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.

1. Evolutionary Potential. Even though I’m a fan of Systems Thinking, I’ve realised that in complex situations, defining a future state and closing the gap isn’t the right approach. I still find system archetypes such as Tragedy of the Commons useful, but more in understanding the current situation than defining a future one. Instead I prefer to explore the evolutionary potential. There may be many different answers, some of which are not yet know, so experimenting, in a safe to fail way, helps evolve to the potential. An interesting case of this is exaptation, where a function is used for a purpose it was not originally adapted or selected for. My most recent aha related to evolutionary potential was that even though complex systems aren’t controllable, they are dispositional. In other words, while we still might not be able to know what the outcome of a change will be (let alone the output or activity to get there), but we can determine whether a change has a positive or negative impact on the overall system.

2 Sense-making. Cynefin is primarily a sense-making framework. This means that the data precedes the framework, as opposed to a categorisation framework where the framework precedes the data. Thus, rather than trying to figure out where an example should go in a matrix, examples are positioned relative to each other based on some criteria, and then boundaries are drawn subsequently. This makes sense-making much more dynamic, and what becomes interesting is not the classification of whether something is complex or complicated, but how things transition across the boundaries. No domain is better than any other as each is contextual. Moving from complex to complicated may be appropriate when optimising or exploiting. Equally, moving from complicated to complex (via a shallow dive into chaos) may be appropriate when wanting to innovate or explore. Further, any scenario is often in multiple places at the same time (after all Cynefin translates from Welsh into “place of our multiple affiliations”). Elements may be simple, complicated and complex, and narrative becomes an useful tool for understanding the differences.

3. Narrative. One of the main benefits of Kanban Systems that attracted me was the power of the contextual approach. A Kanban System is something that is overlaid on top of an existing approach to better understand and improve it and narratives are a great way of discovering, exploring and understanding aspects of a context. Collecting a set of anecdotes about best and worst experiences in a context creates a form of knowledge against which to pattern match for similarity of new situations, leading to better insights and decisions as to how to manage those situations.

Putting those three ahas together, I can imagine applying them through working with organisations to collect a range of narratives, help make sense of them by contextualising them with Cynefin, and then facilitate the creation of appropriate actions to make an impact on the business. Those actions might be safe to fail experiments, based on lean and agile principles, to explore the evolutionary potential for complex problems, or a more direct application of lean and agile practices for complicated problems. Or more likely a hybrid of both!

SPaMCAST 174 – Karl Scotland, Kanban Thinking

Scientific Management Revisited

Is scientific management still relevant for product development then? As I have already said, I believe it is, with the following clarifications. I am making a distinction between scientific management and Taylorism. Whereas scientific management is the general application of scientific approach to improving processes, Taylorism was his specific application to the manufacturing domain. Further, in more complex domains such as software and systems development, a key difference in application is that the workers, rather than the managers, should be the scientists, being closer to the details of the work.

Run Experiments

The used of a scientific approach in a complex domain requires running lots of experiments. The most well-known version is PDCA (“Plan, Do, Check, Act”) popularised by Deming and originally described by Shewhart. Another variation is “Check, Plan, Do”, promoted by John Seddon as more applicable to knowledge work because an understanding of the current situation is a better starting point, and Act is redundant because experiments are not run in isolation. John Boyd’s OODA loop takes the idea further by focussing even more on the present, and less on the past. Finally, Dave Snowden suggests “Safe To Fail” experiments as ways of probing a complex situation to understand how to evolve.

Whichever form of experiment is run, it is important to be able to measure the results, or impact, in order to know whether to continue and amplify the changes, or cease and dampen them. The key to a successful experiment is whether it completes and provides learning, not whether the results are the ones that were anticipated.

Start with Why

Knowing whether the results of an experiment are desirable means knowing what the desired impact, or outcome might be. One model to understand this is the Golden Circle, by Simon Sinek. The Golden Circle suggests starting with WHY you want to do something, then understanding HOW to go about achieving, and then deciding WHAT to do.

Axes of Improvement

One set of generalisations about WHY to implement Kanban, which can inform experiments and provide a basis for scientific management is the following:

• Productivity – how much value for money is being generated
• Predictability – how reliable are forecasts
• Responsiveness – how quickly can requests be delivered
• Quality – how good is the work
• Customer Satisfaction – how happy are customers
• Employee Satisfaction – how happy are employees

The common theme across these measures is that they relate to outcome or impact, rather than output or activity. Science helps inform how we might influence these measures, and what levers we might adjust in order to do so.

Lean

In these posts I have described Kanban in terms of the sciences of people, process and economics. However, this can actually be generalised to describe Lean as applied to knowledge work, as opposed to the traditional definition of Toyata’s manufacturing principles. The differentiation is also a close match back to my original Kanban, Flow and Cadence triad.

• Kanban maps to process, with the emphasis on eliminating delays and creating flow rather than eliminating waste.
• Flow maps to economics, with the emphasis on maximising customer value rather than reducing cost.
• Cadence loosely maps people and their capability, with the emphasis on investing in those who use the tools rather than the tools themselves.

References

The ideas in this article have been inspired by the following references:

• Kanban, David J. Anderson
• The Principles of Product Development Flow, Donald G. Reinertsen
• Brain Rules, John Medina
• Software by Numbers, Mark Denne & Jane Cleland-Huang
• Cynefin

Having a good understanding of how creative people can have an efficient process still isn’t enough however. As Russell Ackoff is often quoted as saying, “It’s better to do the right thing wrong, than the wrong thing right”. An understanding of economics is needed to avoid “doing the wrong thing right”, by focussing on the “right thing”, whether that involves financial return, risk management or information discovery, all of which are of value. One financial model that I picked up from Chris Matts is that features should increase future revenue, protect existing revenue, reduce existing costs, or avoid future costs.

Life Cycle Profits

A basic understanding of investment over time helps explain why smaller batches and smaller increments are preferable from an economic perspective. In Software by Numbers, Denne and Cleland-Huang show the investment, payback and profit periods. A smaller cash injection, over a shorter investment period, can enable a product to become self-funding and break-even sooner, such that the profit can be invested back into the product for continued development.

Cost of Delay

The Cost of Delay concept, as popularised by David Anderson, further informs scheduling decisions based on cost over time. The four most common archetypes used (but limited to) are:

• Expedite – the cost of delay is high and immediate. These items are genuinely urgent and should be prioritised above everything else.
• Standard – 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 – 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.
• Intangible – the cost of delay is likely to happen in future, but the exact nature is unpredictable. Examples are technical debt or infrastructure work

Information Theory

Value does not have to be purely financial. In particular there is often value in information generated, as suggested by information theory.

Information Theory says that for experiments with pass/fail results, a 50% failure rate is optimal. Always failing suggests that nothing is known, and subsequently nothing is being learned. Always succeeding suggests that everything is already known, and thus nothing is being learned.

The Lean Startup approach is essentially based on information theory, with the goal being to loop through the Build, Measure and Learn cycle as quickly as possible.

This can be thought of as buying information, and asymmetric payoff curves help explain the benefits of this approach. Given some notional performance target, an asymmetric payoff curve is one where being below target results in a loss, being above target results in a gain, and hitting the target results in breaking even. Buying information enables the shape of the curve to be changed such that losses below target are minimised, and gains above target are maximised.

Scheduling

Having a good understanding of the economics enables better decision making when designing and scheduling the work. Usually selection of what work should be pulled next relates to cost and value. Higher value for lower cost generally trumps lower value for highest cost.

An example is risk reduction. There is value in risk reduction, where the higher the risk, the greater the value there is in reducing it, and there is also a cost associated with reducing the risk. Having an understanding of the relative values and costs of risk reduction activities informs the sequencing of high value, low cost items earlier and low value, high cost items later.

Similarly Set Based Concurrent Engineering can be informed by economics. SBCE involves working on multiple parallel initiatives in order to reduce risk. Multiple initiatives should only be run while the total cost of the initiatives is less than the value of the risk reduction. Each additional initiative adds less value exponentially, while the total cost rises linearly. Multiple experiments are like buying insurance; when the cost of the insurance is greater than the economic benefit, it’s not worth paying for.

In the final part, I’ll draw together some conclusions.