So I’m reading The Slight Edge, a pretty awesome book by Jeff Olson, and it is dawning on me how his basic principles apply to Agile.

One anecdote that he mentions several times is that when a rocket is flying to the Moon it is actually off-course for over 90% of the time. Now that sounds crazy, except that it’s continuously correcting itself. So it’s not like the rocket is shooting off in some random direction most of the time. Instead the rocket keeps correcting, adjusting, pointing its nose towards its target, but invariably every few seconds or minutes or whatever it’s off course again, so it has to correct itself.

For a very long journey, if you are even just a little bit off course at the beginning, even the tiniest bit, unless you correct your aim by the time you get to the end you might miss your target by A LOT. So if this is true, why would you build a rock-solid, immutable plan and requirements baseline at the beginning of your journey, and then never correct?

Ever hear the saying, “Plans are useless, but planning is indispensable”.  Dwight D. Eisenhower, supposedly. Creating a plan is valuable and important because it forces you to start to understand your problem space, your stakeholders, break down the work packages, etc. But actually creating a detailed plan at the beginning, that plan will probably be pretty wrong by the end of the project.

By now you’ve probably guessed where I’m going with this. If there’s no sense in creating a super detailed plan that can never change, then don’t! By all means create a requirements baseline, but be ready to course-correct very often. For each Sprint, take the time to review the requirements and ensure that you are still pointed in the right direction. And don’t be afraid to adjust or change something. The issue is that typically project management thinking identifies high requirements volatility as a risk factor for failure. So how can you reconcile these two lines of thought?

Write Your Scope-Level Requirements as User Experiences

I’m not saying that you should be willing to just change any requirement willy-nilly. It would be ridiculous to have a requirement of “Build a Vehicle” and then halfway through the project change it to “Build a Football Stadium”. The big-picture scope needs to stay the same. But if you write a top-level requirement as “User needs a laptop app to do X” and then discover that you need a mobile/smartphone version, then now you might have to deal with that impact.

So a better approach? Don’t dictate solutions as your top-level requirements. Instead, narrate user experiences. “Users need to perform function X”. Now if the requirement wavers between a desktop, laptop, and mobile version, then that’s ok because your original scope didn’t change. Any learning and research you’ve done on how “function X” works is still completely valid.

Course Correct Frequently

There seems to be an innate desire in people to have full understanding of the entire project space, as well as a full understanding of the entire solution, very early in the project. But in the fast-moving world of business and technology it’s likely that a) the state of the technology and/or business will change during the project lifecycle and b) there will be emergent behaviors, processes, and user needs that aren’t known at the beginning and won’t be discovered until the solution is being developed. Hence, the existence of Rolling Wave planning and Agile methodology.

One of the key principles of the Agile Manifesto is “Welcome changing requirements, even late in development”. If your rocket is off-course, then adjust! Don’t keep traveling in the wrong direction just because there’s resistance to changing the requirements baseline. That requirements baseline is useless if you are off course and miss the target.

And make sure you do this frequently. If you only perform a requirements review once late in the project, then you might discover by then that you are WAY off course. But if you adjust frequently and continuously then your individual changes will be smaller and easier to implement.

Communicate With Stakeholders to Gain Buy-In

Your project managers and stakeholders will need to gain a certain level of trust that the development process will take their needs and concerns into consideration, and if they let the requirements be developed naturally over the course of the project then the resulting solution will be a much better fit (closer to the target) and thus eliminate later rework. It might seem like it’s taking longer at the time, but if you reduce or even eliminate the need for rework then in the long run it generally takes less time.

This is an important lesson that can be difficult to utilize effectively. It might seem like on paper that an agile timeline is longer than a waterfall project plan, but the agile plan will probably not slip as far to the right as the waterfall plan, so the actual time to completion will be shorter. In other words, your waterfall schedule will almost certainly be missed, whereas your agile schedule, although longer than the waterfall one, will still finish before the late waterfall project is completed.

The big picture takeaway here is simple. Don’t be afraid to change your requirements baseline or your plan (course correct), even late in the game, if you are off course. Frequent, small changes will make sure that your solution stays on target to deliver what the user actually wants and needs, and as quickly as possible.