Trojan rigidity. Agile anti-patterns (I)

One of the characteristics of most traditional – linear, waterfall – styled organizations is the extremely rigid execution of their software development projects . “Our handbook says we need to fill in this form, so that’s what we do guys.” People is these projects live by the blind assumption that whoever invented or wrote down their software development process knew what he or she was doing. So we’ll just fill in the form, even though we’re not quite sure what it is for. And even better, all projects great and small, live under the same regime. This is where six weeks, three developer projects get stuck with a steering committee, an architecture board and a quality assurance work group. We need predictability in our projects more than anything else!

But enough laughter. One of the characteristics of agile software development projects is the flexibility and adaptability to only do what is necessary in the project. No matter which agile process we apply – be it Scrum, Smart, XP, FDD, or OpenUP – we try to delay the actual work to the latest possible moment in time that we actual need to do the work. And we delay decisions in the same manner. In both cases we do this so we have maximum knowledge over what we should and should not do. Thus, for example the design for a particular piece of functionality is done just before building the software.

We know better

These two approaches appear to be totally different or even orthogonal, and yes, they are. Still a lot of organizations cling to the rigidness of their waterfall processes. In most cases this is because they think it will make their projects more predictable and repeatable. Or sometimes just because they just don’t have a clue. In most of these poor organizations, we agile people laugh at this rigidness, because we think we know better. But do we?

I would say there’s also a dark side to our laughter. In fact, with the increasing popularity of agile software development a lot of newbie agilists entering our projects I predict that the freedom and flexibility we preach will slowly shift towards more rigidity and ceremony. And I don’t mean waterfall rigidity, but agile rigidity. Again, a lot of people will think that whoever invented or wrote down their software development process knew exactly what he or she was doing. A lot of people only have a vague clue to why he or she wrote down the process.

No modeling

This agile rigidity anti-pattern is easily recognizable in projects – or even better still: in blog discussions. These days there seem to be more blog and Twitter posts on agile than there are user stories in agile projects. Let me present you with a few examples of this new agile rigidity. In the agile process Smart (see www.smartusecase.com) it is suggested to add a number of work items right from the start of the project to the project backlog that deal with determining project scope, modeling requirements (in smart use cases), creating a sound estimate for the project’s complexity, and also maybe deliver a project proposal. Having a project proposal, is not a bad thing if you want to (sell and) run the project. In my day to day life this short list of suggested work items works quite well, and moreover, is totally compatible with processes such as Scrum and FDD. We have been using this approach in agile projects for about ten years successfully.

However, much to my surprise, when I recently elaborated on this approach – in a blog post – people comments on this post and accused me of actually promoted doing waterfall disguised as agile – just because I advised a few neat deliverables other than writing code during the first iterations or sprints of my projects. Come again? Since when does being agile mean not capturing requirements. I’m not promoting the big upfront design here. Who says I have to deliver code anyway? I’ve used agile principles, techniques  and best practices  in numerous projects, including projects that didn’t deliver any code at all (like code audits). A backlog contains work to be done, whether that’s “check software architecture”, “investigate namespace dependencies” or “write login screen”. My burn down is still valid, and so are my estimates.

Another example? I love to have my requirements modeled out in what we call smart use cases – small use cases of similar complexity and granularity that work pretty well in filling the project backlog and determine sprint backlogs (just to use the currently most popular terminology). But, standing at a coffee machine at a customers office  a Java developer came up to me, claiming that I should write user stories on post-its instead of modeling smart use cases in a UML modeling tool. And why? “Because that’s what Scrum dictates.” Eh.. “We do not do use cases in agile projects,” said my developer, long hair, goatee and all. “And besides, we do not promote modeling tools.” Come again?

Trojan

That’s agile rigidity for you. In my honest opinion, with a huge crowd of people migrating into agile software development, agile rigidity will play an increasing role in our life. And it will definitely contribute to failure in near future agile projects. Now you should note that this anti-pattern is not a threat coming from the ever dangerous outside world. This threat will be coming at you from within your own project. It’s Trojan rigidity. But there’s hope for you: just follow the correct procedures.