Reducing the Cost of Change
To me this is a provocative phrase, “reduce the cost of change.” Highsmith and Cockburn are thinking about the technological costs, which are the kinds of things that Agile is explicitly designed to address. I believe this idea can reach much farther. When the new software is delivered, or the new process is introduced, or the new plan for expansion is announced or, let’s admit, when the new cutbacks are detailed, there are human costs that play out over weeks or months. It follows then, that whatever we can do to reduce those costs will increase our organizational agility.
In the case of software development projects, the Agile practice of including business stakeholders in the development process can certainly mitigate these impacts. But even with that care-taking, there will still be some communication planning required between the participants in the projects (the innies) and those who just keep doing their ordinary jobs (the outies).
Plenty of us have trouble with change. And so, if we find ourselves in organizations that are undergoing a change of direction or any kind of disruption, might it not be an appropriate question to ask, what can I do to reduce the human cost of change?
This reminds me of the topic of resilience I touched on back in March. Then, I quoted from a Harvard Business Review article on “bouncing back from adversity.” What I didn’t include in March, but I’ll add here, are some of the focusing questions that the authors, Joshua D. Margolis and Paul G. Stolz, give to point teams forward in trying times.
- Who on my team can help me, and what’s the best way to engage that person or those people?
- How can I mobilize the efforts of those who are hanging back?
- What strengths and resources will my team and I develop by addressing this event?
- What can each of us do on our own, and what can we do collectively, to contain the damage and transform the situation into an opportunity?
Do you think these are helpful questions?