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

by Robert C. Martin

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.

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.

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.

the requirements are wildly in flux and can never be frozen. This is because the customers don’t really know what they want. They sort of know what problem they want to solve, but translating that into the requirements of a system is never trivial. So the requirements are constantly being re-evaluated and re-thought. New features are added. Old features are removed. The UI changes form on a weekly if not daily basis.

Pretty much zero, of course. That’s because software is not a reliably estimable process. We programmers simply do not know how long things will take. This isn’t because we are incompetent or lazy; it’s because there is simply no way to know how complicated a task is going to be until that task is engaged and finished.

Hope Versus Management

Awesome Chapter

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. The reason we want to know this as early as possible is so that we can manage the situation. You see, this is what managers do. Managers manage software projects by gathering data and then making the best decisions they can based on that data. Agile produces data. Agile produces lots of data. Managers use that data to drive the project to the best possible outcome.

Brooks’ law22 states: Adding manpower to a late project makes it later.

What do every single one of those nearby computers have in common? They all need to be programmed. They all need software—software written by us. And what, do you think, is the quality of that software?

Nothing gets done in our society without software. Every waking moment is dominated by software.

Our society has become utterly and wholly dependent on software. Software is the life’s blood that makes our society run. Without it, the civilization we currently enjoy would be impossible.

Our software is now killing people. You and I probably didn’t get into this business to kill people.

Management might try this a few more times because repeating the same thing and expecting different results is the definition of management sanity in some organizations.

Developers often complain about changing requirements. I have often heard statements like, “That change completely thwarts our architecture.” I’ve got some news for you, sunshine. If a change to the requirements breaks your architecture, then your architecture sucks.

To the extent that a team’s software is hard to change, that team has thwarted the very reason for that software’s existence.

QA should find no faults with the system. When QA runs their tests, they should come back saying that everything works as required. Any time QA finds a problem, the development team should find out what went wrong in their process and fix it so that next time QA will find nothing.

While it is important to strive to find solutions to problems, I expect you to say “no” when no such solution can be found. You need to realize that you were hired more for your ability to say “no” than for your ability to code. You, programmers, are the ones who know whether something is possible. As your CTO, I am counting on you to inform us when we are headed off a cliff. I expect that, no matter how much schedule pressure you feel, no matter how many managers are demanding results, you will say “no” when the answer really is “no.”

A programmer is someone who is skilled at breaking down a task into individual lines of code.

Estimates should be as accurate as possible, but only as precise as necessary to keep the cost of estimation low. An example may help. I estimate the moment of my death to be sometime within the next thousand years. This is completely accurate, but very imprecise.

The iteration begins with the Iteration Planning Meeting (IPM). This meeting should be scheduled to be one-twentieth the duration of the iteration. The IPM for a two-week iteration should require about a half a day.

The stories that are valuable but cheap will be done right away. Those that are valuable but expensive will be done later. Those that are neither valuable nor expensive might get done one day. Those that are not valuable but are expensive will never be done.

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.

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.

The definition of “done” is this: acceptance tests pass.

Many programmers have therefore attempted to do Agile without these practices. They fail, however, because these practices are the very core of Agile. Without TDD, Refactoring, Simple Design, and yes, even Pair Programming, Agile becomes an ineffective flaccid shell of what it was intended to be.

Finally, never, ever, ever, ask for permission to pair. Or test. Or refactor. Or… You are the expert. You decide.

The members of an Agile team are not so focused upon political safety that they sacrifice quality and opportunity.

The strongest advice I can give you, however, is to adopt the full Circle of Life, including, and most especially, the technical practices. Far too many teams have adopted the outer business ring and have found themselves in the trap that Martin Fowler has labeled “Flaccid Scrum.”1 The symptoms of this disease are a slow decline from high productivity in the early days of a project to very low productivity as the project wears on.

It turns out that the business practices of Agile are a highly efficient way to make a very large mess.

Ironically, executives are also often driven by the risk-taking, direct, communicative values of Agile. This is one of the reasons they try to transition their organizations. The barrier is the management layer in the middle. These folks were hired to not take risks, to avoid directness, to follow and enforce the chain of command with a minimum of communication. This is the organizational dilemma. The tops and bottoms of the organization value the Agile mindset, but the middle layer opposes it. I don’t know that I have ever seen that middle layer make the change. Indeed, how could they? Their job is to oppose such a change.

Once you own a tool, the path of least resistance is to do whatever the tool provides regardless of whether it meets the team’s needs.

Retrospectives, especially variants like “Team with the Best Results Ever” or “Six Hats” are a way to ask powerful questions that enable a team to discover opportunities for change on their own and decide independently how to go about pursuing those opportunities.

Check these out

If you have taken formal training on Agile or an Agile methodology, you likely played a number of games that illustrated Agile concepts. Games such as the penny game, Scrum simulations, Kanban Pizza, or LEGO city building.

Check thes out

There is a growing body of coaching tools. Many of them can be found at tastycupcakes.org, retromat.org, and liberatingstructures.com.

Check these out

Simple Design, especially when used with practices such as a microservices architecture, enables Agility in the large.

Agile transformations that purely focus on process are partial transformations.

The assumption that fixing the collaboration among people would improve engineering could not be more wrong.

Companies are still not mature enough to understand that technical problems are in fact business problems.

We will look at our work not as something we need to do as part of a job but as a professional service we provide. We will take ownership of our own careers, investing our own time and money to get better at what we do. These values are not only professional values—they are personal values. Craftspeople strive to do the best job they can, not because someone is paying, but based on a desire to do things well.

“Principles without practices are empty shells, whereas practices without principles tend to be implemented by rote, without judgement. Principles guide practices. Practices instantiate principles. They go hand in hand.”

Focus on the Value, Not the Practice

There is a difference between re-architecting a whole monolith system into microservices and doing TDD. The former has a very significant impact on the cost and duration of the project; the latter doesn’t, as long as developers are comfortable with the technique. Whether or not developers automate their tests should not be relevant to the business. It should be even less relevant whether the automated tests are written before or after the production code. What business should care about is that the lead time from business ideas to software in production is gradually reduced.

Business and developers should have conversations about business value, not technical practices.

Developers should not ask authorization for writing tests. They should not have separate tasks for unit tests or refactoring. They should not have separate tasks for making a feature production ready. These technical activities should be factored into the development of any feature. They are not optional.

Managers and developers should only discuss what is going to be delive...

Developers should be able to clearly describe how they work and the advantages of working that way to whomever is interested. What developers should not do is to let other people decide how they work.

Developers understand Agile to be a methodology for streamlining the development process and for making software development more predictable, more practicable, and more manageable.