Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

Tweet

Mail

Both Agile and Waterfall projects can fail due to poor debt management, however Agile process and techniques allow for finer grain management of debt. Unfortunately Agile debt has become synonymous with Technical Debt rather than a wider view of debt.

If you google Agile debt, you get around 2,980,000 results, if you google technical debt you get around 148,000,000 results, either way, in relation to the Agile domain, all the results relates to technical debt, that debt which leads to increasing cost of change to the software.

I have managed several very large Agile programmes and as the programme manager I have experienced real pressure from technical members of the team to reduce pressure for story delivery and allow more technical debt to be mitigated. It is admirable that technical team members can feel so passionately about the risk of technical debt build up.

Agile purists reading this will be screaming out "who the **** does he think he is restricting the technical team in such a way!"

Well, as the programme manager I am the person accountable for achieving a successful outcome which inevitably is measured in several ways by the programme stakeholders, one of which is cost of ownership and maintenance, however the others usually include cost of delivery, timescale for delivery, value creation.

My view of technical debt is that the related risk needs to be balanced against other risks such as risk of losing stakeholder confidence, risk of late delivery, risk of insufficient budget, risk of poor stakeholder morale, risk from business imperatives, etc. Sometimes as a programme manager you have to make priority calls to avoid any one of those areas of risk being unacceptably high.

This has caused me to adopt a debt oriented approach to risks other than technical debt and to shape my debate with the technical team along the lines of accepting technical debt in order to pay back some other debt that has been allowed to build up. This enables me to convince  the multi-disciplinary team members to accept that their priorities are not always the programme priority and that they must compromise at times in the best interest of the overall success of the programme.

I advise all Agile project and programme managers to try my approach, consider debt against the following programme success factors and take the lead in getting the team to see the diverse nature of the programme debt profile and the need for the emphasis on debt repayment as shifting from iteration to iteration:

• Feature debt.
• Senior Stakeholder confidence debt.
• Programme budget debt.
• Performance debt.
• Timescale debt.
• Value creation debt.
• Resource debt.
• Business imperatives debt.
• Quality Debt.
• Technical debt.

I accept that this may be seen as another form of risk assessment or risk management, however the debt approach is one that is intrinsically part of the iterative/incremental Agile approach whereby each Sprint/Iteration can have the emphasis shifted towards the mitigation of different types of debt.

Of course with the Waterfall approach to projects all this debt can be hidden through the smoke and mirror process of hand off between team and the myth that early lifecycle documents are definitive statements of requirements and design, resulting in the common waterfall scenario of ‘90% done and 90% to go’ experienced in the Testing stage of the project.