Agile is a Tool Box… and a Very Huge One at That!

Consider modern Agile as a delivery philosophy.  Here’s my hypothesis.  Agile is an approach on selecting the best tools for your culture and product.  No one set of tools or even approaches will work “best” for any given engagement.

If you don’t agree, then don’t and you can stop reading now.  It won’t hurt my feelings.  Really.  Otherwise, please take a moment and consider the state of business today.  In some ways, it hasn’t changed as much as people think.  The changes are simply faster.

Consider the ideas as stated in the Agile manifesto (http://www.agilemanifesto.org/).  For each enterprise, every project is unique where one set of tools won’t work necessarily as well as another set of tools.  It’s funny that even experts within the industry, those who have gained the title “Agile Coach” often still believe that there is a “one size fits all” strategy for companies.  That’s simply not true.

Of course, finding the right tool set for your business and project is the real challenge.  Size of the business, company culture and what is already in place take a strong play in what choices you have in choosing the tools and processes in delivering.  Also key influencers are the industry and company type you are in.  A health care company has different objectives focusing on patient privacy, security and care.  A software company focuses on bringing a product that will produce the biggest revenue base.  A consulting company looks to maximize engagements and relationships to bring the most value and profit to their client base.

Since there are a myriad of combinations, my thoughts go into the “guidelines in creating guidelines”.  I like the Mike Cohn approach to blogs and try to bring home one key idea to a blog.  This key idea is continuous improvement.  Never settle on accepting the status quo and always look for better ways to deliver.  If you are in an organization that refuses to change and you are happy with that, then this blog isn’t for you.

Best way to find out on what could be improved is to do the following:

  • Have an “experimentation mentality”
  • Read and explore new approaches
  • Follow key industry leaders
  • Fail and learn fast

These should be relatively self-evident, but I’ve been surprised time and time again how many people who are in leadership positions (and everywhere) get “caught up in their own approach” and become stuck, whether due to pride, ignorance, frustration, apathy or {choose your own emotion} and never improve.  That is the start of the end for that business and granted it is much harder for a 100 year old company to change than a 1 year old company, so it isn’t easy folks.  However, you either move ahead or fall behind.  Over the long term, there is no staying still.

Repairman Jack in Agile

Okay, so I have been an avid reader of F. Paul Wilson’s “Repairman Jack” series (http://repairmanjack.com/) finding out about it through a book club my sales executive friend, Greg Kaufman, introduced to me back in 2002.  Aside from the fact that I’ve befriended a sales person is like cats living with dogs, the book really struck me with the protagonist of the story, “Jack” was able to keep his identity unknown and blended in as an average Joe, never looking or acting like a true rock star James Bond styled hero.

Some basic things I’ve learned about Agile that many people, especially new to the practices seem to fail to understand.  First is why Agile works and second a general guidebook on how Agile should be implemented.  In Repairman Jack, Jack doesn’t fix your broken water pipe or furnace, but instead “fixes” problems in people’s lives whether it be spousal abuse or missing children.  He has his own code of honor and is flexible to situations to adapt to changes that happen in life.  He will get money up front to start, but doesn’t get paid the rest until his work is done.  There is a parallel in Agile delivery too.

Agile’s success arrives from more frequent inspection and adaption so that you know when a product is being built wrong early and change it then avoiding the tremendous costs of discovering later.  The approaches in Agile also work under the principle of the “stop starting, start finishing” mentality.  Agile will allow to have 5%, 9%, 12%, etc. of the product to be done, thereby truly having deliverable components.  They may change over time, but they are functional.  Achieving a shippable product, often called the Minimum Viable Product (MVP), is a top driving goal of Agile and should be for any product delivery too.

For companies that have mastered continuous delivery like Amazon or Google, this isn’t news.  However, what works for Amazon or Google won’t necessarily work for your business or your project.  In my next blog, I’ll cover what approaches have shown to work and not work from my experiences over 12 years practicing Agile delivery.