Recording date: May 17, 2021
Nick and Chris are joined by Olivier Jacques, a Distinguished Technologist at DXC and CTO in DXC’s application services department in France. Recently, Jacques wrote 6 Strategies to Set Time Aside to Improve, an article that spells out six ways to approach technical debt reduction.
Olivier thinks that policy debt, technical debt, security, debt, infrastructure, debt, and other debt types are something that must be paid attention to, but he was wondering why we don’t seem to have the time to address them - we are either too busy, or we don’t have the management support, or sometimes we don’t even know where to start and what do we improve. So he set out to write up some strategies he feels will help.
Following recent conversations, I wrote an article on "6 ways to set time aside to improve". https://t.co/zJz5CgxQH5— Olivier Jacques (@ojacques2) May 5, 2021
We don’t easily know where to start, but he thinks where he saw the biggest struggle was perhaps in explaining to management and leadership what it meant to reduce tech debt, and how to organize a team to make sure that ted debt is not something put on the back burner and forgotten.
First, Olivier came up with The Six Ways, but he wants to be clear that after hearing from many readers, he isn’t saying there are only six ways - we can definitely add many more.
In setting them down, Olivier created two buckets of activity: Work (W) and Improvement (I). He models his Six Ways on the example of the agile scrum team, running in a two-week sprint cadence. And within those two weeks’ worth of sprint, the question is, within this cadence, how can we build in time for I while conducting W.
He makes the assumption is that there is a commitment somehow somewhere, maybe by idea, the product owner or the leadership to explicitly say that they want to improve, and they they are willing to spend 25% of their capacity to do just that. Again, this is a rule of thumb; some teams may not need to spend that amount of time to reduce technical debt. And some teams may be in a state where they actually need to spend way more time in reducing tech debt.
A twenty-five percent improvement on top of everything else. This is not a place where you want to be, because you end up having a very extensive days, obviously, but, but at the same time, it’s very often the expectation from management. There’s often a sort of base-case assumption as the team is just taking care of managing tech debt on the, on their own. Some of the engineers I’ve been speaking to in the past few weeks feel strongly feel that it’s their responsibility to manage tech debt – that this management shouldn’t be actively visible to product owners or other forms of management.
This may be an anti-pattern, but the Second Way is spending 100 percent of your time improving. Olivier calls it Panic Mode.
Say you’ve got a natural slump in the business cycle at your company, or just a period where it is natural to slow down; you might consider spending 100% of a sprint on burndown.
The fourth approach is the Rolling Improvement model. In this strategy, we, we spread evenly who is going to work on improving technical debt. Olivier made a simple algorithm that basically has all engineers spending 25% of their time within a given sprint on tech debt, staggered so that most of the engineers are on their 75% of normal work while a small portion dips into and out of the 25% burndown role.
Nick likes this one, because it lets us not feel like we are throwing our hands up in despair and saying that nothing works, which executives don’t like to hear and, frankly, they’re right in saying that, but it also allows engineers to tend to the garden of things that need to be tended while folding in normal work; he thinks it’s a little bit less disruptive than some of the others Ways.
The fifth way is that everyone spends 25% of their capacity each day – two hours of every eight - on improving. All three like the idea, but Nick points out that it assumes that engineers have eight hours a day to code, which is fantasy. He mentions the large and increasing burden of meetings (citing specifically Steve Glaveski’s terrific article, The Five Levels of Remote Work — and why you’re probably at Level 2) means that you never really have anything near eight hours.
Chris mentions the current joke about “this meeting could have been an email”, and Olivier says that too much work in progress is really terrible for flow. He cites Joel Spolsky’s classic 2001 essay on the subject, Human Task Switches Considered Harmful.
Which brings us to
One sprint of four focuses on tech debt burndown. This is Olivier and Chris’ favorite, and Olivier says he can really rally the team around this vision. They started really looking forward to this one sprint every four that is totally focused on improving and reducing technical debt. No interruption, unless a catastrophe arises, and we get management back up to, to really say, yes, this sprint, we understand you are working on the reducing technical debt.
A technology enthusiast and DevOps transformation principal at DXC Technology, Olivier Jacques specializes in DevOps, software engineering, inner source and open source practices. He created DXC’s DevOps dojos, events and practices that combine training with hands-on labs, gamification with badges, and guidance from DevOps coaches. Olivier is a frequent speaker at DevOps and software engineering conferences.
Chris is a frequent speaker on topics such as serverless, DevOps, cloud, containers, security, networking and the Internet of Things. He’s also a cloud editor for InfoQ and a contributor to open source projects such as Docker, CoreOS and DXC’s Online DevOps Dojo.
Nick is Chief Security Officer at a financial technology firm, and was formerly an NYPD Intelligence Bureau apparatchik. He is co-author of many books, including Cyber Attack Survival Manual; In Context: Understanding Police Killings of Unarmed Civilians and Blackhatonomics: An Inside Look at the Economics of Cybercrime.