- What Are We Changing with Agile?
- The Heartbeat of Agile: Working Code in a Short Time Box
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Heartbeat of Agile: Working Code in a Short Time Box
So much for the differences in plan-based and agile development methods! It's time now to move toward what is common among the methods themselves so we can start to distill common practices to apply at scale.
As we do so, we discover that all agile methods have one thing big thing in common, and that may well be the quintessential difference between agile methods and the waterfall. That is, all development proceeds by creating small chunks of working code in a time box (fixed date.) This new skill is the heartbeat of agile, and when teams master this skill, many other things agile will fall naturally into place. Figure 7-3 illustrates this simple "process model within a process model."
)
Figure 7-3 The heartbeat of agile, working code in a time box
Figure 7-3 illustrates that stories are pulled from a backlog in order of the "next most important thing to do for the customer." Each item is defined/built/tested in a fast, concurrent loop. We use define/build/test as a verb to illustrate that this operation is atomic; one part can't be done without the other.
Within the time box, each item is evaluated for acceptance, and when it passes the test, another story is pulled from the backlog. If it fails, it is reworked, on the spot, until it passes the test. Of course, in order to accomplish this, all the resources necessary to define it, build it, and test it must be continuously present on the team (Chapter 9).
Even then, there are two key elements to this simple process statement, each of which represents a paradigm shift for the new agile team.
1 Working in a Time Box
In a well-disciplined agile process, everything is time-boxed.
The mechanism for handling flexibility of requirements in DSDM is the time box.
—DSDM [2006]
This time-boxing establishes a rhythm for the development organization that becomes the drum beat that synchronizes the activities of all participants. Like a manufacturing schedule, it is repetitive, predicable, and reliable, and all software production and delivery rotates around this cycle. The most important benefit is that time-boxing introduces a near-term milestone that forces both the team and code lines to converge and actually deliver working software at regular intervals.
—Leffingwell and Muirhead [2004]
Iterations Are Time-Boxed
Iterations are timeboxed, and they may be as short as one week or, more typically, two weeks, but rarely longer. (Learning to accomplish this art is the subject of Chapter 10.)
Releases Are Time-Boxed
Releases are time-boxed too. Release dates are known in advance, and scope, not quality or resources or schedule, is adjusted to assure the team meets the commitment of the date.
Meetings Are Time-Boxed
Meetings are also time-boxed. Release planning, iteration planning, iteration retrospectives, iteration demos, and daily stand-ups are all time-boxed, thereby instilling discipline in the team and constantly communicating that time matters. This discipline also helps every team member meet his or her commitments by knowing in advance how much time can be committed to any specific overhead activity.
When we started with agile, I was concerned it might be a less disciplined method for development. In reality, it's more disciplined and provides more accountability.
—Paul Beavers, Director, BMC R&D
2 Developing in Small, Bite-Sized Chunks
The feature (story) should be small enough that it can be done in a few days.
—Poppendieck and Poppendieck [2003]
I like to break stories into tasks that individuals take responsibility for and estimate. I think ownership of tasks goes a long way towards satisfying the human need for ownership.
—Beck [2005]
Agile, in general, and XP, in particular, takes incrementalism to the extreme. Work is divided into stories and tasks. Stories represent "pliable" requirements (or at least the need for a discussion about a requirement); tasks are added to define the specific work that each team member must do to implement the story. The granularity of stories typically represents no more than a few days' work. The granularity of tasks is on the order of less than a day. For those applying use cases, significant use cases may be implemented as granularly as one scenario at a time or by picking any other logical and cohesive piece (such as a single step) of the use case that can be done in an iteration. There are a variety of reasons for doing this, and each represents a key element of agile.
Small Chunks Can Be Estimated and Tracked
The size of the chunks of work that are scheduled into the iteration has a dramatic effect on the visibility of their status. If one large chunk of work is scheduled into an iteration, then by implication, the entire iteration will be devoted to working toward finishing that one chunk, and the chunk of work can't possibly be completed until the end. Gauging progress is a matter of guessing the "percentage complete" of the monolithic chunk. It is also difficult to get the testing group involved early in the iteration when all of the work is delivered in a very large chunk at the end.
If we instead break the monolithic chunk of work into smaller pieces, we can then consider the status of the smaller pieces individually and we no longer have to wait until the end of the iteration to see a chunk of work transition from a state of "in progress" to "complete." Instead, all along the way, smaller chunks of work are transitioning from "planned" to "in progress" to "complete" states as developers take responsibility for, work on, and then deliver each small chunk.
This breakdown gives us a more fine-grained means to track the progress of the iteration. We suddenly can understand whether any particular chunk of work is blocked, ready to be tested, completed ahead of schedule, or perhaps unlikely to be worked on at all. We also have the ability to deliver the smaller pieces to the testing group during the iteration.
Small Chunks Foster Ownership and Accountability
Working in small chunks fosters ownership and accountability on the part of the team. After, all if chunk A is to be delivered in less than a week, the team had better be very certain of which team members are going to define/build/test it!
Small Chunks Divide Big Jobs into Doable, Smaller Pieces
On systems of scale, complexity reigns. Imagine the challenge of coordinating 300 people to build a new system, the likes of which have never been seen on the market. In traditional development models, the problem can appear overwhelming, and no amount of planning can possibly flesh out all the details. In addition, for very large jobs, job satisfaction for the team is often deferred until the end. And as we have seen with our analysis of what doesn't work, even the ending can be pretty unpleasant at times. In such a case, job satisfaction can be entirely missing from the employment equation!
With agile, progress and job satisfaction are constant, frequent, and in real time. The next opportunity to show your wares to a customer, peer, or other stakeholder is at most a week or so away.
Small Chunks Uncover Key Risks Early
It is not unusual for teams new to agile to achieve only 25 to 35 percent of the scope of work they set out for themselves in the first iteration. The reasons can be varied, as we'll see in later chapters. But whether the goal is missed because, for example, the teams are unable to estimate very well or perhaps because a small story uncovered an unanticipated technical obstacle, the results of the first iteration will immediately expose the risks, wherever they may lay. In addition, management has its first tangible view of progress at the end of only the first week or two of the project.