When you work with Atomic Object, you’ll hear a lot about Agile software development. Agile takes many different forms, but all of them are, at heart, about writing better software faster. Agile is part philosophy, part methodology, and part discipline. The Agile Manifesto emphasizes people instead of mechanical processes.
But before diving into the specifics of how Agile works, let’s back up and look at the problem Agile is trying to solve. Why come up with a new system in the first place?
The Problem: Poor Accuracy
In World War II it could take 9,000 bombs to hit a target the size of an aircraft shelter. In Vietnam, 300. Today we can do it with one laser-guided munition from an F-117.
– USAF in 19911
Agile software development is a form of project management, and project management is—metaphorically—about hitting targets. So let’s talk about some not-so-metaphorical target hitting: precision bombing.
The first airborn bombs predate the American Civil War. In 1849, during the First Italian War for Independence, Austrian forces bombed Venice using unmanned balloons. Suffice it to say, accuracy wasn’t one of the requirements.
Ninety years later, during World War II, efficiency had improved but accuracy hadn’t. Fleets of bombers dropped thousands of bombs, which they had to if they wanted to know they’d hit the target. Hitting the target was, largely, accidental.
Software’s poor record with precision
Often software development shares a similar story. First an undisciplined test balloon is sent out, and over time the efficiencies are improved, but without any increase in the odds of success. For large organizations, the few projects that happen upon success pay for the ones that don’t. But small organizations can’t play the same game because playing the odds is expensive—carpet bombing isn’t an option. The smaller you are, the more precision matters.
It’s an inexact comparison—creation and destruction—but it helps to keep a concrete image in mind when talking about something abstract like software development and project management. Agile is not, at heart, about methodologies, craftsmanship, extreme programming, or any of the other reasons you’ve probably heard.
Agile is about precision.
What it Takes to Hit the Target
Even the most thoroughly engineered bombsights of World War II couldn’t account for all the variables that buffeted a bomb between the plane and the ground. There were simply too many factors to calculate. Dropping a bomb precisely didn’t result in hitting more targets.
The same goes for software development. The chances of meeting a project’s goals aren’t improved by launching a project more precisely, detailed requirements document in hand. There are simply too many factors between the launch of a project and the deadline. Even the best launch can’t ensure the project hits its target. Teams change, markets change, technologies change. Better bombsights won’t help. For better accuracy, something altogether different is needed.
Agile artillery
Bombing accuracy didn’t get better until engineers gave up on building a better bombsight and instead began improving the bombs themselves. They gave the bombs agility.
Today’s bombing accuracy is so high that not only have we largely forgotten the term “carpet bombing”, but we’ve come to consider civilian casualties as being avoidable—something of little concern only a few decades ago. We often attribute such accuracy to high technology, like lasers and GPS, but those are incidental details. The big picture is much simpler.
To turn a dumb bomb into a smart bomb, you only need to give it three things:
- Where its target is
- Where the bomb is
- The ability to change course
No matter how errantly a smart bomb is dropped, it will stay on course—provided it can check the target’s position, check its position, and make course corrections. No unexpected wind can push it off course.
Agile Teams
Software teams can only stay on target if they’re given the same abilities that turned dumb bombs into smart bombs. Software teams need agility.
There are a lot of component practices to any Agile program, but all of them—at the core—are about checking the team’s position against the position of the target and making small course corrections to make sure the two meet.
Let’s take a closer look at how.
Where’s the Target? – User Stories & Task Planning
The first job on every new project is figuring out where the target is. At Atomic, the development team sits down with the client for several days to work out what the business does, who the clients are, what they need, and (after we’ve discussed all that) what software will best solve the problem. That gives both the development team and the client a 10,000-foot view of the land below and, roughly, where we’re going. But a high-altitude view won’t help us hit the target precisely, so we move in for a closer view.
With the broad strokes laid out, the development team works with the client to lay out specific features of the software. We call these features “stories.” They’re usually brief (we write them on average-sized sticky notes) and very high-level. A story might be “Users have to log in” or “The app gives the user notifications”.
Stories in hand, the development zooms in for a better look at what they’re trying to accomplish. They sit down together and outline the technical tasks required for each story.
These features, stories, and tasks serve as the positioning system throughout the project. They aren’t requirements that never change, but a way for the team and the client to measure changes when they happen.
Once we know where the target is, it’s time to start tracking where the team is in relation to it.
Where Are We? – Backlogs, Iterations, & Velocity
If you hear Agile practitioners talk about backlogs, points, and task tracking, what you’re really hearing is navigational jargon. These concepts help teams measure their distance to the target and make sure they’re heading in the right direction.
All the tasks outlined at the start of the project are collected and form the basis of the project backlog, the list of work still to do. Tasks are taken from the backlog and worked on. Any new tasks that come up in the course of the project start life in the backlog. Some teams keep track of tasks in the backlog with index cards pinned to the wall. Other teams use specialized software.
Staying on course requires frequent position checks. Go too long without checking your location, and you might find you’ve gone so far off course the error can’t be corrected. Falling bombs check hundreds of times a minute. Agile software teams don’t need to check quite that frequently. Many check where they are every week, some every two weeks. It depends on what’s right for the project and the client. You’ll probably hear this interval between position checks referred to as “an iteration”.
Velocity
One of the most important measurements on a software project is velocity. Any physicist will tell you that velocity is how much position changes over time, and that’s just what it means on a development team. Velocity measures how much work got done from one iteration to the next—how fast the team is working through tasks. The team might measure their velocity in tasks, but more commonly they measure in points.
Points are unitless values attached to tasks that indicate a rough estimate of how much work the development team thinks a given task will be. Not all tasks are created equal, and measuring velocity merely by counting tasks leads to wild swings in velocity—high in an iteration with easy tasks, low in an iteration with hard ones. Attaching some indication of difficulty to a task, and gauging velocity based on that difficulty, takes away some of the dramatic variation and gives a better estimate of what to expect from the tasks coming up on the agenda.
A falling bomb’s velocity is affected by many forces—gravity, wind, air pressure, its own steering mechanisms—and a development team’s velocity will fluctuate as well. A lot of factors affect a team’s productivity, but even the smartest bombs don’t control their own speed, and an Agile development team doesn’t control its velocity either. Velocity is a measurement, not a knob to turn up or down.
All these measurements are about planning and, when necessary, adjusting course.
How Do We Change Direction? – Communication & Empowerment
Projects, especially software projects, are liable to change. It can take years to turn an idea into a product ready for the public, and few founding assumptions last that long. Features change priority. Technology changes. Some stories take less work than expected. Others more. Technical tasks are added and removed as developers learn about code libraries, programming techniques, and unexpected challenges. All these and more represent changes to the target and the team’s position, deviations have to be corrected.
Suppose you’ve given your development team the job of building a site for entering data into forms, but during the course of the project it becomes apparent that some reporting on all that form data would be helpful. Rather than arguing that reporting functionality wasn’t part of the original plan, an Agile team will look for ways to adapt and meet the need, prioritizing features that are valuable to the client even if they’ve come out of the blue.
Without the ability to change course, all that knowledge about where the target is and where the team is in relation to it is an exercise in futility. The team has to be able to change course. Otherwise, there’s no reason to call it “agile”.
In a lot of organizations (especially large ones), decisions are made at the top and carried out at the bottom. Rarely do the lessons learned from implementing make their way back up to the top, regardless of how important they are for making future decisions.
Agile development teams work differently. Often the developers making the decisions are the very same ones putting them into practice, and when they aren’t doing it themselves, odds are they’re standing right next to the person who is. When a decision doesn’t work out as well as originally anticipated, that feedback gets back to the decision maker in short order. The team is able to adapt and change strategies.
Agile teams also take a bigger role in designing the end product. Developers and clients share a partnership, both working together to create the best product for the resources. Often that close partnership is able to come up with new solutions that get the project back on course. Without the opportunity to collaborate and influence the end result, the development team would simply stray further and further from the target.
Being empowered to change direction and navigate around obstacles or compensate for unexpected forces allows the project to succeed in ways other projects can never hope to.
Conclusion
A development team with better accuracy creates new opportunities. Less effort spent trying to hit one target means more targets can be hit. And if you’re development team’s accuracy is very good, you can start to redefine the very essence of what you’re doing.
Almost a quarter of a century ago, the Air Force felt it had reached the pinnacle of precision, the ability to hit a target on the first try. But precision has continued to improve, and today it’s possible to destroy targets with munitions that leave out the one thing that defines a bomb: the explosive. Dropping a 500-pound, bomb-shaped hunk of concrete with a guidance system attached can destroy a small target with a lot less collateral damage than a conventional bomb.
“I can’t use a 500-pound, high explosive bomb against a missile launcher if it’s parked within X-thousand feet of any civilian facility. But if I’ve got good enough precision, I can hit it with 500 pounds of concrete…. That does the trick.”
– Major General David Deptula
1Reaching Globally, Reaching Powerfully: The United States Air Force in the Gulf War, p. 55.
Very nice explanation with wake-up-the-country-club analogies.