Author : Robert C. Martin

For the first three years of my career, I did not know what agile was. I first came to know about the “Agile” word when I was copy-pasting my resume headline from someone else’s resume.

I didn’t know, what it meant. I just copy-paste it. Sadly, that’s the current state of the majority of software companies.

While the agile manifesto was signed in 2001, as time passed by, it started to lose its real meaning. Some companies were creating waterfall again in the name of Agile. And that’s where Uncle Bob’s frustration kicks in, and he wrote this book.

I learned about Agile when I started reading books like Clean code, working effectively with legacy code, and refactoring. I also started learning practices like TDD, Pair Programming, CI/CD, and XP.

Since then I have always been interested in learning more about Agile, and who can better tell this story than Uncle Bob itself, who was part of that manifesto.

Why Agile?

Our software industry is roughly 50 years old which is new compared to other industries like architecture (1500 years old) and medical (500 years ago).

Initially, we did not know how to plan software development, so we started to take inspiration from one of the oldest industries, i.e. architecture planning, which follows a waterfall model.

The waterfall model in architecture requires planning everything upfront and then building the stuff later. We did the same for software development.

But the big difference between them was “The requirement of change”.

Software requirements change too quickly compared to architecture. Where in architecture, once it’s built, then it’s not going to change much. That’s the reason we called it “Soft”ware, not “Hard”ware.

After building software for decades, a group of people came together on February 11-13, 2001, at The Lodge at Snowbird to uncover better ways of developing software and created the following values called Agile Manifesto.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, Agile value the items on the left more.

What is Agile?

It’s a simple idea, but it’s been misinterpreted in many different ways. In the book, the author has shared many short stories on how it was misinterpreted. For example, forcing estimation to meet hard and unrealistic deadlines or managers committing things to business without involving development teams.

Agile is a small idea about the small problem of small programming teams doing small things. Big things don’t get done by big teams; big things get done by the collaboration of many small teams doing many small things.

Agile is about producing just the kinds of data that managers need in order to make good decisions. It’s more about getting feedback on software by having small iterations followed by technical practices like TDD, Pair programming, CI/CD, Refactoring, and Simple Design by teams.

Agile Practices

Every iteration in the project, from the beginning to the end, will have some analysis and design, and implementation in it. In an Agile project, we are always analyzing and designing.

The second half of the book covers best practices for agile development and a majority on what not to do in agile.

Planning

1. How do you plan a sprint?

Agile suggests keeping the feedback loop small by having 1-2 week sprints based on project and team size. Because having lengthy sprints might skew the data and pivoting becomes difficult as time grows.

2. How do you create stories?

User stories are not technical stories. The story should NOT be like I want to make a change in getUser function in UserSession class. The stories should be based on how the user flows and how the user sees it and the Accpetenace test according to it.

For example, when I click on the login button I should see my name in the profile.

Also, make sure these stories are easily visible to the team and business so that they can see the progress.

3. How do you estimate?

There are multiple ways to estimate user stories, but the one way, which definitely is NOT, is by giving an exact number in terms of hours or days.

For example, the T-shirt size technique is one good example of how to estimate stories. This technique aligns very well with agile because it is based on feedback from previous sprints.

Technical Practices

The agile feedback mechanism works well when we follow agile technical practices. Without that, agile is half-baked.

1. Test-Driven Development (TDD)

TDD has a fast feedback loop by following the red-green-refactor rule. In my experience, TDD shines on writing business logic or building an API for a client. However, sometimes it is hard to perform TDD when framework or UI-related code is involved. For example, Bluetooth, live location tracking, and so on.

2. Continues Integration and Delivery (CI/CD)

CI/CD is a way to keep a constant check on the system by running tests to make sure the system is always green and is easily deployable in just one click.

3. Refactoring and Simple Design

Developers should know how to refactor code in a small incremental fashion using the test as a safety net. It will allow the team to make the design simpler whenever they get the opportunity.

This is a team endeavor, so we need to make sure the design should be simple enough to understand not just by you, but by the whole team. Keeping this as practice improves code readability.

Conclusion

Everyone involved in the software development cycle, be it a manager, designer, developer, or QA, should read this book and truly understand what Agile is and how it is supposed to work. What to follow and What NOT to follow.

Because I’ve seen companies use “Agile” as a marketing tool, but once you join, you realize it’s a completely different story. Unrealistic deadline, no feedback loop, no technical practices, and so on. So in order to understand real Agile from the “reel” agile, I recommend everyone to read this book.

You can get it from amazon.

Highlighted Quotes

1. Good, fast, cheap, done: Pick any three you like. You can’t have the fourth.
2. This is the world of the software development team. It’s a world in which dates are frozen and requirements are continuously changing. And somehow in that context, the development team must drive the project to a good outcome.
3. 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.
4. We practice Agile in order to destroy hope before that hope can kill the project.
5. Producing crap does not make you go faster, it makes you go slower. This is the lesson you learn after you’ve been a programmer for 20 or 30 years.
6. You need to realize that you were hired more for your ability to say “no” than for your ability to code.
7. You must find ways to continue learning without the company’s help.
8. 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.
9. However, even as you specialize, you must also generalize. Divide your work between your specialty and other areas of the code. Maintain your ability to work outside of your specialty.
10. The word Refactoring should never appear on a schedule. Refactoring is not the kind of activity that appears on a plan. We do not reserve time for refactoring. Refactoring is simply part of our minute-by-minute, hour-by hour approach to writing software.
11. The belief that quality and discipline increase speed is a courageous belief because it will constantly be challenged by powerful but naive folks who are in a hurry.
12. Companies are still not mature enough to understand that technical problems are in fact business problems.
13. The main goal of Agile is to provide business agility and customer satisfaction, and that is achieved via close collaboration, iterative development, short feedback loops, and technical excellence.
14. The goal is to teach a child to ride a bicycle, not to adopt the training wheels.