Agile methods are of clear benefit while our projects are small enough to be delivered by a single small team responsible for the full life-cycle and incorporating all of the various necessary specialisms. As the project size increases we will eventually reach a state where we face a challenge since the team size becomes increasingly difficult to manage and we seek to provide internal structure through sub-teams. At this point we will typically need to establish the axis along which the team is split.

Option 1: Component orientation
In a large systems it is common to find developers who align themselves to components. This presents a simple option of splitting the team along component lines. By doing this we create a need to split user-centric features into component features and subsequently re-combine and verify the end-to-end behaviour.

In this way we have benefited from natural affinity of developers to components at the cost of lead time. The benefits of this approach will depend on the degree of specialisation and the degree to which specialisation aligns with co-location; this ownership of components by location is common in large systems development organisations. A further drawback, however, is the balance of features to components, it is not uncommon to see feature prioritisation determined by availability of component teams in preference to value, increasing the degree of generalisation increases a teams flexibility to build the next most valuable feature independent of the impacted software component.

Option 2: Discipline
By splitting a team by discipline we risk longer lead times and can easily risk further engraining waterfall like thinking such as stove-piping the organisation with a “throw over the wall” attitude.

However, all is not lost. Kanban systems have been shown to offer a model that recognises the existing flow of work while encouraging innovation to reduce lead time of features. Kanban systems have also been used successfully with teams of up to 50 people, considerably larger than the norm for Scrum or XP teams.

Option 3: Location
Co-location is known to be a strong influencer of team effectiveness. With this in mind it would be naive to ignore location in a discussion of team forming. A co-located team would be expected to out-perform a dispersed team where all other aspects are equal. However, dispersed teams can be used to good effect in order to leverage benefits of feature teams. In this situation we should learn the lessons of those who have successfully built effective dispersed and distributed teams.

Option 4: Feature
The preferred model for team structuring in most Agile methods is to orient teams around delivery of customer valued features. This model encourages increasing levels of generalisation according to the profile of the features being delivered by the team. While integration issues can still arise with feature teams the use of continuous integration will mitigate risks while feature selection can help to limit interaction between teams. Where the project size is very large or the problem domain very complex it is possible to orient feature teams around areas of the problem domain. This is what Craig Larman terms Requirement Areas. By allocating teams to requirement areas we support the team in developing their understanding of the problem space investing in specialisation on that axis in preference to specialising in a discipline or component.

Choosing and Blending
In practice we will typically mix these models in a large multi-location team combining the benefits of co-location, feature orientation and component specialisation while trying to manage the limitations of each. By way of a practical example consider an embedded system distributed across the globe. We may choose to recognise the specialisation of the team that develops the low level board support packages; this team delivers low-level facilities to feature teams. We lean towards feature teams for the majority of user-feature development. However, for high volatility or high risk features we might choose to have co-located feature teams in the vicinity of our key customer groups. This focuses the agility of co-located teams where it adds the most value.

I just checked back to see how much I’d written about MMFs (minimum marketable features). This is a technique I use and talk about a lot so I thought I’d written more that I have.

I’ll provide here a few of the ways I use MMFs and why I feel that they are so helpful when devising incremental delivery strategies.

So, first thing first. MMFs are really a business tool and are a simple technique for devising and expressing the businesses strategy for delivering some outcome. The sweet spot for this technique is in providing an escape from classical big project thinking.
The MMF describes simply the smallest set of features that could achieve some outcome. This is only useful if you have decided to operate in an incremental manner. If you would like to generate benefit (read cold hard cash) early and make decisions based on real data from experiences gained in the market place then MMFs are for you.
An MMF may focus on:

• providing a workflow, e.g. subscription for a news letter
• satisfying the need of some stakeholder e.g. generate a report
• satisfying some persona e.g. advanced user

The key to an MMF is the natural provision of a scope test. Since the first “M” is minimal we should include no feature that could be removed without impact to achieving the benefit. This rule need not be applied dogmatically. However, where I have seen the technique used to greatest effect the challenge was levied often “What if we didn’t have that feature, do we still achieve our goal?”

Using MMFs effectively relies on the understanding that there will be a series of MMFs. I’ve seen dysfunctional behaviour where an organisation had a habit of planning multiple releases but delivering only release 1.

We should remember that an MMF is not a promise to release. Rather it is a recognition that some benefit could be achieved. There are many business reasons for not releasing the minimum that could work and business motivations change over time and as the development progresses. Two examples are:

• A team with fixed release dates

This team identifies an MMF that fits comfortably into the development period and a set of desirable additions beyond the minimum. The team commits to delivery of the MMF and typically delivers a small umber of additional features from the desirable list. This benefits the business since the delayed delivery of the MMF is offset by the improved predicability.

• An organisation trailing in the market and keen to make a splash.

This organisation developed the product using MMFs. Each delivered MMF represented a deployment opportunity as well as a chance to solicit feedback. The MMFs helped provide focus throughout the project on achieving a viable product. However, the business waited until the product was competitive in the market place before true go-live.

Technorati Tags: MMF

Last week I had the pleasure of running a user story workshop for a group of very experienced folk with a broad range of backgrounds and skill sets. We convened the workshop to discuss the challenges that present themselves when we apply user stories for the first time on a real project.

The conversation was broad ranging but, since a number of people have told me that attending the workshop was valuable, I’ll try to capture some of the key issues.

What is a user story?
User stories have been described many times and in many ways, including the following:

• A requirements elicitation technique
• A prioritisation technique
• A planing technique
• A means to capture a requirement
• A means to defer capturing the requirement
• A unit of scope
• A question waiting to be asked

To some degree each of these are true. My personal favourite definition is “a promise to have a conversation”. This cuts to the heart of the approach. We use user stories to capture the need to dig deeper later. Early in a project we find out lots of desires about the end product. Many will grow into deployed features but many will never be built. Some may be valuable but turn out to be too expensive. Others may turn out to represent little value so be lost.
By having a very low fidelity mechanism for capturing requests we can see the shape of a product and the range of needs without delving into detail.

What is a story’s life cycle?
In the workshop I used Ron Jeffries model of a the life of a user story:

• Card
• Conversation
• Confirmation

Over a story’s life it will move from being an idea to being captured on a card i.e. deferred. At some point we will want to know more so we go talk to the appropriate people. We may capture this conversation in any number of forms including notes, diagrams, wireframes and examples. The final stage is to confirm that the story is satisfied. We typically capture acceptance criteria for a story before commencing development, this may or may not be automated as a set of tests. Following development we will demonstrate that the user story is satisfied.

What remains of a story post development?
We should be able to remove all trace of the story post development. Any long life artefacts will be created as a result of the story i.e. these are part of the acceptance of the story.
Stories are a poor solution to documenting a system because of their fragmented nature. One approach I have used in the past is to provide informal, live, versions of documents during development. These can be polished (if necessary) at the end of development. This approach emphasises documenting the right thing at the right time.

Who is a user story about?
User stories are written on behalf of users but also stakeholders. This means that we can express what are often referred to as “non-functional requirements” as stories for a stakeholder e.g. As the Security stakeholder I would like to use 256 bit SSL so that the site is conformant with our security policy.
We also write stories for personas, this allows us to place appropriate emphasis on the class of user who we are building the feature for and ensure that the specific user types goal is the focus rather than something more generic.

We delved into other areas I’ve written about previously too such as MMFs. I hope that this triggers some useful thinking but for me it’s always worth remembering why we use User Stories – to defer analysis until the right time while retaining a view of what the future might look like.

The slides for this session are now available for download Agile Business Analysis - Agile 2010

On Thursday Gary Jones will be talking about Agile Business Analysis techniques in E-3 at 13:30.

This post brings together some of the resources he will be referring to and other related references. If you have a favourite resource for other BA techniques please feel free to comment below.
Jeff Patton on Pragmatic Personas
This presentation from last years conference is a great place to start to find out more about identifying those differences in customer need that really make a difference to your product.

Rob Thomset – Radical Project Management
This book is where we discovered the sliders technique which provides a framework for considering relative priorities of non-functional aspects of the system.

Software by Numbers by Mark Denne and Jane Cleland-Huang
This was the book that introduced the notion of Minimal Marketable Features. This technique provides a means to realise the promise of incremental delivery of customer valued software.

Geoffrey Moore’s book Crossing the Chasm
This book describes the simple visioning exercise we use that, it turns out, provides the rails for the project helping us identify where we are going off track or experiencing a change in strategy.

Others we like include:

9 Box interview technique
Dave Nicolette describes this technique from Keith Eades’s book, Solution Selling.

Technorati Tags: Agile Requirements, Business Analysis

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.

Technorati Tags: cone of uncertainty

Thanks to Rachel Davies for sharing her approach to constructing a diagram of effects.

Rachel proposes that the diagram of effects can trigger a team to discuss how a variety of issues relate and goes on to highlight advice from Bas Vodde and Craig Larman in their first book “Scaling Lean and Agile Development”, the First Law of Diagramming is “The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.”

I have been using a slightly different approach in retrospectives recently. With a similar intent to Rachel I hope to trigger conversations that result in a team sharing there concerns and issues and coming to a shared view as to how these relate and where would be a good point for intervention.

I’ve used this approach a couple of times recently when running retrospectives that cover a few months i.e. not iteration retrospectives where we choose to commit a few hours to investigating issues in some detail.

My favoured approach is borrowed from Eliyahu Goldratt’s Theory of Constraints, it is one of the 5 TOC thinking process and is know as a current reality tree. A current reality tree is a tree of undesirable aspects of your current situation, these are connected to indicate cause and effect.

My approach to constructing this diagram is as follows:

Identify undesirable effects
Invite the whole team to stand around a table thinking of undesirable / unwanted traits of their existing approach (process, tools, methods etc.). Each item should be written on an index card and placed on the table in no particular order. Team members can try to avoid duplicats but if one pops up it is not a problem.

Begin to identify cause effect relationships
Invite the team to select two related cards. These should be stuck on the board and joining with an arrow pointing from cause to effect.

Continue to grow the diagram
The whole team should collaborate to add the cards to the diagram. When I first tried this I wondered how I would cope if groups of cards were not related. I’ve not seen this actually happen yet but should it then I guess we allow for the growth of separate diagrams until we discover a relationship.

Review relationships
In CRT literature there are a set of steps for assessing the existence and relationships between UDEs. My approach is to invite team members to consider where items are missing. Often where many causes relate to a single effect there is a missing intermediate effect.

Since I tend to run this approach in a time boxed session I an looking for the point at which returns begin to diminish. As the group settle on a basic shape and begin to look for intervention points I move to support this.

A good candidate point to intervene at would be contributing to a number of effects or participating in a feedback loop. By focusing on one effect we can select actions that will contribute to reducing this effect and by association those related effects.

Of course, an added benefit of this approach is that we can use the cause and effect diagram to review the effect of our interventions; did we get it right, if not was there something we missed in the analysis?

I hope that this is useful. Do share if you’ve used this approach or something similar yourself.

In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their approach (when working with Scrum) to prioritisation of stories by the product owner within a sprint.

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 was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.

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.

Technorati Tags: Project kick off

Take-away #3 from David Anderson’s Kanban Coaching workshop.

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