Monday, September 24, 2018

How to Budget For Your Company’s Technical Debt


Guest post by Dr. Mik Kersten


While “technical debt” is a term that’s frequently used by technologists, the implication and understanding of it tends to be opaque to the business until it’s too late - just look at how Nokia lost the mobile market that it helped create.

The business and finance side of Nokia had the usual tools for assessing financial risks - but why do we not have an equivalent tool for the operational or existential risks when the debts come from the more intangible investment in technology?

What’s technical debt?
Technical debt refers to the refactoring "shortcuts" taken in IT to meet requirements like time to value (TtV) and speed-to-market. Technical debt is like cholesterol; the more it accumulates, the more it impedes the flow of value.
Legacy systems are a perfect example of technical debt. We are all too familiar with that system that everyone dreads to touch and hopes that it doesn’t malfunction because any modifications to improve its business value will cost time and money. Yet the longer you wait, the costlier it will get due to lack of knowledge and support.

Speed-to-market pressures also increase the debt – such as first-to-market, responding to time-critical customer needs, and faster customer feedback to improve performance and value. Compromises are made with the notion of dealing with the consequences later.

Sometimes it’s as simple as realizing the technology or architecture chosen for a particular product is no longer scaling and needs refactoring. All of these technical decisions impact delivery speed and must be managed to ensure any future changes or products are not delayed. Taking on technical debt is not necessarily a bad thing, as long as it is understood by the business decision makers who put in place a plan for that debt to be paid down.

Why should the business care – isn’t this a cost that IT manages?
Technical debt additionally impacts delivery teams by bloating their work-in-progress (WIP) with neglected work. Neglected work can impact a team’s ability to focus and complete value-adding work. Less completed work leads to longer time to delivery, lower product quality, and less value, impacting customer satisfaction and business performance.

How can IT make technical debt visible to the business?
In a project-oriented view, where changes to IT systems are just another initiative, it’s difficult to prioritize and fund critical changes that will improve the speed of future changes. Yet software needs to go through a period of refactoring to maintain performance.

A product-oriented view enables the business to understand how all work interlinks, providing the ability to predict and fix for the impact of technical debt. However, you can’t measure what you can’t see, so it’s crucial to make technical debt visible. The Flow Framework – a new way of seeing, measuring, and managing product delivery – introduces two metrics that help increase visibility of technical debt:

Flow Distribution
This metric shows the distribution of the different types of work that the IT team has delivered, such as value-adding work like features and functionality, and revenue-protecting work like defects, security related work. Yet the more new functionality they deliver, the less time they have to do the other types of work like defect resolution, working on security features etc. It’s important to keep an eye on what the levels are for technical debt in this equation. Has the level of completed tech debt work fallen in the last few releases? If so, it is leading indicator of more defects/delays in the future releases. In addition, the Flow Framework expands on the notion of technical debt to include infrastructure debt (e.g., data centers and servers), and debt in the value streams themselves (e.g., lack of automation).

Flow Load
Flow Load is a Flow Framework metric that shows the amount of work that a team or seat of teams have taken on. How much work do they have and what proportion of it is technical debt? Is there a lot of technical debt left in the backlog accepted but unfinished because new work is taking precedence? Accumulating technical debt on the backlog can have an increasingly negative impact a company and its products.

Budgeting for technical debt
There are two parts to budgeting for technical debt.

1)   Correlating the impact of tech debt with value-adding work can help business understand its danger on the bottom line. Time and resources must be set aside every financial year to tackle technical debt as debt often accumulates due to a lack of funding and sponsorship.

2)   IT and business should look at trends that determine an appropriate level for when appropriate action must be taken to “pay back". It’s similar to the error budget in Systems Reliability Engineering that helps product development and system reliability teams work together on a level of unreliability that can be tolerated.

If technical debt is not actively monitored, it will gradually impact the flow of value to customer-facing products. Neglect the build-up and a cardiac arrest is inevitable. Make sure technical debt is visible and measured so that the business and IT can team up to proactively tackle and reduce technical debt to ensure a healthy product portfolio that can sustain the business.
Dr. Mik Kersten is the CEO of Tasktop and author of Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. For more information, please visit, www.tasktop.com.

Wednesday, September 05, 2018

Interview at Agile2018

A long-time colleague and friend, Dave Prior, interviewed me at Agile2018 about my presentation on being an agile coach at Toyota. You can find it here.

Thursday, August 09, 2018

Agile 2018 wrap up

I'm on my way home after spending the week at Agile2018. It's been a great conference. I reconnected with old friends, met some new ones, and attended some great presentations.

Monday's keynote was Dom Price (@domprice) from Atlassian. He shared how Atlassian tracked team health via their playbook. One interesting statistic he shared was that 78% of people don't trust their team mates. He also hit a theme that was repeated by many of the speaker; focus on outcomes, not outputs.
Focus on outcomes, not outputs
Wednesday's keynote was a focus on metrics by Troy Magennis. At first I considered not attending, but I'm glad I did. Troy talked about data as a people problem. He said a good way to get "crappy" data is to embarrass people. The data isn't enough, we have to be able to tell a story with it.

There were a number of other sessions that I took something away from;

  • Scott Ambler talked about architecture. A key message was that there are no "best practices" and the approach you apply depends on the context.
  • Tricia Broderick gave a session on facilitation. A point that stuck with me was that if we need to select mentoring or training or coaching based on the situation we're in and our desired outcome.
  • David Bland gave a session on experiments as they relate to new products. He turned the cycle in Lean Startup around and said we should start with Learn. From there, we decide what we want to measure, and based on that we decide what to build. 
This is just a snapshot of the fours days I attended. I have other notes and ideas of things I'm going to use when I get back to my "day job" of coaching. I recommend anyone looking for an infusion of new ideas to consider attending next year. 

Friday, August 03, 2018

Regression to the Mean or High Performing

I had an interesting conversation with one of my Product Owners this week. She thought that over time, planning poker values feel prey to Regression toward the Mean because human nature was such that people didn’t want to stand out and therefore tried to give estimates in line with what they thought others would.

I countered by saying if people were afraid to state what they truely thought the value should be, there is probably a psychological safety issue going on. The purpose of using poker cards during the activity is to avoid anchoring; having everyone influenced by one person stating aloud their estimate. 
After the conversation, another idea crept into my head. I tell teams that small stories are better. I am even a proponent of #noestimates in the right situation. So from this perspective, as a team moves towards high performance, they will get good at vertical slicing and that will lead to smaller stories, and therefore smaller estimate values.

So in response to the original statement, I don't think on a well-functioning team, the estimates are prone to regression toward the mean. However, I can see it happening on a team that is dealing with psychological safety issues. The real test is to watch the velocity over time. If regression toward the mean were happening, the velocity would be dropping over time. If the team is healthy, they will have a steady, or even increasing velocity. 

Friday, May 18, 2018

Illusions

I am still reading Daniel Kahneman's Thinking, Fast and Slow, and I came across an interesting quote
People can maintain an unshakable faith in any proposition, however absurd, when they are sustained by a community of like-minded believers. 
He used the example of stock traders, who think they are successful in picking stocks even though evidence points otherwise. Two out of three mutual funds underperform the overall market in any given year. However stock traders still believe in their approach.

I thought of the example of project management. I went to my first PMI conference in 1999. I was surrounded by like-minded believers in the waterfall methodology for project management, even though evidence such as the Chaos Report showed that our approach was not effective.

Will we see the same effect with agile approaches? Will we fool ourselves into believing we are successful even if the evidence suggests otherwise? Maybe not.

Philip Tatlock did research for his 2005 book Expert Political Judgment: How Good Is It? How Can We Know? Tatlock interview 284 people covering 80,000 predictions and even though these people were "experts" their results were worse then if these predictions were simply assigned probabilities. To compound the effect, the experts were very reluctant to admit that they were even wrong.

Kahneman sums it up pretty nicely. He says that the "errors of prediction are inevitable because the world is unpredictable." (p. 220) He goes on to say that short-term trends can be predicted but not longer term ones; though even the dividing line between the two is unpredictable. The implication to planning is clear; keep the planning horizon short and don't fool yourself into believing you are better than you really are.

Sunday, April 15, 2018

Priming

I'm working on the book Thinking, Fast and Slow by Daniel Kahneman, who won the Nobel Prize in Economics. As you might guess, the book is about how the brain works, based on years of research. He talks about the mind as two systems, the first being fast and intuitive and the second being more deliberate.

One of the ideas he discussing is that of Priming. Priming happens when something such as a set of words impact our thought and actions. He gave a great example of an experiment with two sets of participants. One set was given a set of words associated with being old (gray, wrinkle, Florida) and another group had words not associate with being old. They were asked to create sentences with the words. They were then asked to walk down the hall for the next experiment. The group with the "old" words walked down the hall much slower than the other group...these were all college students so it had nothing to do with their actual age. One group was primed; they had the idea of old planted in their minds and they acted differently because of it without knowing it.

In another experiment, people were asked to put money into an "honesty box" based on how much coffee or tea they drank. There were different posters placed on the wall above the money box. On weeks when the posters had eyes looking down, people paid more money than on weeks when the posters were of flowers.

Think of how easily priming could impact a team. Imaging a team trying to overcome a complex technical challenge such as getting a test case to pass. They aren't sure why it isn't passing and they are discussing solutions. One person's comments could lead the team all in the wrong direction without them even realizing it.

So how do we combat this? The reason priming happens is because our fast, intuitive mind takes over. To combat it, we need to rely on our more cognitive side, which Kahneman points out is also lazy and willing to let the intuitive side run the show. For this imaginary team, using a red teaming approach might work, or an analytical took such as Five Whys. Anything that will get the team to look beyond intuition and engage their more deliberate thinking patterns.

As far as Thinking, Fast and Slow, I'm only about a quarter of the way through and have come across a lot of interesting ideas, so I am sure I'll have more to post on the book.

Tuesday, March 13, 2018

Team of Teams

I recently completed the book Team of Teams by Stanley McChrystal, a retired Army General and former commander of the Joint Special Operations Task Force, operating in Iraq. It's the story of how he transformed that command in order to more effectively execute their mission.  

The book explores the ideas of complicated and complex. I kept thinking about the Cynefin framework, though McChrystal does not specifically mention it in the book. The book starts by talking about the work of Fredrick Taylor around the start of the 20th century (complicated). He then gives some examples of complex problems. My favorite was the introduction of the cane toad in Australia.  

The book then goes into how McChrystal moved his command away from a strict command structure and to a team of teams structure. This change made them more resilient, allowing them to more effectively respond to the enemy.  McChrystal makes a point to show how efficient and resilient are on opposite ends of a spectrum, and being resilient was more important than being efficient. The move to a team of teams was done by cross-pollinating individuals across teams. There was also a liaison program to work with external organizations.  

The parallel between Team of Teams and John Kotter's book Accelerate are interesting. Both recognize the hierarchy can't support today's environment. McChrystal saw the team of teams as a way to be more resilient so that the organization could respond quicker to threats. Kotter viewed it as a way to implement strategy. In both cases, the hierarchy remains, but it is supported by the teams.

The agile world is catching on as well. The Scrum@Scale guide references McChyrstal's book when describing the Scrum of Scrums. I've been trying to build this with my teams. For example, shifting from a status meeting where people report to the manager one at a time while everyone else has their nose in their computer to everyone interacting and building a shared consciousness. The first step, banning computers from meetings so people pay attention.  

Another idea I'm trying is similar to how Spotify uses guilds to share across teams. I'm bringing together developers from across all the teams to discuss technical topics of their choice. We kicked off the initiative by creating an operating agreement, identifying the topics of interest, and picking a topic for the next meeting. I believe this can lead to a number of outcomes: a better shared understanding of the department's work, the ability to move developers more effectively from one team to another to meet changing priorities, and improving skills across all the teams...again, along the line of team of teams.

I recommend Team of Teams for anyone that is working with more than one team and trying to figure out how to create a resilient organization that can keep up with a rapid pace of change.