Has Agile Lost It's Way?

When I got started with Agile in 2007 it was new. Most of us had been delivering software for a while and while we loved developing solutions we hated the often tyrannical circumstances we endured doing it. We knew what worked: lots of unit testing, iterative/incremental development, lots of collaboration, transparency, etc. But until Agile (for me, XP, and Scrum), we didn't know how to pull it all together. What we found, before Daniel Pink gave simple ways to say it, was that when we had the opportunity to 'do it right,' we were on a path to mastery, autonomy, and purpose in our daily work.

Agilists associate the birth of "Agile" with The Snowbird Conference in 2001 and The Agile Manifesto. If we focus on the unmet needs of businesses and governments relying on software then it goes farther back still.  Let's just say Agile's about 16, a teenager. It shows.

Agile has become a big business promising homogenized faster, better, and cheaper delivery to the masses. I would guess that 70% or more of teams who call themselves Agile aren't. At least by my definition but, I'm a tough grader who expects the use of XP engineering practices.

In 2012 Thoughtworks' published an Agile Fluency Model to describe levels of Agility from One Star Teams focused on delivering business value to Four Star Teams optimizing entire eco-systems. Their data suggested that 15% of teams were doing something, but it wasn't Agile. 45% of teams, while focusing on business value, weren't meaningfully improving software quality. As a result, due to Scrum or Scrum-like processes, these teams are only marginally more productive.

As a result of this homogenization, the tyrannical circumstances Agile was to dispel are back for too many. As the market grew, "consultants" with no more than a scrum class and a half-read, frequently derivative book popped up to feed on the Agile sales frenzy, the essence started getting lost.

Turns out that greater transparency can also lead to micro-management and ever more unrealistic expectations on a team. You get worse, not better code. You get less not more shared understanding. Even when you've had some success by focussing solely on visible business value, you may hear, "Wow, we've gotten faster since leaving waterfall. Bet you can go twice as fast! Indeed, you must! Find more process improvements!"

If this is sounding familiar to you I'm sorry. Here's what I suggest you might reference to find the essence:

1. Read the original sources:
• Extreme Programming Explained: Embrace Change
• The Scrum Guide
2. If you are a developer or architect then also check out:
• Clean Code: A Handbook of Agile Software Craftsmanship
• Clean Coders: watch as many videos as you can afford
3. If you are an Architect add these to the above:
• Read Clean Code
• Watch the Architecture, Tech Debt, and TDD videos at Clean Coders
• If you haven't written a line of code in 10 years, and think this is all craziness then spend the next month coding, full-time in your enterprise applications then read and watch the videos again.

Once you are done, happy New Years' 2006! Please don't stop now. Next up:

1. RSA ANIMATE: Drive: The surprising truth about what motivates us
2. Kanban: Successful Evolutionary Change for Your Technology Business
3. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
4. Large-Scale Scrum: More with LeSS
5. The DevOps Handbook
6. BADASS: Making Users Awesome

Ok, happy New Years' 2017! We're not done. So much has happened since Agile was born. Not all of it captured above. Keep in mind that you have to know the rules before you can successfully break them. You should also check into Modern Agile.