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.

J. Timothy King has a good post talking about trying out new tools and being open to experimentation. This is a great sentiment and really the only way to mature at all as software developers. Try new things and see if they help. If you are having trouble with your current tools and processes, then what is the harm in taking a few days (or weeks) to try something new?

From the post:

A growing team is passionate about growth. And that means they will give new tools a fair chance. They might be skeptical. But because of their passion for growth, they will be able to set aside their skepticism. But they must choose to do so. They must choose to consider that maybe they’re wrong. They must choose to list what would need to happen to prove to them that they’re wrong. They must choose to test this list. They must choose to embrace the results and be excited to discover a new truth, to open up a new righteousness.

Another good point he makes is about slack time.

Of course, before you can take that risk, you need to have slack in your schedule. You need to be able to burn time in order to try new things. Slack is where you grow.

From what I’ve seen, too many companies are focused on the short term “get it done” approach. There is often no slack time built into the team’s process to sit and think and experiment. Research is key in improving both the developers’ abilities and the overall quality of the software being developed. Without slack, there is really no point in trying. You’re liable to be seen as wasting time and if deadlines are missed, “because I was thinking about how we can improve our overall abilities” likely won’t be an acceptable excuse.

I hate to keep pointing out one person’s posts, but Lidor is a great writer and says stuff so much more eloquently then I ever could. This time he writes about how we are all afraid to speak up and say what is really in our hearts about how we do software development. We know we should be trying something different, or stopping some technique that is more cost than benefit, but we just go along with what everyone else says, afraid of being labeled “uncooperative, pessimistic, or simply detached from the business reality”, or worse.

When you see a trendy technique that everyone thinks is the silver bullet, but somehow you just don’t see the benefit, speak up. Be that naive little boy who doesn’t know any better and point out that the emperor is naked.

Andrew has an interesting post on what we should call the traditional heavy weight waterfall processes. He comes up with “stubborn” as his adjective of choice, which I agree is a good word. But in his descripton of Agile, he contradicts himself.

In the first paragraph:

Agile is the most disciplined software development process I have used to date.

I was actually surprised at this statement and agree wholeheartedly. Agile is very disciplined. So disciplined in some cases that you get in trouble for daring to break the rules. For the record I’m going with the first entry in this definition of discipline, namely training to act in accordance with rules; drill: military discipline..

Then Andrew’s last paragraph reads like this:

I have found the adaptability of Agile and the disciplines of XP (test driven design, continuous integration, relentless refactoring, early and often delivery of working code) to be a much more satisfying solution for effective software development. And so have my customers.

So which is it? Is Agile disciplined or adaptable? To my mind, these two terms are contradictory. Maybe he ment you can be disciplined in your adaptability with Agile, but it is unclear. In any case, this kind of ambiguity is my main problem with Agile. Who the heck knows what it means anymore? There are so many definitions and so many people claiming to be Agile, that, like I’ve said before, the term is starting to get ambiguous at best, and meaningless at worst. If people just focused on “being agile” instead of “doing Agile” we’d have a lot less confusion.