Stealing Scrum: Responding to Change

The Agile Manifesto consists of four comparative statements that describe the elements of value that drove the development of Agile software development methodology and eventually Scrum as well. The fourth, "Responding to change over following a plan," drives the vast majority of methodologies and practices. Why? Because change is inevitable. Change happens every day.

Even to a team operating Scrum, change can insert itself at inappropriate times. During trainings for Scrum methodology, where groups of people often attempt to work a project using the practice, the facilitator often injects a dramatic change mid-cycle. Even for a methodology with quick sprints and quick turnaround of work, injection of major enough change can wreak havoc on an efficient team. Agile nciples and methodologies pride themselves on responsiveness, though, so how should you deal with change?

Evaluate The Change

Don't throw all caution to the wind and accept any change that comes as if it is the new number one priority. You still have the opportunity to evaluate the new situation in terms of the overall goals that you are working towards. A good Scrum team will accept incoming changes and evaluate their impact on the overall project before making a determination to change course. You should do the same in your daily work. Just because someone drops something in your lap, it does not make it the automatic number one priority for you. However, you may, after measured evaluation and comparison, decide that the new directive is more important than something on your list. And that is perfectly OK. Just as it is OK to push a new request out because it is less important than ongoing work. In the end, any new request or change in direction should be evaluated in the greater context versus your other work and you should determine which takes precedence based on overall impact and your ability to get work done.

Reset and Commit

Once you have decided your path, commit to that direction. Take appropriate measures, though, to set expectations appropriately with others, when you do. Determine as a result of the new request which work you will not be completing in the previously committed window, or decide that you will not be starting the new request until a later time, and then communicate those adjusted expectations to those that are waiting on your output. Your customers need to have appropriate expectations, and you have the responsibility to deliver on your commitments. After setting the expectations, clear whatever you need to so that you can deliver on time.

Remember To Value Responsiveness

It's easy to rely on the methodology and sprints in development, or your daily work plans as you put together your own internal daily stand up. In the end, though, the methodology becomes just another type of plan. At that point, you should reflect on the core fundamentals. Place a higher value to responding to change than your own dogma and methods, even if it causes you to change direction. You usually can't control what caused the change, you can only control your response to change (Tweet that). Know that your response can and will set your direction.

Change is inevitable. No matter how well you plan, how set you are in your ways, something will come your way to throw you a curveball. Respond appropriately.

This article is one of a series evaluating how Scrum methodology might be utilized in non-IT business operations and decisions to improve productivity and performance.

Image credit: frenchy54 on Pixabay