Agile Circling the Drain?

Yesterday, James Shore posted an interesting blog entry entitled The Decline and Fall of Agile. In that entry, he opined as to how the lack of specific direction with regards to engineering practices in Scrum has secured its place as the leading agile method in use today. That lack of direction is also a leading reason why organizations have had challenges sustaining efforts to move to more agile methods of delivering software. In a nutshell, I couldn't agree more. I've said roughly the same things in the past in my own blog entries, Scrum is not Enough and Call it What It Is!

"Uncle" Bob Martin responded in the Object Mentor blog as well as on Twitter, indicating that he believes the notion that the process is the problem is hogwash. He's correct, but only to an extent in my opinion. Individuals do indeed need to be responsible - they need to strive to constantly improve themselves and their techniques. However, the problem isn't only with the software developers! Testers need to do this, business analysts, interaction designers, business people - they all have to learn to improve how they do their jobs in order to make any process successful over more than just the short term. However, a process that leaves people to their own devices to figure out how to attain these improvements is courting disaster. Common sense, as they say, isn't very common.

That's why, to me, the more prescriptive approach of XP (1st edition) makes more sense in that it follows the Shu Ha Ri method of learning. Initially, you must show everyone practices that work, rather than expecting the people to just find them. I once heard Scrum described as "the VB of Agile Methods", for this very reason. It's easy to pick up and start, but unless you already have excellent practices in place you're going to struggle after a while. Think of the fancy 3D fonts and drag & drop controls that got rave reviews in demos, but the overall system was shipped full of bugs, if it even shipped at all. Don't even get me started on DLL Hell!

My point behind the Call It What It Is blog entry was that saying you're doing Scrum when in fact a number of practices were added out of necessity does a disservice to Scrum and the other processes from which those practices were taken. If you're doing XP but using Scrum terminology, just say so!! If you say you're just doing Scrum, the next group in your company that sees your success is going to say, "Wow, let's adopt Scrum!" If they do so without the extra practices, and aren't disciplined enough to be using them already, they will struggle after some initial success.

So, assuming that James Shore is right and Agile is on its way out, what's next? With one client, I'm seeing tremendous synergies with the application of Lean in the business and Agile (or whatever you want to call it) in the software development group supporting that business. The business people understand what they have to do in order to support the development people, and vice versa. Even the approach of introducing Lean to the business was the same as my approach to bringing in Agile for the development team - a short initial training workshop, then right in the deep end with a a coach there to guide the team through the first few iterations.

I can see that two-pronged strategy as being much more effective than simply trying to convert the development teams. Certainly it's more difficult than just changing the software development method, but isn't that the case with most activities in order to make them sustainable over the long term?