pliantalliance.org

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.

Lidor’s latest post is another gem. He says that methdologies, techniques, standards etc are just the manure you can add to a fruit tree. It might make the fruit grow a bit better, but if there are not solid roots (”commitment to quality and professionalism”) and strong trunk and branches (”a culture of mentoring, sharing, and open communication”) then the tree isn’t going to to grow at all, let alone produce quality fruit.

When Lidor refers to a long list of stuff (such as Pair Programming, SCRUM, velocity charts, burn-down charts, Bugzilla, Subversion, lint) he says this:

Each and every one of these methodologies, practices, tools, and standards is being marketed as a solution (and sometimes the solution) for the problems our industry is facing. Maybe the creators of these tools, practices, and methodologies, didn’t mean to market them as such. But the fact is, that most of us tend to perceive them as “just what we need” to improve quality, increase productivity, and reduce costs.

And this is why we want to get rid of the word “Agile”. The baggage it brings with it is extremely misleading. It brings the promise of better software, more productive and happy developers and lower costs. I’m not saying that “Agile” _won’t_ have these effects, but there are no guarantees and it will depend more on your developers and your organization than anything else. So let’s stop misleading people. Let’s continue to share with each other the things that have made software development better (in all the senses) _for_us_, but with the understanding that every context is different and so YMMV. Each of us will have to take all these examples and our own world into account before adopting a new tool, methodology or technique. Sound difficult? Well, yeah, it is. But the Pliant Alliance is not here to do your work for you and anyone who says they are is likely just trying to get into your wallet.