Agile Artifacts: Tradeoff Matrix
Have you ever had to compromise your work-life balance or product’s quality in order to ship a feature on time? Have you ever added people to a project, only to find that it made your project later?
If so, the Tradeoff Matrix is for you. In this 3-minute video, you’ll learn a powerful technique for coming to agreement with your stakeholders as to what to do next when things inevitably don’t go as planned. You’ll protect your product’s quality… and your sanity.
When working on a software project, there are four key levers that you can manipulate: Scope, Schedule, Resources, and Quality. Scope is the total quantity of functionality and features you develop. Schedule is when you make your releases available to your end-users. Resources is the number of people and teams working on your project. Quality is the quality of your project, including the number of bugs, documentation, amount of technical debt, and the degree of automation in your code.
Let’s take quality off the table as a lever right from the start. In the long-run, quality is free. This is because if you compromise on quality in the short term to ship a given scope on a given date with a fixed number of resources, you will incur a lot of technical debt that makes development slower in the long run. So never compromise on quality. You don’t need to over-do it, either, but find the right balance.
That leaves scope, schedule, and resources. We don’t have much information at the beginning of a project, so any predictions we try to make about the delivery of a project will be wrong. In the beginning of a project, these estimates can easily be off by a factor of 4 or more. So if we try to fix scope, schedule, and resources, we will almost certainly have to compromise on work-life balance and quality. Neither of these approaches work in the long run.
The best approach is to negotiate with stakeholders in advance as to what will be fixed, firm, and flexible with respect to scope, schedule, and resources. Only one of each can be fixed, firm, and flexible. Therefore, there are 6 possible approaches.
My favorite approach is fixed resources, firm date, and flexible scope. I like having fixed resources because–according to Brook’s law–adding people to a late project makes it later. This is because it takes time to ramp people up, additional people on the team produces a combinatorial explosion of communication overhead, and the work is not necessarily divisible further. Having a firm date keeps stakeholders happy and gives us a healthy sense of urgency. We can always choose to move the date later if we wish. Finally, having a flexible scope demands that we think very carefully about incremental value delivery and user-centric, iterative software development.
Take the time to talk to your team and stakeholders about the Tradeoff Matrix today. Then you will know exactly what to do when “push comes to shove” and you need to make tough decisions together.