Introduction to Agile: Change is Good

By Wunderer

Welcoming and responding to change can help you to deliver a much more successful project — and agile scrum gives you the framework to do this.

Traditional project management often discourages the implementation of change mid-project. Its processes and controls are designed to protect the project, but their overbearing nature often means mid-project changes are shelved and returned afterwards.

Agile has change management built into its core, rather than making it secondary to the project.

Embrace Change

The purpose of a project is to develop a product or service that enhances something already existing, or to develop an entirely new product or service — but whatever a project delivers, it must deliver value.

Change is not only inevitable but will be needed if we’re to succeed in that aim — so change must be encouraged and embraced. It could result from user feedback, new ideas, management requests, new information or a wide range of other sources. Leaving out a valuable change simply because the change process is unwieldy will risk the success of the project. By accepting change into a project as it progresses, we’re able to deliver the website that best meets the needs of the project.

Agile, by its very nature, is geared towards change and flexibility. It provides simple mechanisms for us to request changes, review them and add them to the product.

Identify Change

We constantly identify changing requirements throughout the project as we learn more about what we’re developing, and as we, or our users, test it, see it and use it. Change can also come from on high in the organisation, or from the outside world. Even once a website is live it’s good practice to continually research and experiment with ways to improve it, plus you’re likely to need to respond to changing technology and commercial pressures.

Once a need for a change has been identified, we then need the mechanism to request changes quickly and easily. Traditional project management would involve the to and fro of change requests, under a contractual framework. Agile simplifies this process by making change the norm rather than the exception — which is a much more realistic approach.

Changes are identified through the gathering of standardised ‘user stories’ (more on these tomorrow) that describe functionality clearly. New user stories should be channelled through the Product Owner who is the only person who can accept them onto the backlog. It’s part of their role to be the conduit for change, and even development team members should channel ideas for change to the project through them.

Value Change

In a value-driven framework such as Agile Scrum, we need to know why we’re delivering a change or requirement — we need to consider how it will be used, and what value it will deliver.

If we can’t clearly describe the value a change will deliver, then we can’t mark it as a priority. A feature that does not deliver value is a waste of time and money. This assessment of value is made by the Product Owner when they accept new stories, or changed stories, onto the backlog. The stories are prioritised based on their value.

Review your product regularly, involve wider teams and audiences to get broad feedback and input. Listen to their feedback and make sure you understand the value of the changes being proposed. See how they fit into the backlog in relation to the other stories.

Implement Change

The views and opinions of users are crucial to the success of the project. Small changes can often make big improvements to the way they operate. If the change is good and delivers something worthwhile, then it could be very high on your list of priorities. Make the most of the simplicity of the process and push it through the next sprint to the delight of your users. It’s amazing how the culture of an organisation can change too when the response of the web team to new requests is to deliver them quickly if they are valuable enough, rather than just to say no, or that it’ll take months.

If you win over your audience they’ll be more likely to embrace and accept the changes that the project is delivering. This acceptance will make the implementation and adoption simpler and will add to the success of the project.