pliantalliance.org

Now that the March issue of Better Software Magazine is long out the door, I can post the pdf of the article I wrote for that issue.. The content was heavily based on some posts on this blog and the opportunity was a direct result of JK finding this site. So thanks goes out to him and +1 for blogging. I’ll probably blog more about the overall experience on my other blog at some point.

I love it when luminaries in the industry start questioning things. JK passed this one on to me this morning. In the post, Alistair Cockburn describes how he facilitated a work session without yellow sticky notes *gasp*. He used mind-map software instead and apparently it worked great.

He goes on to tell of how when he tried to share his experience with others, he was lectured by the Agilista about how yellow sticky notes are the only true way. Of his admonishers, Cockburn says:

Not that they’ve tried it, just that they’ve locked onto the opinion that yellow post-its are superior to everything else, and therefore to be used on all occasions.

But Cockburn goes on to talk about the bigger picture and the real problem.

I wouldn’t write about this if it was just post-its vs electronic capture. It is more general than that. I see my agile colleagues throwing their personal course-curriculum at clients rather than try to solve the clients problems; throwing Scrum training at them rather than …; throwing agile-in-general at them …; throwing 2-week iterations at them …; in general not thinking about what the client is ailing from before spouting generic agile rhetoric at them and lobbying agile-fad-of-the-day would-be solutions at them.

I wonder if comments like this from people the likes of Cockburn mean post-agilism and pliancy are crossing the chasm?

It has been the policy of the Pliant Alliance to not recommend (or decry) any one particular technique or process to the world. We can’t possibly know enough about what others are doing, how they are doing it, the projects they are working on, the people they are working with or the company and clients they are working for to get anywhere near a useful recommendation. We do point out techniques that people are claiming to be the snake oil of the 21st century and usually attempt to discuss when/where those techniques may or may not work. We do get into arguments about recommending processes without much evidence. But most of all we attempt to encourage people to think, evaluate and change.

Another tenet of the Pliant Alliance has been to encourage continuous learning and improvement of the processes we use through the sharing of experience with each other. This may sound contradictory to the above, but it isn’t. In order to think, evaluate and change, we must have some idea of what others have had success with. You should _never_ take other peoples experience as a guarantee of your success, but stories of success from others give us ideas of where we can improve our own process and techniques. Combine that experience with actually thinking about our own contexts and we are approaching the right trajectory towards software development goodness.

Just because we don’t want to push any one technique on you, doesn’t mean we don’t have opinions. However, those opinions live elsewhere in the blogosphere. With the expectation that you’ll take our experience with a dose of thought and evaluation, here are some blogs you _might_ learn something from.

• Sesquipedalian Spew - my personal blog with tech and software development posts mixed in with other general stuff.
• Collaborative Software Testing - Jonathan Kohl explores software testing issues
• nlg(n) - David Benoit’s “thoughts on why software development is hard, why hard things are interesting, and why easy things are boring.”
• Solve The Real Problem - Brad Spencer’s thoughts on professional software development.

Enjoy.

This little quiz designed to measure your company’s agility just makes me cringe. It reduces the idea of ‘Agile’ to a few soundbites and gives the impression (once again) that there is a formula for ‘doing Agile’.

It’s like when your partner comes over with her copy of Cosmo and asks you to take a ‘relationship quiz’. You know only bad things can come out of it and no matter what you say, the quiz will get you into trouble. For the record, I am lucky enough to have a psychologist for a wife, and she recognizes that those Cosmo quizes are just pop-psych drivel. She doesn’t waste her own time on them, let alone mine. They don’t take into account the people involved in the relationship. They generalize issues (often poorly and based on popular myths in society) that couples may have and attempt to provide advice without the slightest bit of information about the people in the relationship, the current state of the relationship and the history of the relationship. So the ‘results’ of the quiz, if you can call them that, are utterly useless and insignificant if you are actually trying to improve your relationship.

There are no checklists, quizzes, formulas, blog posts, websites, books, seminars, pamphlets, conferences or anything else that can guarantee you success in software development. They all provide interesting ideas and give some ways that _may_ help, but they should all be taken with a giant grain of salt and a giant vat of analysis and thinking (the vat I believe is the standard international unit for analysis and thinking). There are _never_ any guarantees.

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.