Is technical debt compromising your team's sprint commitments?
Sometimes we need a process change. We are Agile, after all.
There are 12 principles outlined on the Agile Manifesto.
Two of these principles are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The journey towards adopting these principles for well-established legacy product lines with many teams and dependencies is often a long, challenging road, analogous to taming a dragon.
A step we have taken at Pega is to create more frequent potentially releasable builds throughout development, rather than cramming production-ready quality checks into a period of time for a determined release date.
Before this change was instilled, the majority of issues would be found and addressed during Alpha/Beta cycles. This period of time, called hardening, occurs leading up to a release date. Hardening was anticipated by the teams and planned accordingly.
Many issues are found earlier now that the process change has been implemented. This improvement causes teams to compromise sprint commitments to address high-priority issues throughout development rather than just during the anticipated hardening phase. This change quickly shed light on technical debt that needed to be paid off before a state of continuous releasable builds could be realized. Now we have faster delivery of new functionality.
And what about our Pega team?
Team Dragon Whisperer is one of our many teams who had been feeling this pain. Their sprint commitments had been compromised for three sprints in a row. They were burning out from firefighting, when they’d prefer to spend their time working on new features and improvements to their code base. As a result, they made a pledge to see what they could do to catch up on technical debt and prevent it from building moving forward.
They held a retrospective to focus on quality issues, and held sessions after each sprint to look closely at the specific problems addressed. The root cause for many of these issues pointed to lack of quality code and lack of testing. These are two common challenges when working with legacy code. They realized they needed both a long-term plan to minimize technical debt and a short-term plan to help triage high-priority issues as they come up, all while staying focused on completing sprint work.
For the long term plan, they honed in on a set of five values to guide their work moving forward:
- Quality comes first – We will not compromise quality for the sake of expediency, regardless of the work.
- We will always leave code better than we found it.
- We will attempt to strictly apply the Three Laws of TDD as described by Bob Martin for all work that we do (feature work, bugs, refactoring).
- Write no production code, except to pass a failing test.
- Write only enough of a tests to demonstrate a failure.
- Write only enough production code to pass a test.
- On the rare occasion that a true unit test cannot be written, two other team members must approve the exception.
- Before any code change is merged, there must be a code review:
- This must be done in a timely manner (preferably within four hours, but at least within eight hours).
- If there is a question or a change needed on a code review, we will indicate this in code reviews until the code is satisfactory.
- If code changes occur after approval, new approval is required.
- Smaller changes in more branches is better than one large merge with lots of changes. This makes reviewing code easier.
These values are in direct support of another principle behind the Agile Manifesto:
- Continuous attention to technical excellence and good design enhances agility.
Over time, this dedication results in higher quality code and less high-priority issues.
In the short term—until the fruits of their labor for putting quality first will be realized—they decided to dedicate one full time team member, rotated on a sprint-by-sprint basis, to be the point person for responding to high priority interruptions. If the point person is caught up addressing issues, the rest of the team is free to pick up stories focused on reducing technical debt (Evergreen). If the point person becomes overwhelmed with too many issues at one time, another team member could be pulled in to help as needed. Having one point person dedicated to addressing interruptions and making improvements to the code base each sprint will help reduce overall technical debt and allow the rest of the team members to focus on sprint commitments.
These experiments are in the early stages, and we look forward to reporting back on the effects as a result.
What are some things your teams have done to tame your Legacy Code Dragon? Post your comments in PegaBuzz with the tag #Agile@Pega to join the discussion.