I just finished reading some of Jonathan Kohl’s writings about “post-agile”, which he describes (and I paraphrase) as going past the agile doctrine by taking what works and leaving what doesn’t work behind. He seems to emphasize leaving “the hype” behind, too. I don’t know why this line of thought bothers me, beyond a very basic logical fallacy I can’t help but see: the notion that agile is the hype or that agile is the practices. It isn’t now, and it never was. Being agile requires adapting the process to local conditions, so I can’t understand why adapting the process to local conditions would be something other than agile. I hope stating it that way makes the fallacy apparent.

Kohl concludes one of his pieces with this:

At the end of the day, Post-Agilism is just an idea, or a model that some of us find helpful right now. Don’t find it helpful? Don’t worry about it. We aren’t trying to change minds, we’re just trying to get people to think about what they are doing. If Agilism works for you, great! If something else does, that’s great too. There are a lot of good ideas to choose from, particularly if you expand your view.

I have added emphasis for the portion I want to deal with. Since when can one be agile without thinking about what one is doing? The essence of Scrum is “inspect and adapt”. From what I understand, you can’t do either of those without thinking about it quite deeply. The essence of XP, as Beck described it even in the first edition of “XP Explained” is pick a problem, solve it “the XP way”, then repeat on the next problem. You can’t do that without thinking about what you’re doing. What I dislike about Kohl’s post-agile formulation is that it assumes that agile is the worst way it’s practiced: thoughtlessly. That is not agile; and Kohl’s conception is not post-agile. It might be post-bad-agile or post-dogmatic-agile, but what he calls post-agile is really just agile. This, in spite of his claim to the contrary. (My apologies for the long excerpt to come; I will interleave my comments.)

Isn’t This Really Just “Pure Agile”? Aren’t You Just Reacting to Agile Corruption?

No, we are reacting and adapting to experience on our own projects, and to change. Furthermore, post-agile thinkers I’ve spoken to tend to be contextualists who, like the Context Driven Testing community, believe the value of a practice depends on its context. […]

But this is agile. From what I understand, agile is what the various schools (XP, Scrum, FDD, DSDM, Crystal) all have in common, and they are all context-driven. Some recommend a set of practices to start with, but once you’ve mastered the practices, you know which to use when. Others give you the responsibility to discover the practices you need. Each is driven by a set of principles and values, among which is the notion that we continually improve the way we work. I don’t think any is considered dogmatic, although XP is strongly interpreted by many to say, “Don’t mess with it until you understand how it works; and you won’t understand how it works until you try it as is.” Agile or not, I simply find that advice generally sensible.

Ravi Mohan: “…each agile practice (or the whole lot together with an appropriate label) makes sense only in certain contexts (certain types of enterprise software, with certain types of teams) even in the “uncorrupted”, “pure” state. A “pure agile” process is not superior to a “non agile” process de facto. Agile is not the “best way we know how to create software”. It is one way we know how to create software. It has no intrinsic superiority (except against obvious straw men like “pure waterfall” for projects with rapidly changing requirements). “Post Agile” is just an adjective that describes people who have used agile extensively, adopted what made sense, rejected the parts that didn’t work (and the hype) and choose to think for themselves. It is not a reaction against the perceived corruption of an originally perfect process." (From comments on Vlad Levin’s blog.)

I believe Kohl (in quoting Mohan) confuses “agile” for “a set of practices” here. He may do this just because he uses the term “agile” to mean “a set of agile practices”, but the larger community has been saying for years that agile is not the practices. Ron Jeffries says that XP is what you do after you’ve mastered the practices, echoing Charlie Parker’s line that jazz is what you do once you get past the rules of music and just play. Bill Caputo says, “XP isn’t out there; it’s in here.” Agile is certainly the same: agile is what you do once you internalize the practices; agile, it seems, is Kohl’s “post-agile”.

A popular misconception is that if you are in an iterative lifecycle, focus on communication, customer involvement, value testing, and delivering great software, then you are, by definition “Agile.” […]

I’m pretty sure “agile” was defined at Snowbird as “what’s the least we can do and still build great software?” Recall that “agile” is the term only because people didn’t want to be called “lightweights”, otherwise it’s likely that “lightweight” would have been the term. So if “agile” isn’t its definition, then what is it? It seems to me that being iterative and evolutionary with excellent communication is one sure way to deliver good software without unneccessary process. That sounds agile to me.

The Agile movement did not create these practices, and does not have sole ownership of them. Many of us were doing these things on projects in the pre-Agile era. In my own experience, I was on teams that used iterative lifecycles with two week iterations in the late ‘90s. We looked at Rapid Application Development and adopted some of those practices, and retained what worked. We also looked at RUP, and did the same thing, and a big influence at that time was the Open Source movement. If you go back to the ’60s, thirty-forty years before the Agile Manifesto was created, Jerry Weinberg describes something very similar to extreme programming on the Mercury project. That doesn’t mean the Agile movement is wrong, it just shows that there are other schools of thought other than Agile when it comes to iterative, incremental development.

The Agile movement did not invent these practices – they’ve been around for a long time. Some of us were very excited about what the Agile movement brought to the industry, because we had also been working in that direction. What the Agile movement gave to us was a shared language, a set of tools and practices and advances in these techniques that can be very useful. The Agile movement has given us a lot of innovative ideas, but we can look at pre-Agile and Agile eras for great ideas and inspiration.

This sidebar is irrelevant to the discussion. The agile community doesn’t lay claim to inventing these ideas, although in some pockets, it claims to have re-packaged them in interesting ways. Much of the agile movement has been about rediscovering and repopularizing grand old ideas that were lost in the furor of the CASE revolution and its flawed thesis that programming is just typing. I dislike assuming intent in others, but I have to ask: is Kohl angry because he feels the agile movement co-opted ideas that he held dear? I don’t know that it matters, except to further understand his perspective, which I find troubling in its inherent contradiction. After all, if agile is nothing new, then certainly neither is post-agile.

The bottom line is that whenever I work with a new team, when I find it’s time to introduce a new practice, I start with something appropriate from XP, then adapt as needed. If it’s a new team starting out, I try to use as many of the XP practices as make sense, then fix what’s broken. I’ve done this from the moment I had experienced enough XP to feel comfortable doing it. According to Kohl, that makes me post-agile. According to everything I’ve ever read and known on the subject, that makes me agile.

But why spend an hour writing about this? After all, Kohl says he’s not out to change the hearts and minds of men. What does it matter? Well, let me share something I read on “The Daily WTF”, now called worsethanfailure.com:

To a manager, refactor means to upgrade or add functionality. It is a danger of us techies using our language to explain something to non-techies.

You might well imagine my jaw dropping upon reading this. A term has been warped to mean its exact opposite. How could that possibly help me communicate to both programmers and managers in the course of my work as a change agent? So it is with Kohl’s “post agile”: if he calls “post agile” what large numbers of people already call “agile”, how does that help us communicate?

It takes me one step closer to simply keeping bees and growing asparagus.

Post Script

It seems these opinions have gained some external visibility. It’s always nice to know someone’s reading.