The Date-Driven Project: Cracking the Agile Paradox – Part 4 of 4

Of course we need tools and techniques to successfully manage a project, but we also need agreement among all the stakeholders — agreement on budget and schedule, agreement on functionality, and agreement on rules of engagement.

In this series, I’ve discussed some of the advantages and disadvantages of Agile methods, Scrum in particular. Pristine Agile methods are ideal for projects in which requirements are not well understood at the outset and require some iterative development to achieve clarity. We’ve also shown, however, that open-ended Scrum is incompatible with fixed deadlines, because with little or no functional definition in advance, the schedule is unknowable. Period.

One final common misconception about Scrum is that new requirements can slipstream in at each new Sprint, building incrementally on what’s already been accomplished. That may be true for small adjustments, but the impact of an innocent-looking change won’t always confine itself to future work. Often — very often — with or without a deadline, scope changes can derail a project by breaking or invalidating completed work. When business stakeholders demand a schedule, they must accept and acknowledge that Agile methods don’t magically bend time and space to shoehorn scope changes into the same continuum. That’s their end of the deal.

Software engineers are also on the hook. The only way to predict a completion date is by spelling out and estimating the work from start to finish. I know it’s difficult to convince road weary developers that estimation is a worthwhile exercise, but it’s unavoidable when you’re facing a deadline. One reason estimating causes engineers to experience anxiety is that estimates are too often seized upon by business stakeholders as a blood pact. But a project plan is a measurement, not a promise.

Engineers need to stop rejecting project plans as cudgels, and start recognizing their value as communication tools. A plan is a data-rich model. As quantitative practitioners, engineers should recognize the value of data in discussions of project scope and schedule, especially when that data is supported by proven experience and results. When business stakeholders inevitably need to insert new requirements, the project team will use the project plan to evaluate mathematically how scope changes will impact the schedule.

Given the added complexity, business stakeholders must choose whether a project actually must be date-driven. No question that many business initiatives are tied to the calendar by seasonal demands, competitive pressure, or as a consequence of budgetary constraints. However, business stakeholders need to weigh the tradeoffs between hard schedules and open-ended Agile development. Scheduled projects require more up-front effort and limit opportunity for revision during development, while purely iterative projects allow more flexibility to explore and shape a business automation solution at the cost of predictability. To be sure, these are two endpoints of a spectrum. We can tune predictability by choosing how much to plan vs. how much to work out in a “design build,” a euphemism for “trial-and-error.” What’s important is knowing that you’re making an explicit choice and why you’re making it, and then sticking to the accountability agreement.


Rules of Engagement – An Agile Covenant

Before we tackle a date-driven project of any significant scale, the stakeholders, both business and technical, must agree to the specific principles and practices used to plan and support the schedule. I propose we augment the Agile Manifesto with a balanced agreement among stakeholders:

Covenant for Agile Software Development

Agile methods elevate communication among stakeholders and increase product quality.

Agile methods are compatible with date-driven development, insofar as we plan for success.

Therefore:

A specific date demands specific requirements. The deadline for a project can be determined only when either the deadline supersedes the requirements, or the project scope is known at the outset.

Time is not elastic. When stakeholders ask a team to deliver by a specific date, they must accept that scope changes, however necessary they may be, will almost always impact the deadline.

Planning decreases risk. Initial planning is the best protection against scope and schedule changes.

Project plans are tunable. All stakeholders in a project, including the engineering team, must negotiate the schedule risk, scaling specifications and pre-planning according to the firmness of the deadline.

A predictable schedule begins with accurate estimates. Engineering teams must make best efforts to furnish accurate estimates, with uncertainty stated as plus/minus variance or in time ranges, and in time units (e.g. hours, days, or weeks) appropriate for that uncertainty.

Expect the unexpected. No matter how much we plan, we’ll always discover unanticipated requirements and obstacles. Leave room in the schedule to absorb change.


A successful project begins with common expectations and clear responsibilities, and ends with fulfilled needs and satisfied participants.