Technical Debt Ceiling

By -
With all the yammering from politicians about the debt ceiling this seems like a good time to talk about technical debt.
Technical debt is a metaphor.  Just as each of us incurs financial debt in life (sometimes recklessly, other times prudently), software gets released to production with some corners cut.
The idea that no shortcuts will ever be taken is impractical.  Scrum teams own their solution decisions, including feature coverage and code quality.  Rather than semantic or dogmatic arguments, teams use tools, apply standards and work together (including acceptance criteria, pair programming and code reviews) to release the best quality at the right point in time.  Here's a matrix to help frame a view of technical debt:







We make deliberate, prudent decisions to ship software because we know it will provide value to the business and we want to deliver value as soon as possible. We introduce technical debt inadvertently because sometimes we just don't know what we don't know. (There's no excuse for recklessness; people who don't understand layering die miserable deaths in the cold and get eaten by wolves.)
The key to the metaphor is understanding that, just as financial debt burdens, limits and controls options in life, technical debt burdens, limits, and controls options for product managers and software engineers.  No responsible product manager, engineer, or business process owner would allow a fragile solution to persist for long knowing the associated risks.  A warehouse worker may use duct tape or wire to hold together a shelf or part of a conveyor for a short time (it's cheap and allows work to go on for a short time) but those are only stopgap solutions.

I grabbed this helpful graphic from a post on feature flag management that mentions technical debt in that context:

Rally's help section offers this advice on completing work in an iteration:
Why should all defects be closed before a story is accepted?
When creating a definition of Done for user stories, it is recommended that teams require all defects on those stories be closed before accepting them. Since an accepted story represents a completed slice of functionality, any defects attached to that story represent technical debt and should be resolved during the iteration.
It is good practice to test user stories as soon as they are ready. If additional time is needed to resolve a found defect, the team should consider doing so before starting other stories in the iteration. If the resolution of the defect requires a significant amount of time, the team should not release the associated user story, and consider the necessary work as part of the next iteration’s estimation. Overall, it is better to deliver a single completed and fully tested story, as opposed to delivering several incomplete and untested stories after an iteration.
Why should all tests pass in an iteration?
In addition to acceptance criteria, test cases represent the overall quality and acceptably of a completed user story or iteration. You can create many types of tests: acceptance, performance, regression, functional, usability, and user interface. All of these types of testing are highly valuable in defining Done for any agile development team. As your team integrates these different tests into its daily routine, it becomes increasingly important that all tests are passing before the end of the iteration. In addition, as many tests as possible should be passing when each story is completed as part of the acceptance process.
As you get closer to the end of an iteration, the fewer tests you have completed, the higher risk you have that your commitments will not be met. Incomplete tests represent the risk of hidden defects that will then lead to technical debt, and possibly disrupt future iterations.
At the end of the Sprint, as the team reviews the latest work its completed, they note areas of the code or product where risk persists or has been introduced, and discuss strategies for reducing risk and managing the overall defect and technical debt limit of the product.
If the team seems to be satisfying its current Definition of Done but still finds the defect level climbing after each iteration, perhaps its time to review and update the Definition of Done in the next retrospective. Agile supports the evolution of the Definition of Done to address latest learnings and and support continuous improvement.

Comments

Post a Comment

Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

By -
Defects and Risks are often dealt with in a subjective, emotional way.  That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue.  The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Read more

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

By -
Image
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization.  I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization.  Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
Read more

Chatbot Code of Ethics

By -
A  NYTimes article  describes efforts by a consortium of the largest technology companies to create ethical standards for AI. A related article in MIT Technology Review is titled  AI Wants to Be Your Bro, Not Your Foe . Artificial Intelligence has reached a level of sophistication, and is on the brink of being so pervasive, that we can have these serious conversations. In my work developing AI-powered chatbots to assist with learning, I work within the bounds of these 7 precepts: Right View - our chatbots honor humanity, human dignity, and the human quest for knowledge, understanding and technological innovation Right Intention - our chatbots promote human progress in the areas of intellectual pursuits and personal ethical development Right Speech - our chatbots use encouraging, prudent, and situationally appropriate language Right Action - our chatbots perform with integrity toward the aforementioned right view and intention Right Live
Read more