What do you do when your team/company is all excited to be “agile”, while your customers want to operate in the traditional, heavy-weight, documentation-driven approach? Every now and then I run into Customers or companies dealing with Customers who insists on writing pages of requirement document, with specifications as vague as the night sky, insist on accurate estimates (oxymoron) on turnaround time at the moment of document handover and to not be involved again until they receive the software they asked for?*

IMHO this is one of the biggest issues teams face when they want to use more Agile ways to deliver software. I’ve been in similar situation and sometimes have been able to influence the customers to collaborate more. Sometimes I’ve not been able to. Following tricks have worked for me in the past:

1) First and foremost, it’s worth understanding why they are opting for this approach. In most cases it turns out that they don’t trust the software team and hence they want to push all the risk to the software development side. May be they have burnt their hands in the past. May be their hands are tied. Or may be they are just ignorant of the fact that this is an extremely sub-optimal way to build software. Seeing the world from their point of view, helps me understand where they are coming from. If one is able to see the underlying driving factor and break that bubble, things can get lot more constructive. For Ex: if Risk is the underlying factor, showing them how risky their approach is, can turn things around.

2) Sometimes during the scope discussion of the project, I’m able to highlight things that they’ve not thought through. Sometimes I’m able to hit the nail where it hurts the most. Immediately, the customer moves from a stand where they were saying “We know it all, just build this” to “This piece, we are not sure and it might need a little more work, but rest of the stuff you should be able to plan & estimate”. Slowly through these discussions (couple of hours) you highlight enough such instance, to point out the fact that, there are lots of uncertainties. Also you highlight the fact that we can make assumptions and move on, but it could lead to rather adventurous ending. At this point, I pull some of the biggest project failure case studies and show them how adventurous the ending might be.

3) Sometimes, I start off saying,

I’m sorry, I’m not good enough for this job. You need an expert, who have implemented the same project many times before and is extremely desperate for work to agree to your terms of project execution or you need someone who is an expert at acting to make you feel like they are in control.

I also add saying,

It does not appear to me that your are building a software project for the first time. So if you look back at your past experience, how has this approach of building software really worked for you? Be true to yourself. Were you happy with the results? Did you feel it could have been lot faster and costed a lot less? Also did you feel the team could have come up with lot of innovative, valuable ideas in the project?

Sometimes these questions shake them up a little. At this point, they want to hear more. Its very likely that you’ve touched upon some of their fears and pain points.

4) I also bring to their attention that, I’ve worked for a lot of companies who will go with the traditional model, but put a serious (expensive) change request process. They know that on an average sized project 20-40% requirements will change as the project continues. (There are graphs that show this very clearly.) Software companies typically use this approach as a way to teach their customers a lesson. And on subsequent projects or mid-way through the project, the customer agrees to collaborate more instead of tossing it over the wall. If the customer still does not agree, heck what, you make good money through the strict change request process.

5) At this point, hopefully they are slightly more open to listening to you. So I propose that we start-off with a week or 2 week inception phase to flush out some of the uncertainties and to bring everyone on the same page, so we all can agree upon the common goals. Depending on how important this project is, we price the project inception piece of work accordingly. Sometimes even free. During the inception phase, we do some brainstorming about what we need to build, how it’s going to affect/help endusers and businesses, we build some models, we build some working prototypes, etc. This helps the customers experience the value of collaboration. (It’s like the trailer of the movie.) In my experience so far, most customers see the value, we are able to build some trust and respect for each other and we are really set to build a project using agile methods.

6) After all this, if they still don’t see the point, I tell myself,

Life is too short to waste time on such projects. Time to find a new project/customer. In fact life is too short to build products for others. Its high-time I build my own products.

Interestingly, I’ve had some customers who understand all of this stuff and tell me that the main reason they don’t want to collaborate is, they fear they might get attached to the project. And will not be able to take objective calls. This is a valid point. When I cook something, it always tastes good. Even if it does not, I keep trying to make it taste better. Hard to draw the line. In case of software projects, we can work out strategies so customers are able to collaborate but still take objective calls when they need to.

* This question was asked by Stephen Walters on the Agile Alliance LinkedIn Group.

Recently I read Esther Derby’s blog post on Five Reasons to Hire a Coach for Agile Teams. While I agree with all her points, following are the questions or concerns running through my mind.

• What are the risks involved when hiring a coach?
  • What is success ratio? How many teams you know (not heard of in some cooked up report by a consulting company or a tool vendor) who are successful adopting Agile with a coach’s help? And how many teams do you know who have failed trying to adopt agile without using a coach? Let me clarify, when I say adopt Agile, its not about a bunch of practices. Its about continuously evolving the process to make it lean and more efficient and more enjoyable.
  • Can any coach do or do we need a special type of coach? Point I’m getting at is, your chances to succeed is based on the quality of the coach and her experience.
  • In my opinion your chances of failure is much more if you hire an average coach from outside who does not understand the business, organization and team context & culture.
  • The big problem we face today is we don’t have a good way to know if someone is a good coach or not. What are the chances you’ll end up hiring the right coach? Its not sufficient if someone is a certified professional. In some cases, its not even sufficient if someone has written a couple of books.
  • Also in my experience, ability to connect and influence the team members is very important. A good team member is in a much better position to achieve this than any average coach from outside.
• How sustainable is the model of hiring a coach?
  • What happens when the coach leaves? Is the team evolving their process or still using what the coach put together?
  • Hiring a coach from outside might speed up things. But I’m not sure if people will be able to understand the rationale behind doing certain things. In my experience failure is a great learning tool. Taking more time to achieve something (and in the process failing a few times) is not bad, it make something more sustainable and scalable.
• Can you teach/coach someone to be agile? Agile has been around at least for the last 10 years, what are the chances one or more coaches can change that? (I’m not saying its not possible, I’m trying to highlight that its not simple. It involves organizational transformation and change in individual’s mindset).

My advice is before looking for a training or coaching, do sufficient homework?

I’m thrilled to be back in Bangalore. One thing I really missed in US was the craziness of driving on Bangalore roads. Everything was so systematic, there was no thrill, no excitement, no fun, I would be bored to death. The other day I started to think what did I really like about driving on Indian roads? There was something about driving here, that strikes a chord with the way I work [you would have guess by know, .i.e. develop software]. I concluded that, driving on Indian roads have a lot to do with the way I build/develop software .i.e. using Agile methods. Here are my initial thoughts why I think so…

• Chaos from outside : If you are not driving on Indian roads, it looks like the epicenter of chaos and noise. It will take a while for you to figure out why the traffic on the roads are oriented in 360 degrees. Everyone seems to be honking at each other. If you talk to someone who has watched an Agile team work for a week, they can share similar thoughts about chaos and noise. Companies where I have tried to introduce Agile, chaos and noise seems to be one of their top concerns. Once you are part of the system, life is wonderful. Trust me, you will never look back again.
• Embrace change : If you drive though a street and come back to it a week later, there is a high probability that the direction in which the traffic flows would be reversed. Changing the directions of one-ways is very common here. Driving 2 wheels with helmets on is another rule that has changed at least 10 times in the last few years. There is a constant evolution. The good thing is folks embrace change and continue with it. Strikes a chord with what happened yesterday during your planning meeting?
• Heavy emphasis on open communication and continuous feedback : If you watch people in India drive, you might wonder why they honk continuously and sometimes flash their headlights? Well, that’s our way of communication and feedback. If you watch carefully, the intensity of honking and the frequency of flashing lights varies depending on what one driver is trying to communicate to the other. A gentle honk, means, I’m about to overtake you, watch out. Continuous honking means, move out of my way, you are wasting my time. A gentle flash of light means watch out, I’m behind out. All of us know the importance of open communication and continuous feedback on software projects.
• Self organized : If you look at the traffic rules in India, we are not so rigid about the rules. You will find people overtaking from left and right. Sometimes you’ll find group of vehicles jumping the lights when the opposite side is empty. We don’t even have cops standing everywhere with Speed guns. A lot of busy junctions, don’t have cops. People nicely self organize and move on. I believe in self organized teams and I think that is the most effective and scalable way to build software.
• Adaptive planning : Its quite common to find one of the roads in your route blocked due to some maintenance work or accident. It very rare you’ll find people waiting for it to clear up. Immediately people find another route and move on. We plan to deliver and not deliver to a plan. Its very rare to find that everything on a software project going according to the plan. Things change, we always have surprises and we learn to adapt and move one. Also note that let it be heavy rains, floods or heavy winds, none of these seem to bring the traffic to a standstill. People adapt and move on.
• Stressful and Intense : No doubt driving is a lot of fun, but driving on Indian roads is stressful and can be intense. This is the same feedback I get from people who work on Agile projects. Pair programming session can be quite stressful and intense. Trust me, you’ll feel much more exhausted in 4 hours of pair programming session compared to 10 hours of working on your own. Both of these activities needs a lot of attention and can drain you out soon.
• Mitigate risk : From outside, it might feel like driving on Indian roads is very risky. But if you look at the number of deaths caused due to accidents in India, its far less than that caused in US. Please note that number of deaths includes humans and animals. For those who live in suburbs in US, can tell you how many deers they find dead everyday. The trick is with people traveling so close to each other, there are very little chances to be caught by surprise. With constant feedback and continuous collaboration on Agile projects we try to mitigate a lot of project risks. Pair programming and collective ownership is another great way of mitigating the risk of one person being the bottlenecks.
• Maximize the throughput : If you notice the number of people that travel through these roads each day, its amazing. Look at the roads, every inch of the road is occupied and sometimes we don’t even spare the footpaths. We like to maximize the usage of the available resources (capacity utilization). But at the same time we focus on making sure we reach home/office fast. (throughput). Every software project tries to maximize its throughput and Agile gives me a great platform to do so.
• Minimize the operating cost : I’m not too sure, but my gut feel says the amount of money and effort invested in maintaining and building roads in India is far less than what they do in other countries like US. Also consider the ratio of number of cops to the number of people traveling through these roads; it is very very small. We believe in reducing any form of overhead 😉 This is the harsh reality of software projects. But Agile helps me strike a good balance.
• Agility [the verb] : With the short distance between the vehicles, one needs to have really good reflexes to survive on Indian roads. Its amazing to see everyone jamming their brakes when something unexpected happens. They recover and move on. Being Agile [verb] is the key to success on a software project.

Having said all this, its always easy to find things that are done quite different in these 2 scenarios. Taking any analogy to an extreme causes more harm than good.