A while back I was contacted by a potential client who wanted to “go agile.” But they wanted to do it in a deterministic manner. They wanted a plan, complete with milestones and dates–mostly indicating that other people had changed their behavior as dictated by management.
Sigh.
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.
I recently made the switch to agile on my team: http://www.everydayqa.com/2010/agile-development/moving-to-agile-what-the-qa-team-needed-to-learn/
We have learned a ton a long the way, and found that so much of it was based, as you say, not on practices, but on culture. It has been a rewarding experience and really challenged our team to work in new ways.
If I had a dollar for every time I’ve had to tell someone “You can’t waterfall your way into agile.”
Change is hard, especially when you are talking about some really fundamental values that many people are not even aware they have.
So True!
Agility is not about following rituals, and having everything known in the begining. Agility is about embracing flexiblity. Agility is a “Mindset”. And transitioning is a real challenge.
Unfortunatelly question about the plan is the first (and last) question. Get the plan, later a client asking for % of completed vs. expected rollouts, asking for exact day “when we will be agile”.
Many ‘agile’ coaches support this approach by providing ‘plans on the water’ just to fulfill the expectation and not to tell the true. This way things are just worse and worse as they coach all the industry to continue in old habits. They setup the expectations for agile coaches in very bad position.
I think that industry still needs more education and evangelism and well known agile persons (like you Esther) and organizations (both alliances?) could only help.
Nice post Esther,
For years now I’ve been speaking of and blogging on “Using Agile to Scale Agile” and have been evolving a framework for doing so. This approach works quite well as it allows organizations to envision ‘releases’ of themselves described in terms of demonstrated capabilities and competentcies.
This type of change requires a systems thinking perspective because planning and executing an Agile Transformation in many ways is even more complex than the sofware many of us deliver. So,it only makes sense that such an empirical problem would benefit from an iterative / incremental approach with a heavy dose of PDCA. 🙂