Clean Agile: back to basics notes:


- Opinionated grumblings 
- Lost knowledge of small teams doing small thing and combining them into big things. Not big teams, big things
- Reboot in 2000 as a result of the lost knowledge and vision
- 2020, why do we need reboot now? Message from 2000s and 1950s?
- 1880 scientific management by Frederick Winslow Taylor

"Pre-Agile worked well for projects that enjoyed a low cost of change and solved partially defined problems with informally specified goals. Scientific Management worked best for projects that suffered a high cost of change and solved very well-defined problems with extremely specific goals."

"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."

"Even though it was not what Royce was recommending, it was the concept people took away from his paper. And it dominated the next three decades"

"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."

"But why is this data so important? Is it possible to effectively manage a project without that data? For 30 years we tried. And this is how it went..."

"Sometime in March, we deliver some limping thing that sort of half does what the customers want. Everybody is upset. Everybody is demotivated. And we promise ourselves that we will never do another project like this. Next time we'll do it right! Next time we'll do more analysis and more design. I call this Runaway Process Inflation. We're going to do the thing that didn't work, and do a lot more of it."

"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."

"So now we return to the Iron Cross of project management: good, fast, cheap, done. Given the data produced by the project, it's time for the managers of that project to determine just how good, how fast, how cheap, and how done the project should be."


"You might think that those fingers would point at our bosses, or the executives in our companies, but we saw what happened when those fingers pointed to the CEO of Volkswagen, North America, as he testified before Congress."

"In desperation, the managers ask the developers what can be done to increase productivity. And the developers have an answer. They have known for some time what needs to be done. They were just waiting to be asked. "Redesign the system from scratch." The developers say."

"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). It is a powerful method for managing large projects and portfolios of projects. And if you haven't studied this technique, don't assume that you know it already. There's a lot more to PERT than those Microsoft Project diagrams with which you may be familiar."


"The wording is simple, and the details are omitted because it is too early to count on those details. We want to delay the specification of those details as long as possible, right up to the point where the story is developed. So we leave the story in abbreviated form as a promise for a future conversation."

"It is rare to find a story that cannot be split. This is especially true of those that are big enough to need splitting. Remember, it is the job of a programmer to split stories all the way down into individual lines of code. So splitting is almost always possible. The challenge is maintaining INVEST."

"If QA has not already begun to write the automated acceptance tests, they should start as soon as the IPM ends. The tests for stories that are scheduled for early completion should be done early."

—  I think there is a problem with this approach. For example: how do you write UI test when there is not html elements to hook into?  There is no known ".className" or "#id" to hood into to click and assert. 

— in addition uncle Bob does not discuss Acceptance Tests maintenance effort!

"The tests are written by business analysts and QA before the first half of the iteration in which the stories they test are to be developed. The developers integrate those tests into the continuous build. Those tests become the Definition of Done for the stories in the iteration. A story is not specified until its acceptance test is written. A story is not complete until its acceptance test passes."

"There's a saying among older programmers: "I can meet any deadline you set for me, as long as the software doesn't have to work properly." So who else benefits from defects? Developers who need to meet schedule deadlines."

"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."

"It turns out that the business practices of Agile are a highly efficient way to make a very large mess. Furthermore, if you don't take care of the cleanliness of the structure you are building, then the mess will slow you way down."

"The transition from non-Agile to Agile is a transition in values. The values of Agile development include risk-taking, rapid-feedback, intense, high-bandwidth communication between people that ignores barriers and command structures. They also focus on moving in straight and direct lines rather than mapping out and negotiating the landscape. These values are diametrically opposed to the values of large organizations who have invested heavily in middle-management structures that value safety, consistency, command-and-control, and plan execution.

Is it possible to transform such an organization to Agile? Frankly, this is not something I have had a lot of success with, nor have I seen much "success from others. I have seen plenty of effort and money expended, but I have not seen many organizations that truly make the transition. The value structures are just too different for the middle-management layer to accept. "What I have seen is the transition of teams and individuals, because teams and individuals are often directed by values that are aligned with Agile.

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."

"Can large organizations be created that allow Agile teams to prosper within them? Certainly! However, note that the word is created not transformed.

When IBM decided to build the PC, the company's executives realized that the values of the organization would not allow the kind of quick innovation and risk-taking that would be required. So, they created an organization with a different value structure."

"The bottom line here is that Agile is about software. In particular, it is about small software teams. I am "always frustrated when people ask me how to apply Agile to hardware, construction, or some other task. My answer has always been that I don't know, because Agile is about software.

What about Agile in the large? I don't think there is such a thing. Organizing large teams is a matter of organizing them into small teams. Agile solves the problem for small software teams; the problem of organizing small teams into larger teams is a solved problem. Therefore, my answer to the question of Agile in the large is simply to organize your developers into small Agile teams, then use standard management and operations research techniques to manage those teams. You don't need any other special rules.

"Now the question could be asked is that, since software for small teams was so unique that it required us to invent Agile, why doesn't that uniqueness hold for organizing small software teams into larger software teams? Isn't there some unique aspect to software that carries beyond the small team and affects the way larger teams ought to be organized?

I doubt it, because the problem of large teams, which we solved more than 5000 years ago, is the problem of getting many diverse kinds teams to cooperate. Agile teams are just one of myriad kinds of teams that need to be coordinated in a large project. The integration of diverse teams is a solved problem. I see no indication that the uniqueness of software teams unduly affects their integration into larger teams.

So again, the bottom line from my point of view is this: There is no such thing as Agile in the large. Agile was a necessary innovation for organizing small software teams. But once organized, those teams fit into the structure that large organizations have used for millennia.

Now, again, this is not a subject that I have diligently researched. What you just read is my opinion, and I could be very wrong. Perhaps I'm the old curmudgeon telling all those Agile-in-the-large kids to get off my lawn. Time will tell. But now you know which way I'm betting."

"Instead of pushing TDD, maybe we could start agreeing on the value of reducing the time it takes to test our entire system. How long does it take today? Two hours? Two days? Two weeks? How many people are involved? What if we could reduce it to 20 minutes? Two minutes? Maybe even 2 seconds? And what if we could do that at any time just by pressing a button? Would that give us a good return on investment? Would that make our lives easier? Would we be able to release reliable software faster?"

"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 delivered and when, not how. Every time developers volunteer details of how they work, they are inviting managers to micromanage them."