pliantalliance.org

So apparently, people at ThoughtWorks, arguably the leading Agile consultancy in the industry, are starting to question and debate what “Agile” is and whether or not the whole term needs to be abandoned. I posted about Jim Webber’s post the other day in which he declared himself an ‘Agile atheist’. For a good run down on the ensuing discussion check out this blog post.

What I find most interesting is the different perspectives people have on what “Agile” is. Some people feel “Agile” is rife with dogma and religiosity. Others apparently think everything is fine and haven’t experienced the dogma.

In a comment to Jim’s post, Jeff Santini (another ThougthWorker) says:

You said you are not Agile because you don’t believe in it’s religion and you don’t accept its dogma. Yet I AM Agile and I also don’t believe in its religion nor do I accept its dogma. As a matter of fact I don’t have any idea what its religion or dogma are.

That last sentence just baffles my mind. It is one thing not to have experience the dogma, but to deny its existence is … I actually can’t think of an adjective here. Even if you are a strong believer in “Agile” and the practices that some people say you must be doing in order to be “Agile”, I can’t see how you can deny the existence of some force in the industry trying to push “Agile” methodology as the one true way to develop software. Perhaps we can debate the size of that force (I personally think it is huge) but to deny the existence of “Agile” dogma, one must have been seriously not paying attention to what is going on for the last couple of years.

Later in her post Deborah describes exactly what the “Agile religion” is, although still not committing to its existence.

If Agile religion exists, it seems to consist of a focus on strict adherence to practices without a need for understanding, combined with judgmental criticism of others - clearly ignoring the spirit of the Agile Manifesto’s “people over process,” values-driven approach.

That’s pretty much the whole issue in a nutshell and the entire reason for pliantalliance.org’s existence.

If nothing else I guess the mothership is at least starting to think about what people like Jonathan and myself have been saying for the better part of the last year. I’d call that progress.

I don’t know much but I know that when people start singing songs about a methodology, it is time to move on. We’ve definitely reached a high point (or low point depending on your perspective).

Jim Webber posts about his lack of belief in Agile. He calls himself an Agile atheist.

From Jim:

I am not agile because I don’t believe in the agile religion and I don’t accept its dogma. I like the engineering and planning practices that agile teams use - in the same way that I like people who do nice things (even when they do it because of fear of divine retribution).

Even if you don’t believe in Agile, that doesn’t mean you don’t believe in some (or all) of the techniques that come along with the Agile dogma. Some may think we are throwing out the baby with the bath water when we talk about pliant development or post-agilism, but they are mistaken. We are well aware that the techniques espoused by Agilists do work in some cases. They just don’t work in all cases and sometimes not as nicely as some would have you believe. So let me be clear. We have to be careful not to through out the techniques while attempting to rid ourselves of the dogma. Keep the baby, syphon off the bath water.

I was meaning to get around to commenting on this post about preventing work not in the Agile iteration plan interrupt what the developers are working on. I had some problems with the post but I couldn’t quite put my finger on it. Before I could sit down and think, Joel Spolsky posted his comments and I realized what my problem was (and apparently Joel has the same issue).

The Agile environment described by Dimitri in the original post is too rigid. There is no flexibliity in the plan to be able to respond to urgent requests and do things that are critical to the business, but which weren’t foreseen during the iteration plan. Like Joel, I agree context switching is generally a bad thing, but so is closing the door on the business for two weeks at a time and ignoring what is going on with them. There needs to be some flexibility in software development processes.

From Joel:

Agile development is supposed to be about agility. It’s supposed to mean that you can change plans quickly. It’s not supposed to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can’t rearrange their schedule a bit to serve the needs of the customer. Dmitri’s conclusion, I’m afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn’t take customer’s needs into account.

Unfortunately, this is exactly what Agile is becoming to some. It is becoming a rigid set of procedures that we’ve swapped with the old set of procedures and declared progress. Dimitri’s example is exactly the opposite of “Customer collaboration over contract negotiation” described in the Agile Manifesto. Granted the “contract” has now become a 2 week iteration plan, instead of a 3 year, multi-million dollar deal, but their is still a contract and the Development Manager chooses to stick to that contract rather than collaborate with his customer.

Don’t get me wrong. I personally believe that iterative development is the way to go. We can argue about the details (length, parameters etc) of the iteration, but iterating and evolving software over time based on customer feedback, business needs, technical advancement etc, is the only way I’ve ever developed successful software. So yes, we need to make a plan. We need to know what we are doing. Don’t just sit there, ready for the business to come to you to put out the fires. That is the other extreme and it is not good either. Make a plan, but be flexible and don’t worry if in the middle of your iteration, something comes up that is deemed a higher priority and the plan has to be shifted on the fly. It is better to deal with change than it is to stick your head in the sand and have change destroy your business.

Ravi is at it again and he really hits the nail on the head. In this post he discusses Steve Yegge’s now infamous Good Agile, Bad Agile post, the wrath that post has incurred from the Agile community and his thoughts on the whole mess and Agile in general.

He sums it up like this:

Ok folks, listen up. Agile/XP is no panacea. It is just what worked for Kent Beck in certain contexts. The fact that there are a whole bunch of “agile consultants” both individuals and companies, out to part you from your money in exchange for the arcana of “True Agile” does not absolve you for thinking for yourselves.

That last part is really the key to all this. We must think for ourselves, because no one else will. The only people who are going to be able to determine what is best for your organization and how your organization should develop software with the people, culture and environment you have is the people who are in your organization. If you don’t have the expertise, then hire it. You can still ask for advice from consultants or books or whatever but it is your responsibility to distill and evaluate what they say and how that impacts on your context. Remember, everyone has their own agendas and your organization’s well being is not everyone else’s top priority. No one is going to do your work for you. Think. Evaluate. Change.

In my last blog post I talked about making sure your practices are delivering business value and changing things up if the value isn’t being produced. What I failed to mention was that this process of determining what works and doesn’t work for your context and organization is really difficult.

Fortunately, Marc Evers was paying attention and posted his thoughts on knowing if your practices are working. My first reaction to Marc’s post was, “Crap, that all sounds like it would be a pain and a lot of work.” And then I realized I had that reaction because that’s the truth.

Maybe this isn’t brain surgery and for the large majority of software being developed people’s lives aren’t at risk, but that doesn’t mean developing an organization that excels at software development is easy. There are no easy answers. It requires thought and time and effort. People looking for a quick fix should look elsewhere. You aren’t going to find it here or anywhere else (but you are welcome to keep looking while the rest of us get even better at what we do).

Garrett Smith has posted some thoughts on appropriateness of Agile techniques and being careful about attempting to implement some practice just because “it is Agile”. It comes down to delivering business value. Just because something is “Agile” doesn’t mean it is good for the context the project is being run in.

Garret says:

Just because the team is pair programming, adaptively planning, and driving development with tests does not mean it will achieve the business goal. If the team is programming solo and doing big up front design it does not mean the team will fail.

Couldn’t have said it better myself and there are 100s (1000s?) of cases of both an Agile team failing and a non-Agile team succeeding.

Garrett also says:

I advocate Agile practices; they are generally a better way to get software written.

I like this. In his experience, Garrett has come to believe that Agile practices are generally a better way and so he advocates them. There is absolutely nothing wrong with this. He would be negligent if he didn’t advocate what he has generally had success with.

However, Garrett’s advocacy is tempered with an insight that few possess. The insight is that not everything he has had success with in the past will be successful in the future. Things change and people change. Instead we should be focusing on delivering business value. If the tools/practices you have experience with achieve the business goals then by all means, keep doing them. But, and here is the hard part, if they _don’t_ achieve the business goals or don’t fit in with the context you are in at _this_ point in time, then you must look around at what other people have done to achieve their business goals in order to figure out what will work in your context. You must try to find something that delivers the business value in the context you are in. Sticking to something that doesn’t work and not attempting to find something that works better is negligent at best.

Jonathan posted his latest article over the weekend and I recommend everyone go read it, no matter where you are in the spectrum of Agile. Jonathan talks about many aspects of current Agile thought and does a good job in comparing the various type of people that we see in the community.

In the end, I firmly believe (and I think Jonathan does too) that the “Agile or not” debate is moot. There _is_ a post-agilism movement coming (or already here) and we are going to have to deal with it. The software world is changing (did it ever stop) and if you don’t adapt to the world you’ll get left behind.

As Jonathan says:

Let’s move forward together, and create the new future of software development, standing on the shoulders of the giants who have come before us.