At the Agile 2009 conference, Martin Fowler, Ron Jeffries, Chet Hendrickson, Mary Poppendieck and I had a very interesting discussion about “why some of us felt that there was nothing new at the Agile 2009 conference”. (or even if there were interesting topics, the signal to noise ratio was too small to find it).

Martin’s hypothesis (paraphrased):

Back in the late 90s and early 2000s, the core of the software development problem with regards to process was hashed out and most of the principles & techniques were flushed out via the Agile Manifesto and other techniques. (which of course was the easy bit). What is happening now is, most companies are trying to implement those ideas on their projects inside their organizations. Implementing those ideas is rather tricky and needs a lot of creative tweaking at project level. Its difficult to pull out any generic topics from these implementation and present it to a broad audience @ Agile 200x confs. Hence it feels like there is nothing new.

After which Martin asked Ron, if he has seen anything new on the mailing lists. Ron resonated with Martin. Everyone else seemed to agree.

Overall I’m convinced that this hypothesis makes sense. However I feel:

• Even though implementing Agile techniques on projects needs lot of creative tweaking, we can still find patterns and meta-approaches to implementing/adopting agile. For Ex: Applying Theory of Constraints and Just-in-Time practices to coaching agile teams.
• Personally I don’t find agile implementation @ large enterprises interesting. But I do see a lot of innovation happening in start-ups and small product companies. They are doing things which agilists might consider taboo. If we look at some of the Web 2.0 product companies, they are solving a lot of interesting problems like deploying to production multiple times a day, embracing fully distributed teams, etc.
• Integrating UX and Operations team into the development team is still an open issue. Few companies have done some interesting work in this space.
• And so on…

I feel majority of the Agile community has got into a “preaching mode” and very few people are actually building their own products (eating their own dog food.) This attitude attracts a certain kind of people to the conference and I’m quite skeptical to find innovative new ideas in this crowd. With so much noise its also very easy to miss some weak signals which have potential.

I do know a few people who are doing some really interesting stuff (they are turned off by the Agile brand and generally don’t hang around in these circles). Personally I want us, as a community, to be more inclusive of these people.

The Value Theory: What people value drives their actions.

Value Driven planning is where you plan to do the most valuable things with your resources, and of those valuable things you try to do the most valuable things first if possible.

Target Driven planning is where you have a target or set of targets you try to reach, and you try to do what gets you to your targets.

Target Driven thinking reflects the way we tend to ask people for what we want. For example, “May I have 2 kilos of potatoes please”, “Get me twelve bricks.”, and “I need two tonnes of sand.” What we rarely do is say “This is how my values work or this is what I value, so please do something that will make me happy.”

Similarly when it comes to Agile adoption (or any process for that matter), we see two camps:

• Target Driven Camp: Where people use number of practices, adherence to a specific prescriptive process and checklist based verification of the same, certification, maturity levels, and so on to guide and plan their adoption.
• Value Driven Camp: Organizations highlight what they value, they use their values to guide them with their adoption process. (Please note that their values itself can evolve.) Ex: We value quick turn-around time, so our customers get what they ask for quickly, is this process change inline with our value?

This blog was triggered after reading: Goals Gone Wild: The Systematic Side Effects of Over-Prescribing Goal Setting (a must read).

Thanks to Matthew Leitch for his wonderful summary of Value Driven versus Target Driven planning.

Lot of organizations in India are considering Agile.

• Agile Adoption in Services Companies is mostly driven by customers and competition.
• For product companies its all about
  • Improving productivity,
  • Reducing time to market and
  • Better quality.

While these companies are adopting agile, they have lots of concerns and questions. One recurring theme I’ve seen, is all these companies are really really afraid of failure. IMHO, this fear leads to a very dysfunctional agile adoption. Teams pick what is easy to do and what fits into their existing model, in the name of reducing risk, call it fail-safe 😉 . With this approach individuals and companies fail to see the real benefit of Agile.

This issue is compounded by the fact that a lot of companies are selling substandard certification, tools and consulting.

Also most Indian companies work in a distributed model. Distributed development is another challenge teams are facing and they don’t really see how to fit Agile in their distributed context.

All these points put together makes it very difficult for team to succeed.

These are my biggest concerns today with Agile adoption in India. Does this ring a bell? Can you share your thoughts?

I would be really happy if you want to share your agile adoption story with the agile software community of India. If you can address some/all of the following questions it would be great:

• Why did your company decide to consider Agile?
• How did you build a business case for going Agile? Can you share some artifacts from this original business case?
• Who all was driving this change?
• What measures were taken to set realistic expectations with both Management and Development teams?
• Did you start with a Pilot project? If yes,
  • What were the criteria for picking a pilot project?
  • What was required to get the pilot project up and running?
  • Was the pilot project a success? What were your success criteria?
  • Post the pilot project what did your organization do?
  • How did you roll out Agile to rest of your organization based on your learning from the Pilot project?
• From when you started to now, can you give us important milestones and some artifacts with regards to the same?
• Was there a key turning point in this journey? If yes, what was it?
• Looking back, what mistakes you think could/should have been avoided? And what mistakes you think were worth committing?
• Where is your journey with Agile heading? What are your future plans?
• What does a typical day in life of each team member (developer, tester, manager, etc) look? Any pictures/artifacts you can share?
• What impact did Agile have on your organization structure?
• What mechanisms did you use to guide your teams if they were going down the right direction?
• After having gone through it, do you think it was worth it?
• Any thing else you would like to share?

Someone, really high up the hierarchy (one of the CxOs), after reading a bunch of case studies and reports, decides Agile is the way to go. She builds a business case and announces

We’re going Agile. This will solve all our problems. Our software products will be delivered faster than light.

Hand picked set of managers are sent to the near-by, favorite Scrum Certification course. And from that day onwards, the army of software slaves wear their Agile uniforms and start marching. Starting with those pre-pre-pre-pre-poker; sorry planning meetings to the re-re-re-review meetings to the daily (ouch my legs hurt) scrums. And of course the wet-row-spectives.

After doing all this, your company don’t even see the light, forget delivering products at lightening speed. Then of course you hire a X-Stream black-belt consultant to explain you why you need another Engineering process to succeed. So you start doing TDD, no BDD, no TDD, no RDD with automagic retractoring and revolutionary markitecture. Knowledge of resign patterns is mandated. You also instill the promiscuous rare-programming with sustainable mace and so on.

You continue down this path cursing yourself that you are not good enough. Only if you had the right set of people perfectly following the process, you could see fluffy bunnies jumping all over the place.

On the Agile Alliance LinkedIn group, Eugene Yamnitsky posted the following question:

One of the key Agile transformation success factors is Executive Commitment. Every book and article I’ve read mention this, but there are no good explanation on what it really means.

Great questions!

In my experience, Executive Commitment is very deep and crucial. It’s certainly not as easy as flipping a switch and expecting magic to happen.

What  does this really means?

• First and foremost they need to understand that, for any change program or transformation, its the people and the environment they operate in which makes the difference. Not the new process itself. What Agile tries to do is change people’s behavior and the environment they work in.
• They need to take time to actually understand what is Agile and what it is not. Essentially so that they have the right expectations set. So that they understand the impact of what they are getting into. This should involve talking to practitioners about their experience. Reading at least few experience reports and so on.
• Involving their teams to understand their issues and aspirations. The worst thing the executives can do is decide “Agile is THE way to go” in a closed room meeting and force it down people’s throat.
• Once there is a general awareness about Agile in the organization, ask any one team to volunteer to be the pilot project. Work closely with that team to set realistic plans.
• Once the pilot project is kicked off and folks on that team & supporting teams are sold on the concept, they need to step back & stand behind their teams (support them) and trust them to do their best.
  Send a clear message across the organization that this is important and we really care about this stuff. (There is a big difference between pushing in down people’s throat and doing it collaboratively with their buy-in)
• The Executives need to be open to failures and also need to communicate that clearly to teams saying its OK to fail. We are trying something new, which is a huge paradigm shift and there is certainly risk involved in it. So its OK to fail.
• Also sometimes I find that since the expectation setting is not right, teams are always trying to change their way of working in a hurry, under a high pressure. Its very unlikely that I would do my best under such situations. Give your teams the space and time they need. Like anything new, there will always be a learning curve.
• It usually very helpful to have someone in the organization play an evangelist role. Someone with real first hand experience with Agile. The executives need to invest in the right things.
• The other very important thing that the executives can influence is the organization culture. Encouraging honest and open communication. Not by just doing lip service, but by actually leading by example.
• Like with any change program, everyone (esp. the executives) are always interested to know as soon as possible if the new process is working on not. Is it helping on not? Sometimes people try to put in tracking/measuring mechanisms which are inherently broken. As we all know, you’ll get what you measure. So the metrics you use will influence to a large extend how people will behave. This one single things can screw up the whole adoption process.

I can go on, but I guess this gives you the gist and seriousness of the kind of commitment required.

To conclude, I think it all revolves around

• communication,
• expectation setting,
• collaboration,
• leading by example,
• showing that they care and providing the required support (time, money, effort)
• being open to take the risk of potential failures.