The second, “Making retrospectives work“, is intended to to provide an opportunity for practitioners to discus their experiences in taking part in and/or facilitating retrospectives. A retrospective can be a significant investment in time, given that this is the case we have a responsibility to ensure that we get the returns that we expect. In this session I hope we will identify some common issues and solicit some guidance to help address them.

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.

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.

On Thursday Gary Jones and I 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.

Our slides from this session can be seen here

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.

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.

Iteration is a strategy for discovering a requirement by building software and soliciting feedback. By travelling through this cycle a few times you home in on the true customer need. Where there is a high degree of complexity of uncertainty this feedback driven approach is likely to be more cost effective that attempting to completely analyse the requirement.

By contrast an incremental approach involves building a part of a solution completely followed by the next part.

While iteration expects re-work and assumes the requirement is not known, incrementing can be used when the requirement is well understood and does not pre-suppose (or rule-out) re-work.

In practice we should seek to combine iteration and increments. In previous posts I have described MMFs (minimum marketable features) as a strategy for defining increments. Iteration can be used within each increment to ensure that the customer need is met.

To complicate our mental model a little we can iterate across increments. This provides us with the opportunity to respond to feedback from the market in addition to feedback from more immediately accessible customer representatives.

It is critical to think about iteration when planning a project. While some stories will pass through a single development cycles others may take 2,3 or 4 iterations in order to deliver the value they represent. A simple velocity measure does not provide for the uncertainty and variation that this can represent.

Now for the theory

The Cynefin framework developed by David Snowden described 4 different problem domains; in fact there were 5 and I’ll only consider the first 3 right now.

The domains relate to where we might choose to use iteration.

Simple – sense, categorise, respond
Simple problems are characterised by simple cause effect. When faced with problems in the simple domain we should find out the current best practice for the problem and apply the solution.

Complicated – sense, analyse, respond
Complicated problems are the domain of the expert. With sufficient expertise and thought these problems can be broken down into their simple constituent parts.

Complex – probe, sense, respond
Complex problems are different. These cannot be broken down into simple problems or solved by hard thinking. Rather we must solve these problems through experimentation and feedback.

As we seek to understand our customers needs we should consider where they fit in this classification. We waste our time if we try to analyse complex requirements. By contrast if rely in iteration for simple or complicated problems we are likely to take longer than necessary.

The best teams will learn to recognise where iteration is most valuable and where to apply analysis.

• Be rigorous with terms and definitions: Tom described that, in his experience, careful definition of terms will increase your ability to use objectives to justify decisions. This is particularly true where a document must stand alone.
• Break down objectives so that they can be represented using a single scale: we had objectives that required multiple scales such as combining schedule adherence and quality; Tom recommended a hierarchical model.

An example of one of our objectives is:

Objective: Teams are efficiently delivering high quality, high value software at the right time
Ambition
Team’s clients recognise the quality delivered and appreciate the timeliness of delivery and ability to respond. Clients see their needs met and the benefit realised through deliveries.
Scale

1. % of deliveries that meet client expectations
2. Ratio of value delivered to cost
3. % reduction in cost of delays incurred (£/week) by project teams
4. Mean satisfaction level (0-10) of project sponsors

Having identified a set of objectives we began to brainstorm the strategies, i.e. approaches we could take, to achieve our objectives. We started our with a minimal expression of strategies e.g. “Coach teams”. As we began to evaluate the impact of the strategy against the objectives we found we had to be far more specific. This included identifying how many people would be affected, what areas the coach would focus on.