pliantalliance.org

Google pedestal aside, Steve Yegge’s post last week (Good Agile, Bad Agile) has a lot of choice pliant leaning remarks. Here’s a few of them and my comments.

Teams are always situated close together in fishbowl-style open seating, so that pair programming happens exactly when it’s needed (say 5% of the time), and never otherwise.

This has been exactly my experience with pair programming. It is good when it is needed but it is not needed 100% of the time. Now maybe your company likes 100% pair programming and it works for you, and that is fine, but if it isn’t working for you, it would seem others (myself included) have had success just doing it when it made sense. Our suggestion is you spend a bit of time figuring out if it makes sense and go from there. On a more general note, using a technique when it makes sense is what pliant is all about.

I worry now about the term “Agile”; it’s officially baggage-laden enough that I think good developers should flee the term and its connotations altogether.

I’ve gotten several comments from people asking why we’ve insisted on creating a new term to describe how we develop software. Essentially what we are doing is small-a agile, but because of the baggage that comes with “Agile” and the difficulty with discussing “Agile” vs “agile”, a new term was needed. It was needed if for no other reason than to make _talking_ about it easier to do.

In the real world, every single participant on a project is, as it turns out, a human being.

This is something that “Bad Agile” (as Steve calls it) doesn’t handle well in his opinion. I agree with him. It seems to me that productivity in many Agile methodologies is assumed to be constant, hence the insistance on pair programming, for example. If it were the case that all programmers were consistantly productive, had no personal issues to deal with, didn’t have a baby that wouldn’t go to sleep the night before, didn’t have problems with their love life, were best buds with all their co-workers and generally didn’t have any emotions at all, then many “Bad Agile” practices would work all the time. But, like Steve said, programmers are human and however an organization develops software the fact that the programmers are human has to be taken into account.

So if I were you, I’d take Agile off your resume. I’d quietly close the SCRUM and XP books and lock them away. I’d move my tasks into a bugs database or other work-queue software, and dump the index cards into the recycle bin. I’d work as fast as I can to eliminate Agile from my organization.

And then I’d focus on being agile.

Exactly. Focus on being agile and to hell with all the -isms.

Think. Evaluate. Change.

I think I’ll just be putting a permanent link to Lidor’s blog on the sidebar or something because I find myself wanting to reference most of his posts and I’m starting to feel like a chump for riding his coattails all the time. It is just that he seems to be thinking a lot of the stuff I am, and he can write way better, so who can blame me?

Oh well – check this post out.

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.