pliantalliance.org

Ok, *this* is what we’ve been talking about here for the last three years. I’m assuming the author has never heard of pliantalliance.org, but despite that, it appears he’s been very pliant in his development environment, which happens to be a ‘distributed agile’ team. He and his team looked at Scrum. They looked at XP. They looked at the Agile Manifesto. And they proceeded to be agile with Agile. The team ended up keeping stuff from XP, dumping a lot of the Scrum ‘rules’ and evolving their definition of “Agile” over time into something that works for them.

For the record, I don’t personally agree with everything they have decided on doing. For example, I’m still a big holdout on universal pair-programming. But my opinion doesn’t really matter. I’m not on their team. I really agree with some other things they are doing, like really emphasizing communication and knowledge transfer. But again, my agreement doesn’t really matter either. The point is, they’ve taken what the books said, spun in their own experience, mixed in their own current environment and voila…successful software development. It isn’t that hard.

Jonathan Kohl will be giving a keynote presentation entitled What’s More Important: Being Agile or Creating Value? at the Better Software Conference & Expo in Las Vegas in June. See here for more info. Looks like a great talk. Here’s the abstract:

Agile processes and tools have become very popular over the past few years. They promise success where many organizations have had failures. Concerned over struggles to “be agile” and worried that they are not doing everything that every agile consultant says they must, some organizations are worrying whether their projects are really agile or not. Is worrying about whether or not we are really agile the point? Are we, in our rush to be “agile,” losing sight of what’s really important? Shouldn’t our question be, “Are we creating software our customers value?” Jonathan Kohl focuses on understanding why we are developing software, for whom, and what our end users and team members value. It’s easy to get caught up with the newest trends and tools and measure our success based on their adoption, while forgetting about the basics. Jonathan helps you determine whether your tools and processes are helping you create value or if they are distracting you. Furthermore, if your processes and tools are helping you deliver software that your customers value, does it matter how “agile” you are?

Remember, it isn’t about how well you are doing a process. It is about how well your process is helping you build valuable software.

The notion that you have to deliver business value on every sprint is garbage. It is about making progress with working software, not about giving Joe Blow product owner some warm fuzzies every two weeks. That is all.

The Register has named “Agile” one of the most overused phrases of 2008. Along with “the cloud”, “web 2.0″ and others, “Agile” was deemed to have been “so overused and misapplied during the last 12 months that they began to lose their meaning”.

Here’s the excerpt on “Agile”:

Agile software development methodologies are finally gaining the purchase they deserve in enterprise development shops, but the term “agile” was so overused that the agilistos were all but driven to capitalize references to Agile methods. “Agile modeling” is a legitimate expansion of the term, to be sure, but how about “agile enterprise management” and “agile project management?” It seems as though every business application now guarantees to create an “agile enterprise.” Online advertisers are encouraged to practice “agile marketing.” We now have “agile infrastructures” and “agile service oriented architectures”, “agile platforms” and “agile consulting” ,”agile testing” and even “agile IT”. What we need is an agile editor with an agile red pen.

First of all, yes, it has been over a year since I posted here. The main reason is that I had more important things to adjust to, namely, having a toddler running around the house and moving my family 1000km into the cold of southern Manitoba. Aside from that, I basically just stopped caring about the debate. It just didn’t/doesn’t matter to me anymore. The people who would get and appreciate my point of view had gotten it and everyone else was too mired in their dogma to understand what we were saying. Essentially, I moved on.

So what, you might ask, has brought me out of my pliant slumber? What could possibly make me care, now more than a year after I stopped caring and especially now that I’ve transitioned, (dare I say, “adjusted”) to part-time software developer? The answer is Luke Halliwell.

Luke Halliwell is my new hero. In one post he manages to sum up what I and others have been saying about the Agile movement all along. Namely, that it is all hype and common sense. And he does it with better, more entertaining writing then I ever did.

The whole post is, as my colleague put it, “SOLID GOLD”. But here are a few particularly golden points:

On Agile:

I’m sick of it. I can’t wait for the day when everyone realises how much of a fad-diet, religious-cult-inspired, money-making exercise it is for a group of consultants.

On methodology:

Firstly, beware following any kind of methodology. All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality. But in software, they’re fundamentally designed for mediocre developers who can’t think for themselves.

On people:

“Individuals and interactions over processes and tools” I couldn’t agree more with, but strangely, Agile is all about following processes and rarely mentions that having top people is the best thing you can ever do for a project (you could say your hiring process is more important than your development process!)

On hype:

The hype really annoys me! There are decent parts to Agile, but they’re just common sense. They don’t need a movement or a manifesto behind them, and they don’t need stupid terminology. I don’t see why I should have to call a colleague a “Scrum Master” and keep a straight face.

On daily stand-ups:

Having daily stand-up meetings is ludicrous; it exists simply to protect against the dysfunction of team members that never talk to one another. The Scrum literature goes on about how great it is that people can’t be blocked by anything for more than a day because of these meetings. In anything resembling a normal, common-sense team, people will surely raise blockages with their manager as soon as they occur and not need to wait for a daily meeting!

On scrum:

There is literally nothing here of any interest to me. It’s a bunch of common sense (sometimes bordering on banal) stuff, with some very arbitrary decisions made for you on things like meeting frequencies, and some really stupid terminology. I don’t see how it benefits anyone but the worst of teams, and they have bigger problems.

Gold, gold, gold, gold, gold and gold. Luke has hit the nail on the head and hopefully the games industry will be better for it. At least, I’m sure, his company will be better for it.

I’m not sure if Luke’s post will get me off my duff and make me post more here. I may as well just redirect pliantalliance.org to Luke’s article and be done with it.

cdsmith has a good post on TDD specifically and any software technique/process where he discusses the tendency for some to convince themselves and others that a particularly popular technique/process is worth the effort (even though it may not be) by changing company policy to indicate they should have been doing things the hard way all along. That is, find a TLA (a three letter acronym) you like and change your environment so that the TLA makes sense even if that means it takes more effort because your environment truly doesn’t quite fit the TLA.

To quote cdsmith:

To be clear, I’m not saying TDD is a bad idea. I’m saying that competent software developers ought to make rational choices, by considering the advantages and disadvantages of things for a particular purpose. This is directly opposed to the idea that we ought to stack the deck by defining away the disadvantages and pretending they are good design that we just didn’t recognize until now.

What a great quote. Just for emphasis, I’m going to point out the particularly pliant sentence in that paragraph.

I’m saying that competent software developers ought to make rational choices, by considering the advantages and disadvantages of things for a particular purpose.

Ahhh…. rational thinking….

I was pointed towards this talk given by Joe Rainsberger at the Agile 2007 conference a few weeks ago. The handout sums it up pretty well. Rainsberger is an experienced Agile coach and admitted Agile zealot. Given his good list of mistake examples, one is left wondering if he has ever been on a successful Agile project. And further, Rainsberger is a leader in the Agile movement and even he had trouble. What about the average Agile practitioner? Surely they must be having some problems too.

In his concluding paragraph, Rainsberger says:

In 2007 I realized that I had spent most of the XP-era of my career inadvertently, but consistently, forgetting about the people involved. I demonstrated this attitude by pushing ideas on them, believing the promise of XP over observing how people react to trying XP, emphasizing learning the practices over introducing what the team needs most, and perhaps most notably by assuming that everyone would be happier if they delivered software more effectively.

In short, he was apparently ignoring the context in which he was working. He was ignoring the impact that XP techniques were having on the project and the people he was forcing them on. Not surprisingly this led to some project failures. And now he is talking and writing about it. There may be some hope after all.

I’m currently looking for a new contract and every time I see a job ad with the word “Agile” in it, I’m faced with a conundrum. I don’t really know what it means and as a result I’m not sure if I actually have Agile experience. I certainly have _agile_ experience and I’ve done lots of the things that make up what they call Agile development. Stuff like iterative development, TDD, pair programming, refactoring, continuous integration, working with user stories and backlogs, working with and developing coding standards, participating in stand-up meetings and retrospectives, being on self-organizing teams (with mixed results) and dealing with highly volatile requirements (not to mention customers). I have actually only been on one project that was a ‘by-the-book’ Scrum project, but that was only about 9 months of my 8 year career and for a good chunk of those 9 months I was on a team of 1 which seems to go against the whole idea of ‘Agile’. I’ve never been on a real XP project, though I’ve interviewed with a couple and had many second-hand conversations with people who have. I’ve read alot about Agile development and obviously written a bunch about it on this blog.

And yet, I still don’t know if I have Agile experience because I don’t know what it is. I hope the people writing the job ads realize that they may be missing out on a good chunk of the developer population when they require ‘Agile’ experience and don’t expand on what they mean by that. Of course I’ll still apply and if it turns out they want ‘Agile as in XP/Scrum’ experience, I’ll just turn tail and run. Here’s hoping they actually want ‘Agile as in adaptable, flexible problem solver using a large set of tools and experience to deliver customer value on accelerated schedules’.