Generating PDF

Process +

Agile helps companies gracefully manage change

A valuable aspect of the Agile project methodology is its ability to gracefully manage change. As much as folks don’t like to admit it, we know that project requirements change throughout the life of a project.

Even when much time and effort is put into analysis at the beginning of a project, adjustments in business priority, new products or vendors, revised regulations or missed requirements can all result in changes after development has begun. 

Traditional change management wastes time resisting change

Working on projects within a traditional “waterfall” approach, I have noticed a somewhat punitive attitude toward requirement changes. When a new requirement is discovered, there is hand wringing and time spent asking: “How did this get missed?” or “Why are we just hearing about this now?” After several meetings and various attempts to find answers, the request is then subjected to cumbersome change control and approval processes. Meanwhile, time is ticking away and no work is being done. These unnecessary delays are especially frustrating in cases where the delivery team is ready and willing to implement the change.

Agile embraces change

Agile offers a kinder, softer approach toward change. Rather than expecting the business “ask” to be fully defined up front and then frozen ever after, Agile embraces the changing nature of requirements. It recognizes that project stakeholders cannot know what they don’t know yet. Change is not viewed as a negative, merely reality.

Agile provides a vehicle for easily and quickly submitting new or changed requirements for consideration at any point during a project. This is not to say that Agile projects, particularly those with set delivery dates, can absorb an endless amount of change. Agile provides an elegant way to evaluate changes against remaining project work. If a new requirement is higher priority, it moves to the top of the project’s backlog. This, of course, means that lower priority items may not get delivered. The requirement backlog is constantly being evaluated and adjusted based on current priorities. In the same way, the overall release plan is continually evolving to manage and communicate change.

The Expected Guest

Approaching new requirements in this way changes the dialogue from “How could this happen?” to “How can we get this done?” Project team energy is focused on solutions rather than on perceived problems. Change is treated as an expected guest instead of an unwanted visitor. While stakeholders must consider the impact of requests to the overall release plan, they are not discouraged from introducing changes that are vital to the project’s success.

Related Content