Technical Debt: Pay it now, or pay it later!

The concept of software complexity and deferred refactoring as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ‘92. It has since become an industry wide concept and is a commonly referenced and applied when practicing scrum and agile.
Technical debt is deferred work not directly related to new user story features, but necessary for the overall quality of the system. Examples of technical debt include delaying upgrades to necessary tools and frameworks, delaying the refactoring of overly complex or crude system components, etc. etc.

The problem with technical debt is that it will reduce the velocity of the team, and the quality of the software produced on a greater basis the longer it is ignored and / or deferred (just like only making the minimum payment on a credit card debt).
So now that we have an understanding about technical dept, and the problems caused by it, we can discuss an approach to solving this age old application development and maintenance issue.

Since Scrum teams are supposed to operate in a transparent manner, and the product owner is a full partner with the scrum team, the details of the technical debt that exists and is accruing in a product needs to be visible to and understood by the product owner.
Key technical debt items need to exist in the product backlog. Additionally, the ongoing impact to product quality and scrum team velocity by continuing to defer their resolution needs to be clear to the product owner so that the product owner may rightly prioritize these items in the product backlog.

Additionally some team adopt the notion that in each iteration or predefined number of iterations, a technical debt tax of some number of story points will be included during the sprint planning process. This assures that the most important technical debt items will be addressed when they exist in the backlog, and hopefully the “technical debt balance” will never get to the point where it takes too big of a bite out of a particular iteration or set of iterations.

Also, once the concepts of identifying technical debt and continuing to pay it down on a regular basis are in place, the scrum team becomes very sensitive to these issues, and very cleaver and effective in how it deals with them.

Therefore consistent and thoughtful application of these best practices associated with the management of technical debt will result in better software quality, improved team velocity, a happier and better informed product owner and a less stressed out scrum team! All in all, not a bad deal really.

As always, Paul

Self managed teams vs. command and control style project management

One of the most powerful, challenging and subtle principles of the Scrum process is the notion of self managed teams.   It does not take the experience of too many scrum projects, programs, organizations, etc. before it becomes clear that this change is nothing short of a true paradigm shift!
In larger organizations, the well developed command and control management structure and culture does not prepare new scrum teams with the awareness, skills and confidence to easily adapt to working on self managed teams.   On the contrary, many of the cultural mores go against the principles, skills and techniques required when adopting self managed teams.  One concept that is often problematic is the notion that the team (and therefore all of the Scrum team members) is responsible and accountable for the results of each Sprint.  In many organizations, accountability is more likely to be avoided or ambiguously shared then fully and clearly embraced.

Therefore once the basic scrum process, ceremonies, etc. has been learned by the team, then the more subtle capabilities required by Scrum such as self management begin to become more visible and noticeable.

Common sense dictates that if organizations and scrum teams want to enjoy the potential order of magnitude productivity improvements of the Scrum process they need to migrate from the command and control style project management (PM becomes a constraint to the productivity of the team) to the self management style where many team members can share in the planning, facilitation, follow through, etc. for the team.  In this case much more work can be planned and completed by the team when it is not single threaded through a traditional technical PM.

Fortunately, newly forming Scrum teams that have effective leadership and facilitation will be able to adapt to the principles of self management, shared leadership, etc.  Some simple techniques to help the team understand and develop these skill can include rotating daily stand up facilitation, requesting that various team members share in the defining and updating of work tasks, and  where every possible rotate roles within the team, etc.

In addition to removing the single threaded constraint an even more powerful benefit is that once the team begins to master the self management principles and behaviors, the scrum team can better align itself and ride the energy and inspiration of a number of team members instead of always requiring the PM to lead and drive in this regard. The end result of this transformation (yes, I mean transformation) is significant and much more sustainable over the long team (Less individual burn out).