The Agile Architect

To Think Agile, What's the Real Question?

Our Agile Architect analyzes a letter from a reader and answers the question that wasn't asked.

• By
• July 28, 2015

One of our readers sent in this note, which started me pondering:

How do you handle giving people deadlines for larger projects? While I'll give a deadline for a smaller project/fix, for a larger project, like a new Web site or an app, I'll only give them an estimate of when I think we'll get it done, but I never promise anything/give an actual date. Gets done when it gets done (although it's usually ahead of or at estimate).

I just feel exact dates are bullsh*t, and so I don't give them, instead I offer my honest take on time estimate. Often the people who are requesting the project don't like not getting a date, but that's how it is.

What do you do?

Dear Reader, this is a great question. I could spend hours expounding on agile estimation practices, discussing how estimates are just poor guesses based on "yesterday's weather," and how taking a more metrics-driven approach based on delivered value throughout the project allows you to measure reality and adjust accordingly. In many cases, it's better to just get started on the project and measure progress than to spend that same time guestimating to some imagined degree of accuracy. But I'm not going to talk about this.

Dear Reader, this is a great question. There's a ton of information we could discuss about how to measure the capacity of your team, learning to accept just the right amount of work to keep the team effective, either using time boxing (for example, Sprints from Scrum) or limiting work in process (for example, WIP limits in Kanban). But I'm not going to talk about this either.

Dear Reader, this is a great question. I could spend an entire article discussing the false assertion of the Management Triangle: "You can have it good, fast or cheap. Pick two." By focusing on quality in all its forms, including continuous improvement and skilled craftsmanship, you can speed up the delivery of product and increase delivered features. But I'm not going to talk about this either.

Dear Reader, this is a great question. It underscores the importance of effective communication with your stakeholders. But I'm not going to talk about this either. Well, maybe a little ....

Dear Reader, this is a great question. Fortunately for you, I'm not going to answer it. I won't answer it because there's a much more important question that is implied, but is not being asked. The real question to ask is, "What kind of relationship do you have with your stakeholders?"

Managing to fixed schedules, being commanded to give estimates, the statement "Gets done when it gets done" implies to me that, either implicitly or explicitly, you have an adversarial relationship with your stakeholders. They think they can get you to agree to something up front, then hold you to it regardless of the facts as they reveal themselves throughout the project. You are afraid to commit to deadlines for the same reason.

With an agile approach, we try to avoid the distance and disconnectedness introduced by an "us and them" relationship, favoring instead a collaborative "we're all us" continuous-interaction approach. It's not about someone defining a fixed target and then marching blindly to it. It's about using the development experience as an opportunity for everyone involved to learn, explore and adjust. By changing the relationship with stakeholders from "us versus them" to "all of us," we create an atmosphere where we can work together for the best possible outcome for the organization. In building something large, it's about the journey, not trying to know in advance exactly where you are going to end up. That journey should include the rapid deployment of small amounts of new functionality. This increases the frequency of feedback which in turn increases the pace of learning. From there, you all as an organization can together adjust and adapt appropriately.

So, how do you build this relationship with and between your multiple stakeholders? For me, it's about building a relationship around a shared challenge, with everyone owning the solution. By treating your stakeholders as partners in the development process, giving them insight into what the team is doing and how they are working, and allowing them to work with you in the decision-making process, you turn the relationship from adversarial to collaborative.

Making this change takes a lot of courage. After all, a key to this is providing transparency into what is happening, actively seeking guidance from your stakeholders and then embracing that guidance. Not blindly, of course, but as an opportunity to look at the problem from a different vantage point. It's amazing how many tense relationships I've seen turn around once we stop arguing about deadlines and instead start discussing features, priorities and options.

Most deadlines aren't real. Some are. Know the difference.

Some deadlines are very real. There is real revenue tied to it. Or there is an opportunity that is time sensitive (for example, a trade show). Or there are regulatory requirements.

Most deadlines are artificial, created by someone (maybe you) to generate a sense of urgency and/or to help others coordinate with your efforts. For the former, we have better ways to generate a sense of urgency using agile methods. For the latter, coordination with other people and departments is a real concern that can be addressed with transparency about your metrics on team progress, whether it is velocity, cycle time or something else. The question should not be: "Are we going to hit our date?" It should be: "On what date are we projecting to be finished?" or "What can we have by this date?"

In the end, keep your eye on the goal of the agile principle: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Delivering what people want cures most ills, quells uncertainty, stops rumors and helps foster discussions about what comes next, allowing everyone an opportunity to participate in the creation of something wonderful.