This WoLF profile (Works on the Last "Fire"/Issue, Works on Latest Fire) is generated, either by the person's own motivations that are poorly focused or by a direction of the teams in disparate directions. In any case, they always produce additional work solving problems that are not paid attention to along the way until sooner or later they must be faced with the consequent economic cost and loss of opportunity, among others.
If with software development you wanted to create a movie like the ones about the mafia, the argument could be the following:
…Julia, the owner of "The Home for the Care of Abandoned Bambinos" wants to save it from foreclosure, and it occurs to her to quickly implement the new game app "Abandoned-Child Finder" in time for the holiday season. Her hope is that the subscription and advertising revenue saves the day for the orphanage. Unfortunately, for her app to come out on time successfully, she cheats a bit by taking responsibility for a technical definition debt resulting from an incentive stacking item for epic level players. Everything seems perfect, the home for the children seems safe, its tenants are once again rehearsing for the annual Christmas contest…until Carmen from Customer Service makes a bug report that would put a stop to that optimism and ruin the income related to said debt. definition. Because Julia's team is already on track to deliver the new features needed to raise venture capital, they ignore Carmen's report... that is until Luis, the technical debt collector, the Scrum among Scrums, with a bright red Post-it® note … nailed to the end of a baseball bat. Needless to say, the rest of the movie implies that Julia spent her days figuring out and then ironing out all the implications of not having fixed those definitional errors in the first place, siphoning off the app's revenue needed to prevent the kids from being dumped. to the cold on Christmas Eve.
Yes, it is evident, a very used cliché, but very familiar to product development professionals. It is clear that Julia is doing WoLF duties. If one or more profiles are added to this profile PUFFIN (Plans unending feature factory Initiatives) the chaos and conflict is already that of an apocalyptic movie.
How you get to this situation
Like our heroine Julia, we also put aside the technical debts with the promise that we will pay it later, when there is more time.
The problem is that there is never enough time for various reasons. Some real examples could be the following (without names or easily identifiable details of course):
- The VP of Incredible Sales has promised the Big Fish customer the "XYZ" feature by a fixed date that was likely offered with minimal consultation from the team responsible for delivering the products.
- The anxious venture partner looking to exit wants to make sure a certain domain or vertical is covered before the next IPO.
- The bored programmer building their resume needs hands-on experience building API-driven BI reports delivered using Angular, leveraging the latest in machine learning technology on an Apache Spark cluster.
- The Promotion-Hungry Product Owner who wants to wow the boss with great front-end features in the four months leading up to their performance review.
They all sound like candidates for non-data-driven prioritization, which will come with a potentially huge price to pay and a huge opportunity cost.
So why do we rationalize it like that? Perhaps because working with technical debt is fun, for the first week or so. After that, it becomes a sinister game of bribing and extorting teammates, plus scamming some other unsuspecting team member into doing the dirty work.
How to avoid reaching these scenarios
For those (few) who have yet to experience the 'joy' of a visit from a friendly technical debt collector, it's worth keeping in mind these 7 principles to pay attention to during the process.
Support, investigate and prioritize these principles or situations:
- If an engineer is struggling with technical debt to finish a job.
- If you create a feature with an obvious User Experience (UX) debt.
- If research is required because data did not exist.
- The work is not contributing to customer value, when it was planned to happen.
- A story was published and then it was necessary to play to justify what was said.
- Failed to validate impact.
- You get the idea, but you're still creating more tasks, redoing them, cutting functions, increasing the operational load,... with each step it becomes less impressive.
Boldness and sincerity is essential in taking action so that the team, management, stakeholders, sponsors and, if possible, customers are aware that future versions of the product or service will include the debts incurred. At least it is necessary to establish a correct management of expectations explaining the "unfortunate accidents" that could occur if the responsibilities acquired are not paid.
Whether you decide to simply pay the interest or pay in full, keep in mind that, much like a loan shark, the price of your technical accumulation will likely increase in cost over the period of time it remains unsettled.
References
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations' — Nicole Forsgren & Jez Humble
- 'The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations'— Gene Kim, et.al.
