The problem isn’t the word ‘Agile’ and sorry Ron, the problem certainly is not that “people don’t do what we said”  What kind of elitist attitude is that?  The problem is the message coming out of the Agile community isn’t resonating with organizations that want to adopt Agile.  Organizations want to adopt Agile for a reason and most of the time we overlook that reason and jam a bunch of wishy-washy crap and a bunch of practices down their throat all the while wrapped in a message of “gee, you just don’t get it“.    While the Agile community has evolved and matured, “our customers”  largely have not.   The Agile community is full of fantastic forward-thinkers that have made huge strides in spreading Agile practices and I think the pace of that evolution has far exceeded our customers pace of understanding how to apply these concepts to their context.

I talked to a potential client today and asked him why they wanted to “go agile” and he said to do things faster and cheaper.  That’s his perception of the benefits of Agile and that’s ok.  I certainly don’t blame him for his opinion, instead I asked him questions to understand why he felt that way and what problems his organization is facing that led him to the conclusion that Agile was the way to go.   Most importantly I want to understand his situation and help him improve his organization.

When I first got into Agile, my first experience was with a company using Scrum.  A client came to me and said “we need you to build X, Y and Z“.  I thought this was a good opportunity to learn something new.  When I asked our “Scrum guy” how we can approach this project I was met with what I now know to be the usual rhetoric.  Write some stories, build some stuff, get some feedback and repeat until it’s done.

I had asked how we could come up with the time and cost for it so the client could get budget approval and was met with “uh, you just don’t get Agile….it doesn’t work that way“.   Now that’s just dumb.

Agile needs a context to be successful and oddly enough that context came at the same company.  My at-the-time boss had introduced us to the Rockefeller Habits and it immediately resonated with me.  Long story short, we used Scrum to implement the Rockefeller Habits.  The Rockefeller Habits helped set the business context and Agile was the ‘tool’ that got us there.  We used common sense and used the Rockefeller Habits as our guide, not Agile and the results were outstanding.  I recently talked to my former boss and he mentioned that’s just how they work now.  It’s not the Rockefeller Habits or Agile, it’s just how they work because it makes sense for their business and it’s getting results.

That’s what Agile is.  It’s taking data from your system and making smart decisions with that data based on your context.  We had no automated testing, hell, we had no QA people at the time and a bunch of bugs that WE tracked that NEVER generated helpdesk calls so what’s the point of implementing XP practices?  There’d be no value.

We were just a great mix of people with a shared goal, a FANTASTIC leader and we were willing to try shit out and learn.  That’s what it’s all about and not every organization can do that.  Some organizations need metrics or checklists or other ‘non-agile’ stuff and we certainly don’t need to tell them they are stupid for wanting that.  If that’s what their system can support, our message needs to change to adapt to their reality instead of beating them over the head with a bunch of hokey bullshit.

Demand for Agile is exceeding the capacity of those who really understand it so we’re left with people trying to make sure they are doing practice X right (as is evident by the billions of Linked In discussions I participate in).  It’s not their fault, all we can do as a community is adapt to serve our customers better.  That’s Agile.

What happens after the honeymoon is over?  Going from blank walls and cubes to a lots of stuff on the walls and a nice wide open space and should have made a difference by now shouldn’t it have?

There’s a lot of noise on Linked In, Google Groups and twitter (to name a few) that all seem to try and find fault in a person, team, organization or practice because the results aren’t matching the rhetoric.    So we’ve been at this Agile thing for a while, we found a shitload of problems, came up with a plan to fix them, didn’t see results right away because we chose to not prioritize actually fixing these problems, blamed the methodology and decided to go back to the old way of just ignoring said problems.  Voila!

I remember that fantastic exciting and new feeling when I first met my wife some 15 years ago.  It was fun.  New.  Exciting.  Fast forward to marriage and kids and after the honeymoon was over life got hard and complex.  It takes work to manage our house and family.  Real work.  Any problems we have are our problems and if we chose to ignore them, we suffer the consequences.

According to these stats, 1 out of 2 marriages in the US and Canada fail.  Why is that and what does it have to do with Agile?  Plenty.  When stuff gets hard, we as humans give up.   This Business Week article talks about 5 reasons why we tend to give up on our goals.

• Ownership: thinking “I’ll give this a try and see what happens” instead of thinking “this will work only if I make it work”
• Time: holy cow, I didn’t think it’d take this long, is it worth it?
• Difficulty: This is waaaaay harder than I thought!
• Distraction: Sorry, can’t work on my goal, have a bunch of other stuff to do.
• Maintenance: ah, good enough….I don’t have to keep working at it do I?

Adopting Agile is no different than any change in a company.  It’s a change.  A big change.  A really big change and change is hard.  All the mental models, coaching models, change models, methodologies and such are fine and dandy but sometimes you just need good old fashioned gumption.

Sometimes it’s time to nut-up or shut up.

This is one of many reasons why hiring an Agile Coach is a good idea.  A good Agile Coach will practice what they preach and use these same methods to help with an Agile transformation.  If we are talking the talk, it’s probably a good idea to walk the walk.  For starters it shows you’re passionate about Agile and it proves you know the tools and how to apply them.  It’s also a great opportunity to lead by example.

There is responsibility and “do’s and don’ts” on the part of the coach and the organization to work together towards an Agile transformation.  Below are 4 simple steps with some tips that can serve as a guide for how to approach an Agile transformation.  Again, there is no one-size-fits-all approach but there are some basic fundamentals and common sense practices I have found useful that I wanted to share.

Understand: How do you know if you need a hammer for the job if you don’t understand the task in front of you?

Coach:

• understand why the organization wants/needs to adopt Agile practices
  • are they concerned about quality?
  • is their business in jeopardy and they fundamentally need to change how they operate?
  • are they simple tired of the status quo?
• understand the current state of the organization:
  • how the organization is structured?
  • where is the support for transforming to Agile?
  • what’s the skillset like?
• understand that the Agile transformation is about the organization, not you

Organization:

• understand that an Agile transformation is more about a culture change than an adoption of processes and tools
• understand that Agile is not a quick fix
• understand the an Agile transformation is costly and time-consuming
• understand that ALL levels of the organization need to be involved
• understand that you will not like some of the answers you get from your coach

Educate: This is important.  I find that often people just want the answer.  A good coach needs to educate the organization so they can apply that knowledge instead of giving them all the answers.

Coach:

• teach the 4 values
• teach the 12 principles
• conduct workshops that help the organization understand the meaning behind the values and principles
• make it fun
• Educate them on the use of the tools (both thinking and software tools) you plan to use based on your understanding obtained in step 1

Organization:

• be open to learning, don’t dismiss the education because “it won’t work here“
• reject the status quo,”look around, it doesn’t need to be this way” – Gerry Weinberg
• challenge and question the education, don’t simply accept everything the coach teaches, challenge those teachings to make them work in your environment.

Execute: Now the hard part.  Agile is easy, implementing Agile is very difficult.

Coach:

• start simple, you should understand how much of a shock the transformation will be, a simple approach may be best
• the organization will not always listen to you. You will serve the organization better if you can remain positive and objective
• collaborate with the team(s) and/or organization instead of giving them all the answers
• learn to ask powerful questions to help them relate the 4 values and principles to daily work
• refer back to the values and principles often, this helps drive the organization to think and apply these values and principles
• start internal user groups, blogs, wikis, get collaboration and discussion happening, spread Agile culture

Organization:

• remain optimistic, you will be frustrated at times but stick with it
• “embrace uncertainty ” – Jeff Patton
• expect to experience failure, but remember to learn from it
• it might sound crazy, but it just might work.  Give it a shot.

Reflect:  Use retrospectives extensively, and not just with the team(s).  Retrospectives will help the teams with daily ‘in the trenches‘ work and they will help management and executives inspect and adapt on their transformation plan.

Coach:

• this is a tough one, but be honest with yourself.  Are you the right coach for this organization? Do you need help?
• based on organization feedback, add new tools and practices as necessary to support these new learning opportunities
• help the organization learn how to improve in small increments

Organization

• try not to get overwhelmed, Agile tends to expose problems very quickly – use reflection to make small, incremental improvements and try to avoid the big-bang solution approach
• be honest with yourself, don’t ignore the problems that surface, attack them

Rinse and repeat often.  These 4 steps are cyclical.  Reflection leads to a greater understanding which leads to new learning opportunities that will likely require different tactics during execution.