Recently, I was listening to a lecture that was done a few years ago by Dave Thomas (Not the Wendy’s Dave Thomas).  If you don’t know the name, he is considered to be the author of the agile manifesto. He’s also the first one to correct that label. It’s not the Agile manifesto (despite the URL); it’s a manifesto for agile software development. Over the years it’s been co-opted into something that he never intended and actually doesn’t seem to like.  He still firmly believes in the principles that he wrote out regarding agile software development.  But he is concerned that what was an adjective when he wrote the manifesto has been turned into a noun for the purposes of people making lots of money.

People tend to latch on to agile as the new cool thing to do and lose sight of what works and what doesn’t. I should start off by saying I am not at all against Agile or being agile.  I am certified in one of the more common Agile approaches, as well as some of the predecessor approaches.  The issue is the way many companies implement the principles is like using a knife as a screwdriver.

Agile is everywhere

Agile isn’t just about software anymore, it’s everywhere.  And it’s everywhere as a noun.  There’s a whole new vocabulary around it – scrum master, product owner, retrospective, backlog refinement, etc.  All the cool kids are doing it so companies are racing to get their people trained and certified so Agile (the noun), can solve all their problems.  Used correctly, organizations can see huge improvements in productivity and efficiency.  Used incorrectly, it just becomes a competing overlapping structure within the organization that actually impedes work.  The answer when this happens is usually more training and getting more people certified because the rest of the world is doing it and we have to do it to.

So is it doing Agile or being agile? 

This is where the confusion starts, and the point that Dave Thomas was trying to make when he first came up with the idea.  If it weren’t such a marketable term, they should have called it “Theory X” or something like that.  It would have cut down on the confusion about what organizations are doing vs. how they are doing it. 

I was originally trained on Total Quality Management (TQM), which along with 6 Sigma and a few other principals makes up the foundation for most Agile approaches.  TQM never really had the hype of Agile and was generally relegated to the world of manufacturing until the 1980s.  I was one of the trainers for Vice President Gore’s Reinventing Government program that was firmly rooted in TQM.   It was around this time that the principals started expanding into a variety of business and government areas. 

6 Sigma built on TQM and added more statistics and measurements than most people can keep track of.  They also broke the concept up into belts to show level of proficiency.  It also created a seemingly never ending cycle of training and certification.  Still 6 Sigma required an explanation for most people not familiar with statistics.  6 Sigma was a cryptic term that seemed reserved for the members of a special club.  Companies were paying handsomely to get their people trained and certified so they could join this elite group. Agile was something everyone could relate to without a class in advanced statistics class.

Becoming a Noun

This is where agile crossed the barrier into becoming a noun and savior of all things business related.  It was highly marketable, and they took out most of the statistics and focused on creating value so almost anyone can be part of an Agile team without having to go back to college.  In many ways it’s a beautiful thing.  At its best, organizations using it are able to make giant leaps forward in a short period of time.  Problems that may have lingered for years are identified and solved in weeks.  And people are empowered to solve problems that they might have not been allowed to otherwise.  What could go wrong? 

For many organizations it simply becomes a large line item in their budget.  It’s not designed to be used on all projects/problems and one size does not fit all.  Specifically, if you can’t break something down into chunks of work that can be delivered independently, you will struggle with the concept.  Nine women cannot create a baby in one month.   Additionally, if there are extensive regulatory, or data specific requirements Agile may not fit the bill.  Think of it as one tool in the drawer, but not the only tool in the drawer.

Back to Basics

Whether you have already gone down the Agile path, or are thinking about it, don’t forget what it means.  The following are some of the key points of the Agile Manifesto:

  • Welcome change
  • Leverage self organizing teams
  • Simplify your processes
  • Deliver value to your customers on a regular basis
  • Re-evaluate how the team is doing regularly

If you can adopt this approach or philosophy first, any training or certifications will simply help you get better at being agile.  Wouldn’t you like your organization described as being agile, as opposed to doing Agile?  It is an adjective after all.