pliantalliance.org

Mike has an interesting post about some of his recent experience at a company adopting agile. He seems to have a reasonable amount of skepticism but is willing to try things out, which is good.

One thing Mike touches on with respect to the purpose of pair programming is the fact that developers are different.

Now, it is a fact that individual coders have different talents; some are good at one thing, but not as strong at something else. Some are about the same everywhere. Some are rockstars. And some are morons and couldn’t tie their shoes without looking it up first on ExpertsExchange. Large organizations (the types that have things like “methodologies”) tend to attract few rockstars and lots of mixed talents and assorted riffraff. (I’m not pointing fingers, I’ve worked there too!) Pair programming works well there because it leaves no individual responsible for the output of the team.

This brings up two points.

First, developers can’t be interchanged. You can’t swap out one developer for another and expect the same results. It just isn’t going to happen. Developers are different. People are different. Period. We aren’t robots. We aren’t building 1000 copies of a widget for 8 hours a day. In fact, it is worse than that. Not only do developers not have robotic output consistant with each other, but most aren’t even consistant with themselves from one day to the next.

Second, individual responsibility is a good thing and if pair programming (or anything else) reduces individual responsibility then the output of the team will suffer. We want developers to ‘own’ their code. We want developers to be accountable for what they do. If they don’t care, it will show in the output, regardless of how many developers are working on that piece of output. I’d much rather one developer who takes responsibility for his own code then a pair of programmers that rely on ‘team responsibility’.

For the record, I don’t think the intent of Agile was to reduce developers to robots, but it sure feels that way sometimes.

Over a year ago, I posted Agile Is An Adjective, Not a Noun on spew. I moved it to pliantalliance.org last January.

Now I come across Perryn’s latest post, which sounds awfully familiar. Read the comments as well.

In one comment, Steve Bates says:

It seems to me that saying ‘Agile Practices’ makes about as much sense as saying ‘Lightweight Running Shoes’. A person will generally run faster with lighter shoes than heavier shoes, but that’s not always the best tradeoff. For example, for trail running you might want a heavier (somewhat less agile) shoe to lower the risk of damage to your feet.

Of late there has been more and more people piping up in the blogosphere about issues pliantalliance.org is concerned with. Perhaps I’ll have to find another soapbox to stand on soon. I can only hope.

Could the Agile Manifesto possibly have some short comings?

A couple of interesting posts talking about the manifesto and usability popped up this morning. Check them out.

- The Interface is the Program, and it ain’t Agile
- Refactoring the agile manifesto

I like that more people are questioning things. We should all _always_ be questioning all things. Nothing is stable and everything is questionable. Challenge the status quo, because no matter what else it is, status quo != progress. We can always improve.

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.

With increased traffic, comes increased spam. In an effort to combat comment spam I’ve installed a captcha plugin for Wordpress. I realize this is kind of a pain and I hope it won’t deter people from commenting since I like getting feedback and generating discussion. You can always register and then login before commenting, in which case you won’t see the captcha. Of course, I’ll delete any account if spam gets posted through it.