pliantalliance.org

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.

Google pedestal aside, Steve Yegge’s post last week (Good Agile, Bad Agile) has a lot of choice pliant leaning remarks. Here’s a few of them and my comments.

Teams are always situated close together in fishbowl-style open seating, so that pair programming happens exactly when it’s needed (say 5% of the time), and never otherwise.

This has been exactly my experience with pair programming. It is good when it is needed but it is not needed 100% of the time. Now maybe your company likes 100% pair programming and it works for you, and that is fine, but if it isn’t working for you, it would seem others (myself included) have had success just doing it when it made sense. Our suggestion is you spend a bit of time figuring out if it makes sense and go from there. On a more general note, using a technique when it makes sense is what pliant is all about.

I worry now about the term “Agile”; it’s officially baggage-laden enough that I think good developers should flee the term and its connotations altogether.

I’ve gotten several comments from people asking why we’ve insisted on creating a new term to describe how we develop software. Essentially what we are doing is small-a agile, but because of the baggage that comes with “Agile” and the difficulty with discussing “Agile” vs “agile”, a new term was needed. It was needed if for no other reason than to make _talking_ about it easier to do.

In the real world, every single participant on a project is, as it turns out, a human being.

This is something that “Bad Agile” (as Steve calls it) doesn’t handle well in his opinion. I agree with him. It seems to me that productivity in many Agile methodologies is assumed to be constant, hence the insistance on pair programming, for example. If it were the case that all programmers were consistantly productive, had no personal issues to deal with, didn’t have a baby that wouldn’t go to sleep the night before, didn’t have problems with their love life, were best buds with all their co-workers and generally didn’t have any emotions at all, then many “Bad Agile” practices would work all the time. But, like Steve said, programmers are human and however an organization develops software the fact that the programmers are human has to be taken into account.

So if I were you, I’d take Agile off your resume. I’d quietly close the SCRUM and XP books and lock them away. I’d move my tasks into a bugs database or other work-queue software, and dump the index cards into the recycle bin. I’d work as fast as I can to eliminate Agile from my organization.

And then I’d focus on being agile.

Exactly. Focus on being agile and to hell with all the -isms.

Think. Evaluate. Change.

I think I’ll just be putting a permanent link to Lidor’s blog on the sidebar or something because I find myself wanting to reference most of his posts and I’m starting to feel like a chump for riding his coattails all the time. It is just that he seems to be thinking a lot of the stuff I am, and he can write way better, so who can blame me?

Oh well - check this post out.