Agile practice irrespective of flavour (Scrum Kanban XP …)can often be reduced to:

• Work in small batches
• Deliver often
• Build the most valuable chunk first

And it’s the “value” bit that can get us in trouble.

How do we determine which is the most valuable bit? Particularly early on in a project we need to be careful about how we prioritise. Do we just get a bunch of business folk to fight for their favourite features or do we have some hard won lessons to apply from many years of technology project management?

One of the first projects I was responsible for was fixed scope and fixed price. The customer was documenting requirements to be handed into the “agile” development team who built and tested software prior to a traditional system test cycle. Not very agile!

However, we benefitted greatly from the rhythm or scrum, the rigour of agile engineering practice and the predictability the the planning and tracking approach provided.

Most significantly, by taking the Product Owner role I was able to prioritise according to my own definition of value. Put yourself in my seat, you work for a software consultancy, it’s your first project and it is fixed everything, what makes one feature more valuable than another? The answer is risk. When everything is fixed value is in the reduction of risk. In fact I combined prioritisation according to risk with other engineering considerations such as profile of the work to bring the project to a successful conclusion.

So what about other interpretations of value? I’ve been helping a client with a project initiation over the past couple of weeks and found myself using the word uncertainty a great deal. It seems that driving out uncertainty held a great deal of value in that context. In fact, when kicking of a project we look for information generation first, then seek to identify key risk areas and mitigation strategies such as finding new stakeholders or driving out technical risk with proof of concept work.

Uncertainty isn’t new; I often use the “cone of uncertainty” model to express the value of reducing uncertainty. As wikipedia will tell you, this model is primarily concerned with project estimation. At the beginning of a project, skilled estimators may have a factor of 4 error in either direction. Over time error should rapidly reduce as information arrives and the project progresses. This dynamic is known as the Cone of Uncertainty and is the inner line on the graph.

The outer line is the cloud of uncertainty. This is what could happen if uncertainty is not driven out of the project. Right to near the end of the project there is significant error in estimating the size due to missing information.

When we execute agile projects lets not forget the value of driving out uncertainty. This isn’t an excuse to analyse everything to death. Our goal is to recognise where the uncertainty that matters is hiding. Those innocuous features that come along and prove the architecture is flawed are a prime example. We must do enough to understand the risk we are carrying while being sensitive to the cost of gathering detailed information pertaining to speculative requirements.

I have spent plenty of time this year working with clients who required help in initiating new projects and each time I have emphasised the importance of establishing the drivers for the project in order to provide direction and purpose. Even knowing how important this process is it surprised me the degree to which Tom wishes to emphasise the value being derived from a project and more specifically the metric for it’s measurement.

Of course metrics are important but the rigour that Tom encourages makes his methods different and (to me at least) interesting. I’m not seeking a silver bullet, but I do recognise that Tom’s methods may indeed be right in some situations where we must show measurable progress towards a set of objectives.

The workflow Tom introduced for establishing Goals was deceptively simple at it’s core; check out his web site or book if you want the detailed / in depth version.

• Objectives

The project sponsor(s) is asked to brainstorm up to ten strategic drivers for the project. These might include aspects such as usability or quality as well as outcomes such as reduce system operating costs. These must be phrased carefully to ensure that they really do represent the project goals. In practice the group I was working with found it difficult initially to pitch these at the right level. Very high level goals can prove difficult to work with while lower level goals may be strategies in disguise.

• Ambition

An ambition level describes what the objective would look like once fulfilled. This should contain something compelling and forms the basis of the later steps. For example;

Objective: Increase customer satisfaction
Ambition: Customers are delighted with our service

• Scale

The scale is the critical step that leads us to metrics. It is important that we establish a scale rather than a measure (a distinction that does not come naturally), thinking about the units can help here. We also need to suspend our disbelief over if this could ever really be measured. In our example the scale could simply be – annual customer renewal rate, or might include – average satisfaction level recorded in annual customer survey.

• Meter

This is the specific approach to be taken in measuring achievement of the objective. So, in our case the meter might be – percentage of customers who, when up for renewal, do renew subscriptions per calendar year. However, that is not all, the Meter should also include the current state, a goal and potentially a stretch goal.

Our team have used Objectives, Ambition level and Scale to ensure that we share a common understanding of the objective, what Tom refers to as clarity. This has been a little time consuming but has demonstrated numerous issues with mistaken assumptions and different opinions. In all I do believe it has been time well spent.

• Strategies

The next step is to think about fulfilling these objectives. There may be many possible ways to fulfil objectives, each candidate approach is called a strategy. Strategies can be compared in an Impact Assessment table where each is considered and compared through it’s estimated ability to impact the objectives.

Today myself and colleagues had our objectives on post-its on the wall vertically with strategies running horizontally as we began to identify where strategies contribute to fulfilling an objective. This agile take on impact assessment lead us to re-evaluate our objectives in light of strategies we felt were right but who’s underlying objective was not properly represented in our list. We also considered those strategies we had decided against, the ability to defend such a decision through the impact on objectives was considered beneficial.

The next step will be to review how strategies contribute to our goals when their effect is factored by cost. This should lead us to select the most cost effective strategies possible to achieve our intended outcome.

Conclusion

Often, in agile circles, we are accused of lacking rigour and make decisions that appear to be gut feel rather than numerically defensible. I will be looking out for opportunities to bring Tom’s approaches to bear on problems where that addition of rigour can facilitate defensible decision making and a shared view on what is important.

Technorati Tags: Tom Gilb

Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.

By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.

As is so often the case I feel that I fall between these two camps.

• I believe in an empowered team who pull from the backlog
• I believe in the team making a commitment to a sprint scope
• I believe in the team self-organising around moving that scope through to releasable product

But, there is always a but, these things don’t preclude prioritisation.

We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.

When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:

• The team is challenged to find ways to move stories to Done faster
• The team is encouraged to collaborate and help each other out in favour of picking new tasks
• We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
• Where a sprint commitment is missed we loose 1 story rather than a bit from each story.

So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.

For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?

I used a variety of tools and techniques to bring the project to life. As is usually the case, some worked better than others so I thought I’d review the approach and describe some of the issues and possible reasons.

The agenda for the day was:

1. Review project vision and goals
2. Establish key priorities and concerns
3. Establish candidate releasable chunks
4. Decide what to do first

Attendees included the development team, development management and business sponsors.

Project Vision

After some general discussion about the product we set about defining the Vision. The group were split into smaller groups each mixing development and business folk. Each team was asked to come up with an elevator pitch for the project of the form:

For __Customer__ who __has some need__
the __product name__ is a __product type__
that __will provide some benefit__
unlike __competing products__
out product will __key differentiator__.

In reviewing each groups proposed vision statement we settled on a single elevator pitch that embodied the purpose of the project and began to focus the team on what might be important.

Project goals

To further cement the way in which the product could be judged a success we went on to identify candidate goals. These included some consideration of how we might measure success.

These two exercises were received with some enthusiasm as the sub teams collaborated over achieving an accurate representation of the product. The need to measure outcomes causes business sponsors to work with those who were more technically minded in order to achieve measures that were specific, measurable and representative of the desired outcome.

Goals in this example included areas such as customer and sales force satisfaction as well as specific operational cost reduction goals.

Sliders

This is a technique that I picked up from Rob Thomsett’s Radical Project Management. I have used it to great effect in the past where trade-off was a critical demand of the project.

The sliders technique works by selecting a set of traits that could be considered to be in tension. These are represented as sliders that can be fully on, fully off or anywhere in-between. The stakeholders and team can discuss the implications of various slider positions. For example when considering cost and budget to be fixed we may choose to allow for some flexibility in scope in order to ensure quality.

Thomsett uses these seven measures of success; satisfied stakeholders, meet requirements, meet agreed budget, deliver on time, meet quality requirements, satisfy the team. I have used the same technique with other measures such as maintainability, time to market etc.

This technique was less well received than the previous two. While the discussion that was provoked was valuable some members of the group were unhappy with the somewhat arbitrary nature of the measures. One sponsor suggested that he felt that he was having to trade off his goals before even the project has started.

I believe that this early trade-off is a valid concern and it came up more than a couple of times throughout the project. When we apply agile principles to product development we look for small meaningful increments. This can be uncomfortable where a sponsor has internalised a grand vision.

Establishing releasable chunks

This exercise starts with the suggestion that it is good for the project to reach a releasable state early. We begin by identifying a set of capabilities of the system. These are grouped based on cohesion. I use the notion of Minimal Marketable Features to focus on achieving small releasable increments. We begin to prioritise these and work to make the first chunk as small as is reasonable in order to achieve marketability.

This was the most valuable and effective part of the day. The notion of MMF was used extensively through the project with the business sponsor often stating that a feature was “important but not necessary for this MMF”. Further, the focus on marketability places some focus on needs that can often be deferred such as security testing, performance testing and help facilities.

The following day would include beginning to identify the User Stories that would be necessary in order to achieve MMF 1.

Lessons learnt

In reflecting on this exercise there are things I would do the same and things I would consider doing differently. The initial Vision and Goals exercise was well worth while. While I know that the success sliders approach can be useful I may not have used that technique in this particular context.

A technique that I chose not to use, on reflection, would have been a good choice. As a part of the identification of releasable chunks we should have begun to identify those personas that we could address and how they related to different feature sets. I believe that this would have increased our focus on specific features and aspects of features.

We live and learn

Thanks for taking part in my mini retrospective on this workshop, I hope it can be of use to others. Please do feel free to ask questions of make comments below.

A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.

Theory of Constraints (TOC) is a large subject that I was first introduced to some time ago by Pascal Van Cauwenberghe and his explanation of the 5 focusing steps for process improvement. Since then I’ve seen TOC pop up at a few Agile conferences. The most notable aspects that tend to be discussed are the 5 focusing steps mentioned earlier and the TOC thinking tools. The Thinking tools offer techniques for root cause analysis, problems solving, conflict resolution and planning. While there have been a number of books explaining these techniques the source material is a set of novels written by Eliyahu Goldratt the first being The Goal: A Process of Ongoing Improvement.

David’s first book (Agile Management for Software Engineering) was focused on applying TOC in a software engineering context so I guess it’s not surprising that he wold choose to spend a little time explaining the connection between Kanban and TOC.

At this stage I should say that where David has applied TOC he has subsequently realised that a Kanban approach would have led to an equivalent result and is a conceptually more simple approach.

The areas of TOC that David chose to focus on were the classification of bottlenecks and the application of Goldratt’s 5 focusing steps.

1. Identify the bottleneck
2. Decide how to exploit the bottleneck
3. Subordinate the system to the bottleneck
4. Elevate the bottleneck
5. Repeat

These steps carry with them a set of pre-suppositions.

• We understand the goal of the system
• A system has a single bottleneck that constrains it’s throughput
• It is better to undertake changes that have no cost first i.e. improve utilisation of existing resources before adding resources

While for most types of system I am willing to hold with these pre-suppositions we should accept that while bottlenecks can move in a manufacturing context they are likely to move more quickly within a software context due to the greater degree of variability.

So, an example of applying these steps in a software development context might be;

Our goal is to construct, test and deploy software.
Our constraint is in system test, this is apparent due to a build up of software that has not been tested.
We identify exploit opportunities by considering where we loose test capacity e.g. recording timesheets. Since test is the bottleneck, time spent doing administration is directly reducing the output of the system.
We subordinate the system to the bottleneck by changing responsibilities e.g. PM to take on some administrative tasks from testers.

At this stage we return to assessing where the bottleneck is. If we run out of exploit / subordinate opportunities we may choose to elevate the constraint. This is where we consider adding resources, automation or training.

To close we should consider how a bottleneck might manifest it’s self in a system. Though others have suggested classifications for bottlenecks David’s approach is to consider 2 types.
Capacity constrained resource
Non-instantly available resource

For example compare a bridge with a ferry. A bridge has a fixed capacity, congestion occurs where too many cars attempt to cross. A car ferry will cause queues even where capacity is sufficient due to it’s non-instant availability.

Technorati Tags: Kanban Coaching, Theory of Constraints

Value trumps Flow
Flow trumps Waste reduction
Eliminate waste to improve efficiency

This mantra might be deceptively simple. We need to consider each aspect in turn.

Value
In a Lean sense value is in the eyes of the consumer. Activities can be classified as value adding and non-value adding. Classifying activities isn’t always as simple as it sounds; development = value adding, fixing defects = non-value adding but what about testing? If you’re not sure then answer this, would you do more of it if you could? Remember, not every non-value adding activity can be eradicated in the short term.

Flow
In this context flow refers to the uninterrupted adding of value from concept through to realisation. When presented with a need we should seek to fulfil it in a continuous chain of activities with minimal time in queues and minimal delay.

Waste
There have been a number of attempts to define waste in software development through comparison with manufacturing industries. In the Kanban class David chose to classify wastes as transaction & co-ordination costs, failure load and depreciation of assets. I believe that this could form a useful framework assuming that we accept a certain amount of waste as necessary.
For example daily stand-up meetings are certainly not value adding and fall under the category of coordination costs, however, they are a necessity in the contexts of many teams. Perhaps more on waste in another post.

So, to reiterate, value will trump flow where we choose to disrupt flow in order to meet an opportunity. An example of this would be a new requirement that must be expedited in order to minimise the cost of delay. An expedited request will cause delay in all of the other in-flight requests.

Next we choose to trump waste reduction with flow. This is most visible where we introduce buffers to ensure maximum utilisation of a bottleneck activity. Recall that the theory of constraints teaches us that the throughput of the bottleneck determines the throughput of the entire system. Where flow is somewhat ragged we will introduce a buffer to ensure that work is available. Buffers can be considered wasteful, however, the benefits of the increased throughput out-way the benefits of reducing inventory. Another example might be the introduction of non-value adding activities at non bottleneck stations that, while wasteful in them selves, might serve to improve flow through the bottleneck.

Finally we aggressively eliminate waste from the system in order to improve efficiency while remaining conscious of two temptations:

• to use economies of scale to hide transaction costs
• drift into ‘analysis paralysis’ for fear of failure load

Technorati Tags: Kanban, Kanban Coaching

Given this it was interesting to reflect on why a Kanban approach might be right for a team or organisation looking to adopt an agile way of working.

David highlighted a number of reasons why Kanban might be the right approach including:

• Optimising an existing process is easier and more effective than trying to introduce a new one
• Provide what execs want
• Achieving high maturity

The first of these points challenges the approach that many process improvement initiatives have taken in providing new job titles, new process, new document templates and more. By contrast where an organisation has an existing process, possibly with specialisations and tooling in place, a Kanban initiative would seek to model existing workflows and expose issues leaving job titles and working methods intact. This approach is likely to meet less opposition since it cut’s less to what individual contributors care about and identify with. In addition a Kanban system should generate metrics that inform further improvements, for example to working practices. With luck, by this point sufficient buy in will have been achieved to minimise objections.

The second point cuts to one of David’s mantra’s. Exec’s, he asserts, all want the following:

1. Predictability
2. Business Agility
3. Good governance

In addition David likes to emphasise

• Empowerment without loss of control
• Self organisation without fear

Two aspects of David’s approach to applying Kanban appear to contribute a great deal to keeping these promises. The first is an emphasis on metrics. Particularly where an electronic tool is employed a Kanban system can inform a wide variety of management decisions. This is often missing where agile teams rely on a more emotional output from retrospectives. The second aspect is the exposing of policies. Many classes of issues that constrain the performance of development teams can be described as policies. Once de-personalised these can be considered with respect to the risk that they serve to mitigate and the benefit they bring as contrasted to the over-head.

And finally we come to the maturity argument. A high maturity organisation will be able to; make statistically defensible decisions, implement causal analysis and resolution and effectively deploy process improvements.

While a Kanban system will provide a rich set of metrics and enables the application of a great deal of knowledge accrued in the management of pull systems, it’s great strength (from my perspective) is process improvement. A Kanban system will make any mismatch in capacity between specialists visibile. The board can be annotated with information regarding blocking issues. But, best of all, where a blockage occurs the Kanban system will release resources to deal with the constraint.

Given this focus it seems likely that a Kanban approach may appeal to a class of organisation who see little appeal in more developer centric approaches. Kanban offers a tool set for the management of knowledge work. However, while Scrum and XP expose trust and respect as key principles these remain a choice for the manager applying Kanban.

Last month I was fortunate enough to attend David Anderson’s Kanban Coaching Workshop. Here is how David described it:

This 3 day workshop is for experienced Agile coaches, existing Kanban practitioners, and those who have previously taken David J. Anderson’s Kanban class. This workshop is intended to be an interactive collaborative session designed to facilitate knowledge sharing and learning. The class will be divided into approximately 10 sections with a slide presentation or tutorial from David to introduce each section. The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Each participant will received a personal recommendation from David J. Anderson as a result of participating in the class.

The three days were run in a very interactive style with 8 delegates including myself. Since all of the delegates were either Kanban practitioners or practicing agile coaches the discussion was both lively and in depth.

Subject matter covered a wide range including:

• Motivations for introducing Kanban
• Getting started with Kanban
• Comparing Agile and Lean decision making
• David’s “recipe for success”
• Reviewing David’s Microsoft XIT case study

Rachel Davies has already blogged some of her isights from the workshop here and I plan to add a few of my own key take-aways over the next few posts, these will be grouped under the Kanban Coaching tag.