What is a True North?

True North
True North

The True North is the first element of my TASTE model and is in the middle of my X-Matrix template. It is the central piece which holds the other elements together. On the X-Matrix I define the True North as:

The orientation which informs what we should do.

That is a bit abstract and jargony, so lets unpack it a bit. By orientation I mean that a True North sets direction. That direction doesn’t define any specific destination, let alone how we get there, but it does help us decide (i.e. it informs) what the next steps might be. In other words, rather than simply following a plan, we can ask “does this step take us towards our True North or away from it?”

When if comes to actually crafting a True North statement I’ve been evolving the way I describe my approach, and my current recommendation is to consider 3 aspects, conveniently as usual beginning the C.

  • Is it challenging? In fact a good True North is probably so challenging that its unlikely to be achievable in the foreseeable future. As such, it is not a target.
  • Is it compelling? Is it something that people will want to spend their time working on? Will it bring people together to collaborate on the collective challenge?
  • Is it concrete? Can people imagine what it would be like to achieve this ideal best? In other words its more than a woolly vision or mission statement or a set of platitudes.

I find that those 3 together can be used to create something which is short and snappy and describes something which is both ambitious and inspiring; a utopian outcome which is just over the horizon and out of reach.

As an example, a typical True North for a Lean manufacturing plant might be something along the lines of “zero defects”. Probably not achievable in the near term, but imaginable and worthy of striving for.

A recent example for an Agile Transformation was along the lines of “immediate development and deployment of customer requests”. Again, definitely not achievable in the near term, but clear enough to create alignment and focus.

There’s a phrase I picked up from somewhere (Google suggest multiple sources, mostly to do with personal development) that suggests focussing on:

who you want to be, not what you want to do

This seems like another way to think about a True North, describing an organisations long term objective rather than a short or medium term plan or solution.

What is Backbriefing?

Backbriefing A3
Backbriefing A3

I talk about Backbriefing a lot in conference presentations and will have mentioned it in a number of blog posts. In particular I put together a Backbriefing A3. However, I don’t think I’ve ever really described what I mean by backbriefing or what it involves. Time to rectify that.

Background

I first learned about backbriefing in Stephen Bungay’s book The Art of Action where he talks about it as part of Directed Opportunism. It is an approach to close what Bungay calls the Alignment Gap between Plans and Actions. This is where there is a difference between what a plan suggests people should do, and what they actually do. Rather than creating more detailed plans with more detailed instructions, Bungay suggests instead to allow people to create and implement their own plans to meet an intent, and to check for alignment with a backbrief.

Thus backbriefing is a process with which people can check their understanding of the intent of their work and whether their plans will meet that intent.

Process

Typically this involve 3 steps:

  1. The brief – the initial description of the work. Leadership briefs the group being asked to carry it out, not in terms of a plan but in terms of the intent, such as what goals and aspirations are. Thus the brief describes the problem statement.
  2. The backbrief – a replay of the understanding of the work. The group briefs back to the leadership what they heard, including their plans for how they will carry it out. Thus the backbrief re-describes the problem statement along with an initial solution.
  3. Feedback and adjustment – a review to clarify the work. Together everyone revises the articulation of the intent and the work. This could be due to misunderstandings in communication, or to take into account new information learned from the backbrief. Thus the feedback and adjustment refines both the brief and the backbrief.

Practice

The A3 template I created is the way I do backbriefing in practice where it is used primarily for steps 2 and 3 above. The various sections cover the understanding of the brief (Context, Intent and Higher Intent) as well as the initial proposal for carrying out the brief (Team, Boundaries, Plans). As the A3 is populated and reviewed, its can be updated to deflect any feedback and adjustment.

In the context of the X-Matrix, I like to start with backbriefing for the initial set of Tactics, where teams are given a Tactic as their brief and use the Backbriefing A3 to create understanding and alignment around what they are being asked to work on. This then becomes part of the Catchball process to translate the organisational strategy into the daily tactical work.

Postscript: I have followed up this post with another one on Backbriefing and the Curse of Knowledge.

What is Catchball?

Back to Black

I’ve mentioned and alluded to the Strategy Deployment concept of Catchball in various posts but I’ve never really described what I mean by it. This post is an attempt to fix that.

The Metaphor

Catchball is a simple metaphor for a collaboration,  where a ball is thrown between people in a way that everyone is involved in the game. As part of Strategy Deployment, it is throwing a ball between members of the organisation, where the ball is an idea or proposal for change or improvement. Thus the development of an idea becomes a team sport, where everyone is involved in improving it.

The Definition

I have based my definition on the question addressed in the paper “Hoshin Kanri: Implementing the Catchball Process” by Charles Tennant and Paul Roberts. They ask “how can the consensus process known as catchball, be effectively implemented in western companies to facilitate the Hoshin Kanri method, to translate top management goals into daily working?“.

From that, I would say that Catchball is:

a consensus process to translate organisational strategy into daily tactical work

The three main pieces of that definition are about consensus, process and translation.

Concensus

Consensus means that people are agreeing to something, as opposed to consent where they are only giving permission. We want people to agree with an approach because they have been engaged in formulating it and had the opportunity to express alternative and diverse perspectives. Rather than taking an idea and watering it down until we can get permission, we challenge it an improve it until we can get agreement. The principle is that no single person has the answer, and the whole is greater than the sum of the parts. This is similar to the ideas I wrote about in a previous post on Strategy Deployment as Organisational Improv. Consensus doesn’t happen accidentally, however, which is why we need a process.

Process

Process is the intentional action we take in order to achieve consensus. Generally this is where tools such as A3s templates for backbriefing and experimenting are useful, and I often say that it is the A3s that are the ball with which we are playing Catchball. The A3s provide the focus and discipline for people to reflect on and improve ideas as they pass them around. Thus the steps of populating, reviewing and monitoring the A3s can generate consensus on what we are doing, why we are doing it, and how we will know whether its is working. There is also the process of interpreting the high level goals in order to do the right work, which is the translation.

Translation

Translation is required to align strategy (e.g. top management goals) with operations (e.g. daily tactical work) in a way which avoids imposing or inflicting solutions on people, and instead enables engagement, involvement and contribution. Having a consensus process means that the translation is created by the people doing the work, and is therefore able to be applied in both directions. Translation generally happens through a nested PDSA cycle such as the one as I described in a previous post on the Dynamics of Strategy Deployment.

If we take this definition of Catchball – a consensus process to translate organisational strategy into daily tactical work – then we can start to explore alternative ways to play the game. What other processes might we use, or what other translation mechanisms are there? For example, how does Agendashift provide a consensus process for translation? This is one are I am hoping to cover in a 3-day Agendashift + X-Matrix Masterclass in Brighton in October with Mike Burrows. If you’d like to join us, follow the link for tickets.

What is an X-Matrix?

An X-Matrix is a template used in organisational improvement that concisely visualises the alignment of an organisation’s True North, Aspirations, Strategies, Tactics and Evidence on a single piece of paper, usually A3 size (29.7 x 42.0cm, 11.69 x 16.53 inches).

The main elements can be described as follows:

  • True North – the orientation which informs what should be done. This is more of a direction and vision than a destination or future state. Decisions should take you towards rather than away from your True North.
  • Aspirations – the results we hope to achieve. These are not targets, but should reflect the size of the ambition and the challenge ahead.
  • Strategies – the guiding policies that enable us. This is the approach to meeting the aspirations by creating constraints which will enable decisions on what to do.
  • Tactics – the coherent actions we will take. These represent the hypotheses to be tested and the work to be done to implement the strategies in the form of experiments.
  • Evidence – the outcomes that indicate progress. These are the leading indicators which provide quick and frequent feedback on whether the tactics are having an impact on meeting the aspirations.

The alignment of all these elements is shown through the 4 matrices in the corners of the template, which form an X and thus give the format its name. Each of the cells in the matrices indicate the strength of correlation (e.g. strong, weak, none) between the various pairs of elements, forming a messy coherence of the whole approach.

Completing an X-Matrix is a collaborative process of co-creation and clarification to get everyone literally on the same page about the work that needs to be done to succeed. Used to its full potential, the X-Matrix can become a central piece in Strategy Deployment, helping to guide discussions and decisions about what changes to make, why to make them, and how to assess them.

You can download a copy of my X-Matrix template, along with some related ones. Like most A3 formats, there are many variations available, and you will find that a lot of other X-Matrix versions have an additional Teams section on the right hand side. My experience so far has been that this adds only marginal value, and have therefore chosen not to include it.

If you would like help in using the X-Matrix as part of a Strategy Deployment improvement approach, please contact me to talk.

What’s the Difference Between a Scrum Board and a Kanban Board?

During a recent kanban training course, this question came up and my simple answer seemed to be a surprise and an “aha” moment. I tweeted an abbreviated version of the question and answer, and got lots of interesting and valid responses. Few of the responses really addressed the essence of my point, so this post is a more in-depth answer to give more detail.

When the question came up, I began by drawing out a very generic “Scrum Board” as below:

Everyone agreed that this visualises the basic workflow of a Product Backlog Item, from being an option on the Product Backlog, to being planned into a Sprint and on the Sprint Backlog, to being worked on and In Progress, to being ready for Accepting by the Product Owner, and finally to being Done.

To convert this into a Kanban Board I simply added a number (OK, two numbers), representing a WIP limit!

And that’s it. While there are many other things that might be different on a Kanban Board to do with the flow of the work or the nature of the work, the most basic difference is the addition of a WIP limit. Or to be more pedantic you might say an explicit WIP limit, and as was also pointed out (although I can’t find the tweet now), its actually creating a pull signal.

Thus, the simple answer to the question about the difference between a Scrum board and a Kanban board is that a Kanban Board has WIP Limits, and the more sophisticated answer is that a Kanban Board signals which work can and should be pulled to maintain flow.

Of course, this isn’t to say that Scrum teams can’t have WIP limits, or pull work, or visualise their work in more creative ways. They can, and probably should! In fact the simplicity of just adding a WIP limit goes to show how compatible Scrum and Kanban can be, and how they can be stronger together.

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!

Does A Kanban System Eschew Estimation?

I was recently involved in a brief twitter conversation which started when Mike Sutton tweeted:

estimation is not about the number that pops out. It is about exploring effort and discovering that you don’t know stuff.

Paul Dyson responded:

spot on! This is fundamentally what I don’t like about the kanban “if people find estimation hard, don’t make them do it” mantra.

Which is where I jumped in:

where did you hear that “kanban mantra”? Not one I’m familiar with.

Only to be told:

err, it was actually in the talk you gave at mini-Spa!

Since then, Paul has blogged some more on estimation, and this is my response, hopefully clearing up what I said, or at least meant to say at mini-Spa, in addition to what I’ve already written on estimation and waste.

A simple summary and paraphrasing of Paul’s post would be:

Estimation, as part of time-box planning, leads to whole team interaction and collaboration, to create learning about past capability and forecasts of future capability

Lets start by drilling into these key points from Paul’s post. Essentially the implication is that by eschewing iteration, we cannot have whole team interaction and collaboration, cannot learn about past capability and cannot forecast future capability.

Whole team interaction and collaboration

I can think of 3 ways a team a whole team can interact and collaborate around planning a new piece of work without estimating in a time-box planning meeting:

  • Cadence. The team agrees a cadence at which they will all get together to collaboratively plan new work. This planning cadence looks at what new items the team may be able to pull, given their current work-in-process, rather than estimating what items they may be able to complete.
  • Workflow. The team explicitly models their workflow to make transparent that fact that they need to get together to plan new pieces of work when they are pulled. This stage could be a stage called “Planning”, or even ”Analysis”!
  • Just do it! When the team pulls a new work item, they spontaneously swarm on it to plan it. This probably requires a small and high performing team.

Even so, this is assuming the whole team really does need to interact and collaborate on every piece of work. However, not every piece of work is equal, and there may be some smaller, simpler features that can be planned and delivered by a smaller group.

Create learning about past capability

We can learn about our past capability by measuring data such as cycle time, and tracking it with a Statistical Process Control chart. Common cause variation is to be expected within a stable system. However, special cause variation is something we can look at in more detail to see what we can learn (as long as we don’t change the system in response to special cause variation).

Forecast future capability

Once we understand our past (or current) capability we can use that information to forecast future capability. By understanding how long things have typically taken in the past (with natural variability) we can determine how long things will take in the future (with natural variability). Dennis Stevens has recently written some great posts discussing knowing when we will be done, using classes of service and service level agreements to manage variability.

So kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost. The old joke does still apply (“Doctor, Doctor it hurts when I do this”, “Don’t do that then”). If it hurts to estimate, then find other ways to encourage whole team interaction and collaboration, learn about past capability and forecast future capability. On the other hand, if estimation doesn’t hurt, or costs too much, then it may be the right thing to do in your context.

What I think we do agree on is that when we are planning, we should decompose work for understanding, rather than sizing (thanks to Eric Willeke for this phrasing). As Mike says, the estimate is just a number that pops out of the discovery.

Is Kanban A Relabeling of Scrum?

Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim Coplien at Scan-Agile, after (but not necessarily the result of) a conversation over dinner where myself and a few others were describing how we used Kanban. Each time we described different aspects of our processes, Jim would say something along the lines of “but I do that with Scrum”.

So what would it mean for people to have so misunderstood Scrum that they have reinvented it and called it Kanban?

  • It might mean that at their heart, Scrum and Kanban have the same intent. That both are really focussed on helping teams think about their processes in order to help them succeed.
  • It might mean that the way that Scrum was originally articulated (and is still articulated according to the latest Scrum Guide) was not as clear as it could have been. That teams might misconstrue the focus on roles, meetings, artefacts and rules.
  • It might mean that there are alternative ways of articulating the same intent. That teams might find alternative articulations valuable.
  • It might mean that Kanban can be equally misunderstood. That teams might be bewildered by a less prescriptive approach.
  • It might mean that we should spend more time on understanding how to help teams solve their problems and less time arguing and fighting over preferred solutions.

These are just some of my thoughts. They do not mean that I think Scrum is bad – just not perfect. They do not mean that I think Kanban is perfect – although it’s currently my first language.  The topic drew a good crowd at the Scan-Agile Open Space and we had a good discussion. What else might it mean?

Does A Kanban System Eschew Iteration

There has been some recent discussion on the blogoshpere and twitterverse about the relationship between Kanban Systems for Software Development and the concept of iteration. The often raised concern that a Kanban System is “Waterfall 2.0” came up again, along with the suggestion that a Lean perspective might view iteration as rework, and as a result be waste.

One of the conclusions was that both a Kanban and Time-boxed approach are independent of iteration. I like Jeff Patton’s description of iteration. Iteration is used to find or improve a single solution. Incrementing is used to build up additional solutions.

It is perfectly possibly with a time-boxed approach to define a product backlog based on already decided solutions, and then prioritise User Stories to incrementally build up the functionality for those solutions. I don’t think this is that uncommon. Similarly, a Kanban System could be used to only incrementally build up the functionality for pre-determined solutions.

Done well, both a time-boxing and Kanban approach will prioritise work to generate knowledge and feedback which will help discover or refine solutions. What is really being prioritised in this case is a problem, or an ROI Component (as the Real Options tribe like to call it). This is where I think a Kanban System can help by explicitly managing the work at both levels. The ROI Components, which I prefer to call Minimal Marketable Features, can be prioritised and limited as Work In Progress. The MMFs can then be expanded to candidate User Stories which can also be prioritised, managed and limited in order to iterate the MMF. Eventually, the User Stories will be collapsed back together to actually deliver the MMF as an increment.

Thus a Kanban System can explicitly visualise that MMFs are being delivered incrementally, and are being iterated using User Stories. While this same approach can be used with time-boxes, it will often be implicit.

What is Cadence?

Mark Stringer gave me some good feedback recently, that I clearly hadn’t described what I meant be Cadence at the recent miniSPA conference. In order to try and correct that, I thought I’d try and clarify with a blog post that it not simply variable length iterations.

The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.

Time-boxing is one specialised form of cadence. It’s like a metronome, giving a single tick. All the main process events are based around this single tick, as shown below where the dotted vertical lines represent the Sprint boundaries. In this example, the unit of work is a User Story, and User Stories should be small enough to be scheduled into a Sprint, and subsequently completed in the same Sprint. Stories in Progress are limited to two, as a good Scrum team might, but Stories don’t always fit exactly into a Sprint. Note also, that while releases can happen each Sprint, User Stories are only potentially shippable product increments.

Sprint

Kanban on the other hand has a cadence which is more like a drummer. The rhythm is more complex than the single tick of a metronome, and can be more varied, as shown below. In this example, the unit of work is a Minimal Marketable Feature, which while needing to be as small as possible, is not constrained be being required to fit into a schedule. Instead, an MMF is able to flow over a number of process events while it delivers some releasable value. Planning, reviewing, retrospection and releasing all still happen regularly, but they are de-coupled. They can happen independently, at differing rates, which may provide more freedom in creating a natural process which enables the team.

Kanban

A cadence is usually ‘harmonic’, in that there is a neat overlap between the different rhythms, as in this example. However, it does not have to be. A look at some definitions of cadence can show why. These are some favourites I picked off dictionary.com

  • In music, the ending of a phrase, perceived as a rhythmic or melodic articulation or a harmonic change or all of these; in a larger sense, a cadence may be a demarcation of a half-phrase, of a section of music, or of an entire movement
  • Music. A progression of chords moving to a harmonic close, point of rest, or sense of resolution.
  • The flow or rhythm of events, esp. the pattern in which something is experienced: the frenetic cadence of modern life.

Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. A pattern which allows the team to know what they are doing and when it will be done. For very small, or mature teams, this cadence could by complex, arrhythmic or syncopated. However, it is enough to allow a team to make reliable commitments because recognising their cadence allows them to understand their capability or capacity.