Up a bit, right a a bit. Towards the Purposeful Zone.

The team coaching model posits that good coaching is most effective and poor coaching is least detrimental when teams are well structured and supported. Integral to being well structured are the notions of being a real team and that team having a compelling direction.

However, what does being a real team with a compelling direction look like in practice? The following quadrants are a simple tool that can help us better understand where our own teams might sit, taking into account the levels of meaning and commitment in their work.

A team in quadrant 1 has high meaning to their work but they lack a whole team commitment. This means the team fundamentally enjoys the work its undertaking and gets satisfaction from it yet ultimately they aren’t united on where they’re heading or how they’ll get there. A team in this quadrant can be characterised as dreaming. They’ll have ideas of what they’d like to be able to achieve and yet no joined up desire or plan on how to get there.

A team in quadrant 2 has low meaning to their work and a low whole team commitment. This means the team is lacking enjoyment and satisfaction in their work. The team struggle to relate to the work at hand and don’t see it as important. As such the team lacks a unified vision or understanding of where it’s heading. A team in this quadrant can be characterised as drifting. There’s work to be done although no clear desire or plan for moving forwards.

A team in quadrant 3 has low meaning to their work although they have engendered a strong whole team commitment. As with the drifters the team struggles to find personal meaning in their work and as such it can feel arduous with the effort to complete it somewhat forced. The team do however have a plan in place, they ultimately know where they’re going and have developed a strong team commitment to move forwards towards their goal. A team in this quadrant can be characterised as grinding away. They’re moving forwards but the journey lacks meaning and enjoyment.

A team in quadrant 4 has both high meaning to their work and a strong whole team commitment. Their work is important to them, they can relate to it, get enjoyment from it and understand the value that’s derived from undertaking it. The high level of meaning helps engender a strong whole team commitment to their vision and goals. A team in this quadrant can be characterised as purposeful. The high levels of meaning and commitment lends purpose to their work which in turn helps move them into the realms of high performance.

Where does your own team sit in this quadrant, are they in the purposeful zone? If not, how close are they to the purposeful zone are they and is it meaning, commitment or perhaps both that they’re currently lacking in their work?

Understanding where a team currently sits can help us better understand how we can help a team move forwards. As a general rule our role as coach should be to help teams move up a bit, right a bit in these quadrants. Work with the team to help them find increased meaning in their work and a stronger sense of commitment to where they’re heading and we can help move them towards the purposeful zone and world of high performance.

Another interesting exercise might be to see where you personally sit in this quadrant. How meaningful is your current work and how committed are you to it? Is there scope for moving yourself up a bit, right a bit? 

Hosting an Agile Meetup with Liz Keogh

So, I've been a bit quiet on the blogging front recently. I do however intend to 'reactivate' myself, and that starts now with this post describing an agile event we recently hosted at our works campus.

Last night we were pleased to welcome the Kanban Coaching Exchange for their monthly meetup. The speaker for the evening was Liz Keogh. Liz is always pushing the boundaries of Agile thinking and so we knew we were in for an interesting and thought-provoking presentation. As with all of Liz’s presentations there was a rich mix of information and ideas, so I’ve summarised some of the key points below.

The focus of the presentation was on the Cynefin framework, a practical application of complexity theory, and how we might utilise that to better think about complexity in our own projects. As part of that we would also look at key Agile tools such as Feature Injection, Deliberate Discovery and Real Options to help us understand how we might work to embrace and handle that complexity.

Liz framed the introduction of the Cynefin framework with the notion that all projects have risk. “If a project has no risks, don’t do it”, on the premise that there should always be something new to discover and deliver. That risk can exist in various states, as illustrated by the domains of Cynefin:

Simple (Where things are obvious)
Complicated (Where things are predictable but still require expertise)
Complex (Where out comes emerge and we learn by doing)
Chaotic (A state of accident and emergency)
Disorder (Not knowing what domain dominates)

The characteristics of each domain were discussed along with an illustration of the dynamic relationship between them, for example, the catasrophic boundary between Simple and Chaotic, where complacency can lead to failure.

Different levels of graded complexity were then presented from 5 (nobody has ever done it) through to 1 (Everybody knows how to do it). These were then illustrated in the context of Cynefin, using the framework to understand the domains in which the different risk levels sit, with the most common forms usually sitting across the Complicated and Complex domains. With that in mind Liz then ran us through some key Agile tools which can be used to work with complexity and risk; Feature Injection, Deliberate Discovery and Real Options. These are tools which have been emerging from the world of Behaviour Driven Development in recent years so it was really interesting to see Liz’s latest views on them.

Feature Injection

Feature Injection, in line with emerging practices such as Impact Mapping, is a practice designed to enable us to derive scope from goals, all linked back to an overall vision. This is a practice which I've been trying to use in some of my projects so I thought it was particularly valuable to get a clear summary of the Feature Injection hierarchy:

Vision – The value of the project
Goal – What’s needed to go live
Capabilities – What’s needed to achieve a business outcome
Feature – User interface component which enables a capability
Story – A slice through a feature to enable faster feedback
Scenarios – An example of how the system will be used

Essentially then we can use Feature Injection to break down a project, embrace uncertainty and risk whilst ensuring that we continue to map back to value.

Deliberate Discovery

We then moved onto the importance of discovery within handling risk. The three tenets of Deliberate Discovery were illustrated:

 -Assume ignorance – there are things we don’t know
 -Assume second order ignorance – there are things we don’t know that we don’t know
 -Optimise for discovery

Essentially, when thinking about priorities in a project we can optimise for discovery by taking a risk-driven approach. This can be reflected in backlogs by making them high-level and risk-first.

Real Options

We then briefly looked at Real Options and it’s three tenets:

 -Options have value
 -Options expire
 -Never commit early unless you know why

Understanding the options we have available, the value attached to them and understanding the impact of early commitment is something else we can use to help understand and deal with complexity and risk.

Fixed Scope or Fixed Goal?

A lot of people in the Agile world talk about 'fixed scope' projects. However, just how well aligned is the concept of fixed scope with Agile? Moreover, is it aligned at all and does the concept send out a contradictory and confusing message?

One of the things that we accept within Agile development is that requirements will emerge and evolve throughout the course of a project in line with our understanding of the problem and solution. This understanding is rooted in the Agile manifesto which tells us that we should value responding to change over following a plan.

Jonathan Rasmusson in his "The Agile Sumurai" book expands on this value by giving us the three simple truths of software development:

- You can't gather all the requirements up front
- The requirements you do gather will change
- There is always more to do than time and money will allow

I'm not sure that anyone involved in software development would disagree with any of those. So, if we accept these facts then surely we also accept that scope will change throughout the course of a project? If something changes then how can it be fixed?

What we really mean by a fixed scope project is that it isn't fixed by time, i.e. we're going to deliver something but there isn't a hard deadline for that fixed something to be delivered. The question is what that fixed 'something' represents. To explore this a little further we can look towards the different levels of Agile deliverable. Feature Injection outlines the following:

Vision > Goals > Capabilities > Features > Stories > Scenarios > Code

At the story level any typical project is likely to see lots of change. New ones emerge, existing stories change or are dropped altogether. At this level there is constant evolution.

The same is true for features, although perhaps to a lesser extent. If we consider features to be our high level stories or epics we also know that these are likely to change throughout the course of a project.

Capabilities are those things which will enable a business to achieve their goals. There's normally more than one way to achieve or contribute towards a goal and these are also open to change as we move through a project and learn more about the domain and requirements.

So what about the goal of a project? Although planned deliverables are likely to evolve the original goal or intention of the project is likely to stay the same, or ideally it would anyway. If the goal is continually changing then the 'project' is at best in support mode or at worst suffering from a lack of direction.

For example, a gaming website may undertake a project with the goal of increasing it's number of active users by 20% and there may be many ways in which to achieve this. We might have an initial view of the capabilities and features that we intend to deliver the goal but these will not just likely evolve but hopefully so as our understanding increases though learning from rapid feedback loops and validation of value. We may find, though validation, that a planned capability or feature is not contributing towards the goal of the project as intended. As a result of that validation we may well decide to amend that capability, focus efforts on building other capabilities or bring in entirely new capabilities.

Whatever the choice there will be an inevitable change in scope but the goal of the project will remain the same, and we'll be continually validating (hopefully) against that goal.

So when we talk about fixed scope should we really be talking about fixed goal? It does seem, at least, better aligned with the Agile concept of responding to change.

The Perils of the Large Backlog

This post is a result of some thinking triggered by a recent quote by Dan North; "How can you respond to change when you have 600 stories in your backlog?".

This statement seems so seemingly obvious but at the same time so often overlooked. We know that throughout the course of a project new requirements will emerge and existing requirements will change. As an Agile team we want to be able to effectively respond to that change and, as the Agile Manifesto tells us, be positioned to harness that change for the customer's competitive advantage.

That said, the first thing we see many project teams doing in their quest to be Agile is create massively long product backlogs. Backlogs containing so many stories that the team immediately find themselves rooted in a level of detail which directly inhibits their responsiveness to change. I refer to 'level of detail' in two contexts:

- Low level (overly granular short term requirements)
- Long term (overly vague and non relevant longer term requirements)

Both contribute to the problem by creating a backlog which is so low level and long term that any requirements change requires a complete review, restructure and rewrite of the backlog. This is obviously a massive overhead and will probably lead to a team actually trying to avoid change, never mind trying to harness it. It isn't Agile and in turn the customer/business will struggle to be agile in their operation.

We can even go a step further and use queuing theory to reflect on the effect that long backlogs have on our Agile process. Not only does a long backlog affect out ability to respond to change it affects our ability to deliver change in the first place. Little's Law as part of queuing theory tells us that:

Size of Inventory = Processing Rate x Delivery Time

We can adapt this, as below, to see the impact that the Size of Inventory has on Delivery Time.

Delivery Time = Size of Inventory / Processing Rate

We can see from this that Delivery Time can be reduced by either a reduction in the Size of Inventory or an increase in the Processing Rate. Let's now place this in an Agile context:

Story Delivery Time = Size of Backlog / Story Throughput

Now lets apply some simple numbers:

100 stories in the backlog / 10 stories completed a week = 10 weeks for a story to be delivered

This 10 week Delivery Time results from a culmination of the time it takes for a story to get into the backlog, the time it takes for work to start on the story and the time it takes to complete work on the story.

There are two things that can be done here to reduce the Delivery Time. Firstly we can speed up the time it takes to complete stories. There are many ways in which this could be done e.g. better specification and engineering practices, those however are a subject for another post. The second way in which we can reduce Delivery Time is by reducing the number of stories in the backlog. With a smaller backlog we can start working on stories sooner, complete the work and deliver value for the business sooner.

Now, in reality this may be slightly complicated by the fact that stories don't necessarily go through a backlog sequentially, indeed some stories might end up not being done at all. Generally speaking though queuing theory shows us that we can get items through a system more quickly if there are less items waiting to be completed in the first place. Lean thinking, Work in Progress limits and flow systems all provide us with practical ways in which to benefit from this understanding. Further examination of these however is again a subject for another post.

Future posts aside, the message from this post is a fairly simple one. Long backlogs inhibit our ability to respond to change and deliver value. They inhibit the Agility of the project team and in turn inhibit the agility of the business. We should therefore strive to avoid them. Down with the massive backlog!