Coping with Change

It's a Key Aspect of Agile, but Change Without Control Is Chaos

5 September 2013

Phillip Stiby
PCS Internet Engineering LTD



One of the 12 principles of Agile software development is: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Change is inevitable; everything changes and can change a lot over the lifetime of a project. For some reason, however, a lot of people who decided to go Agile seem to throw control out of the window. Scrum does a couple of things to help manage change without losing control. Here is one to begin with.

The sprint is the first control, this short period of time when the team has committed all its effort into delivering some business value. What's committed for the sprint should not be altered. Only when the new feature, function, or defect is so critical that the business is happy to take the loss of work is it truly worthwhile to make a change here, because that is the true cost of derailing a team in mid-flow.

The change should in fact land on the product manager's desk. From there it will be added to the backlog, valued, and prioritized.

With the change in the backlog, if it is sufficiently valuable and high enough in priority, it will be picked up in a future sprint. But with knee-jerk requirements, it's all too easy for changes to be seen as less required, and it can be nicer to let them stay at the bottom of the pile.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 2.5 (6 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.