As Thomas Hobbes observed in the 17th century, “Life under mob rule is solitary,Everyone who has worked in software for more than a few years can probably relate to this observation. Software projects seem to lend themselves especially well to two things: fantasy-based planning and painful and repeated collisions with reality. Smart development organizations, tired of hitting their heads against the same wall over and over again, are looking at a new way of building software: Agile development. But life on an Agile project is different, and people need new skills to succeed when the easy stages of the waterfall are stripped away and they dive into the Agile whirlpool. Here are the five Agile commandments that every team member should know (we had ten, but we broke them into two releases):
poor, nasty, brutish, and short.” Life on a poorly run software project is
solitary, poor, nasty, brutish, and hardly ever short enough.
- Steve C
McConnell, Software Project Survival Guide
I. Thou shalt prioritize
In a waterfall project everything is high priority, until it isn’t. When you take that big pile of work and break it into iterations, though, you need to distinguish between “kinda high priority,” “really high priority,” and “really REALLY high priority.” For best results, you should rank all of your requirements from 1 to n and work through the queue in order.
Prioritization is a rare skill. It requires you to find the balance between two factors – value and cost – and to not only quantify them but understand and be able to describe them in detail to a variety of audiences. Value means different things to different people. To the marketing person it means, “I could sell that to our customers in a moment.” To the business user it means, “That would finally make it possible to do my job painlessly.” To the technical architect it means, “Until I get that, I can’t build any of this other stuff they want.” You have to be able to capture all of those definitions and translate them into a simple statement: “This element of the application is more important to us than that one.”
Cost is both simpler to describe and harder to specify: it’s the effort required to build a component, but no one knows exactly how long that is until it’s done. You can get a relatively close estimate once an application is designed, but it’s nearly impossible to make accurate estimates early in a project when you need to set priorities. Usually, it’s good enough to say, “That’s easy, and that’s hard. And that? Just thinking about it makes my head hurt.” Balance that with the value, and priorities emerge. Do the easy-but-valuable stuff first and save the interesting-but-nearly-impossible features for later.
Of course, before you can prioritize things you need to know what they are, which brings us to…
II. Thou shalt break it down
Waterfall projects, even relatively short ones, are monolithic by nature. You gather all the requirements, then you design the whole application, then you build all of the features for the release, then you test the whole application at once. Throw in a few stage gates and signoffs for good measure and you’ve got yourself a project! Agile development breaks this concept down, in more ways than one. Rather than assuming that we can know all of the requirements before we even start, we assume that we will learn as we go. Rather than requiring formal signoffs and then locking down any further changes, we build in checkpoints to review the application and add any new features that we feel will make it better. Rather than building everything at once, we build the most valuable features first and let people start using them as soon as possible.
In order to build this way, you need to be able to take large problems and break them down into small ones, a talent that is surprisingly rare in today’s business environment. We all know how to take small problems and make them into crises – thirty minutes watching CNN will show you that – but we struggle when asked to make something simpler. Just as a run-on sentence can be broken into shorter and clearer sentences, so a convoluted system requirement can be broken into its functional components. Learn to do this and you are on your way to (capital A) Agility.
III. Thou shalt communicate wisely
In a waterfall project, formal communication is the rule. Agile development, however, replaces static documentation and formal handoffs with person-to-person communication and collaborative problem-solving. If you jump directly from one to the other, significant chunks of important information will be lost. You need a strategy to broadcast the results of meetings, to capture decisions where everyone can see them, and to maintain a living documentation set that accurately reflects the current state of the application. Rather than relying on giant documents set to educate latecomers, newcomers, and drop-in stakeholders on what you’re building, you need to create 10-, 20-, and 30-minute pitches that present the project in varying levels of technical detail.
Agile works best when everyone knows what everyone else is up to. In the absence of a hive mind, however, you must be mindful of the information that you possess. After every decision, ask yourself, “Who needs to know this, and how should I share it?”
IV. Thou shalt go with the flow
Waterfall projects are like marching band music: regimented, slow-moving, predictable, and often ending with a noisy crash. An Agile project is like jazz: within a tight structure, the players are free to improvise to make the end product as beautiful as it can be. To succeed in this environment, you need to let go of your concepts of how things should go and concentrate on getting to the destination. The important thing on an Agile project is not what we thought we were doing yesterday, but what we need to do today to reach our goal. Once you are able to make that mental adjustment, to focus on that target on the horizon even as you make minute course corrections, you will be able to increase your personal efficiency and your team’s velocity.
As Stephen Covey says, “Start with the end in mind.”
V. To thine own self be accountable
On an Agile project, there’s nowhere to hide when you don’t meet your commitments. You meet with your team every day to discuss what you did yesterday, what you plan to do today, and where you need help. When you miss a deliverable, the person sitting next to you is immediately affected. The traditional waterfall excuses – “That wasn’t in the spec,” “The requirement was unclear,” “I’m waiting for the documentation signoff,” etc. – don’t work, so you have to actually do what you said you would do.
Believe it or not, this is shocking to some people, who find the long silences that greet their daily status reports increasingly uncomfortable and must decide to either start working or go find another project to hide in. High performers find this environment invigorating, though, as they are finally able to just do their jobs with a minimum of obstacles. If you are ready to take the credit and the blame for what you do every day, then you’re ready to go Agile.
So, there you go. As the Lord said on the eighth day, when he created programmers by mixing silicon, Doritos, and coffee: “Go forth and be Agile!”