Its hard to embrace change…
Embracing change is a core agile value — but humans and organizations resist it by default. Early reflections on why change management is not optional in agile transformations.
A key theme in Agile is embracing change. We hear time and again that change is good, we should “welcome change”, yada yada yada. Most teams I see are sick of change. On one hand they are not fully exposed to the business case for change, to the sense of urgency around changing fast. On the other hand, change is HARD for them to absorb.
Effectively embracing change means overcoming the cost of change curve. Traditionally, we were taught that change costs more, the later you learn about it. This is still true. The cost is comprised of the complexity of dealing with change when it is buried under layers of work that was done since the original development was finished.
In many systems the quality of the codebase makes it even harder – spaghetti code, copy pasting, and a bunch of other smells / technical debt aspects make time work against us.
Coding for change
So how can Agile Engineering practices help us deal with change?
First, since we anticipate anything can change, its important to avoid wasting work in areas which might change.
In general its important to do as much of our work “just in time”, avoiding the planning ahead that is based on wishful thinking about how the future will look. The XP principle of “Simple Design” helps us provide the simplest solution that can possibly work. Complexity and “Fully Featured flexible solutions” are our enemy here. We have no way to know that they will actually be used since we cannot really predict the path the system will take. You Ain’t going to need it – YAGNI is another key XP phrase.
We also need to keep our systems at very high codebase quality to minimize the cost of changing when it does happen. Refactoring as part of the ongoing development cycle helps us achieve a Sustainable Pace where we might pay an ongoing small price, in order to be ready for whatever curve ball change throws at us. Think of exercising in order to keep our body healthy and able to cope with whatever life throws at us…
Early warning: iterations, TDD, CI
The air force uses AWACS planes and other types long range radars to get early warning.
In agile we use iterations, TDD and CI.
Iterations are a key factor here. Since we get feedback after every iteration we hear about required changes earlier, as well as discover many defects due to the testing we do in order to achieve PSP. This much can be achieved without any special engineering practices.
Test-driven Development provides much earlier feedback about the behaviour of our units, modules and systems, and makes sure that our system is REALLY Designed to meet its specification.
Continuous Integration provides early warning for any integration issues, avoiding any form of “Big Bang” integration problems.
Making the change safely
Once we do need to make a change, we rely on a high quality codebase, as well as several safety nets, in order to proceed quickly.
If we use ongoing Refactoring, applied the relevant Design Patterns, kept the design as simple as possible, the cost of making the change will be as low as it can be. Once we implement the change, Continuous Integration, together with the test suite we accumulate using TDD, will catch any problem we create very quickly. Weeks of regression testing, or Dev/QA managers losing sleep over a risk-taking testing coverage, will thankfully become a part of our past problem.
Next: how iterations strain teams
how fast iterations strain the typical team starting with agile…
Moving from agile theater to real business agility takes more than a framework. Explore Business Agility advisory or let’s talk.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →