Learning Agile summary

Introduction

Learning Agile by Andrew Stellman and Jennifer Greene Agile principles deliver valuable software through iterative development and continuous customer feedback. How do you deliver value when customers cannot clearly explain what they truly need? Imagine Henry Ford asking people what they actually wanted because they would have said faster horses. Ford gave them cars instead, but imagine if he had not done that.

Years would have been wasted trying to satisfy that demand. Chances are that by the time his product hit the market, someone else would have already started. They would be selling cheap, reliable cars, and his product would have been dead on arrival. This happens through iterative development and continuous customer feedback.

We will be talking about software development instead of cars, but we will look at the same problem. One answer is a bundle of practices and principles known as Agile. If you have heard that word before, you have probably also come across some related concepts. These include Scrum, Kanban, XP, and Lean.

Often, there is a temptation to rush into discussing these methodologies right alongside Agile. For Andrew Stellman and Jennifer Greene, the authors of Learning Agile, that risks putting the cart before the horse. Detailed methods mean little until we understand why Agile deserves serious consideration. So that is what we will be doing in this summary.

We will be looking at the why of Agile by following a project from start to finish. Along the way, we will see how Agile principles can help a team of software developers. They can work more efficiently and effectively while also delivering a better product.

Why Waterfall Processes Fail

Why Waterfall Processes Fail. Tradeo Chapter 1 Why Waterfall Processes Fail How can a product be finished on time, fully tested, and still fail the moment customers see it? Imagine a company building one of the first electronic book readers. The hardware team has a prototype, a chunky black device with a small keyboard, and a USB port for loading books.

The software team is given 18 months to turn it into a revolutionary product. At the beginning, every stakeholder meets to decide what the device should do. The specification is ambitious. It includes a storefront, publishing tools, market statistics, and every feature the group can imagine needing.

Then the plan flows downward through design, development, and testing. No one is expected to question the requirements once they have been approved. Eighteen months later, the team delivers exactly what it promised. Every feature works, and management is pleased.

Then the reader reaches the market and fails. During those 18 months, an industry standard for electronic book formats has emerged. Retailers do not want to support the company's unique format, so the carefully built features have little value in the real world. The project did not fail because the team ignored the plan.

It failed because the team followed the plan after the world that created it had changed. This is the weakness of a waterfall process in uncertain work. It assumes that requirements can be understood early, then protected from change while the product is built. That approach can work when the problem is stable and familiar.

But when customer needs, technology, or standards are still moving, a long plan becomes a long bet. The alternative is not to abandon planning. It is to replace one large, irreversible plan with shorter cycles of planning, building, learning, and adjusting. The next chapter shows how that cycle keeps a team connected to the reality outside its meeting room.