Thanks for the kind words.

"post-agile as an expression for beyond agile seems a little self-contradictory me."

That reminds me of the Eagles song lyric: "You can check out any time you want, but you can never leave." :-)

-Jonathan

Good points. :-) At any rate, we should talk one on one someday if you're curious about my thoughts.

Post-Agile (as in "post-capital A Agile" or "post-the Agile movement") is different from post-agile, as in "agile" in the dictionary sense. It's difficult to explain, and Jason Gorman and I will freely admit that there is probably a lot less to it than people think. Furthermore, we are all about getting results, and have both found that Agile practices, taken too far, often get in the way of delivering solid software. Furthermore, skill is an often overlooked factor. A skilled team can accomplish just about anything, no matter what the practice is. I mis-attributed a lot of early Agile successes I was a part of with the Agile process we were following.

Some people have left the Agile movement, retaining what they want to keep, and pushing forward. They don't want to be reabsorbed back into "Agile" proper, but want the permission to experiment more and not go back to BDUF or a phased approach (unless that works for them.) Post-Agilism is one idea, and one outlet to support innovation when feeling stifled. I've used the concept to help a team that had an Agile failure. Management wanted to return to the old ways that were ineffective because it felt safe, but post-Agilism helped the team retain the good Agile practices they were using when things went south. So in that regard, post-Agilism helped further the Agile cause in that company, because it helped the team reach their goals.

It is a bit irritating to have every neat manufacturing idea suddenly be called "Agile", even if it was called theory y or theory z management, or lean, or TQM or something else in the past. Or have the idea misconstrued that if you leave the Agile movement, you are against iterative, incremental delivery, high customer involvement, high levels of communication etc. You can get all of those things without being "Agile". In fact, people did it for years before 1999-2001. As Jason Gorman says, just because I don't like McDonalds doesn't mean I hate beef burgers. However, I do see some contradictory "post-Agile" marketing, like "post-Agile Scrum" or "post-Agile Lean" which muddies the waters further. That's what happens with terminology though. Terms get hijacked whenever money is involved. Jason and I are kind of an anti school of programming thought that wishes to embrace anything that helps us get the job done, Agile-approved or not. It's fascinating to look at software development practices from the mid-'60s, or to look at successfull BDUF, 'waterfall' teams for example.

I'm much happier being "Agile fluent" than being "Agile". My software toolkit diet is far more varied and balanced without worrying about Agilism anymore. But that's just me. If Agile processes are doing it for you, keep doing it. There's more than one way to deliver software successfully. As a tester, I try to pride myself in being as process and tool agnostic as I can be. If an Agile practice is working, great. If not, what do we do about it? Too many times we put Agile processes on a pedestal and keep repeating the same things that weren't working in the past without figuring out what we value, and how to use our tools and processes to help us achieve our goals. Post-Agilism is just one way I think about solving that problem. It's helpful for me, Jason and others, but confusing for many others. If I could communicate more clearly maybe that would help.

-Jonathan

"When I hear about teams who struggle with Agile, assess the situation, choose to keep the parts that work and abandon the rest, I see this as being Agile not becoming post-Agile."
Sure, but that's just part of the picture. What about using practices that would be considered un-Agile as well? What about teams that create strange combinations of practices, some of which most Agilists might find too "Tayloristic" or "waterfall" but it works for that team? I don't think the Agile movement has a monopoly on innovation, even though there have been some great ideas that have come out of it. I want to hear more stories of alternative ideas people have used to solve problems. Unfortunately, many of those ideas are labeled as "not Agile" on teams I've worked on. I got tired of the divisiveness and bigotry and decided to try something from without the Agile camp. There's nothing worse than seeing a team struggle, and have one member suggest something to help, only to be told: "That's not Agile!!!" and have the idea turned aside. After a while, I thought, "maybe they are right, but who cares if it is Agile or not?"

Maybe "formerly Agile" is a better description of me. Or maybe losing the "Agile" thing altogether would clear away some of the confusion. Some of us don't want to be in the Agile movement anymore, but still use some Agile practices, tools and ideals. Why do we have to be called "Agile" or a continuation of Agile? I'd prefer to just call the whole thing "software development" again, and forget about the "Agile" and "waterfall" ideals/strawmen. "Agile" was a good step in the right direction, now let's not get complacent. Let's build on that and improve. On that point, I believe you and I are in violent agreement. :)

A pure implementation of either Agile or waterfall is either very rare, or does not exist. On our real, live projects, we have limitations and have to make trade-offs one way or the other. Some "waterfall" teams I've been on did a lot of incremental work and had user experience influences, strong customer involvement, collaboration-friendly contracts and lightweight documentation. They were successful in shipping software that the customers valued. Some so-called Agile projects I've witnessed had little customer involvement (other than the product owner who drew the short straw), no end-user focus, and reams of documentation. They weren't successful at providing value. I expect we all fall somewhere within the continuum, either tending towards one direction or the other. I imagine few of us would be purely Agile or purely waterfall. There are other ways to look at this as well. What did we call iterative/incremental projects before the Agile marketing term was coined?

At the end of the day though it is mostly just philosophical. I think it goes beyond semantics, but it isn't a big deal. On real projects, you and I probably do similar work. I may help a testing team adjust to Scrum, or the whole team figure out how to manage backlogs better, or make decisions about priorities, what to test, etc. etc. If it gets people thinking about providing value to their customers and themselves, questioning their processes and tools, and experimenting to see what works for them as they try to reach their goals, then I'm happy.

Anyway, let's do chat about it face to face. :-)

-Jonathan

Thanks Mike. I always enjoy chatting with you, and I like your work. Furthermore, your "No Glory in 'The Middle Way'" post resonates with me a great deal.

-Jonathan