A Different Approach To Estimation & Tech Debt Prioritization
10 May, 2018
VP, Technology at ThoughtWorks
Many years ago I was leading an engineering team of about thirty people who were working on a five-year program replacing an old legacy system in a large enterprise. We had a program manager who didn't really understand the technical details of what we were building and was managing 'by the numbers'. The program manager was plotting the team's estimates in MS Project and using that as a contract to punish the team when any estimates were incorrect. Some might think this is a reasonable approach, however the team was juggling building the new system, while maintaining the existing system, and fixing tech debt along the way - all in a very complex domain. The program was behind schedule, the Program Manager was not happy, and the team was demotivated. We needed a new approach.
As we stepped back to analyze the problem, we realized that we had 'work requests' coming in from three different avenues; new functionality that the business wanted, operational issues (i.e. bugs) within the existing system, and a lot of tech debt that needed to be resolved as the team was moving quickly. The challenge was building a roadmap that accounted for all these inputs. The team came up with the hypothesis that it would be easier to manage the prioritization and development of tasks if we broke everything down into similar size work units, instead of estimating tasks. In order to test this hypothesis, the team went through the exercise of breaking down all the current feature requests into similar size chunks. If there was a big problem we would break it down into smaller pieces to make everything, as much as possible, the same size. Next, we put everything into a backlog - all similar sized chunks of our new features, operational issues, and tech debt. We then developed a few of the similar sized tasks to get a sense of roughly how much effort was required to complete a task. When we had a good sense of the tasks and similar sizing we were able to create a backlog which the business stakeholders could prioritize effectively and the program manager could build a roadmap of predictability. This brought to light another challenge of articulating the value of resolving tech debt to the business stakeholders, who constantly prioritized new features and resolving operation issues over cleaning up tech debt. To resolve this, we split tech debt into two categories; (1) small refactorings which we could complete in between feature creation tasks and (2) large modernization projects which required more analysis and effort. For example, there was one area of the codebase which over time had grown large and messy. We needed to refactor it into a smaller set of independent services, however this was no small project. Instead of trying to squeeze it in between other tasks, we created a business case identifying the effort required, the risk to the business if it wasn't completed, and the efficiency gains they would get from the engineering team if we were able to complete the work. We then presented the business case to the project stakeholders and got approval to add the modernization tasks to the prioritized backlog.
Firstly, as we broke down our work into similar size units, we continued to estimate against these work units, so that we could compare and contrast the results once complete. Upon comparison we found that the team was much better at same-sizing tasks (pattern matching) than it was at estimating. As an engineering team that's faced with tech debt, it's important to be able to identify the effort required, the risks of not doing the work, and the efficiency gained in a business case. This allows the business to make an educated prioritization of what work to do when.
Marc LeBrun, VP of Engineering at Flow Kana and a co-creator of the Apple Mac, recalls how one of his early prototypes failed to meet the original intent but how that failure turned into an unanticipated opportunity.
VP Engineering at Flow Kana
Alessandro Pintaudi, Product Management Director at Payfit, talks about how teams need to focus more time on building the right things and how to keep doing it with scale.
Product Management Director at PayFit
Maria Petrova, Principal Product Manager at Zalando describes how she built an organizational design from product and stack in a way that tech and product effectively function in a collaborative environment.
Principal Product Manager at Zalando
Gourav Chindlur, CEO at Tercept, shares his experience of scaling his company in multiple markets and ensuring the right information flow between the headquarters and multiple geographies.
CEO at Tercept
Peter Maddison, Founder at Xodiac, delves into all the important details of moving legacy applications into the cloud.
Founder at Xodiac
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.