Back to Basics: Responding to Change
Agile, adjective. able to move quickly and easily. The final value pair focuses on the “Agile” part of Agile Software Development.
Responding to Change
over
Following a Plan
If we cannot evolve our plan over time then we are not Agile. This value is not about constantly changing for the sake of change though. Agile practices value the ability to change as new information is discovered.
This value is where PMOs got the idea that there is no planning in Agile methodologies. It’s also the one that generally creates the classic “Waterfall versus Agile” dichotomy. Setting aside the fallacy of calling classic project management waterfall let’s dig in to this a bit.
Agile project management, whether Scrum, Kanban or something else, requires planning. The value is not to constantly change instead of plan, it’s to respond to change instead of blindly sticking to the plan. The idea is to make our decisions at the last responsible moment. That allows as many unknowns as is practical to be cleared up before the decision is made. This really isn’t new. We have all altered our plans due to change in our lives at one point or another, especially if we have kids. Even during a solidly stage-gated project we can generally make adjustments to each stage until it starts.
That really points to the other problem brought up by this value. Agile and Waterfall are not polar opposites. There is no “us versus them” with a winner at the end of the day. Agile methodologies and Waterfall are differing points on a project management style spectrum. In fact, different Agile Methodologies are at different points on this spectrum. Whatever tool is best for a given situation is the one that should be used. That includes tools from classic plan-driven project management.
Software development is more like creating artwork than stamping out widgets on a factory line. When creating art sometimes the medium provides unexpected challenges that require a shift in the plan. Sometimes the customer the commission is for can present similar issues requiring re-work of the plan. It is the artists responsibility to deal with these issues, not the plans responsibility to anticipate them. Agile project management is the same. Needs and situations will change as the project progresses. The Agile project manager, or more specifically the Agile team, needs to respond to those changes, not resist them to the detriment of value delivery.
More Than A Process | Our Agile Journey
March 29, 2020 @ 11:19 pm
[…] The problem is that they haven’t embraced the idea of an Agile process. They just changed from their former process to Scrum, but kept focusing on the Process and not the People. They made an initial jump to the new framework, but now are more concerned with following the framework than doing the best work they can as a team. […]