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?
Wow its a very good post. The information provided by you is really very good and helpful for me. Keep sharing good information.ReplyDelete
Software Testing Services
Software Testing Company
Functional Testing Services
QA Automation Testing Services
Functional Testing Company
Performance Testing Services
Security Testing Services
API Testing Services
Regression Testing Services
eCommerce Testing Services
Mobile App Testing Services