Connected Leadership

Last week at the London Scrum User Group's meeting the topic kept coming up, in a form or another, of how to convince the client, within a waterfall organization, that managing their project with an agile methodology can sometimes be the best approach. This could be an external or an internal client with some sort of formal requirement that would be somewhat incompatible with the artifacts already being produced.

Agile is incompatible with waterfall. You either do your project in one breath or you do it incrementally. You can't estimate your project with waterfall, manage with agile and expect to be on budget. So how do you talk your client into accepting your agile methodology?

Show Results. The Bottom-Up approach

The first answer that came up was the Bottom-Up approach. You prove your methodology is the best by results. If you are in a small company and you want to convince your boss that agile is good for the company, you just use it for your project and the results will serve to make your point. I think this is a rather optimistic view. Think about Ken Schwaber's statement that about two thirds of Scrum implementations fails, if you fail you will have a hard time arguing that agile just made it transparent that the project would fail anyway. However, I can't argue againts the fact that this approach has proved fruitful for some companies entering into agile, even big companies, so there is something positive about this. Often the department using agile would create a contagious atmosphere in the work environment, causing others to experiment with it.

The power of demand. The Outside-In approach

If you let your client know you can also provide agile professional services, eventually when a sponsor comes along requesting your client for his project to be managed with an agile methodology he will remember you. This will also be a natural consequence of the Bottom-Up approach. Only Outside-In will have a bigger impact on your organization, who will start thinking about adopting agile more seriously within the business strategy.

Formal vs Real. The Connected Leadership approach

I came across this very interesting concept in a book by Emmanuel Gobillot I am currently reading. It's about the ability to engage with individuals in ways that ensures resilience so that boundaries of the formal organization can be transcended and no opportunity is missed. I hope I got it right.

According to Gobillot there is a 'formal' and a 'real' organization. The 'formal' serves the established bureaucracy, with processes and procedures focused on task completion, but usually poor to respond to change. The 'real' is the networks of people you have built within (or outside) the organization. This is a flexible version of the 'formal' organization you can rely for agility.

So when you want to get your iterations started and you have all of you environment and artifacts ready, but the PMO policy demands all the usual overhead, you can go as high as you can on your 'real' organization hierarchy and try and negotiate within your network to satisfy the expectations in a way that will not compromise your project.