Your organization has decided to become more “Agile.” Why? As we learned in a previous blog post, “Because Our Competitors Are” is not a valid – or sensible – reason.
Before embarking on a change, adoption, or improvement program, you need to know the rationale behind that decision. So… why Agile?
A traditional approach to answering this question might see the executive team going off-site for two to three days and holding a workshop where they decide why they should be Agile, then design an adoption strategy, and then summarize the whole thing in a few sentences to be sent out in a memo.
Typically, large-scale change initiatives have a lot more ceremony, more meetings, and more setup than this. However, there are several key failings, including that they involve only a select few executives in the envisioning and decision-making process, and they attempt to plan for the long haul.
There are dozens of examples in our industry of failed change efforts that have cost billions of dollars and proved that this approach doesn’t work. At Nokia, Stephen Elop issued the famous ‘burning platform’ memo in 2011, and yet two years later the company was sold to Microsoft. In 2013 Avon had to write off $125 million of work that built an enterprise software implementation which drove representatives away. This was change that failed to help the very people it was intended for.
These and other failures involve some combination of the following:
- Why – The “Why” isn’t understood by most of the victims of change.
- Strategy – The “Strategy” created by the executive group doesn’t make sense to all of the people doing the work.
- Ownership – People at the edges of the system (who do most of the work) feel no ownership of the change.
- Connection – The strategy doesn’t appear connected to the problems that the people at the edges of the system are experiencing.
- Improvement -The strategy appears to improve the lot of the executives, but not of the doers.
- Culture – The change doesn’t fit the organization culture.
- Leadership – Top level is asking for change but doesn’t appear to be involved in making it happen.
To be effective, Agile organizational change needs to… well, involve the Organization! Not just the executives who have made the decree, often without fully understanding what the goals of the change are. This shouldn’t be a quick decision made at a two-day corporate retreat. It needs to be an ongoing effort to figure out the “why” collaboratively and share it effectively, being mindful of some essential ingredients.
We address those ingredients in the next blog post: Agile Change or Adoption – the Steps to Go from “Why” to “How”
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.