Last week I worked with an Agile coach who helps large organizations to move their software development from traditional waterfall programming to adopting agile approaches. What does that mean? Well, waterfall programming means you start out by telling the programmers what you need, then they go and program for a few (or more than a few) months and finally come back with a program for you to use. Now you can see whether you actually knew what you wanted in the beginning and whether the finished product fits. In an agile approach the programming cycles are shortened to weeks and at the end of each iteration stands a good enough product that you can start using and trying out, giving feedback to the programmers so that they can go back to tweak, adjust and make it fit.
One of the great and scary things about becoming agile is that it doesn’t just mean using a different kind of product in the end. But that it means significantly changing processes, power and incentives within the organization. So introducing agile is not just a technical switch but actually an organizational change effort. And this is why my colleague proposed that we Net-Map it.
So at the beginning of a 1 1/2 year project he has just started we met with the three leading managers who oversee the agile implementation for this international corporation. And asked them the simple and difficult question: Who are all the actors who will influence the success of the project (positively or negatively)?
What did we find out? Well, my colleague now has a list of people he wants to invite to the first planning round. And within this list, he knows of a few people who need special attention, e.g.:
- The social integrator, that everyone feels comfortable going to with new ideas or the need for feedback.
- Some actors from neighboring domains who fear that their influence might be diminished by the implementation of agile.
- The strongest driver of the process in the leadership team.
He has more clarity about the drivers that motivate the different people involved and their priorities, especially when it comes to the question: “Is it more important to get stuff done and show results fast or to implement and document processes that others can follow in the future?”
Also, mapping out the whole situation provided a great opportunity to dig deeper into the history of this project, the divisions and people involved and how their past experience with each other might influence their ability and willingness to work together on this project. This specifically is an area where external consultants can easily step on landmines from conflicts they didn’t even know existed…
And finally, working with the project leaders on this and giving them the space to draw a map of their views and experiences, allowing for disagreement and exploration as well as finding a shared core, was a great way of laying the ground work for a longer process of collaboration, getting to know each other better, seeing what their priorities and worries are and reassuring them that we have heard.
Filed under: case studies, Change Management, notes from the field, Organizational Learning, Other people's work | 2 Comments »