Changing to Agile, in an Agile Manner
One could make a plan for mass training (aka sheep dip), I suppose. One could dictate that by June 10, 20XX, all teams will practicing TDD. Or that all projects will be converted to backlogs and loaded into agile project management software.
But that doesn’t seem so agile to me. It seems like it misses the point of learning and adapting; of embracing values; of understanding systems and patterns, how the work works, what’s working and what’s not. Without considering the WHY behind processes and learning as you go, you are only going through the motions.
Start with understanding the current state, and what problem you are trying to solve by “going agile.” Understand how the current structures and goal alignments are supporting or hindering the goal of delivering products to customers, and identify targeted changes that will improve that ability. Identify where and you can change the pattern and establish structures that will help the new pattern take hold.
Make a Road Map, knowing that you don’t know everything and can’t foresee all you’ll discover on this journey of change. Describe the desired pattern and the steps that you can currently envision to get there. You won’t be able to see all the steps. If your initial actions are effective, your culture will be changing. Any far-future actions you described from the driveway may no longer be what’s needed when you are 100 miles from home.
It’s impossible to know everything at the outset when you decide to make what amounts to a cultural change. You take some steps, observe the effects of actions, and adapt, learning as you go.
Deterministic planning fails with complex software systems, and it fails with organizational change. Organizations are far too complex, and we need to plan for adaptation, learning, and the fact that the organization will be changing as the plan unfolds.