With Agile, Trust Teams To Meet Objectives, Not Dates

More and more organizations are moving to Agile because they see it as a silver bullet for completing projects faster. But Agile is not about going faster. It’s about focusing on objectives, removing waste in processes, and accommodating necessary changes along the way. Unlike the tightly packed, cascading plans of traditional projects, Agile roadmaps provide only general guidance. And because Agile expects requirements to change as new information becomes available, predicting completion dates can be difficult—think of them as projections, not commitments. When organizational leaders remain fixated on deadlines and timelines, it demonstrates a lack of understanding and trust in the Agile process. Left unacknowledged and unchecked, this behavior can undermine Agile teams’ ability to be successful. Through our work managing hundreds of Agile projects, we’ve seen—and helped reverse—this dynamic up close. How? By helping leaders reframe their perspective and reset their expectations so they can build trust in their Agile teams and the processes they follow.

Understanding How Agile and Waterfall Differ

The Waterfall methodology is designed to have a fixed scope, but variable resources, and time to deliver a release. This approach works because a large portion of the overall project is dedicated to getting the requirements right. It is easier to decide how many resources you require once you know when it needs to be accomplished. Changes to the project are done through change requests, which then trigger a request for additional budget to either bring on more resources or extend the release date.

Source: Adapted from “The iron triangle and Agile,” R. Nagappan, 2020

Agile, however, is designed with fixed resources and fixed time limits—only the scope is variable. In Agile, requirements are written iteratively based upon what was learned in the last time increment. The goal is not to continually complete a project but to continually build a product over time. When changes are introduced, the scope of the requirements is the only thing that can change. This change occurs in terms of descoping some features to add in others.

Agile has set time boxes that never change. And Agile always delivers on its dates. However, what is delivered is subject to change. It’s the fluidity about what precisely will be delivered that’s the challenge for Agile. It’s like saying we will be building a house, but the details of each room and configuration are not blueprinted up front. As the house owners learn more and prefer some features over others, the final product will change. Since the budget is fixed, the owner cannot accommodate all their changes, but instead must prioritize one feature over another. In the end, they won’t get everything they wanted because they didn’t know or articulate it initially.

Agile asserts that non-essential functionality within scope can and should be sacrificed to deliver higher priority items. This decision requires prioritizing scope in a continuous, iterative, and collaborative process. It allows new information uncovered through ongoing collaboration to result in adaptions of the priorities. In this way, functionality with the most significant business value is prioritized for delivery first, and elements outside the core functionality are prioritized last.

Why Do Leaders Ask for Dates in Agile Projects?

Fundamentally, it’s a trust issue. Leaders want specific dates and detailed roadmaps because they don’t trust that their vision will be executed the way they want it or when they want it. There could be mistrust stemming from various reasons, not the least of which is conditioning. Many leaders have been taught to trust by verifying. Others have traditionally been rewarded for completing projects—the faster the better. Leaders fear that if they don’t put this level of control in place, the right decisions will not be made and that will reflect poorly on them.  If as an Agile project manager, you’re constantly being asked to manage to a deadline or update a roadmap, it’s most likely a sign that leadership doesn’t understand how the process should work. This lack of alignment is not uncommon, but successfully addressing it requires new ways of thinking and behaving. And old habits can be hard to break.

Changing Leadership Expectations: Alternatives to Dates

How can you get the entire team on the same page, embracing Agile, and feeling like they’re working in the right way? The first step is to understand where leadership is coming from. They are used to, and find comfort in, the dates and details of each phase in a project. Agile scares them because it lacks this level of certainty—even if the roadmap tumbles like dominoes as soon as something changes, they at least had one in the first place. It’s this combination of uncertainty and fear that drive leaders to press hard for dates and line items. And because implementation teams don’t want to let their stakeholders down, they typically don’t push back.

It’s imperative for teams to start the conversation about dates before Agile transformation starts. Is there an actual deadline, a valid constraint that everyone needs to know? In Agile, the only thing you can control is the scope of work to get to that deadline, so it’s critical to talk less (or not at all) about dates and more about what needs to happen. Stakeholders’ requests can still be part of this discussion, but not in the context that they will be completed on a particular date. Setting clear objectives—the things that need to happen—is the alternative to dates in Agile. Once everyone starts working with objectives instead of dates, and understands why they’re doing a specific item, leaders can trust the team to make the right decisions.

What about Scope Creep?

The dreaded term “scope creep” in the Waterfall approach doesn’t exist in Agile. It’s just new priorities. A principle of Agile is to be very open to change, so regardless of how late into the project you are, changing requirements are welcome because that new information can make your project better in the end. But the freedom to make changes comes at a cost: To complete the new work, something else needs to move down in priority or be descoped. Teams can agree to pivot when it makes sense (in service to a need or objective), rather than feeling like some change was imposed. In the end, it’s not about missing a deadline (and making the team feel badly about it), it’s about accommodating change to deliver a better result.

A New Way to Communicate Progress

Once you stop talking about deadlines, and focus on objectives, some of the fear around discussing progress should abate, but it requires a new way of communicating. In many scaling frameworks, we commit to increment objectives, but those are not the same as deadlines and the team needs to clear about the difference. The same goes for requests for estimates on dates, which can be misinterpreted as deadlines. When these misunderstandings happen, it can leave leaders disappointed and team members afraid that the information they provide will be taken out of context.

Agile teams often know that they will not hit a commitment ahead of time, and sometimes avoid bringing the delay to light. But for Agile to be successful, teams need to continually estimate as new information comes in and reset objectives as necessary. Changing this pattern of behavior comes back to trust. If you trust your teams and the objectives you’ve collectively set—and the teams trust that there will not be any backlash—then they will feel safe being transparent about both progress and setbacks.

Adapting to Agile Requires Trust

It’s important to realize that Agile isn’t fit for every organization or every project. If your culture and business model demand fixed completion dates for every project on a roadmap before the work kicks off, then Agile is probably not for you. But if you do decide to give Agile a go, you need to adapt to how it works—not the other way around. That means:

• Leaving the obsession with dates and deadlines behind (and the culture of fear that can come with it)
• Focusing on what’s most important to the achieving the objectives you’ve collectively set
• Embracing change and the prioritization choices required to accommodate it; and
• Communicating the good, the bad, and the ugly—always

Leaders that move to Agile frameworks without moving their mindsets, only stand to gain a frustrated team and subpar outcomes. Instead, enter the Agile arena with an open mind, set your teams up for success, and trust them to make the right decisions.