Where am I...

So right now I'm working out how to pull my different posts and blogs together into one place. Mostly I write on LinkedIn these days, but maybe I should bring this back to life again, rather than move it : )

Still here, still Agile.

Transformation troubles and non-technical debt

Technical debt if not managed can end up becoming a critical factor dramatically slowing down future development and in some instances has lead to whole-scale system re-writes just to keep products maintainable. The flip side is that by taking that "loan" occasionally, often a quick win can be leveraged to enable a new product to be born, a market opportunity to be captured or a deal to be won.

The sad thing is that for the last several decades most corporations have been choosing those "easy solutions" in their operational space. Individual departments have bought their own software to solve their own problems whilst not really worrying about integration with other areas. Others have home grown their own processes without considering the "customer" journey (try a value stream mapping exercise in a finance department!). And many have created products and KPIs that predominantly meet internal company goals rather than external customers and market requirements.

As this has been going on, these companies have become larger. What once was a "point fix" is now scaled up to become an integral part of the organisations processes. What once was seen as "a little bit of extra admin we can live with" is now a part of an oppressive organisational culture. What once was "for now we think we know what the market needs" is now the hand on the rudder of the organisations product roadmap. Scaling anything is an effective way in seeing where all the inefficiencies lie and where the limiting factors are - just try driving 70mph on the motorway when it is full of other traffic on a Friday night.

So our organisations processes and culture are actually just like our technical code-bases, after-all a code-base is just a written version of a load of processes and behaviours. Well-maintained code is easy to understand and easy to enhance or change; and the term "well-maintained" normally means re-paying any technical debt "loans" on a regular basis.

We all live in an imperfect world though and the point that organisations come to decide they need a "Transformation" is normally because the non-technical debt (or cultural / organisational debt if you prefer) has become such that product delivery is slowed/stuck, innovation is lacking, processes are overbearing, staff are unhappy and often shareholder value is slipping as a result.

Barry O'Reilly wrote a piece about Explore vs Exploit organisations, and the above situation could also describe the "Exploit" organisations who have got towards the end of wringing their current market dry but are not able to explore new markets due to their internal culture and constraints.

So where does this take us?

Large consultancies are often brought in to help manage large Transformations and amongst them (and elsewhere) are people who will give projected financial improvements as a result of their prescribed transformation. "You will develop product this much faster/gain this many new customers, so it's worth £X million." however the 'cost' is often not really quantified. Nik Silver wrote an interesting article on the cost vs value of paying back technical debt and I think the same broad principals can be applied with organisational debt too.

Nik neatly suggests that you can model the payback point of stopping product development to fix technical debt. This is based on the velocity of product development beforehand and the "boosted" velocity afterwards as a result of the debt being paid (vs just continuing without the fix).

It's worth noting that the break even point is well after the period of activity of "solving the problem", so if we apply a similar mindset to Transformation we should not expect a net gained benefit until some time after we are done Transforming.

Of course whilst that makes perfect sense from a benefit delivery perspective in a product development domain, in the organisational domain it could be shaped a little different as the benefit over time is probably already diminishing rather than being steady (hence the need to "fix things") so it could look like this:

Also you won't find any Transformation agents telling you that you wont get any benefit during the transformation process (or you wouldn't sign up to it would you) but recognise that the overhead of "change" is going to make productivity/output/profit dip in the first instance. You can't add extra work into a system without the system responding to the work.

So in the above diagram at the point when you exit your "Transformation" you are actually potentially net benefit worse off than if you hadn't done it at all. You've borne the cost of buying in consultants, you've lost staff, you've gained new staff, you've bought new software, you've built new processes and retired old processes, you've re-furbished the office space, and you've scared the jam out of most people along the way, but the believers are still on board.

So was it worth it?

Well that is difficult to quantify as what you have actually done is payed back the "non-technical debt" in your organisation all in one go and "boosted" your future velocity as a result. You're still in business and now better prepared to take on the future, in fairness you've potentially saved the company from a steady decline and uncertain fate. Things are certainly different, that's for sure.

But was this the only option? What you have done is a full system re-write of the organisations' "code-base". Perhaps was it better to fix the "non-technical debt" little and often just like we encourage our developers to do?

Divining Business Value for Agile Projects - Value Mapping, Value Statements & Measures.

Mike Cohn once said "Product Owners are often given the vague and mostly useless advice "Prioritise on Business Value" " and he's right.

If you read a scrum guide or a paper on prioritisation, or indeed many of the learned texts on Agile, they all seem to fall into a grey area around what business value actually is. They will potentially give you reams of advice on prioritisation methods, however these can only be applied once you understand where your value lies.

In reading around this I found Emergn stating in VFQ (value, flow, quality) that you can prioritise effectively if you can measure (or estimate) Value, Cost, New knowledge and Risk. The thing is; the first two are in cash (£/$) so what if the purpose of your project is to improve customer relations or company reputation?

Thoughtworks have had a good go at this one and in a paper by Paul Ellarby which I enjoyed; it proposes the way to value measurement is to create the four elements below:

• #1 Develop your organization's “value language” 
•  #2. Understand the value-cost of each portfolio down to the feature level 
•  #3. Allocate value points across all capabilities 
• #4. Track value vs. cost for each iteration

This has some good guts behind it and the concept of "value dials" for a range of elements important to an organisation seems well thought out and helps us "find" our value. It also makes the point that those value elements may or may not map to the bottom line so helps with non-financial goals. My observation though is that this concept seemingly needs adopting at a Corporate level as a framework and then cascading down all projects or it doesn't seem to work properly. In organisations that are not in a position to transform their own governance but still need to understand value per-project/in-project there still seems to be a bit of a gap.

I then drifted in to a bit of a twilight zone and found myself thinking "well if you can measure value, then you can define value" - and an Agile colleague introduced me to the book "How to Measure Anything - finding the value of intangibles in business" by Hubbard. I managed three chapters of this book, and the anecdotes about how you can measure complex things with simple means was pleasant enough. Apparently you can estimate the scale of an atomic bomb blast by scattering confetti into the resultant wind, and seemingly you can estimate the number of piano tuners in Chicago with relative ease.

What this book didn't really do for me though was unlock the challenge of finding what is valuable versus what isn't, and therefore I was back to square one again. Through conversations with more Agile colleagues I now have a quick recipe (credit to Nik Silver & Laurence Wood):

1. Run a Value Mapping workshop with stakeholders (real ones) using a wall like this:

• Use post-its to capture things that feel relevant or valuable to the project or outcome, and categorise them above - you may end up with the same items in both swimlanes but in different categories (duplicate post-its as appropriate).
• Discuss the conflicts and shared values across the canvas.
• Create a very small group (sub-set) of the post-its that represent what is truly important/valuable (in theory this will only come from the left-hand side)
• Agree that the remaining post-its are not truly important and therefore should not form the a value statement for the project/outcome or bias any later prioritisation.
• Photograph both of the above!

2. With the stakeholders above, write a single value statement for the project/outcome.

• A value statement is a very brief description of why something is being done. It should contain some visible business value, this can be financial or non-financial. It is very helpful if this is described as an outcome.
• TIP: Try writing a value statement as a User Story and see what "So That" says.

3. Agree a Value Measure for the Value Statement.

• A value measure describes some tangible way of detecting a change. It can be financial, emotional, or physical/environmental. It could be a bank balance increase, or simply the number of smiling people in the office - yes it can be that random.
• TIP: Write your "user story" Value Statement, then add line 4 “As measured by:” ..your Value Measure

Do not worry about the mechanism or feasibility of how to actually measure it.

If all has gone well, then you now have a clear definition of what is valuable to the activity/project/outcome being considered, and you have an idea as to what could be a measure of it (not how to measure it). As Hubbard suggests; anything that affects any type of change whatsoever can be measured (even things like love, happiness, and reputation), otherwise it did not affect a change.

You should now have a "thing" which you can publish and measure against; "Are we working towards our value statement" "Does this activity contribute to our value" and more pertinently when it comes to prioritisation; simply "Which of these two do we think will contribute the most to our value".

Whilst it may seem silly; a conversation about whether a hundred balloons or a massive cake would bring the most happiness to an office (as measured by smiles) can usually divine an answer one way or another. You can use this "either-or / hotter-colder" test to a whole backlog and you don't ever have to actually count the people smiling. :)