pliantalliance.org

On November 27, 2000, I walked into a new job that would eventually save my career in software development. I was 18 months out of university and had been through several horrible projects. I had been stuck in consulting land, flying to the nether regions of the Maritimes and participating in back-breaking requirements gathering death marches and silly little one-off projects. I had told my wife that if InfoInterActive (IIA) didn’t work out I was going to find another industry to work in. I was serious.

So I walk into IIA and one of the first things I notice is a banner on the wall of the engineering department that reads “Solve The Real Problem”. I thought to myself “Hmmm, that sounds logical. I wonder why I’ve never heard that phrase before?” For the next two and half years I learned exactly how to apply “Solve The Real Problem” and it is because I learned how to “Solve The Real Problem” and how to develop software successfully that I am still a software developer today. Despite the fact that I have since moved to Calgary and gone through more distinctly non-”Solve The Real Problem” type projects, I still know that it can be done and that giant robust software systems can be built with an extremely high degree of quality and velocity. Two of the leaders of “Solve The Real Problem” at IIA are Brad Spencer and David Benoit. I consider them co-founders of pliantalliance.org since they really are the ones who came up with it. (Despite having posting privileges here, they have yet to post anything … nudge, nudge.)

Solve The Real Problem. Period.

I’ve come across yet another independant redefinition of what pliantalliance.org is getting at. It comes from Lidor who once again hits the nail on the head with FlexDev. FlexDev is defined as “creating the optimal process for each project”. Brilliant.

Lidor has a another post in which he points out that it doesn’t matter what you call it and I totally agree. Unfortunately, as he discovered, people insist on talking about how they are approaching a project so naming the “process” is somewhat helpful. Lidor came up with “FlexDev”, Jonathan came up with Post-Agilism and I came up with PSD. I’m sure there are others out there with other names. Comment below if you already have your own name. I think it gives credence to all of our thinking that we have independently gotten frustrated and have attempted to redefine how we are doing our jobs.

The extreme result of the current trend of questioning the applicability of Agile is complete abandonment of all things Agile. Ravi is now going to “focus on writing good software”, which is what I thought this whole industry was about in the first place.

Let me just say that we at pliantalliance.org still believe in the thoughtful, context sensitive application of the techniques that make up Agile software development. We’re just not sure that dogmatic pigeon-holing of all projects into Agile is the most productive way to go.

Dan North has a post about how agility is about coming up with a “repeatable, predictable way to adapt to change”. First of all, as we’ve discovered, “Agility” is about marketing, so in a sense, Dan is wrong. However, getting better at software development _is_ about evolvibilty. Adapting to a changing context and working in a way that best suits that context is the path to better software development.

From Dan’s post:

“As an agile process coach, my job is to increase a team’s – or in the case of an Organisational Transformation programme an entire organisation’s – ability to evolve. Taking a cue from Mother Nature, you can’t expect this to occur overnight. The weight of evidence shows that macro-mutations in the process are almost always going to be detrimental. Instead you need to evolve the organisation towards evolvability, or agility, through a series of small steps that are easy and intuitive to grasp.”

Replace “agile” with “pliant” and I agree 100% with this. Think. Evaluate. Change.

Brian Marick, a well-known “Agile tester” and signer of the Agile Manifesto, has confirmed what I had feared all along, except it is worse than I thought. Not only is “Agile” just a marketing term, “It was explicitly conceived of as a marketing term: to be evocative, to be less dismissable than “lightweight” (the previous common term).”

I thought it was some money grubbing marketers and book sellers who hijacked the term that the Agile Alliance so smartly chose, but that doesn’t seem to be the case. It appears we were being duped all along and that’s really disappointing.

Oh well. Brian’s post essentially ends a large debate that pliantalliance.org has been having (mostly with itself) about whether “Agile” was to be taken literally or not. This is actually a good thing. Now we can get on with the business of pointing out this difference to people and promoting the alternative of critically evaluating one’s own context and changing processes/techniques where appropriate as a means of improving how software development is done.

For the record, the “pliant” in “pliant software development” is not a marketing term and is ment to literally mean doing software in a pliant way.

Steve Bates blogs about Perspectives on Agility and his concern for the trend towards rigid Agile processes.

He talks a bit about psd and points out that “It’s also good to remember that even the techniques for determining what works best should be pliant and context-dependent.” This is exactly the sort of thinking I’m talking about. Awesome.

An excellent post questioning whether the oft heard Agile zealot cry of YAGNI is always justified. Lidor doesn’t say YAGNI should be abandoned or that BDUF is the way to go. He says quite pliantly that although YAGNI makes sense on the surface, “reality is somewhat more complex”. Sometimes making the bet to invest in the future based on experience and the context you are in is a good bet and therefore the right thing to do. A balanced approach is what is needed.

Jonathan has a good post coining the term “Post-Agilism” which is a “brand of process skepticism exhibited by experienced Agilists” he’s come in contact with. Processes are constantly questioned. Ones that don’t work are thrown out and ones that do work are continually tweaked to make them better. This is the definition of pliant software development.

On a side note, Jonathan is based in Calgary and his pliant leanings officially ties Calgary with Halifax for the largest pliant software developer community, at a whopping two people.