Limiting WIP (work in progress) is another of those wonderfully simple Agile principles that many of us still struggle to implement and possibly understand the significance.

It’s fundamental to Lean/Kanban, and yet explaining it through Little’s Law is dull and abstract.. so here is my attempt to make it engaging and shareable.

It's clearly something we should be trying to reduce.

Lead time is a great empirical feedback loop:

• Easy to measure - when did we start and when did we finish on a piece of work
• Represents a system-level behaviours
• Is 'impossible' to game or cheat
• Easy to see trends over time. Are we becoming more or less responsive?

So…. what is the best way to reduce lead time (cycle time)?

Little’s law

This maths is robust and applies across all kinds of systems, from the queue at your coffee shop to the progress of a feature through your team.

https://en.wikipedia.org/wiki/Little%27s_law

It’s easier to visualise this as

If you want to half the lead time

– you only have two options

– and one is much quicker and cheaper than the other

This is probably our default response and it does work. However, it will take a lot of time and cost.

This is much quicker and cheaper to implement.

It is also the reason why Kanban obsesses about it - if you are not reducing your WIP to the optimum level, then you're not doing Kanban

You can do either or both

..but the quickest, cheapest way to intervene at a system level and improve customer perceptions, responsiveness and innovation - is to reduce WIP

Tweet.

Arranging work around projects is a significant impediment to the creation of a responsive organisation. Hopefully this simple illustration shows how focusing on projects generates waste and delay – and the good news, there is an alternative. 

Clarification: Following some feedback I suggest you read this in the context of any project where value can be delivered incrementally - typically IT projects. (5th Dec)

Project-centric thinking allocates ‘resources’ to the project.  A team-centric approach takes the work to the team.

Project-centric thinking first creates the somewhat arbitrary artefact called a ‘Project’

It then attaches a number of key elements like; a budget, project manager, requirements and shares of different ‘resources’

Projects artificially create a large batch - where highly valuable features are made unnecessarily dependent, and therefore delayed, by lower value features.

When you include the other projects, the picture becomes complicated.

This complexity appears to need process to bring a sense of order and so we introduced:

• Process and gates to manage the budgeting and requirements gathering.
• Project managers to allocate resources, parcel-up pieces of work to different people and then chase them up, creating summaries and reports for stakeholders.
• Governance and steering groups reassure the organisation with a sense of control.

However each of these interventions generates waste.

A Catch 22, where both the complexity and the attempts to deal with the complexity, introduce waste through task switching, delays and non-value-adding activities.

A note on waste: I am using the lean definition of waste i.e. any activities undertaken by an organisation that consume resources but do not add value. Where value is defined by the user.

In a picture as complex as this we begin to focus inwardly on the process rather than on the user and the flow of value.

Please don’t read this as a dig at Project Managers. These activities (not the role) are systemic and have emerged through an understandable, but ultimately misguided attempt, to manage and plan our way out of complexity.

So, what does the alternative look like..

Keep the teams stable, with all the human benefits that gives us, and take the work to the team.

Stable cross-functional, co-located teams develop trust and effective ways of working.

They bring other benefits too:

• Better solutions – created from multiple perspectives
• Less stress as team can focus on their work and not be distracted
• A sense of common purpose and endeavour can raise moral, less solitary working.
• Organisational resilience as skills are spread between team members
• New arrivals can get up to speed faster and blended into an existing team. Important in organisations with increasing rates of churn
• Key-man risk can be mitigated with no isolated developers.
• Quality improves through peer review and join responsibility for code quality.

A way-of-working based on Agile principles and practices brings a simpler, calmer picture of how value flows.

A portfolio backlog is created that includes all the work to be done. Not forgetting non-functional work and those smaller nuggets of functionality with a potentially high ROI and user benefit.

Portfolio backlogs help move towards a more continuous flow of smaller batches of work.  This improves the predictability that the business craves.

Work is taken to the team.

The work might be 'accompanied' by a Product Owner who is clear about the opportunity, knows the domain and is best placed to maximise the return from the investment that is about to be made .

A single parcel of work is taken to the team.

This could be a Release lasting a few months although preferably a smaller MVP or shippable increment.  The smaller the better.

Bigger pieces of work can be given to more than one team and split down into backlogs for each team.

Note: work in the portfolio backlog is not made up of projects but of releases of projects, each of which can be shipped to live. Giving us earlier value, less risk and more predictability.

This simpler, calmer picture of work being taken to the team requires fewer Project Management non-value-adding activities, like resource planning and delegation and instead focus on value-adding work.

Governance can add value by guiding and validating work.

Further reading

If you want to explore this further then there is plenty more on the  #noprojects tag on Twitter

Alan Kelly has been talking about this for a while. http://www.allankelly.net/static/presentations/Oredev2016/Oredev-BeyondNoProjects.pdf

and InfoQ has a good article  https://www.infoq.com/articles/noprojects1-projects-flawed

Tweet.

Agile can be seen as an interplay between its two overarching goals of building the right thing and doing it properly. Although 'Interplay' is putting it positively, as they often compete for resources and spend much of the time far from a harmonious balance

The dominance of Scrum in the Agile landscape has perhaps had us focused too much on the left hand side of the picture. We’re slowly correcting this to appreciate the importance of the counterbalancing right.

Of course the more technically-aware have been working hard on this for many years. However, it’s still quite shocking just how few organisations have really grasped how important, and difficult, it is to build the thing right.

Such an imbalance is probably the fastest way to accumulate technical that we have yet invented.  

Helping stakeholders understand this picture enables them to appreciate the true Agile picture and the consequent levels of investment in skills, people and tools that are needed.

Luckily Agile has some very good and established patterns to ensure we can achieve this balanced state.  

Yin and Yang speaks of complimentary and interdependent forces in a dynamic system, just like those we try to work with in software development

Build the right thing..

Is achieved through a number of established Agile principles and practices. 

Get close to users and understand their real requirements

• The Product Owner role in Scrum, and its equivalents in other Agile approaches – clearly identify the person with domain knowledge who we can hold accountable for ‘what’ is built.
• Well established ways to deeply understand requirements e.g. User stories, Specification by Example or Feature Driven Development
• These both enable us to hear the ‘user’s voice’ amongst the complex hubbub of development
• Early, frequent validation of our deliverables keeps us aligned to expectations
• More telemetry and metrics of how the solution is actually used help to validate the solution provides us with the final feedback loop

Build better solutions through closer collaboration and on-going emergence

• Daily collaboration within the team and between the team and PO or users encourage emergent solutions, informed by multiple perspectives.
• We have found ways to unleash the creativity of intelligent people and tapped into the collective, focused purpose the team.

Don’t begin to develop software that is not properly understood or may become blocked

• Definition of Ready (for development) ensures we don’t start to work on requirements that we don’t understand or are too big or ambiguous.

Align overall development capacity to changing organisational priorities

• Portfolio Backlogs act to align development capacity with the organisation’s evolving priorities in a single place, transparently.

And.. the Agile Manifesto says

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”.
• “Business people and developers must work together daily throughout the project. “
• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Build the thing right

Summarises the technical rigour that many organisations appear either unaware of – or find too difficult to try.

Prevent bugs or find them quickly when cheaper to fix

• Test Driven Development, Continuous Integration help to prevent defects – or find them rapidly
• Cloud-like technologies mean we can finally afford to do performance testing earlier in the process

Keep focus on the code quality

• Peer review of code, clear coding standards and pair programming help to move good practices around a team and establish accountability amongst peers for the work they are doing. This is much better than trying to ‘police’ the quality by an architect or other external role
• Code quality tools like SonarQube track key trends, like complexity or maintainability, over time. Alerting us to any negative drift in the trends of complexity and maintainability.
  • If I were using outsourced teams, this would be an easy, transparent and fair way to hold them accountable for the quality of their work - and yet so few companies do this.
• Refactoring and principles of ‘internal open source’ also help to maintain the focus on code quality.

Make the solution resilient and adaptable

• It is certain that the solution will evolve over time. Well documented code, wrapped-up in automated testing is a fundamental pre-condition to that process of evolution.

Focus on finishing high quality work

• The team’s ‘Definition of Done’ and Scrum’s emphasis on shippable quality every sprint helps to embed quality in the team’s daily work.
• Slicing work up into small chunks means we get more of into the done column more frequently

Building it right, through to live

• The ability to reliably deploy the solution into live is a key part of building it right.
• The automation of testing, build, environment-creation, configuration and deployment are relatively new though already indispensable set of disciplines and capabilities.
  • All brilliantly summarised in Jez Humble’s book ‘Continuous Delivery’

And.. the Agile Manifesto says;

• “Continuous attention to technical excellence and good design enhances agility. “
• “Simplicity - the art of maximizing the amount of work not done - is essential. “
• “The best architectures, requirements, and designs emerge from self-organizing teams”.

A living backlog needs a strong internal structure (skeleton) in order to effectively guide a project and maximise the value delivered to users.

That structure enables the backlog’s primary purpose of alignment to the business with a clear sense of priority and delivery sequence.

• Time and priority to know when value is likely to be realised and the relative priority of work. Using Iteration Paths
• Business-centric to enable stakeholders to guide development and understand the evolving scope. Using Area Paths

A ‘living backlog’ is one that:

• Guides decision making, identifies risks and possible opportunities
• Is comprehensible to all stakeholders and is ‘prioritise-able’
• Provides a solid basis for metrics to answer the question ‘are we on track?’
• Is up-to-date and can incorporate emergent changes in scope
• Reflects the different streams of work including: planned (project), BAU, Support and non-functional work

As opposed to many of the backlogs I see, which feel more like a necessary but unloved artefact to be dragged along by the team.

The four dimensions to structure and slice a backlog in TFS are:

• Iteration paths to provide a time and priority-based view
• Area paths to provide the business with a recognisable perspective that will inform decisions
• The work-item hierarchy (e.g. Goals-Features-PBIs) to align to the business case
• Tags to flexibly ‘cross-cut’ the backlog thematically

Iteration paths

The Iteration path enables the creation of burn-up chart for the next release / deployment and therefore key to be able to answer the key question:  Are we on track?

Well planned and maintained Iteration paths enable a simple burn-up chart like this.

This chart is from our www.senseadapt.com collection of simple visualisations for TFS. For more see my previous blog on the 'Landing Zone' chart

Deployments to live might be a regular cadence of monthly /quarterly drops, with a preference for more frequent, smaller batches.

Three ways to use Iteration Paths

Kanban

In a Kanban-like approach each Iteration represents a ‘bucket’ of functionality to deployed.

1. Release 15.8
   1. PBI_1 to PBI_n
2. Release 15.9
   1. PBI_1 to PBI_n

Scrum

Teams using Scrum will include the sprint iterations within the iteration for the release/deployment

1. Release 15.8
   1. Sprint 1
      1. PBI_1 to PBI_n
   2. Sprint 2
      1. PBI_1 to PBI_n
   3. Sprint n
2. Release 15.9
   1. Sprint 1
   2. Sprint 2

Mature Agile

Teams who deploy frequently will benefit by using the Iteration path to manage their different release horizons, for example:

1. In the next month
   1. PBI_1 to PBI_n
2. Within 3 months
   1. PBI_1 to PBI_n
3. 3-9 months
   1. PBI_1 to PBI_n
4. Probably never
   1. All the rest of the PBIs

The ‘probably never’ iteration is a useful parking spot for PBIs that are unlikely to see the light of day – but which stakeholders get twitchy about deleting. This keeps them out of the metrics and maintain focus on the more valuable PBIs

Work-item Hierarchy: Goals – Epics – PBIs – Tasks

These can be used to align the backlog to the original business case

• Goal: the business or technical goal that we are trying to achieve
• Feature: large stories or logical collections of PBIs.
• PBI: (Product Backlog Item) – the value-carrying piece of work that will be tracked through to live.
• Bugs: can either be linked to PBI or Epic
• Tasks: The actual work that needs to be done to deliver a PBI (mainly used in Scrum)
• Tests: linked to a PBI or Bug

Note: Your work-items may have different names from those above.

Area Paths

A living backlog must actively engage business stakeholders and the Area Path is the best way to do this.

Area Paths provide a recognisable, business-centric structure for the backlog. The structure will vary by type of project, see the three examples below.

Talk through the best structure with business stakeholders, as this is their window into the project.

The Area Path branches enable rolling up of PBI data. A simple way to show the relative effort and progress for a particular aspect of the project.

Area path by stakeholder

In the example below the money to fund the teams comes from the business divisions. The HR stakeholder naturally wants to quickly see a summary, including progress, of all the work that she is funding.

There will also be non-functional work e.g. automation of testing and deployment, which should have its own Area Path, if it does not relate to a specific top-level stakeholder.

1. Marketing
   1. CRM
      1. Campaign content
      2. Campaigns
   2. Planning
   3. Tracking
   4. Advertising resources
2. HR
   1. Recruitment
   2. Reviews
      1. Permanent
      2. Contractor
   3. BAU
3. Sales
   1. BAU
   2. CRM
      1. Prospects
      2. Clients
      3. Brokers
4. Non functional
   1. Automation
      1. Testing
      2. Build & deployment
   2. Refactoring
      1. Decommissioning system x
   3. New API for brokers

Area path by user / role

In this example from an online retail application, the Area Path is used to slice the backlog by role.

1. Marketing Manager
   1. Planning and reporting
   2. Managing range
   3. Managing Product
      1. Import new products
      2. Archive older products
   4. Promoting
      1. Promote a range
      2. Couponing set-up
   5. Managing content
2. Customer delivery assistant
   1. Preparing for delivery
   2. Delivering customer orders
      1. Taking payment at door
      2. Getting customer feedback
   3. Returning to depot

Area path by functionality

Here the Area path is used to slice up a product like Outlook, by functionality

1. Organise Email
   1. Search Email
   2. File Emails
2. Manage Email
   1. Compose email
   2. Read email
   3. Delete email
3. Manage Calendar
   1. View calendar
   2. Create appointment
4. Manage Contacts

Tags

Tags are great at thematically ‘cross-cutting’ the backlog.

For example:  all PBIs that relate to a compliance strand of work; PBIs that use a specific technology; PBIs that have dependency on a third party service

A word of caution:

• Tags are not easily delete-able. You need to first remove them from every item, then wait a few days for them to be cleaned out of the database. See this description of tag-cleansing process 
• it’s easy to duplicate or slightly misspell Tags, leading to consistency problems

Use a ‘Two Dimensional’ backlog

A ONE dimensional backlog is a simple, powerful way to prioritise work however they are tedious to review and difficult to comprehend.

A poorly understood backlog makes it difficult to see opportunities and deliver more value from the project.

A TWO dimensional backlog is simple way to show both the time aspect of the project and the functional / business perspective.

• Time (iteration paths) are shown down the side
• Functional / business (area paths) are shown along the top

Add some colour and shapes and it becomes multi-dimensional. The chart above uses colour to show the state of the PBI.

Below the size of the pie chart shows how much work is in each area whilst the colours show the state.

The two dimensional backlog is analogous to ‘Story Mapping’, a popular technique for gathering requirements for Agile projects. See http://jpattonassociates.com/user-story-mapping/

I urge to read Jeff’s book, it’s a great summary of better ways to gather requirements.

Later blogs will look at monitoring the health of the backlog, what are the vital signs that you should be aware of.

Tweet.

Are we really 15 years into Agile and still failing to master one of the foundational principles? That is to use data to provide frequent, actionable feedback loops. Most teams still rely on the most rudimentary of metrics… velocity and burndowns.

We know we can only deal with the complexity of software development by using, ‘inspect and adapt’ cycles. We have collected lakes of data in every TFS, Jira and Rally instance and yet most of it remains as clear and useful as a stagnant pond.

Metrics are tainted by years of association with ‘governance’ and of being used to feed the ‘process Gods’. The idea that the individuals within teams might actually benefit from this insight seems to have been overlooked.

SenseAdapt is a collection of simple visualisations that enable teams and stakeholders to sense what is going on in their system and adapt it, in order to deliver more value.

Our aim with SenseAdapt is to bring objectivity and help create a shared, common understanding of what is going on. The conscious and sub-conscious motivations of team members, project managers and stakeholders too often clouds the picture.

The visuals are being used by three of our largest clients and continue to evolve rapidly with their feedback.

Data-based, Actionable Insight

• Data-based
  • We utilise the data that teams are already collecting. Although, now that that data benefits them, there is more reason for them to care about its quality
• Actionable
  • Just one click away, or on a dashboard, and displaying the real-time data
• Insight
  • Simple, comprehensible visual representations
  • Relevant as it shows how the system is behaving right now, not just retrospectively

Note: SenseAdapt continues to evolve. Please get in touch if you would like a demo or join our other clients in trying it on site. For the moment it is free – in exchange for your feedback.

Team-Facing Visuals

Used through the day, possibly in a dashboard, and draw attention to the parts of the system that need action. For example; PBIs (Product Backlog Items / user stories) that have got stuck or forgotten, the levels of WIP per person, the number of unestimated or PBIs that are too big.

The visuals also provide useful input into the retrospectives.

WIP by person

Highlights who is overburdened in the team and therefore needs to complete a few items of work – rather than continue to start new items.. i.e. adopt the ‘Stop starting, start finishing’ mantra. Could be used at the daily stand-up

Cumulative Flow Diagram (CFD)

Shows the behaviour of the system over time, the bottlenecks, levels of WIP and lead times.

Requirements readiness

Draws attention to the PBIs that need to be refined, sliced smaller or estimated. The chart shows the numbers of PBIs of each size, and their state. It clearly shows the unestimated stories as well.

Sprint (Iteration) burndown

This is better than the commonly used sprint burndown, as it shows the rate that the team is actually completing stories – not just tasks.

This example shows a typical anti-pattern of last minute closing of stories in a sprint. The story burndown, in points, is shown on the right hand scale, with task burndown on the left.

The use of live data means that this chart can show an ‘intraday’ burndown

Backlog health

Shows whether PBIs are in the correct Iteration Path or Area Path (when using TFS).

Most metrics are driven from the Iteration path, therefore PBIs in the wrong iteration can lead to a misleading picture and incorrect forecasts.

This is toggle-able between Iteration paths (above) and area paths (below)

PBI Staleness

Teams quite often come to overlook PBIs, which may stall in a particular state or just be forgotten, this particularly the case if there is a lot of WIP (Work in Progress).

This chart draws their attention to PBIs that have not been amended for and need some attention.

Business-Facing Visuals

These charts help stakeholders understand where the project is and when or what options there are for intervention.

Live project data – one click away. Each saved chart has its own URL that can be emailed or held in a project page or wiki.

They help to keep stakeholder expectations realistic and aligned. Significantly more informative and transparent that opaque RAG updates, which hide as much as they reveal and remain largely subjective.

Burn-up / Landing Zone

The burn-up clearly shows the range of likely delivery dates of a project. The example below is from a client with two teams totalling 20 people.

The project is likely (we deal in probabilities) to land in the shaded green ‘landing zone’. It’s clear, in this example, that one of the key risks to the delivery date is the rate of increase of the scope.

o

This forecasting is based on standard deviations from the mean , which can be varied by the user, using more or less history in the calculation of the mean and choosing how many standard deviations for the forecast.

Most teams have settled for burndowns and velocities which offer far less insight and awareness of possibilities. See my other post for more on the Landing Zone

In the near future we will use Monte Carlo (see below) simulation to model and forecast both the scope and the throughput rates.

Feature Progress

Shows the progress of PBIs within a feature. Business stakeholders can clearly see the relative size of features, as well as the progress.

Release Treemap

Shows the status and relative size of all features. Clicking on any feature will show the same for its child PBIs. Features and PBIs can be opened directly in TFS.

Simulating the future

Thought leaders, like Troy Magennis, toil on the edge of our Agile consciousness, promoting ideas that we should all have embraced in a heartbeat – specifically that the data of how our systems have behaved to date is the best predictor of how our systems will behave in the future.

His website and blog Focused Objective makes a very strong case for this approach.

Essentially, if you want to predict when a project is likely to land, you need to:

1. Create a mathematical model of how your system, whether a single team or a programme, has been behaving historically, based on the actual data
2. Then take the remainder of your backlog and run it through that model thousands of times, giving you a frequency distribution of the possible dates it could finish.
3. Use that range of dates to engage stakeholders and start discussions about what could be done to land the project successfully.

After 10,000 runs the output looks something like this.

We will write more extensively about the use of simulation within SenseAdapt in later blogs.

Tweet.

I’m embarrassed to admit that, as a long time Agile coach, I hadn’t appreciated the benefits of burn-up charts over burn-downs, merely seeing it as a mirror image - I was wrong.

However it has brought me to this metaphor of landing the project in a zone where two joysticks, held by different stakeholders, guide in the project (or MVP or ‘next release’). The PO (business) holds the scope ‘joystick’ whilst the team adjusts the ‘throughput rate’.

Being co-pilots in this joint endeavour helps foster collaboration between the two ‘sides’.

i find that the most insight-generating metaphors are simple and incorporate a familiar aspect of our physical world.

Make the most of the historical data we have

Our historical data of ‘completed work’ shows the rate of delivery (velocity). Which we can extrapolate into the future using pessimistic and optimistic rates.

A vertical line down from where these cross the scope line, gives us a date range that this project will finish. In this case I’ve assumed the scope doesn’t change after today.

The angle of those pessimistic and optimistic throughput rates is largely determined by the team and overall system effectiveness.

Note: We currently use simple calculations to decide the angle, e.g. optimistic (median +25%) and pessimistic (median – 25%). Alternatively a moving weighted average works well too.

Not forgetting the ‘S curve’ that David Anderson writes about here

This shows there is often lowering of the throughput rate in the last 20% of a project – assuming that the definition of done was not quite perfect – which is common!

We are also developing projections based on ‘probabilistic forecasting’ and Monte Carlo simulations to provide more clarity on the likely outcomes. Troy Magennis has been leading this approach in the Agile world – this video is a great introduction

Step 2 – Scope evolves

We know the scope line will probably continue to drift upwards, in fact there are probably two future scope lines:

1. The desired scope that was in the business plan and stakeholders thought was necessary when the project was first conceived.
2. The minimal scope, or MVP, that would deliver value to users, generate learning and is a viable delivery.

We need to develop better ways to model this change in scope, however we’ve all seen this in projects, even if the root causes vary.

There are two possible date ranges within which this project will go live.

• Minimal scope = mid-June to early-August
• Desired scope = mid-July to mid-Sept

The Landing Zone

It’s easier to visualise and to say, with a fair degree of confidence, that the project is going to land somewhere in this green zone.

Representing the truth in this comprehensible, palatable way stimulates many more possible interventions, for the team and business, than a RAG status ever could!!

Options to hit an immovable date

To be confident that we can launch at that conference in mid-August, we can see what options we have to reduce scope to come within the pessimistic line.

It’s also clear that we will at least have the MVP by the conference and possibly a little more.

A client recently told me of some members of a development team saying how they couldn’t see the value of adopting Agile. It’s not uncommon to hear similar sentiments in many teams.

This got me thinking about how we often externalise the indefinable in order to; understand it, sell it, master it and sometimes resist it.

The common coaching attempt to reposition Scrum/Kanban as a ‘framework’ rather than a ‘process’ doesn’t come close to the visceral resistance (fear) we feel to something ‘other’, that is outside of us.

The real challenge is not one of semantic classification, but of human self-identification and engagement.

In essence this is about our ‘way-of-working’, something we are fully immersed in. Like being in water, we can’t push against it. This is what we do, hour-to-hour – it’s not external to us… it is us. And that’s the quasi-Zen bit**.

That Kanban board over there is merely a reflection of the way we currently work – it’s not ‘a process’. If it’s not an accurate representation – let’s improve it.

If it turns out that my way of working is less than perfect, and I find myself wasting time then what could I do to improve the situation. [Hopefully we move to replacing ‘I’ with a team ‘we’… but ‘I’ is where it begins.]

When it comes to Agile principles there is no external 'process' unless you choose to define one. Scrum, Kanban or XP are merely instantiations of those principles – they bring those principles to life.

We need to find a way for people to see beyond their own work and to the results of their collective efforts with others. After all, the ultimate purpose in our work is in delivering value to users – and that usually requires other people.

I’m keen on ‘optimising the whole’ and ‘Systems Thinking’, however that too is a form of externalisation and should be introduced carefully.

My current (June 2014) , evolving recipe for Agile adoption is:

• Blend Agile principles into your existing way-of-working, at a rate they deliver measurable improvements and are ‘digestible’ by the individual and organisation
• Catalyse the evolutionary process with a sense of urgency and in a clear direction – the ‘True North’ vision
• Whilst keeping it safe to learn and recognising those that share their learnings.

And what I would say to a team is:

• ‘Let us try to improve the way-we- work in order to reduce waste and frustration. ‘

This probably comes across as a negative perspective – and yet, I think it evokes a particularly powerful emotion in us – because it’s based on actual feelings.

A more ‘positive’ perspective like, “deliver more value” arises from abstraction that doesn’t resonate as deeply or evoke emotion in me. As an individual I can’t influence (on my own) the behaviour of that system – and so, whilst I might recognise it as a laudable goal, it doesn’t impel me to action – at least in the early stages.

Whilst there is positive emotion associated with recognition of a job well done or in the sense of completion when one puts something in the ‘Done’ column, I think the ‘negative’ is more likely to stop us tolerating the status quo.

** I am in no ways a Zen practitioner, however I did find these ten Zen principles have some resonance with Agile principles: Awareness, Present Moment Focus, Non-judgment, Acceptance, Validation, Tolerance, Compassion, Invitation, Patience and Practice http://www.drnataliemasson.com/TenPrinciples.html

Apologies if by the end of this you saw it as a thinly veiled attempt to blog a catchy title (See Zen And the Art of Motorcycle Maintenance http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance )  However, there is something illusive about this topic which requires a certain contemplative mind-set, which is another aspect to that I was trying to convey.

Tweet.

Portfolio-level prioritising is fraught with problems… ambitious senior stakeholders, promoting their agenda, rarely meeting together to see how their projects compare to others resulting in a portfolio in continual flux – and not a little distrust.

Such vague, contradictory, fluid priorities at the top trickle down through the whole organisation… generating waste as they go….

Getting a stable, visible and well prioritised portfolio backlog is a key step towards successful Agile adoption.

Prioritising by ROI or a strict financial measure does not work – even though we wish it did and keep trying to make it so – an army of commercial accountants couldn’t set enough rules and then get everyone to play by them.

The underlying challenge

The real challenge is not whether to do a project – but which one to do next.

i.e. this is about prioritising, not about getting a business case signed off.

Every client I’ve worked with in the last seven years has had more than two years of projects with over 100% ROI in their backlog i.e. they would all pass the business case test.

The other challenge is to keep the business focused on the most valuable projects – and minimising Work In Progress (WIP).  The easiest way to keep insistent stakeholders at bay is to at least START their project… spinning up more and more WIP as we do so.   

Value is not enough

The value of an Epic (slice of project) or MMF (Minimal Marketable Feature) itself is not enough. Some valuable work is trivial to deliver, whilst another is costly – so our approach needs to quickly identify those with a high value:cost ratio – and get it moving through the system..

The value / cost ratio is the key– and we decide what constitutes value and cost – which means we can include some less tangible elements, like risk. We can also find a way to include ‘gut instinct’, which factors in our experience.

The ranking needs to be simple, quick, objective (as possible) and transparent.

The process itself adds value

The process encourages conversation and adds insight and understanding between stakeholders – this is not the wasteful process that some have suggested.

This approach helps to ensure the conversation at least starts from the same place – i.e. with a common understanding of what we are trying to prioritise.

No business should make a decision purely on such numbers – however, this weighting process at least allows for comparisons to be made.

How to get to a usable value / cost ratio

Both value and cost are made up of several elements, customised to the specifics of a company or programme.

For example, one of clients use the following:

These are then weighted by the stakeholders, depending on importance , with weightings adding up to 100.

Each element is given value of; 0,1,3,5 or 7, writing the text in the boxes is another valuable process for stakeholders to discuss and agree on.

This element score is then multiplied by the weighting to give an overall value score for that Epic or MMF.

For example:

Epic 1 ‘Remove step in the basket checkout journey’ scores;

• 3 for ‘strategic alignment’,
• 7 for ‘customer experience’
• 5 for ‘cost of delay’

giving an overall value score of 3x65 + 7x 35 + 5x10= 440

Whilst the cost is:

Epic 1 scores:

• 5 for effort to develop
• 1 for technical risk
• And 0 for architectural

Therefore Cost = 5x50+1x30+0x20 = 280

Giving an overall value / cost ratio of 1.57

All the epics can be summarised in a table like this..

At a glance we can see that Epic 3 gives us a greater return than Epic 1 – even though 1 has an overall higher value. This data is easily presented and understood by senior stakeholders.

It’s easy for one stakeholder to see what rankings have been given for an epic and to drill into the assumptions behind it and so we get discussion, trust building and a better decision.

The benefits are clear:

• The assumptions being made about value and cost are made explicit
  • Asking why someone gave a 5 rather than a 3 quickly surfaces the underlying assumptions – and starts a valuable conversation.
• More visibility, and multiple perspectives means better decisions and stronger buy-in to those decisions – and a more stable backlog
• It’s quick – and there’s room for valuable instinctive ‘gut feel’ judgements
  • Rather than in overly (misleadingly) precise financial models
• It results in a single number that can be used for an initial prioritising of the backlog
  • Stakeholders can then adjust the order for dependency, or other business reasons that may not be in the model.
• Coming up with model is itself an useful step for senior stakeholders –
  • What are really the key components of value and their relative importance
  • Likewise for cost, there is a now a way to factor in risk and architectural impact and dependency and not just effort.

A way to calculate value delivered – another illusive metric

Having derived a value of an Epic it is now possible to begin tackle one of the most difficult questions facing an organisation or programme:

How much value have you delivered in the last quarter?

It’s now possible to total up all the epics delivered and their accumulated value and follow the trends… It’s true we don’t have an absolute value – but the trend does tell us something useful..

Note : Typically we have used to prioritise the MMFs and ‘Epics’ (slices of project) whilst in principle it could be used finer-grained user stories, the process would probably need adapting.

Tweet.

The simplest illustration of the benefits of focus must be this one – clearly illustrating that if we focus on _and finish_ one feature (or project) at a time then all 3 features are delivered quicker.

Agile emphasises delivering value sooner – in order to generate revenue, create lessons and validate assumptions.

1. In the ‘current situation’ all three features are started as soon as they are requested – but none are finished until near the end.
2. Focusing on one at a time means that A and B are delivered value sooner in the second example
3. However, many studies (e.g. in Tom DeMarco and Tim Lister’s book ‘PeopleWare’) show that there is a real cost in switching between tasks.
   Therefore, assuming a saving of only 10% – we see that all three features are delivered significantly sooner. This is not just a marginal gain, it could translate into weeks of additional sales.

As well as the benefit of earlier value and lessons – don’t underestimate the energising effect on a team that delivering A, and knowing it’s in the hands of users, can bring. Focus increases the ‘realness’ of the work and sense of achievement and recognition that the team.

Focus also means more collaboration within the team, which can only bring a better solution – creatively built from multiple perspectives.

The intuitive assumption is that the sooner we start something the sooner we finish it…

… the real challenge is how to adjust the behaviour that’s driven by this assumption, which often recurs at every level of the organisation.

Tweet.

Many turn to contracts as a way to reduce risk. Agile has several alternative, and proven, was to reduce risk. This blog outlines shows how to get from a contract to an ordered list of clear requirements and why that is a better way to define what functionality your customers would value – and then deliver it.

The following recipe can take us from that contractual mind-set to a more palatable Agile one.. by reducing the bitterness of risk.

Step 1: Take one contact (any size will do)

… and flatten it out to see its many pages of requirements..

Step 2: Go through document identifying the specific requests for functionality and value. Shade the more  important / valuable requirements in a darker shade.

Step 3: Boil off the narrative – to be left with the essence of the requirements. Making it easier to read and comprehend. As independent elements in a list they are also easier to keep fresh – with minor clarifications, instead of having to reissue multiple versions of a document.

Risk reduction: the requirements are more easily comprehended in this form – free of the padding narrative, and sometimes semi-deliberate obfuscation, in a document. Stakeholders can get a better idea of what is being delivered – further helped if we use a visualisation technique like story mapping. Hence reducing the risk of misaligned expectations.

Step 4: Further refine requirements for readability – by writing them in simple, non-technical English, from the perspective of a human user and understandable by everyone. – i.e. user stories.

Step 5: Disambiguate* by paring down stories with the use of clear acceptance criteria

(* yes, disambiguate is a word http://dictionary.reference.com/browse/disambiguate)

Step 6: Line up your requirements/stories with the most valuable at the top –defining valuable in whatever way makes sense to your business… it’s not just about money and revenue Risk reduction: The requirements are clearly prioritised, allowing stakeholders to see and question earlier decisions, thereby reducing the risk of abrupt changes of strategy and direction. Risk reduction: Developers work down the list from the top, making sure the most important functionality is delivered first. This is very different from when a developer team is given a document of unprioritised features, where they may choose to tackle the riskiest or most intriguing part first.

Step 7: Start to deliver the most valuable stories first. Note we say ‘deliver’ not ‘build’ or ‘develop’ or ‘code’. 

Focus on the first shippable slice of functionality – and get it to your customers as fast as possible, to deliver value, learn from feedback and validate your assumptions. This is usually called an MMF (Minimal Marketable Feature) or (MVP) Minimal Viable Product – as advocated in ‘Lean Startup’.

Step 8: Continue to slice the stories down to clarify and ensure you can deliver several (5-15) every iteration.

Alastair Cockburn’s Elephant Carpaccio http://alistair.cockburn.us/Elephant+Carpaccio+exercise is a good recipe for this

Step 9: Slice the stories vertically – so that a user can validate the work and give feedback to the team. Slices should be end-to-end, going through each layer of the cake.

(Excuse the mixing of cake and elephant Carpaccio imagery there.. but you get the point – cake Carpaccio would crumble)

Avoid slicing horizontally i.e. spending 4 weeks building out all the database first – because that doesn’t deliver any value or even prove that the functionality works

Step 10: Working down the list from the top the business may decide that they have enough functionality to go live. You may not deliver the lowest value elements – and that’s great. If the dish is good enough to eat – why waste time and money on that last bit of seasoning… (OK, that might be stretching the recipe analogy..) Risk reduction: Avoid building the low value features which will probably never be used. Save the money – twice - firstly to build it and secondly to maintain it, for ever. Risk reduction: By properly finishing work as we go along, like a good chef, we aren’t left with a huge amount of un-estimate-able testing (washing up) at the end. This significant unknown (unknowable!) risk of back-end testing is almost eliminated with good engineering practices. Allowing companies like Flickr to deploy to live many times a day.

Note: Whilst you _could_ start with a contracted document – a far better place is a user story workshop, with actual users writing stories onto cards. These are much quicker, more energised and almost certainly generate a better set of requirements to start the project with.

There are many other ways in which Agile reduces risk – this blog has only looked at a few of the upstream contracting elements.

Whilst this recipe won’t guarantee a good experience, hopefully it illustrates how the contractually minded a new perspective on risk management in software development.

Tweet.