Clean Agile: Back to Basics (Robert C. Martin Series)

by Robert C. Martin

The Manifesto did start a rebellion of sorts. It was meant to inspire the development of lean, clean code by using a collaborative, adaptive, feedback-driven approach. It offered an alternative to “heavyweight” processes like Waterfall and the USDP.

Agile is a small idea about the small problem of small programming teams doing small things.

Aren’t we supposed to be doing big things with big teams? Heavens, no! Big things don’t get done by big teams; big things get done by the collaboration of many small teams doing many small things.

Movements in software follow a predictable path. At first there is a minority of enthusiastic supporters, another minority of enthusiastic detractors, and a vast majority of those who don’t care.

Unfortunately, once a movement becomes popular, the name of that movement gets blurred through misunderstanding and usurpation.

When did Agile begin? Probably more than 50,000 years ago when humans first decided to collaborate on a common goal. The idea of choosing small intermediate goals and measuring the progress after each is just too intuitive, and too human, to be considered any kind of a revolution.

For example, the programmers who wrote the control software for the Mercury space capsule worked in half-day steps that were punctuated by unit tests.

Waterfall was the logical descendant of Scientific Management. It was all about doing a thorough analysis, making a detailed plan, and then executing that plan to completion.

We did the standard sort of thing where we write issues down on cards and then sorted the cards on the floor into affinity groupings. I don’t really know if that led anywhere. I just remember doing it.

The word “Agile” was mentioned, and one person commented that it was currently a hot buzzword in the military. In the end, though nobody really loved the word “Agile,” it was just the best of a bunch of bad alternatives.

How do you manage a software project? There have been many approaches over the years—most of them pretty bad. Hope and prayer are popular among those managers who believe that there are gods who govern the fate of software projects. Those who don’t have such faith often fall back on motivational techniques such as enforcing dates with whips, chains, boiling oil, and pictures of people climbing rocks and seagulls flying over the ocean.

This physics constrains all projects to obey an unassailable trade-off called the Iron Cross of project management. Good, fast, cheap, done: Pick any three you like. You can’t have the fourth.

The reality is that a good project manager understands that these four attributes have coefficients. A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary. A good manager manages the coefficients on these attributes rather than demanding that all those coefficients are 100%. It is this kind of management that Agile strives to enable.

It is a critical goal of Agile to get those two charts on the wall. One of the driving motivations for Agile software development is to provide the data that managers need to decide how to set the coefficients on the Iron Cross and drive the project to the best possible outcome.

Agile development is first and foremost a feedback-driven approach. Each week, each day, each hour, and even each minute is driven by looking at the results of the previous week, day, hour, and minute, and then making the appropriate adjustments.

What is the first thing you know about a project? Before you know the name of the project or any of the requirements, there is one piece of data that precedes all others. The Date, of course. And once The Date is chosen, The Date is frozen.

This is the world of the software development team. It’s a world in which dates are frozen and requirements are continuously changing.

If only we could just say we were done with implementation. But we can’t, because the thing about implementation is that is actually has to be done.

The thing about the Waterfall idea is that it just makes so much sense. First, we analyze the problem, then we design the solution, and then we implement the design. Simple. Direct. Obvious. And wrong.

This loss of hope is a major goal of Agile. We practice Agile in order to destroy hope before that hope can kill the project.

Some folks think that Agile is about going fast. It’s not. It’s never been about going fast. Agile is about knowing, as early as possible, just how screwed we are.

Agile is a process wherein a project is subdivided into iterations. The output of each iteration is measured and used to continuously evaluate the schedule. Features are implemented in the order of business value so that the most valuable things are implemented first. Quality is kept as high as possible. The schedule is primarily managed by manipulating scope.

What drew me to Agile in the first place was the high commitment to discipline over ceremony.

Software is a compound word. The word “ware” means “product.” The word “soft” means easy to change. Therefore, software is a product that is easy to change. Software was invented because we wanted a way to quickly and easily change the behavior of our machines. Had we wanted that behavior to be hard to change, we would have called it hardware.

If a change to the requirements breaks your architecture, then your architecture sucks.

Developers have the right to make and update their own estimates.

There is a whole mathematical method surrounding the management of trivariate estimates. If you are interested, I encourage you to research the program evaluation and review technique (PERT).

Typically, we write the story on an index card. I know, I know. Why in the world would we use such ancient and primitive tools when we have computers and iPads and…? It turns out that being able to hold those cards in your hands, pass them across a table to each other, scribble on them, and otherwise handle them is immensely valuable.

Please remember: World War II was managed3 on index cards, so I think the technique scales.

This rejection of detail is a discipline. And it’s hard.

These numbers are vague, fuzzy, imprecise things that do not relate directly to real time.

But there is a beautiful thing about vague and fuzzy numbers. It’s called the Law of Large Numbers.4 When taken in quantity, the fuzziness integrates out! We’re going to take advantage of that later.

No! Iterations do not fail. The purpose of an iteration is to generate data for managers. It would be nice if the iteration also generated working code, but even when it doesn’t it has still generated data.

The project is not over when all the stories are implemented. The project is over when there are no more stories in the deck worth implementing.

User stories are simple statements that we use as reminders of features. We try not to record too much detail when we write the story because we know that those details will likely change.

Stories follow a simple set of guidelines that we remember with the acronym INVEST.

Refactoring is never a story. Architecture is never a story. Code cleanup is never a story. A story is always something that the business values. Don’t worry, we will deal with refactoring, architecture, and cleanup—but not with stories.

We don’t want a single story to dominate the whole team for an entire iteration. An iteration should contain about the same number of stories as there are developers on the team. If the team has 8 developers, then each iteration should contain about 6 to 12 stories. You don’t want to get too hung up on this point, however; it’s more a guideline than a rule.

Planning Poker6 is a similar technique, but it involves cards. There are many popular Planning Poker card decks out there. Most use some kind of Fibonacci series. One popular deck contains the cards: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞. If you use such a deck, my advice to you would be to remove most of those cards.

You may also wish to include 0, ∞, and ?. In Flying Fingers, you can use thumbs down, thumbs up, and an open hand for these symbols. Zero means, “Too trivial to estimate.” Be careful with those! You may wish to merge a few of them into a bigger story. Infinity (∞) represents too big to estimate, and therefore the story should be split. And (?) means you simply don’t know, meaning that you’ll need a spike.

The goal of each iteration is to produce data by getting stories done. The team should focus on stories rather than tasks within stories. It is far better to get 80% of the stories done than it is to get each story 80% done. Focus on driving the stories to completion.

The points are a currency, and the team is devaluing them under external pressure. Come back to that team next year, and they’ll be getting millions of points done per iteration. The lesson here is that velocity is a measurement not an objective. It’s control theory 101: don’t put pressure on the thing you are measuring.

Remember, the only failing iteration is an iteration that fails to produce data.

The practice of Acceptance Tests is one of the least understood, least used, and most confused of all the Agile practices. This is strange because the underlying idea is remarkably simple: Requirements should be specified by the business.

What the team needs is a model of the problem domain, which is described by a vocabulary that everyone agrees on.

That was the moment that I learned that a software project is a marathon, not a sprint, nor a sequence of sprints. In order to win, you must pace yourself. If you leap out of the blocks and run at full speed, you’ll run out of energy long before you cross the finish line.

Managers may ask you to run faster than you should. You must not comply. It is your job to husband your resources to ensure that you endure to the end.

Working overtime is not a way to show your dedication to your employer. What it shows is that you are a bad planner, that you agree to deadlines to which you shouldn’t agree, that you make promises you shouldn’t make, that you are a manipulable laborer and not a professional.

The most precious ingredient in the life of a programmer is sufficient sleep.

The point is that Continuous Integration only works if you integrate continuously.