Personal development and organisational structures are often viewed as the ‘fluffy’ stuff, with little relationship to bottom-line. This Blog series will attempt to demonstrate that the reverse is true. In this third blog, we’ll examine the overall effect of working in a rapidly innovating industry with a long-term talent shortage.

Perpetuating Dross? An Industry Dilemma

The software industry is young. It’s only been around for about 60 years… We’re still finding our feet and demand for our product is increasing exponentially. Banking and Retail have had millennia to refine their practices; we’re still learning ours… When we then add to this learning curve the scarcity of resources, it’s easy to see why in 1994 the Standish report were stating only 16% of software projects were successful.

Projects have been so unsuccessful that C-level executives ripped the software development capabilities out of their companies and off-shored it to countries like India, I once heard that “If I’m going to have projects that fail, I’d rather fail cheaply.”

However, more damaging to the software industry is not its embryonic stage, nor its learning curve, nor even the scarcity of resource, but the acceptance of poor product as the norm – the perpetuation of dross.

Customers of software have become accustomed to and accept defects as part of the product offering. Not only that, but also they expect and are prepared to upgrade products themselves, on a regular basis, and pay for the privilege of doing so in support and maintenance contracts or annual licensing.

In what other product development vertical would it be acceptable to have so many defects?

One of the effects of poor software implementations has been the creation and growth of an entirely new industry the Customer Services Call Centre. Companies understand that their technologies and processes are not aligned and faulty, so they establish huge customer service operations to answer customer queries and complaints and resolve the errors.

A further effect of accepting poor quality software production is the institutionalisation of waste within corporations. Executives attempt to control the situation by implementing more and more processes, bureaucracy and safety nets, as well as customer services, service management teams, and DevOps teams. This creates more cost, complexity and opportunities for error.

If each company made the time and resources available to solve root cause issues, then companies would learn to create and deliver the most value from the customer’s perspective, while consuming the fewest resources, by fully utilizing the knowledge, skills and thinking of those who perform the work

So poor product development within software has become the norm, we are perpetuating dross.

We create poor product, customers accept poor product, and therefore we are justified in creating more, poor product. We don’t evolve, we don’t improve our profession, we accept mediocrity in the name of profit and the cycle continues.

If you look at any other mature profession there are some key, visible elements… Doctors, civil engineers, solicitors, and bankers have set qualifications, apprenticeships, certifications, accreditations, regulators and associations. This represents a huge investment in the capabilities of the profession – how does the software industry compare?

Software development is in its infancy, we are all still learning, and we should be creating learning organisations. We should not accept poor quality product, and we are damaging the reputation of our profession by continuing to accept this course.

We’ve been working with a small, ambitious, energetic financial services technology company. They’re a ‘green-field’ agile site, with executive sponsorship for agile adoption and a large portfolio of work to deliver.

Having assessed their portfolio, capacity and skill-sets they’re looking to increase their team size by recruiting a Scrum Master, a .Net Developer and an Agile Tester.

If you’re interested in working in a small company, in south-west London, actively adopting agile practices, where the results of your efforts are clearly visible, please contact recruitment.uk@ripple-rock.com

http://www.ripple-rock.com/about-ripplerock/careers-uk.aspx

http://www.ripple-rock.com/about-ripplerock/careers-uk/agile-tester.aspx

http://www.ripple-rock.com/about-ripplerock/careers-uk/agile-developer.aspx

http://www.ripple-rock.com/about-ripplerock/careers-uk/scrummaster.aspx

Original Post: http://businessvalueexchange.com/brains-are-machines-series-blog-2-innovation-automation-investment/

Personal development is often viewed as ‘fluffy’, with little relationship to the bottom-line, not something a CIO would hang a vision and strategy on. This Blog series: Brains Are Machines, attempts to demonstrate that the reverse is true. In this second blog, we highlight that despite our rapid innovation and adoption of automation within software development, the need for higher levels of investment in developing people remains.

Innovation

Technology innovation is rapid, the speed of innovation is accelerating and technology is ubiquitous. So whichever way you look at it, you either need to excel at creating & distributing software or you need to excel at assessing, purchasing and integrating software into your existing architectures, processes, people and culture. And this trend is only going to increase.

So if you were given a strategically critical project this year, i.e. the future P&L of the company depends on its successful implementation and return on investment, who would you trust to deliver it? Would you out-source it? Would you bring in contractors? Or would you give it to your own teams? I.e. Your own ‘machinery?’

If you wouldn’t give it to your people i.e. your brains, your machinery, what does that say about the state of your machinery and your ability to maintain it? What does it say about your capabilities for creating a team or organisation that meets the needs of the business?

Furthermore, what is the reason for not trusting your machinery with the job? Lack of knowledge? Lack of capability? Or lack of capacity?

Automation

Some of your competitors are now able to deploy enterprise-level, mission-critical applications on a daily basis. Through Continuous Delivery [1] (an encapsulation of many agile practices) the business can ask for a change, have it designed, developed, tested and deployed live, on an enterprise scale within 24 hours if required.

Test-driven development, continuous integration, automated acceptance testing, automated environment provision, automated configuration, automated load & performance testing, automated application and database deployments enable this capability…

Each of these individual innovations has removed many manual processes from the value stream of creating and delivering software, and the effect has been to rapidly reduce cycle time to market. These innovations implemented in concert, represent a fundamental shift in software development capability and capacity. Continuous delivery is starting to incrementally evolve business models.

But even accounting for this automation and reduced cycle-time, you still need people to establish and maintain that capability… The brains are the machinery, and are needed to write the automated tests, configuration and deployment scripts, to design the environments to be automatically provisioned and to establish the continuous integration process, as well as design and write the code.

And you’ll need resources to take you on beyond this point, adopting the next level of processes and technologies that drive the business forward in this ever-changing technology landscape.

Investment

So if the brains of your teams are the machinery of business, if technology is moving so fast, if you’re in a talent war and your people are implementing these technologies or assessing and integrating them… Do you really have the right level of focus on, and investment in the attraction, retention and development of your people?

Original post: http://businessvalueexchange.com/brains-are-machines-series-blog-1-shifting-sands/ The industrial revolution saw the landscape of Britain transformed from rural & agricultural to urban & industrial. The mass exodus of people from the country into the city represented a fundamental shift in the social fabric of the country.

The companies themselves were able to recruit and retain low-skilled workers, working on high-cost machinery that required constant maintenance and investment. The machines had maintenance schedules, were constantly oiled, monitored, measured, and had parts regularly replaced because they were the core contributor to the profitability of a company.

A worker leaving the company had little impact on the capability of the business to create its product.

The information age has brought with it a shift in power toward the knowledge worker due to the nature of work. The information worker is a higher-cost resource, holds more tacit knowledge and intrinsically more value to a business, as their knowledge is part of the whole make-up and fabric of a company. Put bluntly “their brain is part of the machinery”. And therefore a business has more reliance on its people as resources, rather than its machinery (or infrastructure).

A worker leaving the company has a larger impact on the capability of the business to create its product or service. Tacit knowledge is leaving the business, a new worker is required and their induction into the collective takes far longer and costs a lot more.

So if brains are the machinery of your company, what kind of shape are they in?

How much are you investing in them, what does their maintenance schedule look like?

The software industry has a scarcity of resource, and this scarcity of resource has existed for a number of years. In the manpower survey of 2012[1], 25% of EMEA employers reported difficulty filling jobs due to a lack of available talent. It has led to you being in a talent war, having to pay c20% fees for recruitment of team members before they’ve walked through the door. Also, your best ‘machinery’ is at risk of being head-hunted by the competition.

So if you’re paying c20% to a 3^rd party just to bring talent through the door, and your best talent is at risk of being pinched, how much should you be paying to develop and maintain that talent?

[1] Talent Shortage Survey 2012, Manpower Group

I’ve been invited to become a CIO Thought Leader and Featured Contributor on a new IDG produced site in collaboration with HP Enterprise Services. The site is called The Business Value Exchange and you can find out more about it here.

I’ve written a couple of blogs including a piece on the Cellular Business model and the start of a blog series entitled “Brains are Machines”.

I hope you enjoy the thinking!

The Cellular Business Model

Business in the 21^st century is fast-paced, our tools are the internet, the knowledge worker, internationalisation, globalisation, the PC, the cloud, digital communications, a networked global economy.

So why are our organisational structures and practices based on 200 year-old thinking?

The current hierarchical corporate structures that dominate our economies have been in place for over 200 years and were notably supported and defined by Max Weber during the 1800s. Even though Weber was considered a champion of bureaucracy, he understood and articulated the dangers of bureaucratic organisations as stifling, impersonal, formal, protectionist and a threat to individual freedom, equality and cultural vitality.

In the 21st century, and particularly in the software industry, we need to evolve. Hierarchical enterprise structures were requisite for the 19th century, should probably have evolved in the 20th century, and are certainly out of date in the 21st century. Enterprises today need to focus on creativity, speed to market, data, intellectual capital, technology adoption and agility.

When you consider the abundance of waste within large organisations – the bureaucracy, governance procedures, multi-layered management hierarchies, complexity, politicking, and size, it is abundantly clear why innovation is impeded. Organisations become slow to market, narrow in perspective, and are reduced to becoming dinosaurs awaiting oblivion… or merger, acquisition, management buy-out, government bail-out etc.

A more suitable model for organisations in the 21^st century is cellular in structure.

The entire organisation is a cluster, swarm, honeycomb of individual, autonomous teams of 6-10 members, with each team functioning as an independent profit centre. Companies achieving this cellular model would have the flexibility, adaptability, speed to market and open-minded perspectives required to function on a large scale in rapidly innovating markets.

Through the adoption of Agile & Lean Thinking, Open Book Management, Pattern Theory and Cloud Computing, we can see how an enterprise could exist as a swarm of multiple, independent, autonomous, profit-making entities.

Using Open Book Management, we provide each cell with a clear and unequivocal financial view of the cell, its costs and its expected returns. Principles and practices such as producing shippable product every iteration and the focus on product quality found within agile development, support rapid delivery cycles and speed to market.

We amplify the learning through the use of pattern language for software and organisational structures. The technology infrastructure for a cell to develop and distribute its software products on a global scale without significant capital expenditure, is afforded by the use of cloud computing. As the customer base grows, the ability to serve a wider audience increases on a transactional basis and with cloud technologies this enables a cell to respond effortlessly to elasticity of demand.

The business world is changing at a phenomenal rate, and yet our organisational structures and cultures are not responding or adapting quickly enough. Corporate strategy is no longer purely about research, analysis and long-term planning and investment, it is about making the business more able to cope with change. Our current “in-built” culture and mind-set of hierarchy and centralised command and control is no longer fit for purpose. Market share will be eaten away until more innovative thinking is applied to corporate structures, governance and operating models.

The Cellular Business Model achieves the level of adaptability and flexibility required to react to and exploit market opportunities in the 21^st century.

For a more details of the Cellular Business Model: www.cellularbusinessmodel.com

The Agile:MK Journal, Issue 04 March edition is available from www.agilemk.com.

This edition is a write-up of the March User Group session was a discussion about Writing Good Requirements.

This blog is part of the Blog Series: A Decade in Agile and was first published in February 2005. My updated reflections are in blue italics.

I believe that adopting a scrum approach to project delivery provides the following benefits:

• Higher levels of business buy-in
• Higher levels business involvement
• Clearer alignment of functionality to business value
• Higher levels of adoption
• Better ROI

Now... for clarity, I'd like to point out that I have created business cases before and hope I will continue to do so for agile projects. I've used ROI, with discounted cashflows, NPV and IRR and even the Benefits Management process designed by Cranfield Business School. But... often the traditional delivery approaches do not help the team to maintain a focus on the business case throughout the lifecycle of a project.

Often once the requirements have been stated, the business moves into the "pay and pray" stage, where they hope that in about 6 months time they'll get what they asked for. Agile approaches have in-built processes that ensure a constant focus on business value.

The assumption in my thinking at this time that I couldn’t see, was that a strong, intelligent, informed and networked Product Owner is directing, prioritising and developing the product backlog. In my earlier scrum projects the product strategies,owners and backlog were very clear and iteration was part of the process

Increasingly, the role of the Product Owner is becoming more demanding and important, I think there are a number of reasons for this:

• Agile teams are getting faster
• Sprints are shorter
• The scaling of teams is more prolific
• Teams are incrementing but not iterating

As teams get faster they create more demand on Product Ownership. More stories are required per sprint, more software is created for review and delivery. Couple this with shorter iterations of just 1 or 2 weeks and the Product Owner necessarily becomes a full-time role just to fulfil the artefacts and cadence of a fast team, regardless of managing product strategy, market analysis or customer analysis and feedback.

If we then add in the scaling of teams then Product Ownership necessarily becomes a team activity with Proxy Product Owners (or similar title) where the ‘delegation’ of business requirements definition and prioritisation is essential and suddenly we find ourselves moving swiftly back to ‘middle-men’ between the customer and the development team.

Of more concern to me is the increasing devaluation of iteration. I think here I ought to define what I mean. In a sprint, the team will take in stories as vertical slices of software to product a potentially shippable product. This slicing of software and delivery of pieces is what I refer to as incremental delivery.

Whereas, iteration for me, is the ability to return to a piece of software and evolve it, change it, adapt it, alter it, based on feedback from the business or customer. My current concern is that many teams are delivering in increments, but are not actively seeking the feedback from the customer/product owner and expecting to iterate upon the increment.

Rather, teams feel that they’ve got to get the increment right first time and are increasingly spending more time upfront to get things ‘right first time’ rather than using the more tangible medium of customer feedback to refine their product.

If this trend continues, teams will lose the benefits of agile working and will increasingly put more pre-sprint activities in place creating longer cycle times to market with less customer validation and poorer product.

and now I'll tell you how...
Scrum is focussed on delivering increments of shippable software every 30 calendar days (typically 2 weeks now). In my experience, the impact on the business stakeholders and user group of seeing quality software delivered every 30 days (one 30-day iteration is called a sprint) is immense... http://www.controlchaos.com/about/

Picture the scene... It's the programme kick-off meeting, the steering group, user group and entire programme team are assembled and you are presenting the project business case, objectives, structure, ways of working and plan. Then you say, "and the first delivery will be in 19 working days."
I was not short of a few sceptical faces that morning...

However, 19 days later, I was in front of the same audience showing the working software. Now we'd only built about 8 pages, but they were of production quality. The functionality enabled the user to search for and view product information and provided on-line help. This functionality was built using .NET technology integrating to an IBM AS-400 mainframe.

The impact of delivering this one "sliver" of production code was astounding. Suddenly the user group could see that we were really building this stuff straight away, and from the end of sprint 1 until live date, we had significant levels of business buy-in and involvement. Far more than I have ever experienced using traditional, waterfall methodologies.

Now scrum also uses a Product Backlog. A product backlog is a list of high level business requirements prioritised purely on a business value basis. So what's so new about that? ... Nothing.

What is new, is that because we are delivering full production code at the end of every sprint, we can measure our expected business return directly against cost far more precisely. AND... at this point assess the outstanding functionality, and either change direction, de-scope because the outstanding functionality has low business value, or continue with the project as it is.

This gives us clearer alignment of functionality to business value. Because of the incremental approach, the closure of requirements every 30 days, and the ability to more granularly relate business value to requirements, the value of the project is transparent to all stakeholders.

At the end of each sprint the sliver of functionality is made available to the business users to review and feedback on. Feedback is classified as an enhancement or bug, but the real value is that the business users are iteratively reviewing and directing the design of the solution as the project progresses. By the time the solution moves into production, potentially 8 months later, adoption levels are far higher than those of traditional project approaches.

Finally, scrum approaches give you a better return on your investment. Firstly, the teams are more productive see http://blogs.conchango.com/stevegarnett/archive/2004/11/19/297.aspx. But from a business perspective, the incremental completion of the highest priority requirements by the project team, means you will always be maximising your investment, because the team will always be building the stuff the business has prioritised as the greatest value.

In my experience, using scrum has really benefitted the business stakeholders because change is embraced, only valuable functionality is built (and this is picked by the business), and superfluous requirements are not built which reduces waste (Lean software development)

http://www.poppendieck.com/overview.htm

www.agilemk.com

Latest issues of Agile:MK Journal available.

Next Meeting: Tuesday 26th March, 6pm-8pm, Jurys Inn Hotel, Midsummer Boulevard, Milton Keynes

For clarity, this blog will focus on how to manage technical debt i.e. make it visible, communicate it, quantify it, and prioritise its removal. This is because  in my experience it is not only a challenge to fix the debt, it can also be very challenging to get time and resources assigned to fix it unless a high profile issue has occurred which highlights the debt.

Blog Structure:

• Technical Debt – Definitions
• Strategy 1: Evolving a Mature Definition of Done
• Strategy 2: Preventing Unacceptable Technical Debt
• Strategy 3: Prioritising & Quantifying Existing Technical Debt
• Strategy 4: Tactics for Fixing Technical Debt

A Definition

There are many definitions of technical debt available, my favourite is by Martin Fowler. Please have a read if you’d like a bit more clarity on the term: http://www.martinfowler.com/bliki/TechnicalDebt.html

Accruing Technical Debt

Most companies are creating technical debt all the time – lets take an example:

“The team I’m part of has just started a project. We don’t have a test environment but we’ve got our dev boxes and a build server so we can get cracking. Our definition of done is okay, we’ve said we’ll use coding standards, will build features to the acceptance criteria in the story and will have a review of features with the Product Owner. We’ll write unit tests on new bits of code, and prepare test scripts but because we haven’t got a test environment we won’t be able to do integration testing or regression test the features to ensure nothing has been broken in the process of creating new features. We’ve done a couple of sprints and there’s more bugs in the solution but once the test environment is available we’ll sort them all out. “

For some clients we work with, this in not a rare scenario, but inherent within this approach is the creation of large amounts of technical debt and its growing exponentially. I think the following slide from Colin Bird’s CSM course highlights the problem very succinctly.

As these items of increasing bugs, lack of regression testing, unclear coding standards, unclear understanding of the quality of code being produced due to a lack of pair programming, TDD or even peer review and a complete lack of visibility of how the solution will perform in an integrated, production environment increase sprint on sprint (phew!)… so the mounting technical debt will start to impede velocity and add more work on to the end of the project in order to move the solution from an immature definition of done to production ready.

The typical result of this approach left unaddressed is a set of hardening and stabilisation sprints that take months to get into production. This causes knock-on effects of losing stakeholder trust and support, blocking other projects from starting, keeping resources longer than expected messing up resource planning, and generally losing kudos and trust across your internal teams – and that’s before we talk about the impact on consumers of your product!

Strategy 1 – Evolving a Mature Definition of Done

One of the first major conversations I expect to have with a Scrum team is about the definition of done. Scrum specifies that the team should create ‘potentially shippable product’ every sprint. This is, in essence, the heart of the problem of adopting Scrum. It is the reason why so many technical, engineering and test capabilities must change and adapt in order to be able to achieve this ‘rule’.

An immature Definition of Done speaks volumes about the team’s overall ability to reach hyper-productivity levels of software development. If the gap between a story done in sprint and a story deployed into production is big, then after the final ‘development’ sprint, you should all expect a considerable period of hardening and stabilisation.

We’ve recently been using Value Stream Maps to help articulate the flow of work through development teams. The Value Stream Maps show customer expectations, information flows, physical flows, productivity metrics and value stream metrics including waste.

The physical flow often shows software being created and then moving through the environments of development, test, user acceptance, pre-production and into production. So, with your team, where is code deployed within the sprint i.e. when its tested and set to done in sprint, how far away is it from production?

• And what is the cost or amount of pain to be inflicted before it reaches production?
• How many unknowns exist between your team’s definition of done and production ready code?
• What are you doing to evolve the Definition of Done to reduce the gap between sprint done and production done?

Again value stream maps come to the fore when considering these questions as does Application Lifecycle Management (ALM).

In order to avoid the long and painful hardening/stabilisation period, the team must be focussed on continuously evolving the Definition of Done to bring feedback loops and risks into the sprint and reduce the gap from sprint to production so that they are truly creating ‘potentially shippable product’.  

Strategy 2 – Preventing Unacceptable Technical Debt

Again, I’m afraid I’ll have to refer you to Martin Fowler’s blog which introduces the Technical Debt Quadrant:

http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html

Ahh, the 2 x 2 grid! Takes me back to hours upon hours of MBA study! Thank god that’s done with!

I have often used this grid to work with teams on prevention. i.e. preventative measures in order to reduce future technical debt. As with all preventative activities, they usually take longer to implement but when adopted have a significant impact.

Use these categories to decide which sources of debt are acceptable and which are not acceptable within your organisation, and then establish tactics for preventing unacceptable behaviour…

Prudent & Deliberate

Generally, I don’t have a problem with behaviours that sit in the top right quadrant… assuming that is really where they belong. Often this quadrant is misunderstood. It is not about having to ship because stakeholders are expecting a shipping date, or someone’s bonus depends on it shipping on a set date – those scenarios actually belong in the top left quadrant.

The top right quadrant is reserved for business drivers that have a compelling ROI for why a product has to ship immediately – i.e. responding to a threat to the business bottom line, or exploiting an opportunity that positively affects the bottom line. If in doubt, a good challenge would be to inform a board member of the situation and ask if they are aware that the product is shipping due to a compelling business agenda.

Examples of where the top-right might be justified:

• Entry into new market (first to market may mean that less quality or features with more work-arounds might be acceptable)
• Regulatory or Legal Requirement (a compliance date has been set whereby non-compliance would represent significant negative brand, operational or financial impact to the business
• Peak-period opportunity – within retail the Christmas period is increasingly becoming the most critical part of the annual cycle and failure to launch prior to Christmas could have a significant negative impact on the company’s performance.

Reckless & Deliberate

Top left is indicative of poor management, usually corners are being cut in order to hit a deadline that is related to perceived operational needs rather than an underlying clear business case. Rushing teams because someone somewhere has communicated a deadline and then driving to hit the deadline because of the deadline’s sake rather than a compelling business need.

This is a very common cause of Technical Debt. If the board or shareholders were informed that a project was cutting corners and creating technical debt which will slow the company down in the future, they’d want to know why. In fact, I think that if the subject of technical debt was discussed more openly and quantified, they’d be far more examination of portfolio management capabilities.

A lot of the time, this is occurring not because there is a business case for hitting this date, rather due to how the company delivers projects. Examples of Reckless & Deliberate:

• Rushing the project to completion because there’s lots more projects to deliver and the matrix resource plan needs to transfer resources
• Cutting corners in a project because the programme manager and/or director have incentivised objectives based on the project being delivered into production this year
• Pushing the project through because the client wants it on a set date, no one has built a relationship with the client to discuss the details, nor has the client been informed of the affect on quality if the delivery is rushed

None of these are necessarily easy to change, but, stopping these behaviours will have a significant, positive impact on the long-term velocity and well-being of the company.

Reckless & Inadvertent

Incompetence at one level or another is the key contributor to debt created within this quadrant. You don’t know what you don’t know and could therefore be blissfully unaware that you are creating a huge amount of technical debt. As a manager/leader, I’d want to prevent the reckless & inadvertent creation of technical debt and there are many tools to help me do this.

Essentially, this is about investing in your people, processes and tools – again something not done enough!

Pair programming, code reviews, static code analysis, continuous integration, automated test suites help to provide feedback on code and design quality. Communities of practice, clear role description, personal development plans, training budgets with technical strategy alignment are tactics for helping people get better at what they do and lightweight iterative methods with visual management help to ensure processes are continuously reviewed and improved.

Prudent & Inadvertent

This is a natural occurrence. Regardless of what walk of life we are in, or what job we do, over time, we’ll return to a previous piece of work and see a better way of doing it. It is the natural sequence to gain more domain knowledge about a particular piece of work.

Just because we know that with hindsight and increased experience in a year or two’s time we’ll look back and see a better way, doesn’t mean that we procrastinate or spend large amounts of time trying to second guess the future.

Rather, we keep to the agile principles of:

• Our highest priority is to satisfy the customer through early and continuous deliver of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
• Working software is the primary measure of focus
• Continuous attention to technical excellence and good design enhances agility.
• The best architectures, requirements and designs emerge from self-organising teams
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Strategy 3 - Prioritising & Quantifying Existing Debt

So, lets assume we’ve implemented some tactics for reducing our Reckless & Inadvertent debt and our Reckless & Deliberate debt and now we’re going to spend some time ‘speeding-up’ the company.

Where Does it Hurt?

This is how I have approached the problem in the past.

The first thing to do is to try to establish how painful a particular piece of technical debt is. i.e. if you have to touch this part of the solution in the future, how ‘painful’ will it be? How much additional time will be spent understanding the area, re-writing parts to get is to work or integrate with other new parts? This ‘pain’ factor is represented by the yellow part below and we’ll refer to this as the interest.

Next for each item of debt, we need to understand the effort involved in fixing it, and we’ll refer to this estimate as the Principal. 

How Much Does it Hurt?

Having established how much interest is payable upon the use of any part, and knowing what it takes to fix it - the principal - we can now work out which pieces to fix, and why. 

Looking at the slide above, which piece of debt do you think should be fixed first?

The answer with this amount of information is A, as it has the highest amount of ‘pain’ or Interest, with the lowest effort to resolve ‘Principal’. However, what we haven’t considered yet is time and the frequency of payments. i.e. what if in the next 6 months item A on the left will only be changed/touched once, but the item on the far right ‘D’ will be touched 10 times?

Now which item of debt do you think should be fixed first?

Who Cares?

So we’ve established the frequency of Interest payments and found out that the most painful item of debt is item D on the far right. Have we finished?

No. Because until now we’ve focussed purely on the IT decision-making side of Technical Debt i.e. how painful it is, what it takes to fix it, and how often it hurts our development efforts. What we have yet to consider is whether our prioritisation takes into account business value. 

A fair few years ago as Head of Software Development, my team created a product portfolio. i.e. we took all our disparate applications (and there were many, and they were disparate) and grouped them into families of applications that served specific business needs.

This was a very powerful exercise and it helped us to clearly discern where we were adding value and supporting the business. It also allowed us to quantify the value of software applications based on which business units were using them and how much revenue was being generated by those units.

In this way, we were able to prioritise fixing technical debt based on a clear alignment of business value.

So now we can quantify the size and frequency of Interest payments and we know what it will take to pay-off the principal to remove the debt. In addition to this we can prioritise the debt in terms of the value of the application to the business at the moment, but what about the foreseeable future.

Strategic Intent

The final consideration when prioritising technical debt activities across your application portfolio is the future needs of the business upon the application landscape. Which systems are critical to the future of the business? Which will be decommissioned as the portfolio moves through the foreseeable future?

In answering these questions, we will understand the future needs of the business upon the application landscape and be able to focus the entire development effort on improving the highest value systems of the business both for today and tomorrow.

Technical Debt Portfolio Prioritisation

By taking the factors we’ve already discussed: Interest Payment; Principal; Frequency of Payment; Business Value;  and Strategic Intent - we can now create a high level, business-derived prioritisation matrix for articulating, quantifying, prioritising and resolving Technical Debt.

The first step is to map current business value/usage against the future strategic needs of the company.

This mapping will provide an initial view of the value of applications within the landscape.

Once these applications have been reviewed, categorised and the output discussed with business stakeholders, we can initially provide a generic approach to dealing with the debt:

• Operationally Maintain
• Fix the Debt
• Don’t Touch the Application
• Focus on Prevention

Strategy 4 - Tactics for Fixing Technical Debt

We now have a means of categorising all the applications within the landscape and assigning relative value to them based on current and future usage requirements. Within these categories we are able to specify the ‘pain’ of technical debt, as well as the effort required to fix it.

We also have some strategies for dealing with the debt:

• Ignore – for applications that are Dogs
• Reduce – for Cash Cows to ensure the application is operationally maintainable
• Remove – for the Stars
• Prevent – for the Problem Children

Hide the Work - I’ve seen teams hide the work to fix the Technical Debt. This tactic can be successful but I feel it goes against the grain of transparency and honesty and ultimately the fixing of debt should be a business driven activity. But, I have seen this tactic work so it should be considered within your context.

Leave the Code in a Better State - The on-going development strategy should always be to leave the code in a better state. It’s a simple statement that is rarely adhered to. The rule is that every time you touch a piece of code, you leave it in a better state. It could be as simple as an additional unit test or some clearly articulated comments or as complex as writing a suite of unit tests and refactoring a component. If every single developer adopted this strategy in your organisation the state of the code base would improve significantly over time.

Ask to Leave Code in a Better State – This tactic is closely related to the one above, but is cognizant of the fact that some companies micro-manage their teams to the extent that any time not spent directly working on the addition of features can be rapidly identified and can cause friction. This tactic addresses the scenario where a developer identifies a piece of technical debt during a sprint, that they think should be fixed. Rather than just sorting out the problem (which is desirable outcome), the developer would escalate to the Scrum Master and Product Owner. If you have to resort to this tactic then there is a lot of work to do in educating the business and IT management about the problems of technical debt, as well as a recognition that you have not provided an environment that allows self-organising teams to flourish.

Create Story & Justify – Typically, leave the code in a better state is not a fully adopted way of working across development teams and the more typical way of fixing technical debt (other than complete re-platforming) is to create individual stories and treat them as ordinary backlog items. When you get this up and working fully, involving the Product Owner in the reasoning behind the work, both parties learn a great deal about each other’s perspectives and it can be a valuable lesson in understanding the business and technical domains.

Allocate Release Ratio – Another tactic I have introduced in order to achieve some progress in fixing technical debt is to ‘Allocate a Release Ratio’. When articulating the value of addressing technical debt and prioritising it within a Product Backlog, I have often seen that despite best intentions, the Technical Debt items sink toward the bottom of the backlog and do not get resolved.

There are a number of reasons why this might occur so to mitigate against this occurrence, I seek agreement from key stakeholders to allocate a certain amount of a release backlog to technical debt items. This approach has certainly been successful in ensuring TD items are addressed. Ultimately though, the best tactic remains to leave the code in a better state as it is more efficient.

Summary 

Ultimately this is about understanding the value of your application landscape, understanding where its weaknesses lie and finding a way within your organisation to ensure it is fit for purpose now and in the future. I hope that the next time you hear the term Technical Debt you’ll have gained a clear understanding of what it is from Martin Fowler’s blogs and you’ll also have some tips for how to address the problem from this blog.