apm 6 3

Well, in case you haven't noticed, in the world of agile project management, we often focus on delivering value. But there are limitations on that, aren't there? I mean, there are just things we have in the environment, in the organization, on the teams, in the systems that are. Well, they're like constraints to our delivery. We've got some unique time constraints. So let's talk about the role of constraints in an agile project and hopefully we'll discover that they aren't always a bad thing. Don Reinerston, in his book the Principles of Product Development Flow, said, if you only quantify one thing, quantify the cost of delay. This powerful statement underscores the importance of understanding how constraints impact our ability to deliver value in an agile context. Now, constraints are limitations or restrictions we face in our projects like time, budget, resource or technical capabilities. And while constraints may seem like obstacles, they actually play a crucial role in shaping our decisions and maximizing outcomes. A few years ago, I was leading a team developing a financial software platform for a major finance company and we had this ambitious goal to launch the platform before the end of the fiscal year. That was our time constraint. And it's a good thing. It's a good thing to have a go live date. Initially, we tried to cram all the desired features from the product backlog, just push them right in. We prioritized them based on importance and hitting that go live date. But as we progressed, we realized that's not really considering the cost of delay. For each of these features, we more on what cost of delay is here in just a moment. We then shifted our focus to ordering the backlog based on the cost of delay, rather than just prioritizing features. This change, this sort of change in our perspective, it allowed us to identify which features would have the highest impact on our launch date, but also the highest impact of potential revenue. By quantifying the cost of delay, we were able to make informed decisions about which features to develop first and and which ones could be postponed. This approach helped us meet our time constraint while still delivering significant value to our client. Constraints act as boundaries within which we must operate, forcing us to be creative and efficient in our solutions. Honestly, as I've gained more experience and more perspective, I've come to really embrace constraints as a good thing. They help us focus on what's truly important. They can even prevent scope creep, which can derail projects. You are so smart. But look, it's important to recognize that like unrealistic or sort of false constraints, those can present risks to a project. For example, if we set like an impossibly tight deadline or severely underestimate the required budget. We risk delivering like a lame product or failing to deliver at all. That's why it's essential to express constraints clearly and understand their impact on value delivery. One powerful tool for managing constraints is the concept of cost of delay, which I touched on earlier. Cost of delay is the financial loss that happens when a product or feature isn't delivered at the ideal time. It shows how much value is missed for every moment a feature is delayed. To prioritize your work using cost of delay, rank features by how much money or value you'd lose if you delayed them, tackling the most costly delays first. For example, if you had a feature that you thought was going to generate $20,000 of revenue per month, well, the cost of delay is $20,000 for every month that you delay releasing it. Okay, this brings me to an important distinction. Ordering versus prioritizing. Now, prioritizing it typically involves assigning importance levels to items like high, medium, or low priority. And that's pretty common. But ordering, on the other hand, that involves arranging backlog items in a specific sequence based on multiple factors. Things like value, cost, risk, dependencies, and of course, priority. When we order our backlog, considering the cost of delay, we're better equipped to maximize value delivery within our constraints. Now, let's talk about how to effectively express and manage constraints in an agile environment. First, we have to identify and document all the known constraints as early in the project as possible. Easy things like deadlines, budget limits, but also things like available resources, technical limitations, or regulatory requirements. Next, we're going to communicate these constraints clearly to our stakeholders. And we're going to ensure that everyone understands the boundaries within which which the project must operate. And we're going to regularly review and reassess constraints throughout the project lifecycle. They might change. New ones might emerge. We want to regularly reassess, use visual tools like constraint boards or burn up charts to make constraints visible and track progress against them. And I want to encourage you think about constraints as creative challenges rather than roadblocks. Constraints can drive innovation. They can help create efficiencies when they're approached with the right mindset. Understanding and effectively managing constraints is crucial for maximizing outcomes in an agile environment. By quantifying the cost of delay and ordering your backlog accordingly, you can navigate constraints while still delivering the highest possible value to your stakeholders.