As software engineers, we are conditioned to brace for change. The very nature of our work requires that we be ready for it. Yet, at our cores, we don’t want there to be any changes. We don’t surrender to the inevitable changes that are going to be required after we submit content for a code review. Instead, we steel ourselves against it, and gear up for battle with a mindset of resistance. We don’t want our QA teams to find any bugs because we’ll then have to make changes to the code we’ve already written.
The experience, however, is like the Grinch who does everything that he can to stop Christmas from coming. Of course, the holiday arrives anyway. Similarly, despite our best efforts to plan and design an agile effort which builds change in, we’re still not entirely prepared to embrace those changes when they do come. And they will. They always do.
Agile Value #4: responding to change over following a plan” speaks to this behavioral response. It’s all about our attitude. Are we prepared for change and willing to accept that there will be change (as there is for every software engineering project)? Or are we preparing for a fight that we are inevitably going to lose?
Agile craftsmanship requires that we be nimble in our designs and in our approach. The code we write must stand up to meet the quality demands of the project and not interfere with other parts of the project, but it has to be nimble, too. Anyone at any time in the future may need to rework that code or replace it altogether. If it’s rigid and inflexible, the effort to update it (or replace it) will be that much more intense. Working sprint after sprint is already intense enough – we don’t need to add more stress to our day. In contrast, we need to take measured steps to reduce it.
One of the best ways to manage this stress and to reduce our anxiety is to prepare for change. Embracing a mindset of flexibility prepares us for the change that is coming. If our response is calm and collected, the changes requested will be received just like any new project instead of what may feel like a personal attack on our abilities.
Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted colleague and partner to the clients we collaborate with.
Christopher Okhravi, an authority on agile software development, offers an insightful perspective on the application of Agile Value #4. He reminds us that, “We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.” Another factor that we need to remember is that rigid planning and process are the antithesis of the freedom derived from an agile approach. As each project unfolds, we learn more about the needs of that project and gain new insights on how to best deliver the code needed to execute the project. However, as we do so, we tend to drift further from the original plan which no longer reflects our reality and this creates tension for everyone involved.
So, what is the best way forward? Embrace Agile Value #4. We must plan for the worst but hope for the best because change is inevitable. We must be nimble – and stay that way. Change is a necessary element of what we do. We can design our product roadmaps to be responsive and proactive or we can choose to be reactive and struggle to keep up. Getting ahead of industry needs and trends helps us prepare for the changes that will come. Being open to continuous feedback from our clients, our managers, our peers and our colleagues helps us evolve into a trusted co-worker and business partner.
“Change always comes bearing gifts.” ~Price Pritchett
Practice Lead, Java Cloud
What We’re Reading Around the Web
Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”
“To be agile, you need to be able to ask, ‘Is this agile?’”
Applying Agile Management Value 4: Responding to Change Over Following a Plan
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”
Getting Started With Agile: Responding to Change Over Following a Plan
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”