Abstracting Aspirations with a Value Framework

The end of a rainbow disappearing behind some trees, representing the aspirations which guide towards realising value.

In previous posts, I have described a high-level way of thinking about Agile Tactics for the TASTE model and the X-Matrix. This post follows them by introducing a generic way of thinking about Aspirations.

What are Aspirations?

On the X-Matrix template, I describe Aspirations as the “results we hope to achieve”. Aspirations are just hopes and desires, and that is an important point. They describe ambitions and the size of those ambitions. As such, aspirations are intended to help provide a sense of the magnitude and scale of the journey, along with the direction set by the True North. I sometimes ask the question, “at the end of the year (or another period), how will we know if we have been successful?” The goal is to be able to recognise progress and achievement. That may be subjective, and not have any specific numbers. Equally, it may be defined in relative terms rather than absolute numbers.

I have already discussed some considerations regarding measures with the X-Matrix to avoid the “tyranny of the explicit” and a “cliché of platitudes”. Additionally, we want to avoid Goodhart’s Law, often stated as “when a measure becomes a target, it ceases to be a good measure”. Thus, aspirations are not targets or specific goals and are not there to incentivise or reward people. Instead, they should help people recognise and focus on what is important.

A Value Framework

With those caveats dealt with, how can we identify aspirations? Typical examples I give tend to be around the nature of a specific business and its business model. For example, that might relate to markets, customers, products, or subscriptions. However, in general, I find that the aspirations can be tied back to a value framework described by Joshua Arnold. I’d recommend reading his post on understanding value which describes the framework in more detail.

In summary, there are four buckets:

  • Increase Revenue – Additional sales to new or existing customers, by delighting or disrupting to increase market share and size.
  • Protect Revenue – Improvements and incremental innovations, to sustain current market share and size.
  • Reduce Costs – Becoming more efficient with improved margins or contribution, to lower costs that are currently being incurred.
  • Avoid Costs – Improvements which sustain and do not increase the current cost base, or prevent costs that are not currently incurred but may be in the future.

Value Buckets as Aspirations

I think that this can be a useful framework to help organisations think through what their aspirations are for their agile transformations. It helps clarify what they hope to achieve through a transformation. For example, it could be that they want to be able to go after new customer segments or markets. i.e. Increase Revenue. Or they may want to improve quality and reduce customer churn. i.e. Protect Revenue. They may want to improve internal processes through automation. i,e. Reduce Costs. Or they may want to increase employee engagement and reduce employee churn. i,e. Avoid Costs.

Thus, the value framework can help articulate what success might look like, in terms of direction and magnitude. As a result, the challenges or opportunities that need to be addressed in order to meet the aspirations can start to be diagnosed and identified. That in turn allows coherent strategies for agile transformations to be explored. I plan to write about this more in a future post.

A crude metaphor might be that Aspirations, and this value framework, can be a guide towards the pot of gold at the end of the rainbow, and help determine when it has been found. However, the Aspirations don’t indicate exactly where that pot of gold is, or guarantee how much will be in it.

The Best Agile Accounting Approach To CapEx and OpEx

Agile Accounting

What is the best way of accounting for costs as different types of expenditure with agile development teams? This is a question that comes up every now and again, particularly during more significant transformations. I usually respond by explaining that I’m not an accountant. It’s also not a topic I particularly care about.

However, I heard Johanna Rothman make a comment which struck me during the recent Drunk Agile Holiday Special. At least I’m pretty sure it was Johanna! I now understand why I don’t care and can give a much better answer.

Value and Cost

Before I get to that though, it’s worth reiterating one of the underlying principles behind agile software development. That is a focus on value.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile Manifesto Principle #1

I often say at some point towards the beginning of a new transformation that increasing value is infinite while reducing cost is zero-bounded. This comes up when I get a sense that an organisation views Agile as a means to reduce costs. After all, it’s associated with being more Lean, isn’t it?

I explain that an agile approach might actually cost a little bit more. However, that should be a relatively small increase in cost compared to the potentially significant increase in value. In other words, it’s better to focus on being more effective than more efficient. Or to paraphrase Russell Ackoff, it’s better to focus on doing the right thing, rather than doing the thing right.

Revenue and Tax

Let’s go back to how to allocate costs to different types of expenditure for agile development teams. The usual reason for this is to minimise tax liabilities. After all, minimising tax will increase profit. As a result, organisations try to design their processes and practices to make it simpler to minimise tax. That’s fairly easy in a traditional, large batch, stage-gate process. Different stages can count as different expenditures. The challenge is that it’s not so easy with agile teams who focus more on collaboration and flow.

What Johanna said is that it’s better to focus on increasing revenue, than reducing tax. Just like value and cost, increasing revenue is infinite while reducing tax is zero-bounded. Thus increasing revenue is the thing which should drive decisions on ways of working, and not minimising tax.

In other words, don’t worry about it. That’s the best agile accounting approach to CapEx and OpEx. Instead, your real strategy and how you are going to deploy that strategy is what is going to have the maximum impact.

Making an Impact with Kanban Thinking

This post pulls together a number of ideas  on impact into a single place, and will become the content for a page in Impact on the Kanban Thinking site.

What is Impact

Outputs creates Outcomes which have Impact.

Designing a Kanban System involves the evolution and discovery of a good design. It cannot be pre-determined in advance. Thus instead of defining a future-state and working towards it, we start with the current-state and work away from it, exploring and assessing different alternatives. Each output of a design iteration will create different outcomes, and those that improve the system can be said to have a positive impact, while those that worsen the system have a negative impact.

Impact, therefore, describes the disposition of the system, or its tendency to behave in a certain way. Rather than defining a planned destination, impact points to the desired direction, such that we can check whether any changes are moving us towards or away from the direction we want to be heading. Impact can be assessed by using narrative techniques to capture stories about utopian (and dystopian) futures, and subsequently asking whether an outcome is likely to lead to more of the positive stories and fewer of the negative stories.

Describing Impacts

When imagining what impacts would be desirable, its easy for our experiences and biases to lead us to narrow our thinking and prematurely converge on only one particular type of impact. To avoid this, and encourage diversity in exploring a wide variety of potential impacts, Kanban Thinking describes three types to consider, giving different perspectives.

  • Flow. This is Doing the Thing Right. Stories will be primarily related to the process, efficiency and reliability.
  • Value. This is Doing the Right Thing. Stories will be primarily related to the product, effectiveness and validity.
  • Potential. This is Doing the Thing Sustainably. Stories will be primarily related to people, euphoria and flexibility.

Impacts as Triads

When exploring the impacts, it will become apparent that there is not always an obvious and neat mapping to either flow, value or potential. Thus, the three impacts can be thought of as a triad, with each being a vertex of a triangle.

Triads are concept I learned from Dave Snowden and used by the Cognitive Edge Sensemaker Suite (note that they have a patent associated with this), where a triangle is used as a measuring instrument to assess against three parameters. By using triads, impacts can be placed relative to where they have the strongest affinity, without having to decide on any one in particular. Imagine an impact being connected to each vertex with elastic. The greater the affinity to a vertex, the greater the tension, with the final position being a result of the combination of all three. Thus the story in the triad below has the strongest affinity with the Flow vertex. The next strongest is Potential, with Value being the weakest.

Impact Triad

While triads are an approach not directly supported by the canvas in its current form, the deliberate choice of words to describe each impact creates multiple possible triads which could be explored. Deciding where an impact goes generally requires more thinking, and generates greater dialogue and insight.

FlowValuePotential
Thing RightRight ThingThing Sustainably
ProcessProductPeople
ReliabilityValidityFlexibility
EfficiencyEffectivenessEuphoria

Generating lots of utopian (and dystopian) future stories, instrumented with these triads, will generate patterns which can give a sense of where the improvement opportunities are for making an impact.

Example

Here’s an example of thinking about impact from the three perspectives. It is intentionally lacking in direct relevance to minimise the risk of biasing your own answers to the questions.

When I go running, I’m generally wanting to improve my health and fitness. What impact do I want to have?

  • From a Flow perspective, impact could be about pace and speed. I could imagine a utopian future where I can run a 4 minute mile.
  • From a Value perspective, impact could be about distance and stamina. I could imagine a utopian future where I can run 100 miles.
  • From a Potential perspective, impact could be about friendship and community. I could imagine a utopian future where I am the president of a local running club.

None of these are mutually exclusive. If I can run a 4 minute mile, then there is a high likelihood that I’ll be involved in a running club, and training longer distances as well. However, explicitly exploring the different perspectives avoids me just focussing on one thing such as speed, to the detriment of friendship or stamina.

What stories would you like to tell about the impact your kanban system makes in the future?

Heuristics for Building the Right Thing

On Monday I had the privilege of spending the day with some really smart people. Organised by Gojko Adjic, other attendees included Chris Matts, Henrik Kniberg, Mary and Tom Poppendieck, Gabby Benefield, Jeff Patton, Aaron Sanders and Olaf Lewitz.

The theme of the day was exploring how we can help organisations not just build the “thing right”, but build the “right thing”. We spent the morning sharing and exploring the various techniques we used, such as Story Mapping, Impact Mapping, Effect Mapping, Feature Injection, Real Options and Lean Canvas. We then moved onto more general discussion on the problem we are trying solve, before focussing back in on putting something together to try and articulate the commonalities we had found and create a platform to continue the conversation and try and make an impact ourselves.

Henrik has already blogged one statement summarising our conclusions.

Great results happen when:

  • People know why they are doing the work
  • Organisations focus on outcomes and impacts rather than features
  • Teams decide what to do next based on immediate and dircet feedback from the use of their work
  • Everyone cares

Another output was what I called “Heuristics for Building the Right Thing”. I mentioned heuristics in relation to Kanban Thinking, and again, the goal was to provide enough guidance for people to learn, without constraining to specific solutions or techniques. We started by brainstorming ideas and then grouped those into 5 themes, before putting some action-focussed words describe the themes. We noticed that there was a general feedback loop that the heuristics formed, and that there was a missing heuristic that was central to everything. Thus we ended up with:

  • Understand your customer
  • Be Comfortable with Ambiguity
  • Co-Create
  • Learn Fast
  • Make an Impact
  • Make it Visible

IMG_1222 IMG_1221

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.

The Economics of Raking Leaves

I was out in the garden this weekend raking up leaves. Having read Geoff Watts recent post about using Scrum to clear his leaves – and as someone who can’t do anything without thinking about work (see Kanban and Quad Biking!) – my mind turned to how I would use Kanban Thinking to approach the work at hand. Surely I would advocate single piece flow by clearing up each leaf individually, visualising and measuring my progress?

I hope its clear that doing as such would be insane! But why? Maybe “single leaf flow” would be better? Why did my instincts shout out otherwise? The answer, as I have learned so often recently, comes down to making an economic trade-off. Every decision has a value and a cost, and finding the right balance is key, preferring higher value and lower cost.

image

Each leaf cleared from my lawn would have value in progressing me towards my goal of a tidy garden. However, the transaction cost of removing each leaf individually would be far too great. Therefore, a more sensible trade-off was to batch the leaves into piles, so that transaction cost was spread over a larger number of leaves.

Further, like Geoff, I also considered the risk of creating multiple piles before bagging them up. I could also run out of bags, or have the piles blown away. However, I knew I had plenty of bags, and it was an unseasonably still day, so I created multiple batches before bagging. I was even able to safely have lunch between batching and bagging without any regret. In other words I made another trade-off between the value (in terms of addressing risk) and cost. The value (or risk) wasn’t great enough to justify the cost.

I may not have designed a Kanban System to rake the leaves, but I did apply some economic thinking to decide what to do. If there’s one main lesson I’ve learned over the last few years, its that there is rarely a ‘right’ answer, but that there are trade-offs, and they are usually economic.

Starting An Agile Transition With Why

In March this year I gave this keynote at the Rally Agile Success Tour in London. This is a video of the talk, followed by a write-up. The slides can be downloaded from here.

People don’t buy WHAT you do, they buy WHY you do it. Simon Sinek says that this is the fundamental reasoning behind what he refers to as the Golden Circle, which he describes as a natural law occurring in many forms, in the same way as the Golden Ratio. He cites example of the Golden Circle including Martin Luther King, who said “I have a dream” not “I have a plan” and the Wright brothers, who succeeded first with manned flight despite having less money, education, connections and publicity as competitors. The Golden Circle suggests that we should start with WHY, before determining HOW, and finally WHAT, rather than starting with WHAT.

image

Starting an Agile transformation with WHY involves knowing why you want to use an Agile approach, and the goals you are aiming for, rather than becoming Agile just because it seems popular or a good idea. Therefore, begin by defining your WHY, deciding where you want to go and creating a vision of the future that you hope Agile will help create. Then Agile will be a means to an end, rather than an end in itself. Your WHY is your destination, and Agile can help with HOW you get there, and guide WHAT you do to get there.

WHY

A WHY is what motivates people to take action. It is a purpose, a cause or a belief. It is a reason to care and want to get out of bed in the morning. A WHY is not to make money. Money is a necessary precondition for business, in the same way that breathing is a necessary precondition to living although our purpose in life is not to breathe. Making money may also be a desirable result, but it is not a WHY.

WHY is the equivalent of the System Thinking premise of purpose. Complex Systems have a purpose which influences behaviour, the product of the system’s elements and interactions. Dave Snowden uses the Magic Roundabout in Swindon as an example of a complex system whose purpose is to enable a high throughput of cars with a low accident rate. Reports show that it achieves this purpose, despite also being generally regarded as one of the scariest roundabouts in existence. By starting with WHY, the roundabouts designers created an effective, safe and resilient WHAT. Starting with WHAT leads to the less scary but more common design.

image

WHY is always going to be context specific, but one simple generalisation would be that it is to satisfy customer demand. Demand analysis can help understanding of what work adds value, and helps us towards our WHY, and what work doesn’t add value. John Seddon describes failure demand is work that results from not doing something right, or not doing something at all. That is not to suggest that we should strive for perfection and be right first time with up front analysis and design. Value can still be added in small, incremental and iterative steps. Think of it like a ticket machine at your local deli. When a customer first takes a ticket then the request can be considered value demand. Subsequent tickets for the exactly same request can be considered failure demand. However, further tickets could be for similar, related requests because the customer comes back for more of the same, as opposed to exactly the same.

Simon Sinek argues that our brain is wired to start with WHY. Our first brain, the Limbic System is what deals with emotions, unconscious thought, instinct, and governs our behaviour. Our thinking brain, the Cerebral Cortex, is what deals with rationality, conscious thought, intellect, and governs our language. Thus, our natural behaviour is to make decisions emotionally, unconsciously, and instinctively. We then justify those decisions rationally, consciously and intellectually with facts. I have just bought a new car (well, new for me) and spent a not insignificant amount of money in a totally impulsive purchase. I had no intention of buying a car when I entered the garage, but fell in love with the car and ended up talking myself into deciding it was an opportunity I would regret if I missed it. Similarly, both times I have bought a house, which is both an important decision and major investment, the decision was because the house “felt right”. The size, condition, location, price etc. came second.

How

HOW describes the way that a WHY will be realised. It can be thought of as a set of guiding principles that help map a WHY to a WHAT. A HOW can also be a specific outcome that is to be accomplished without detailing the activity and output required to complete it. Additionally, HOWs are often ways of differentiating approaches and describing them in comparison to competitors.

One way of describing HOW an Agile approach enables a WHY is with the metaphor of a Recipe for Success. David Anderson popularised this idea with the following recipe:

  • Focus on Quality
  • Reduce WIP
  • Balance Capacity against Demand
  • Prioritise

Similarly, my colleague Ken Clyne at Rally talks about the fundamentals of Agile as:

  • Focus on customer value
  • Deliver early and often
  • Reduce batch size
  • Pull quality forward
  • Inspect and adapt
  • Create a collaborative culture

These recipes are a guide to HOW to achieve Agility in order to achieve a WHY. However, they are not specific enough to describe WHAT to do.

A common explanation for WHY organisations want to become Agile is “Better, Faster, Cheaper”. These are at best HOWs, and not WHYs. In fact, I would suggest that cheaper isn’t even a HOW. To paraphrase John Seddon, focussing on cost will usually result in cost going up.

Another approach to describing HOW to become Agile is through a transformation strategy or roadmap. Options for which path to take include beginning slowly with a single, fully Agile pilot project from which to learn, diving in and moving all project to an Agile approach in one go for clarity of message, only beginning new projects or initiatives as Agile to avoid risking current work, or incrementally solve specific challenges with certain practices for a more evolutionary transition.

Working Agreements can also be considered as a description of HOW. Explicit policies for how work is done can be created by recognising how value is created, how that creation is visualised and made transparent, how the work in process is limited, what cadences are used for synchronisation and co-ordination, and how continuous learning and improvement happens.

My personal take on HOW to be Agile is in terms of flow, value, capability. Achieving flow involves eliminating delays and focussing on reducing the lead time from concept to consumption. Delivering value involves making sure that the right things are being worked on and the right problems are being solved rather than “doing the wrong things righter”. Building capability involves developing people and their skills working as teams aligned to the organisation strategy.

What

WHAT is done proves that a WHY really is believed. It consists of tangible ways with which a WHY is realised and provides clear data points that actions are according to a WHY.

Agile practices are WHAT teams do in order to enable them to realise their WHY. Further, practices can be associated with HOW agility is demonstrated, in terms of flow, value and capability. The following is one interpretation of some practices. I’m sure there are many others.

Flow

User Stories are a technique to break down functionality into small pieces of demonstrable functionality which can create single piece flow. Time-boxing and kanban-style limits are both ways of managing WIP and enabling a focus on finishing rather than starting to keep work flowing. Visualisation approaches help teams see all the work so that they can focus their energy in the right places to keep flow. Strong teamwork and collaboration minimises the need for queues and batches which cause delays. Test Driven Development, with its emphasis on automated unit testing and refactoring, keeps designs clean and quality high so that new work can progress quickly. Continuous integration and deployment help works flow right through to the customer without lengthy release processes causing delays.

Value

Product Backlogs, User Stories, Minimal Marketable Features and other value-focussed forms of requirements are intended to help teams ensure they are delivering maximum benefit. Similarly, the On-Site Customer, or Product Owner roles are intended to maximise collaboration with people who are determining and receiving the value. Iteration demos and reviews are a means of gaining early and continuous feedback and validation that the product is delivering the intended value. Frequent and continuous delivery means that the value can be realised as soon as possible. Acceptance Test Driven Development and Behaviour Driven Development provide techniques for delivering value through quality and clarity of functionality.

Capability

Dedicated, cross-functional, value focussed teams mean that learning and knowledge is kept, shared and built upon to develop capability. Various collaborative practices, such as Pair Programming, Collective Code Ownership, Group Design, Team Estimation and Planning Poker similarly share knowledge around a team. Regular demos and reviews provide a cadence with which feedback and learning can build product capability, while regular retrospectives provide a cadence with which feedback and learning can build team capability. Visualisation of work, and the way value is created, gives visibility of bottlenecks and constraints and other issues such that they can be resolved to improve capability. Slack ensures that teams have spare capacity to both address these issues, and spend time on other forms of capability development which will improve future productivity and performance.

Conclusion

When embarking on a change initiative using Agile approaches, always “Start with WHY”. Use the WHY as a True North with which to guide the Agile transformation and steer decisions on which Agile practices to use for what reasons. Understand HOW agility is going to help progress towards the WHY, and WHAT Agile practices will provide the means to get there.

A clear WHY, that people are motivated by, will make it more likely that they will want to use Agile. However, Thomas Edison said that “vision without execution is hallucination”, so don’t stop with WHY, but make sure that the Agile HOW is also well known and the Agile practices that form the WHAT are clearly understood to ensure that the goal is successfully reached.

People and Process: Two Sides of the Same Coin

I wrote this short article for JAX Magazine, but it seems JAX doesn’t want to make it easy for people to access the content (you have to register to get a download link which only works once). So I’ve decided to post the article here as well. Its an evolution of some of my thinking that goes back to the new lean and agile picture I posted.

One of the value statements from the Agile Manifesto is “individuals and interactions over processes and tools”. This is often abbreviated to “people over process” with a common interpretation being that the human aspects of software development are the primary areas we should be focussing on for improvement. However, this is counter to the ideas of W. Edwards Deming, who said “a bad process will beat a good person every time”. Similarly, Don Reinertsen has said he prefers “people times process” because if either is zero, then the product is zero.

People and process are two sides of the same coin, both equally important in understanding how to improve capability to deliver valuable software.

People

This side of the coin is about taking a group of people, who form a team in order to develop a capability. Peter Senge wrote in ‘The Fifth Discipline’ that “the fundamental learning units in an organisation are working teams (people who need one another to produce an outcome)”. Creating teams in this way allows people to iteratively learn about the way that they work so that they can incrementally develop their capability in order to improve the outcomes that they produce.

This is the basis of all the popular Agile methods such as Scrum or Extreme Programming, which all recommend creating cross-functional and co-located teams, collaborating with high bandwidth communication. Thus, the people side suggests that forming outcome-focussed teams, rather than activity-focussed silos, will result in an improvement.

Process

This side of the coin is about taking a vision, which is developed into a product in order to deliver value. Mark Denne and Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about “an ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality”. Taking this approach means that a product will maximise its value through being iteratively refined piece by piece in order to incrementally deliver functionality.

This is the basis of Lean approaches such as Kanban, which focuses on creating an explicit understanding of the process in order to learn how to deliver valuable pieces of software more effectively by modelling and visualising the work and associated policies. Concepts such as Minimal Marketable Features and User Stories help break down the work into smaller pieces. Thus, the process side suggests that continuously delivering small pieces of functionality with minimal delays, rather than waiting to release large batches of features, will result in an improvement.

People and Process

It is when we put these two sides together that we can achieve significant improvement. The iterative loops of learning about both the team and the product link into each other enable product value to rapidly flow through capability teams. This is the development nirvana we are trying to reach.

This model also gives some insight into why the “Waterfall” model, described by Winston Royce in his 1970 paper ‘Managing the Development of Large Software Systems’, has proved to be unsuccessful. It is not because the simple work-flow described was inherently wrong, but because the work-flow has typically been implemented with specialist silos rather than capability teams, and with large rather than small batches. It is both these two sides of the coin that should be the focus of learning and improvement in order to help us on our journey to the nirvana of product development flow.

A Model for Creating a Kanban System

This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

  • Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
  • Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
  • Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

  • Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
  • Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
  • Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
  • Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
  • Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.