Your Agile Is Not My Agile

“The more you know who you are and what you want, the less you let things upset you.”

That’s a quote from the 2003 movie “Lost in Translation” starring Bill Murray and Scarlett Johansson.

When I started thinking about this post, the title of that movie came to mind. 

The problem with Agile is that…

• How people choose to translate and apply the Agile Manifesto values and principles vary greatly.
• There is no one way of implementing Agile.
• That’s its greatest weakness and its greatest strength at the same time. 

Its weakness because it leads to senseless and wasteful religious-like debates over whose Agile is better.

Its strength because of its almost chameleon-like ability to shape-shift and adapt to any domain and environment.

How might we overcome this dilemma between weakness and strength?

That’s where the quote from Bill Murray’s character, “Bob” comes in:

“The more you know who you are and what you want, the less you let things upset you.”

— “Bob” from Lost in Translation

In other words, it’s only a dilemma if you let it be.

As long as you’re satisfied with what your Agile ways are achieving, does it really matter that someone else is achieving just as much if not more with their Agile ways?

So, let them.

Let them if the two worlds are and remain independent but, what if they do not?

What if these two worlds collide? Now what?

Whose Agile will prevail?

That’s the situation at my current client.

Over a dozen newly forming Agile teams composed of a mix of permanent employees and contractors.

Each with their own understanding of and experiences with Agile.

With as many perspectives on what Agile is and how to do it as there are number of people.

Some quotes from a recent Mike Cohn email post nicely captures my experience:

“…. teams today are formed of people who learned and practiced agile differently. Different training and different experiences led them to different opinions about how best to do agile.”

“People are often heavily invested in how they’ve done things in the past, especially if they were successful.”

• There is no one definitive, best way to do Agile
• What worked in one company may fail miserably in another company
• What works for one company is a function of that company’s culture – or simply, how things get done around that company
• Each individual is entitled to their opinions about how best to do Agile
• Which opinion or combination of opinions prevails will best be decided by the collective team

“… confusion over agile vocabulary and the proper names of common agile practices, taking some time to define common terms and baseline practices can help”

So what did we do to “define common terms and baseline practices”?

• We defined our Agile Operating Model rooted in the Scrum Guide and layered with organizational structure and role nuances that made it unique to our company culture 
• We trained and re-trained everyone on what we considered to be our most important baseline practices.
  • We originally delivered Agile training to a business only audience thinking that new IT hires would already be screened for “agile experience” and would not need the agile training. How wrong we were! Especially for two of the four training modules:
    • User Story Writing
    • Agile Estimating
  • Without this training, the results were conflicting views on what a ‘good’ User Story looked like and Estimates that looked more absolute than relative based.
  • So, we included everyone (Business and IT) for those two modules. 
• We suggested HR add an agile literacy test to the recruitment process. Sure beats just
  • Checking for agile certifications and
  • Asking the closed ended question, “Do you have Agile experience?”

All of our investments and efforts to align on OUR definition of Agile and OUR ways of working practices as quickly as possible led to the best possible return-on-investment:

More time and clarity doing the work and less time and confusion arguing and debating over how to do the work!