pliantalliance.org

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.

In an effort to avoid comment spam, I’m using a Wordpress plugin that shuts off comments after 28 days. Since traffic is increasing around here, I’ve upped that time to 60 days but if comment spam becomes a big problem I might put that back down.

If you want to comment on a post that has comments closed, simply email me and I’ll post again so a discussion can ensue. Thanks for your patience.

ocean posted the yesterday on his misgivings about unit tests. He’s worried that unit tests might occasionally mask underlying issues with the design of a system. Developers are perhaps too focused on getting the green light on as opposed to ensuring that issues they run in to and the impact of the issues on the overall system are completely understood and fixed. This is definately a case of Solve The Real Problem and if unit tests cause people to not dig deeper to verify that the integrity of the system is maintained once a failing test passes, then they could be in for trouble.

I’m not saying this is what actually happens with unit tests and I don’t think ocean is either, but being aware of possible pitfalls in using any technique is always a good idea and an important part of the ‘Think. Evaluate. Change.’ philosophy that is PSD.

In all seriousness, I am extremely interested in the thoughts and opinions of some of the better known people in the Agile industry, people we would consider leaders. The signers of the Agile Manifesto would be a good place to start. I am curious what they think of ‘doing Agile’ vs ‘being agile’. I am curious whether Agile is just a marketing term or if the original intent was to promote actually developing software in an agile manner. Are they stepping back from supporting specific methodologies like XP and Scrum? Are they for or against blanket imposition of Agile techniques on a team, regardless of the context and consequences?

Martin Fowler recently posted about Agile Imposition and thankfully he is not in favor of it.

But agile methods aren’t the best for all situations, and personally I’d rather have a team work in a non-agile manner they chose themselves than have my favorite agile practices imposed upon them.

Any other leaders out there with opinions on all this? Are they publicly going to comment here (or anywhere on the web for that matter) if their opinions have changed over the last couple of years? I’d like to hear from them. I’ll even offer to post comments (direct quotes or not) anonymously if any of them want to email me privately.

This should be interesting …

A post on The Bag of Holding says some great stuff that I agree with 100%.

Great stuff.

On another note, the post also talks about how fads rise and fall in a fairly predictable pattern which usually involves some period of fighting between proponents and opponents of the fad. I want to clarify that when it comes to Agile software development, I am not an opponent. I think many, if not all of the techniques espoused by Agilists will work in many contexts.

What pliant software development opposes is what Mike talks about in his post, namely the blind implementation of a methodology that we believe will solve all our problems and make us perfect. This just isn’t going to happen and promoting a silver bullet solution is negligent at best. BTW, I’m not saying that the belief is valid or that all proponents of Agile are preaching a silver bullet, but it is believed nonetheless by some subset of the proponents, adopters or potential adopters of the methodology and thus it creates a problem for the rest of us who know Agile is not a silver bullet.

Someone is pushing the silver bullets and whether it is Agile, a get rich quick scheme or a diet plans, we should strive to debunk them whenever possible.