Nature Of Software Development

by Ron Jeffries on Agile Software Development ISBN:1941222374

Excerpts:

Preface

Part 1 - The Circle of Value

Chapter 1 - The Search for Value -

Chapter 2 - Value Is What We Want -

I think of value as simply what we want.

A Project delivers value only when we ship the software and put it to use

But there are times when we might just ship the first bit and then stop

We need to guide our teams to build pieces that make sense to us, and to our users. These are often called minimal marketable features (MMFs).

Suppose the height of the features is their value, and the width is their cost. Which ones should we build first, and which ones should we defer until later? Pretty clear, isn’t it?

Some of those later features look pretty boring. What would happen if we did different, more valuable features, even for some other product?

We might even switch our investment to a new product!

Who might feel negatively impacted by a product shift? How might we make that shift a good thing for everyone? Can we focus on a portfolio rather than separate products with diminishing returns?

Chapter 3 - Guiding Goes Better "Feature by Feature"

With a monolithic project, late in the game we can’t do much to cut costs

We laid out this project with an all-or-nothing mentality

Our old red conventional project drones on and on, delivering too little information, too late. But the green project shows us real, valuable features at frequent intervals. We can see what is happening. We can see the software!

Can you see how a flow of visible features would be easier to manage? Can you see how you could maximize project value as you go?

We can even change features, adding new ones in response to better ideas or changing user needs.

When our projects grow feature by feature, we can respond to what’s really happening. We can respond to the changing needs and inputs of the business and of management

Chapter 4 - Organizing by Feature

organize into small teams, each of which builds features that the Product Champions can understand. Make sure that each team has all the people and all the skills necessary to build the entire feature, not just part of it.

Maybe you don’t have enough database experts or user experience (UX) experts

I’ll bet you have people who understand databases rather well even though you wouldn’t call them “experts.”

you might find yourself creating a team whose database person, or UX person, really isn’t quite good enough.

Now create a Database Community of Practice, or UX Community of Practice

Chapter 5 - Planning Feature by Feature

We do need to plan. We don’t need a detailed list of what will happen and when. When the time comes, let’s decide then what to do next. A too-detailed plan will just waste time and create confusion

It’s important to identify key features that we’ll need to have early, as well as features we can’t live without. Let’s identify and record those

Sometimes our organization just doesn’t work that way. They insist on knowing whether this proposed project will take weeks, months, or years, long before they’ll decide to invest in it.

We need a way to get an initial cut at project size.

I’d prefer to work from a budget, a deadline, a Product Champion who decides what to do next, and a team who can ship software at will

Things go best if each feature, often called a story, takes only two or three days to do.

I don’t recommend working with larger stories and breaking them down into technical items, often called tasks

We plan each Iteration right before it begins. To decide how much work to take on, we need to understand the work. As a team, we discuss the work. The team’s Product Champion presents one feature at a time, followed by a brief team discussion about what it’ll take to accomplish the feature. Everyone stays engaged, and the team understands the feature before committing to do it.

I don’t recommend estimating the individual work pieces at all. Instead, understand them, and then look at the aggregate and decide how much of it the team can do.

During planning, especially short-term planning, it’s tempting to set up “stretch goals” or to “encourage” the team to do “just one more feature.” Please do not do this. It’s devastatingly destructive. The reason is that the team will in fact try. Eager to please, they’ll unconsciously hurry. They’ll leave out just a few tests. They’ll leave the code not quite as clean as they might have

estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value. Consider de-emphasizing or eliminating cost estimates and steering to success by a focus on value.

Chapter 6 - Building the Product, Feature by Feature

If we want small features frequently, what, in general, will all of us need to do? What specific pitfalls do you see?

This means that our business-side people need to build up skill in breaking down large, vague, sweeping requirements into small, practical next steps that deliver maximum value for minimum effort.

The feature-by-feature style includes a complete development cycle in every iteration: requirements, design, coding, and testing.

For feature-by-feature development to work, the software needs to be nearly free of defects at the end of every two-week iteration. It needs to be nearly free of defects all the time.

We also need to grow the design as we go

Chapter 7 - Build Features and Foundation in Parallel

We’re not sure how fast we can go: we never are. If we build foundation first, we will surely build too much of it

Just as it would be wrong to build every possible feature, it is wrong to start by building each feature out to its fullest glory

We can do the best possible job of this if we do small versions of each necessary feature, with just enough foundation to be solid

building just enough infrastructure as we go

Chapter 8 - Bug-Free and Well Designed

We test at two levels, with “Business” tests and “Programmer” tests

acceptance test-driven development

developer tests need to be checked much more frequently

We could rely on our business-level tests to catch these problems, but they usually take a long time to run, and they don’t point to the specific programming error when they do fail

Keeping the design good as it changes is called refactoring

Business needs to know that the program works. Acceptance test-driven development is one good way to keep current on what’s working. Developers need to know precisely what’s broken when something breaks. Test-driven development is a key tool in accomplishing that

Chapter 9 - Full Circle

Part 2 - Notes and Essays

Chapter 10 - Value—What Is It?

The problem of the “Product Owner,” of management, of all the people who decide what we should do next, is to look deeply at the many things we value, and to choose a sequence of development that gives us the best possible result in return for our time, money, and effort in building our product.

Chapter 11 - Value—How Can We Measure It?

We don’t really know the numbers.

Take any two things you might do. Ask yourself which one to do next—which one is more valuable right now

Then ask yourself why you prefer what you prefer. Write down a few notes

Ask your stakeholders. Whether they agree with you or not, ask why.

Chapter 12 - Of Course It’s Hard!

Every aspect of this work is complex, but we do not need a complex process to do the work. A complex process holds us back, imposing rote activity when we need to observe what’s going on, adjust it, and improve it.

Chapter 13 - Not That Simple

Chapter 14 - Creating Teams That Thrive

In his book Drive [Pin09], Dan Pink speaks of Autonomy, Mastery, and Purpose as drivers of both employee satisfaction and improved productivity. (Motivation)

A dedicated business-side person is needed to guide your development team by identifying what’s to be done and what’s to be deferred. This designated person is sometimes called the Product Owner, or the Customer. In this book I use the term Product Champion, because the best results come when the whole team feels ownership in the product, with one business-side person providing vision and “championing” the product.

In some teams, the Product Champion brings in defined solutions rather than concerns or problems. This can work but it’s far from ideal. Your team will be slower to gain a sense of purpose if they are spoon-fed solutions rather than being allowed to creatively solve problems

A self-organizing team with a common understanding of its purpose: this is the sweet spot

Chapter 15 - The “Five-Card Method”for Initial Forecasting

Repeat the breakdown until each feature seems to be about the same size. What’s a good size? Something the team members think they can build in about a week

Chapter 16 - Managing Natural Software Development

Let’s consider Peter Drucker’s components of management: planning, organizing, staffing, directing, and controlling. We’ll look at each of these, and what these ideas mean for managers, in the context of the Natural Way.

our job isn’t to stick to the plan—it’s to steer our course for the best result, not some fixed target.

Chapter 17 - Whip the Ponies Harder

Under pressure, teams give up the wrong things. They don’t test enough; they leave the code in poor condition. This reduces value, increases the delay to getting the value, and reduces the value they can deliver later.

Frankly, when I look into an organization that “needs more features,” what I almost invariably find is an organization that can’t say no. They have become order takers rather than decision makers.

If you must try to go faster, analyze sources of delay. These usually have more impact than individual productivity.

What are the real causes of delay on your project? Is decision making slowing you down? Defect correction? Handing things off between individuals or teams? What’s your delay? Work on that.

Can we at least use our velocity to predict when we’ll be done?

In a word, no!

Chapter 18 - To Speed Up, Build with Skill

gets the conversation aimed at why it’s difficult to produce an Increment. And once we’re dealing with why, it’s easy to figure out things to do. The answers usually come down to build times, integration times, and test times.

When the team ships software to QA, we must already be certain that it will not be coming back with defects in it.

We do that by testing it ourselves. The technical practices of acceptance test-driven development (ATDD) and test-driven development (TDD) enable us to do this quite nicely.

Chapter 19 - Refactoring

The time needed to build a feature comes from two main components: its inherent difficulty, and the accidental difficulty of putting it into whatever code already exists. Teams are good at estimating the inherent difficulty. What makes us erratic, what makes us slow down, is the accidental difficulty. We call this difficulty “bad code.”

What seems to work best is to follow the Campground Rule: Leave the campground a little better than you found it. Every time we do a feature, we start by cleaning up the area where we are going to do the work. We don’t have to make it perfect, just sufficiently better to help our feature ease in. And once our feature works, we clean up the code as we always should—plus a bit more.

Chapter 20 - Agile Methods

I am, by good fortune, one of the authors of the Agile Manifesto.[1] The story I tell here is in accord with the Manifesto, to the best of my ability.

To me, Scrum plus technical practices amounts to XP.

Alistair Cockburn’s Crystal Clear is an Agile framework that is even simpler than Scrum

Chapter 21 - Scaling Agile

in most cases, they’re wrong. They don’t need to scale. They need to do plain old simple Agile software development.

Agile is quite simple. The most popular Agile approach, Scrum, has just three roles, a handful of activities, and one major artifact: running tested software.

That doesn’t mean Agile is easy.

To get more features, you add more feature teams, all delivering software into a single product.

Aren’t we skipping something? How do those teams coordinate? Now we’ve got multiple teams doing features. How can they avoid stepping on each other’s toes?

Agile teams coordinate using tests.

Will you need a specialized infrastructure team? Quite often, if you’re fluent in Agile, you won’t.

Even in giant efforts, it turns out that almost everything being done is being done by single teams

Chapter 22 - Conclusion