Using Net-Map to become more agile

Ok, I wrote about how a different sector (e.g. international development) could use agile philosophies to improve their work and become more relevant and adaptive. But we also looked at it from the opposite direction: Is there something I could offer the coaches to improve their work. At the Agile Coach Camp I did two Net-Map sessions (and then some impromptu lunch break ones for those who couldn’t attend the “real” ones), and there we talked a lot about what Net-Map could do for Agile.

If you come to an organization (as internal or external Agile coach) and you want to implement Agile, this is not like saying: “We are going to use this new product now… but we will keep on working the way we did before”. It’s a radical change in what the organization does and how it does it. And as we know, the core reason for forming an organization is to organize chaos, provide stability and predictability. So typically organizations have a strong inherent force toward doing things “how we always did them” and are allergic against change. A lot of organizations are sort of ok with changing what they do (e.g. producing new products to follow market development) but changing how things are done is the scariest thing, because that attacks the glue that holds an organization together.

And that is the main reason why introducing Agile is not a technical as much as an organizational change task and why the Agile coaches got so excited when trying out Net-Map. Typically they are brought into the organization by someone who thinks Agile is a great idea and is looking for a partner in implementing it in the organization. The coaches should, however, not fall for the illusion that “the organization” wants to become agile. It’s always more complex than that. You will have people who fear loosing their power as experts or clearing houses as the new way of doing things is introduced, you will have others who don’t agree that you can trust people to deliver instead of micromanaging and controling every breath they take, some (maybe in the leadership) will wake up one day and realize that they underestimated the depth of change that they invited into their organization and get very nervous about it, because they actually just wanted an increase in productivity without a revolution in work flow organization or organizational culture.

As a coach you come into this situation and see all these people just as “the organization”, a mass of faces, having no idea where the secret and open supporters and saboteurs sit and how this specific change process fits into the history of this organization. In our Net-Mapping session, participants mapped out their own perception of specific organizational constellations they have to deal with and developed a deeper understanding of the core stumbling blocks and coalitions. That is a great first step. But imagine how powerful it would become if you started to use it with the people driving and impacted by the change. Interviewing your first point of contact / the person who initiated the Agile implementation would be a first step to understand the lay of the land. Then, in individual or group interviews you would talk with people who have very different perspectives on this, making sure that you are respectful to everyone, no matter what their stand is. So instead of saying: “These people are for or against Agile (the good and the bad people)” you would have to frame both perspectives positively, for example by saying that they are for stability or for change… Apart from getting a very fast in-depth understanding of the positive and negative, formal and informal power networks, you would also have a great way of understanding the root causes for people’s hesitations and allowing all of them to feel like they are part of this development within their organization, instead of feeling like this is something leadership is doing to them.

Some of the coaches were really excited about the idea of including initial Net-Map sessions into their approaches, so maybe I can soon write about how this actually worked.

Net-Mappers of the world unite – and write!

If you read my blog regularly you know that I love hosting guest posts in which people describe their experience with Net-Map and give you a fresh view of the method, their experience and understanding. But over the years some of my colleagues (you know who you are) have become such core members of our community of practice that I sometimes feel like our brains are wired together and we think in the same direction – only they sometimes take it further than I would have even thought. And it feels strange to call them “guests” on my blog, while they are “partners in crime” in reality.

Paolo Brunello, Net-Mapper extraordinaire from Italy, wants to stop being a guest and start being a regular contributor and partner on this blog and I am glad to have him. As far as I am concerned, he is the Net-Map philosopher and he produces the most amazing visuals and presentations (no surprise here, as he teaches powerpoint mastery in his other live). I am looking forward to hearing more about the Net-Map sessions he facilitated at the FAO Share Fair in Rome. And I hope he will upload some of his Net-Map talks here, so that you can also see / hear him talk and get to know him.

And to those of you lurking in the shadows, sitting on your own Net-Map experience, wondering if that could even be interesting to anyone else… The answer is: “Yes!” The more diverse experiences and perspectives we share here, the better for our common learning. So whether you got confused or enlightened or anything in-between when using Net-Map, write a little post, shoot me an email (, be my guest and become a partner.

Agile international development?

Most innovations are not completely and utterly new ideas that no one has ever had before, but rather happen when you take an idea that works in one context and try it out somewhere else. So while I talked with the software developers and coaches at the agile coach camp last weekend, I kept thinking: What if we used the principles that they use to make software development more participatory, user-oriented and faster learning and adopted them in international development projects? The basics of this new approach are summed up in the:

Manifesto for Agile Software Development

“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

Have a look at the way it starts. It is not about “we have all the answers” but “we are discovering better ways by doing”, not just by theoretical thinking about it. In my years of working with international development projects I have seen all different kinds, but I must say, a lot of projects still are heavy on the right hand side. Let me take you through how I connect this manifesto to my experience to explain some of the things I have seen in international development. And tell me if this relates to your experience as well…

“Individuals and interactions over processes and tools”

Someone has a tool (whether it’s a new solar cooker or a new kind web platform) they are excited about and look for a place where they can implement it – and for funding to do so. If you have a hammer, the world looks like a nail… Some of these hammer and nail projects have really interesting unintended effects of a side aspect of the project, maybe the training meetings allow the stakeholders to network, even if the content they learn is less relevant. But how many projects are able, willing and allowed (by their funders) to have a close look at this, abandon their hammer and just focus on what really has an impact?

“Working software over comprehensive documentation”

 Some donors seem very focused on extensive documentation, pre-defined evaluation and filling out forms, and less insistent that the project or product actually works on the ground. Agile teams believe in very fast feedback loops, they might program for a couple of weeks, get to a point where a product (thought far from perfect) can see the light of day, be tried and tested and the feedback you get is fed into the next cycle of improving the product. Imagine doing that in a development project. Take your solar cooker or web platform prototype to the potential users after a few weeks, let them play with it, get their feedback, incorporate it in the next design and bring it back to them soon to play (or cook) some more. Continue to improve.

“Customer collaboration over contract negotiation”

At the coach camp we talked a lot about the fact that trust is crucial for being agile. And I think that is one of the reasons why a lot of people involved in development projects (whether funding or implementing) try to develop contracts and other binding commitments that are as waterproof as possible, because working with strangers (or new colleagues) from different cultural and socio-economic backgrounds and with different expectations makes it extremely difficult to develop trust. So the thinking is: If I don’t know if I can trust this one, I better have a really good contract to protect me. However, we often work in countries where a written contract has only a guiding function and is impossible to legaly enforce and it is the quality of the trust and collaboration with your “customers” on the ground, that is your strongest protector against abuse or fraud. But while that is something that many successful development practitioners know and do intuitively, that happens on the level of individual learning and is not supported by the general structures we work in.

“Responding to change over following a plan”

I think that is what resonated most strongly with me, because I have seen so many projects that were bound to execute the plan that they had come up with in the initial proposal, even if they found through their work on the ground that something else would work much better, a different problem was much more severe or conditions on the ground changed rapidly from the time they first developed their plans. I was once in a project meeting where the donor representative said: “You know, this is a learning project, so if you realize in the middle of it that you need to change your approach, that is fine.” I think we felt something like shocked relief that a donor would actually say that.

The agile coaches I met didn’t talk a lot about programming and code etc. but about how to support organizational change, how to encourage managers to be open to new approaches and how to deal with resistance. One of the most powerful things about this meeting was that it was a gathering of the tribe (as in “people of the same kind”): In their work as change agents they might often be the most radical, craziest person around, trying to convince their reluctant clients that being agile is actually possible and beneficial. And here they were, a large room full and within this room they were all mainstream, not radical at all. And the things that would spur endless discussions and scepticism outside would just get a “yes, I know” and the reassurance that the other person did indeed know.

If agile philosophies are to take root in international development (and I have seen donors and implementers who are leaning towards them, even if they call them something different), I think it is crucial to – once in a while – gather the tribe and just say “yes, I know” to people, who are just the same kind of crazy…

And now back to my question above… does this resonate with your experiences? And: Where do you go to meet your tribe?

Net-Mapping at Agile Coach Camp, Columbus, Ohio

These fish are ready for the next cocktail party! (copyright by Sugar Daze on Flickr)

I’m feeling a bit like a fish on a cocktail party, surrounded by all these agile programmers and agile coaches, knowing that I have brought them some wooden toys and post-its and paper to play with tomorrow. But after getting used to the feeling, I can just recommend to any flounder or herring to attend a cocktail party every once in a while. Getting out of your comfort zone opens your brain and turns all the switches to learning and observing. And because agile programmers are trying to implement radical innovations in organizations (not just a new product but a new way of how things are done, connected to a whole new philosophy), they have to deal with the issues that Net-Map looks at every day: Who are all the obvious and hidden influencers, how are they connected, what do they want and how much power do they have to get it?

So tomorrow we will do one of my crazy 2 hour speed mapping sessions, where I will throw them into the cold water of (nearly) self-facilitating drawing a map of an issue that concerns them, so that they can experience what the method does and learn something new about that issue. Yes, 2 hours are never quite enough for teaching and trying it out at the same time, and facilitating a group of unknown size alone through this process is also something that leads to high adrenalin levels. But then, what is wrong with high adrenalin every once in a while and if things or people get stuck along the way, I can always activate my German roots and sternly remind them of the importance of Puenktlichkeit.