pliantalliance.org

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.

I don’t usually preview my future posts, but this morning I came across this post from Steve Yegge. I haven’t even finished digesting it, but you should go read it right now. I’ll wait…. go now and read … then come back.

… …

Welcome back. Did any of that sound familiar? If it didn’t, then roam around here for a while and see what you think. Seems to me Steve has stumbled upon pliant by accident. Nothing like independant thoughts to strengthen pliant resolve.

I’ll post some more later, since Steve has some good points and some great quotes. I’ll leave you with the quote at the beginning of the post and my recommendation to go read the post again.

Scrums are the most dangerous phase in rugby, since a collapse or inproper engage can lead to a front row player damaging or even breaking his neck.
— Wikipedia

I came across Buildix this morning which is ThoughtWorks’ version of the “Agile development platform on a disk”. I commend them for getting a single platform together that combines project management, collaboration, source control etc, all in one, but yet again, it shows how un-agile Agile is. They are sending a message that _this_ is the way to do Agile development. If you aren’t using _this_ particular set of tools, then you aren’t Agile. This is yet another sign that Agile does not mean actually being agile.

Mary Poppendieck once again gave a presentation at CAMUG last week in Calgary. I didn’t really learn anything new. It all sounded like sound advice.

Two interesting parts:

1) Mary said something along the lines of development groups need standards and standards are there to be challenged. They are there to be used as a baseline against which we can measure improvements in the standard. Now technically she was talking about architecture, tool and code standards, but I wondered about higher level standards like lean development. I managed to restrain myself from asking if lean development standards could be challenged.

2) Towards the end of the presentation, someone asked about Scrum and in particular about the backlog. Mary replied with something along the lines of that the backlog is just a way to put off people’s requests and is really only useful in a disfunctional organization. Basicly, if you are a good organization, you shouldn’t have a backlog. Now, I could care less about the Scrum backlog specifically and whether it is good or not, but I was pretty jazzed to hear the descent from Mary. What? Sometimes Scrum doesn’t work? I’m shocked. (Ed. That last part was sarcasm). It was also pretty funny as the palpable rumble of amazement/disagreement wafted through the crowd.

First of all, I’m not saying collaboration is a bad thing. For me, it has been key in the success I’ve had in software development. However, I’ve always had a problem with the XP bullpen style of developer space organization which apparently is supposed to ‘facilitate communications’. Nguyen is really getting frustrated with the noise that this type of workspace produces and I couldn’t agree more. Even in a cube farm, the noise can be enough to drive you crazy. No barriers at all must be a nightmare when developer arguments get going, when business analysts start spewing their knowledge or when testers cheer with glee as they find another bug.

I can’t speak for the other roles on the team, but developers definately need some quiet to think. I’m not advocating 24/7 radio silence, but an opportunity to have a quiet time in front of your computer so that your mind can focus on the problem at hand is key to solving any problem.

Just like most everything else we talk about here at pliantalliance.org, it comes down to a balance. Yes, there needs to be an environment that is open enough (both physically and socially) for good collaboration to occur, but there also needs to be a way that developers can get some peace and quiet.