Agile beyond software
Agile Doesn't Mean Throwing Out the Plan
Responding to change over following a plan
The fourth value of the Agile Manifesto, "responding to change over following a plan," is the one people get most wrong. They hear it as permission to skip planning. It says the opposite. Plan, and then let new information make the plan better. Agile without a plan is not agile. It is chaos with a stand-up meeting.
What the fourth value actually means
The Agile Manifesto closes with "responding to change over following a plan." As with the other three values, the word that matters is "over," not "instead of." The authors were not telling teams to stop planning. They were telling teams to stop treating the first plan as sacred when reality moves.
Dwight Eisenhower said it better than I can: "Plans are worthless, but planning is everything." The specific plan you wrote on Monday will be wrong by Thursday. The act of planning is what leaves you ready to adjust when it is. New information should not threaten the plan. It should improve it. That is the whole loop: change, fueled by information, becomes iterative improvement.
Adaptability is a skill, not a personality trait
Here is the part most teams miss. Adaptability sounds like a temperament, something a person either has or does not. It is not. Adaptability, critical thinking, and problem-solving are skills, and like any skill they can be taught, practiced, and improved.
People who are genuinely good at this are rarer than you would think, which is exactly what makes them valuable. The good news is that you do not have to hire for it and hope. You can build it on the team you already have.
How to build adaptability on your team
A few concrete ways to make adaptability a habit instead of a wish:
- Train it directly. Invest in agile methods, change management, and plain critical-thinking practice. Skills you name and teach get better. Skills you assume people already have do not.
- Break down the silos. Adaptability dies when sales, marketing, and customer support cannot see each other's work. Get them sharing knowledge and trading skills so the team can spot a change early and respond as one.
- Treat agile skills as a moving target. What worked last year will not fully fit next year. Build in continuous learning so the team evolves with the market instead of lagging behind it. HBR's Learning to Learn is a good primer on making that a habit.
- Reward it out loud. Notice and celebrate the people who adapt well under pressure. A culture that rewards adaptability gets more of it.
Plans are guesses. Update them.
None of this means you wing it. It means you hold the plan loosely. Write it, commit to the direction, then watch for the signal that says it needs to change. The teams that struggle are not the ones that change course. They are the ones that finish a plan they already know is wrong, because changing it feels like admitting failure.
This is the same misread I wrote about with the first agile value: people assume "individuals and interactions over processes and tools" means process is bad. It does not. The pattern repeats every time. The manifesto names a priority, and people hear it as a prohibition. (More on that one in Process Is Not the Enemy of Agile.)
The takeaway
Agility is not a buzzword, and it is not the absence of a plan. It is the discipline of planning well plus the skill of adapting when the plan meets reality. Build those two habits into your team and you get the thing everyone actually wants: a group that can change direction without falling apart.
If you want help building that kind of adaptable, cross-functional team, here is how I work with teams. For more on applying the agile values outside of software, browse Agile beyond software.