The agile disease

Luke Halliwell recently wrote an exceptional piece titled The Agile Disease. And, as someone that pushes this disease in various forms, you might be surprised to hear that I agree with just about everything he’s written on the topic, save a few points. For example, the commercial trendiness of Agile and its “manifesto” is just something I don’t buy into:

And secondly, they had to make their methods trendy and fashionable, so that clueless management at big corporations would hire them in.  Enter the “Agile manifesto” and “Extreme Programming” … Could they pimp their stuff any more blatantly?  

Luke’s major criticisms of typical Agile methods (such as Scrum) hit the nail on the head too:

A specific danger of the Agile processes is doing the easy parts and not the hard parts.  I’ve seen a number of teams saying they’re adopting Scrum, but when you look closely they’re doing the trivial parts (such as daily stand-up meetings and calling someone a Scrum Master) and missing out on tricky but important ingredients that could actually help them (for example, making their team cross-functional and reflecting on their practices regularly).

One of his most pointed ripostes is simple this: “Agile gives you an excuse for not introducing a little rigour and discipline into your project.” Dead on, mate — a danger that’s so commonplace it’s painful.

Agile is not a solution in and of itself. Those who sell a particular methodology — whether Scrum, XP or even Rational Unified Process — as the end-all-be-all solution to any organization are just plain wrong. There is no single solution that will work across an entire organization or even within a single project.

Every project, every team, every organization needs to develop a process that is suited to their needs.

I strongly believe that Agile principles such as Scrum provide an excellent basis for new teams to start with — a building block with which to create a foundation. On this foundation, a solution can be built. After 20 years of project management and consulting to solve the hard process problems faced by many organizations, I know that process is part of the answer. But throughout all of my projects, I’ve never seen a single, canned solution that works.

However, a solution can be created by drawing on a tool set that includes Scrum as a starting point, formal Software Quality Assurance and testing principles, good team organization, and possibly elements of more complex methodologies such as Rational. The very aspects of the challenges faced by any given project team will change the requirements, the conditions and the ultimate solution.

One thing that people often forget is that Agile itself recommends frequent self-inspection. This applies to the very process itself — in other words, the process that is put in place today may be woefully incorrect just a little ways down the road. The company grows, the team changes, the clients become bigger and more demanding — and the process had better change to reflect that evolution of the business. One size most definitely does not fit all.

So, all this aside, there are a few critiques I have of Luke’s post:

• “The ’sprint’, or in plain English, one iteration of software development, is nothing new.  You’d have to be pretty feeble to benefit from moving to these.”  Well, terminology aside (I don’t care if it’s a sprint or an iteration or a cycle), I actually do find value in fixed duration sprints. Most of the value extends beyond the development team — it is external. A fixed duration sprint aids in setting customer expectations around release cycles. It helps to have an artificial “time box” in which to set some work goals as well — otherwise, the customer keeps pouring more features in and is surprised when they find out it will take six months. Finally, I strongly object to those long, six-month development iterations: Short cycles with real, usable software delivered to the customer is useful. It keeps the team focused in one area, it helps prioritize and set goals, and it gets something into customer hands frequently (whether for hands-on feedback or just for perception, both are valuable).
• “The product backlog is just an estimated, prioritised list of everything you have left to do.  I find it hard to imagine a working software team that doesn’t have this already…” Alright, agreed — and yet, it happens all the time. Most often it’s not so much not having a list, it’s having an unwieldy, huge list that has no prioritization and no cost estimation. The product backlog simply formalizes a process wherein the customer is expected to help prioritize work based on its value.
• “Having an assigned person (the ‘product owner’) to control the backlog exists purely to combat a crazy situation where multiple people tell developers what to do.” Absolutely. Having multiple “bosses” (maybe it’s the CEO who thinks he can “chat” with the development team — and totally change the perspective on priorities) needs to be cut off and this is one tool that helps. But it’s not the only problem the product owner role address: What about a customer that has multiple stakeholders, multiple owners that all feel they can set project priorities? I’ve run into a few projects with this problem. Having the customer appoint their “voice” ultimately resulted in saving days of lost developer time.

Luke’s final comment on Agile as a whole:

There is literally nothing here of any interest to me.  It’s a bunch of common sense (sometimes bordering on banal) stuff, with some very arbitrary decisions made for you on things like meeting frequencies, and some really stupid terminology.  I don’t see how it benefits anyone but the worst of teams, and they have bigger problems.

I won’t argue the point that there is nothing here for Luke. But lets not forget about those companies that are just starting out, forming their first development team without any idea how to do it. Having some documented process — and possibly hiring a consultant to help guide them to a solution — is not a waste of effort. Quite the contrary, many companies have gone under after hiring a bunch of developers and “some guy” who says he’s a project manager… without having any idea what they were in for. Having an experienced hand at the wheel will benefit any organization — and if that comes with a bit of Scrum, or as Luke calls it “common sense,” it’s good for the whole team.