Making a Difference: Change For Free!

 

This post is unabashedly about adaptability and agility.

We all want to make a difference. We also want the things we work on and create through our work to make a difference. In order for the things we create to make a difference to our business clients, they have to reflect the knowledge and insights of what is needed we gain as we work on creating products. This recognizes that we can't know everything up front. 

One of the challenges with traditional approaches is how to address change to reflect the new knowledge and insights  that the business acquires along the way. We know how it works - create a change request, fill in all the necessary sections to talk about what the change means to cost, schedule, scope. risks, who needs to approve, etc. It gets even more complicated and onerous, and expensive when we are dealing with vendors. It often makes you wonder if it's even worth the effort as most changes get rejected due to their cost or schedule implications anyway. Near the end of the project the change requests are often focused on removing things from the project to stay within budgets, timelines, or both.

In my experience, some the things that get dropped under such conditions can have significant value, while some of the things that were done early on actually had far less value, as the delivery approach is not based on an incremental highest value first model.

However, when agile approaches are practiced correctly, change can be free. No really. They can be free.

How can I possibly say that?

Let's use Scrum as the premise. When teams use Scrum they do the highest value things first. The backlog has everything they know so far about what they intend to build into the product. It is a statement of intent though - it is not cast in stone. It can be changed for the next and future Sprints based on new information, changes in team and business understanding of what is possible with the product, as well as priority changes of what is highest value by the business and the Product Owner.

The Product Owner is the one that talks to the business about what the product mus do, how long it will take to build it (the number of Sprints) and the cost. It is not uncommon to fix the number of Sprints and hence the costs at the outset. A good reason for doing this is so that everyone develops a laser-focus on what is truly of highest value first. The premise for this post is this was done.

The Sprint demo is where the business gets to see what was done so far in the latest increment of the product. They also get to reflect on the choices so far about what is in the product. Their reflection is also about what to do next.

• They can continue based on the backlog grooming and hence the highest value items at the top of the backlog
• They can choose to redo the priorities of what's highest value based on what is already in the backlog
• They can choose to add new things to the backlog as highest value and hence will need to be done next

The team has a cadence to which it develops and delivers.  If you can agree on the number of total points that the product will contain based on the agreed number of Sprints, then any changes you need to make along the way, as long you drop items with the same number of points as the ones you are adding, then the actual cost of a change is free.

This is one of the ways to look at what is so paradoxically different about the thinking in agile versus traditional approaches. It forces you to really think about what matters most and to truly get the idea of being adaptable to what emerges. If something emerges that  has a higher business value than what you had previously identified then it must take precedence. 

Remember it's about what is valued most, not everything that may have value. What is valued most is based on what we currently know, which can be quite different than what we knew a month or two ago.

So whether it is an internal Scrum team, or one that as put in place through a procurement process, if you're really willing to focus on what has the highest value and willing to drop items that are of lesser value, then you should be able to make changes for free!

Jeff Sutherland, co-author of the Manifesto for Agile Software Development and the Scrum Guide first suggested the idea of change for free in a class in the Netherlands in 2006.

What do you think - can we do a better job of facilitating others to make a difference today so that our organizations benefit now and continue to do so in the long run?

If you’d like to talk strategic intent, adaptive strategy, back-casting over forecasting, outcomes over outputs, any of the agilities, or pretty much anything you think I may be able to help you with in making a difference in your world, here is my availability during the conference:

• Saturday the 28^th from 1:30 to 4:30
• Sunday the 29^th from 3:00 to 5:00
• Monday the 30^th from 9:00 to 12:00

You can also connect with me at:

• https://twitter.com/cooperlk99
• https://www.linkedin.com/in/lawrencekcooper
• www.TheAgilitySeries.com