Read the Fine Print

As with many organizations these days, my company does Agile software development. Ignore for the moment that there is something wrong with that statement (and if you don’t see it, that’s fine, most people don’t). Agile is all the rage currently in software development. If you haven’t heard of Agile methodologies and you’re in the field of software, I have to ask what super-remote part of Antarctica you’ve been living in for the last ten years?

Agile development is a reaction against heavyweight project methodologies that focus on the documentation and the plan more than the people and the software. The various Agile flavors have the following elements in common.

• Highly iterative and incremental development cycles focused on continuous delivery of working software.
• Short feedback loops.
• Small, self-organizing (self-managing), cross-functional teams of motivated professionals.
• Close collaboration, both within the team and with the customer.
• High value placed on simplicity and adaptation.

Agile in itself isn’t the answer to all of life’s problems. This should surprise no one, but there are a small few who are shocked when it doesn’t do what it is supposed to do. Like other methodologies, the various Agile methods are tools. It is up to those wielding them to make them work and create art. Being a certified Scrum Master or agile practitioner won’t make projects miraculously successful any more than buying a table saw will make someone a master carpenter.

Scrum, XP, Lean, Kanban and the various other disciplines look good on paper, but you need to pay attention to the fine print. What fine print? I imagine the Agile coaches, Scrum consultants and anyone else that makes money in Agile training don’t always mention it, though in the interest of full disclosure they really should. If you have a copy of the Agile Manifesto you can read the fine print with a magnifying glass while standing under a blacklight on the third Tuesday of every month.

For those of you without blacklights, here’s the fine print:

• Use some common sense. That’s all Agile really boils down to. Yes, the people closest to the problem should be making the decisions. Yes, those people need to talk, raise obstacles, and otherwise work together. Yes, incremental design and development can work better than providing reams of documentation that no one will ever read. Yes, requirements can change and you must be able to react accordingly. Yes, the final product is orders of magnitude more important than following the plan. Does it really take an entire methodology to recognize these things?
• Do not use for mission-critical systems. The thought of NASA doing Agile development should scare anyone that doesn’t want rockets and satellites falling out of the sky. Likewise, the firmware used in pacemakers better not have a team of agile practitioners guaranteeing that they followed Scrum to the letter.
• If you are in management, do not use Agile if you are unable to let go of the traditional command and control hierarchy. This should be obvious when you see the part about self-managed, self-organizing teams, but micromanagers don’t always realize that they’re micromanagers.
• Everyone on an agile team needs to have some kind of technical background, preferably coding. That Project Manager with an MBA and no experience writing actual software might make a good Scrum Master, but they will need something to do for the other six hours of the day and that something should be moving the project forward. Similarly, if you have Systems Analysts or QA Testers that don’t know what code looks like, you better have a plan for them before because “cross-functional teams” means just what it says.
• Agile team members must be self-motivating and the team must be comprised of more good developers than average or below-average developers. A team of average developers cannot create great software in anything resembling a reasonable period of time, regardless of what methodology they use. Similarly, a team of good developers can probably create great software in any methodology, Agile just frees them up to do it more effectively.

For organizations that practice a more traditional development process, the transition to Agile will be highly disruptive. Making the transition without knowing all the implications will border on traumatic. Please don’t take this to mean that Agile is in some way flawed. It is very effective when used in the right context to solve the right problems. It is not, however, a silver bullet. Any ‘Agile Consultant’ that says or implies otherwise should be looked at askance, unless of course they mention the fine print.