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.

The delivery pipeline is an idea which resonates with our clients. The simplicity of the metaphor and the truths that it reveals make it a compelling message to share with others in the organisation.

The pipeline helps to visualise two key Lean principles; seeing the end-to-end value stream and ‘optimising the whole’ http://bit.ly/ImpLean It illustrates the emerging emphasis on Continuous delivery’ http://bit.ly/CDAgile

The overall organisational aim is to balance the pipeline, as any constrictions generate waste.

The pipeline helps with the key challenge of getting senior stakeholders to prioritise and budget the money, and time, to balance the pipeline end-to-end.

Instinctively, because developers create functionality then, if we want more functionality, we must need more developers. Whilst jarringly simplistic, this is a perspective held by too many senior stakeholders.

However, adding more developers or teams, immediately leads to an imbalance in the capacity of each section. More development teams develop more code, which we then try to force through the lower environments – where it sits, wastefully, in queues or trying to muscle its way past other projects waiting for a limited slot in a integration test environment.

In addition to the waste, the quality plummets due to the stress of trying to get work through this constriction. A situation that is often made worse when these downstream environments are shared with other projects / programmes.

Similar constraints usually exist upstream of the developers. The Product Owner role is new to most businesses and the level of on-going work they need to do is often underestimated. Beyond the responsibility for preparing stories every sprint, collaborating with the team on a daily basis, POs need to actively engage with stakeholders and users.

The diagram below illustrates the actual capacity of the pipeline, which can be quite an attention grabber. It’s troubling for senior stakeholders to realise they are paying for all that under-utilised development capacity.

Steps to a balanced pipeline

Step 1: Communicate the need of optimising the system end-to-end

Use the pipeline diagram to communicate the essence of the challenge. These issues are difficult for even IT people to see and understand, even though they live with the stress of these systemic shortcomings on a daily basis. Create a sense of urgency by providing estimates of how much this waste is costing, both in money and in delayed value to customers.

Step 2: Prioritise and target specific interventions at the points where they will have most impact

• Investment in the environments, automated testing and deployment tools to ensure frequent/continuous movement of software through the environments to live
• Improve the quality and frequency of collaboration across traditional organisational boundaries, e.g. between developers, service introduction, support and infrastructure.
• Improve ways of working upstream between Product Owners, stakeholders and the teams. A clear vision with stable portfolio backlog is more likely to create a steady flow of high priority work into the development teams.
• The teams themselves can improve quality and throughput by adopting Agile/XP technical practices and working more closely with both the product owners and the ‘downstream’ teams.

Step 3: Visualise the waste with a value stream map

Visualisation and quantifying of the waste is key to building a sense of urgency for change and then targeting interventions at the most wasteful sections of the pipeline.

Value stream mapping is the simplest and most effective way to identify where the biggest queues and worst bottlenecks are in the system. The best resources on value stream maps are Mary Poppendieck’s books, including Implementing Lean Software Development’ http://bit.ly/ImpLean

Real-time visualisation of queues is best done with Kanban techniques, which can highlight emerging issues in the system.

Step 4: Get senior stakeholder support and the budget and time

The level of investment needed in environments and tools are often new to a business, which may not be clear on the sizeable returns available. These returns are often in the form of reduced waste, which many senior stakeholders can’t see or evaluate – even though they can sense waste all around.

A senior director estimated that 50% of their software development expense was wasted. How have we ended up accepting, or not able to deal with, this level of waste?

A smoother flowing pipeline also reduces cycle time, meaning that profit-generating functionality is deployed sooner.

Whilst getting the budget is difficult enough, ensuring the work actually gets done, month after month, is even harder, given the prevailing culture in many businesses.

Businesses and managers are rewarded for delivering value to customers. Few businesses reward managers for improving the capability of their system to deliver value.

It’s common to recognise the sacrifice in fixing problems – rather than rewarding those who prevented the problems in the first place.

The ‘non-functional’ work needed to improve system capability is difficult to value and prioritise in any company-wide backlog of work. Those that understand the potential benefits of a balanced pipeline need to articulate that value and be prepared to be held accountable for delivering the promised benefits.

This cultural bias, towards delivery and not improving the means to deliver, continually sabotages attempts to balance the pipeline.

Step 5: Expect resistance and be in it for the long haul

The value stream maps highlight that many constrictions occur at existing boundaries within the organisation. The delay, hand-offs, lack of visibility and accountability at those boundaries are the biggest challenge to creating a balanced pipe.

These changes to what people do, how they work with others, changes to accountability and their daily work will generate resistance.

Specific action is the best way to ignite the change. People on both sides of the boundary typically suffer from its existence and are often keen to improve the situation.

And… it’s not just the pipeline… but the shape of what you put down it..

In addition to working on the pipe itself – the throughput will be significantly improved by looking at the material going through it. This is the subject of a follow-up blog, where we’ll look at batch size, variance and work-in-progress as key variables.

In the meantime, Mary Poppendieck already has some good insights on this at http://bit.ly/LeanPipe

Tweet.