Agile Embraces Change, But Does NOT Always Encourage It

This content is syndicated from VersionOne by VersionOne. To view the original post in full, click here.

One of the biggest reasons many organizations adopt agile methods is because agile embraces change – shifting business priorities, new customer needs, competitive pressure, etc. But just because agile methodologies embrace change doesn’t mean that agile encourages change. It's common sense that not all change is good – often it can be distracting and frustrating to the team and the overall organization. The key is know when change is “good” and when its potentially “bad”.

It’s easy to justify just about anything, but it takes disciplined organizations, product owners and agile teams to recognize good versus potentially bad change. The responsibility often falls on the product owner in conjunction with the executive management team to determine the business value of changing high level priorities (often at the product or release planning level), but the team also needs to stick to their guns when change is introduced during iterations/sprints. Agile project management allows for a significant amount of change at the highest planning levels, when the least amount of information is known and little work has been done, but significant reprioritization is discouraged during a release and practically forbidden during an iteration.

Good change is often characterized by the potential to increase business value delivered. For example, if a significant number of customers (these are often internal customers if you’re on a marketing team) request a feature that was previously lower in the backlog, it’s common sense to move it up in priority. But the case for changing priorities isn’t usually that clear. One or two large customers might be making a lot of noise about a particular feature right now, but do any of your other customers or prospects even care? It can be tempting to drop what the team has been doing and change course, but it often isn’t wise. Spiking (researching effort) the work required to deliver the requested feature is often a good first step. If the team determines that the effort is minimal and it wouldn’t jeopardize completing other higher-priority features in the release, the potential benefit would most likely outweigh the potential harm. If the team comes back and says the effort is significant and would put the release at risk, then you have a couple of options – take the time to reach out to other customers and reassess the potential value, or let the customer know it’s in the backlog.

Leave a Reply

Your email address will not be published. Required fields are marked *

7 − two =