Refactoring to Agility

Next Page

Book Cover
Refactoring to Agility
By Carol A. Wellington
...............................................
Publisher: Addison Wesley Professional
Pub Date: June 30, 2006
Print ISBN-10: 0321486471
Print ISBN-13: 978-0-321-48647-9
Pages: 80

Table of Contents
Overview

A Practical Framework for Gaining Agility's Benefits Without the Risk

Agile methodologies, such as XP, Scrum, Crystal, and Lean Software Development enable development organizations to deliver higher-quality software far more rapidly. However, for the "non-agile" development organization, transitioning to agility is an enormous leap, requiring radically new skills and presenting profound risks.

In this book, leading agile practitioner Carol A. Wellington introduces the first systematic, three-phase process for moving smoothly to agility. Just as developers have learned to refactor code to improve performance and maintainability, Wellington shows how to refactor processes to improve agility.

Using Wellington's framework, you can gradually move toward agility, while maintaining full control and avoiding disruption. You'll lay a solid foundation for agility, and then refactor more and more of your processes, systematically introducing agility wherever it delivers compelling value. You can retain current processes that work, and implement the best agile methods for your organization, regardless of their source. This practical approach can help you build organizational confidence in agility, drive measurable benefits, and minimize risk every step of the way.

Coverage includes

· Phase 1: Time-boxed iterations that deliver customer-visible functionalitynot just components

· Phase 2: A lightweight measurement process to detect problems and evaluate changes withoutwasting too much time gathering and analyzing data

· Phase 3: Identifying your worst process "smells," uncovering their true underlying causes, and fixing them

· Incrementally bringing agility to planning, estimation, analysis, design, development, and process management

· Eliminating tasks and processes that don't add value

· Overcoming pitfalls and hidden interconnections that complicate your agile transition

· Learning to lead the transition to agility, gaining buy-in from team members, customers, and executives

Whatever your role, organization, or current methodology, Refactoring to Agility can help you reap powerful value from agile methodswithout the risks.

Dr. Carol A. Wellington is a professor of computer science and the department chair at Shippensburg University of Pennsylvania. Prior to this position, she was a leader in large software development organizations, building operating systems and real-time embedded applications. Dr. Wellington currently uses this combination of academic and industrial experience as a consultant to help companies question their assumptions about development processes to improve their agility and product quality.

Next Page


Table of Contents

Previous Page

Book Cover
Refactoring to Agility
By Carol A. Wellington
...............................................
Publisher: Addison Wesley Professional
Pub Date: June 30, 2006
Print ISBN-10: 0321486471
Print ISBN-13: 978-0-321-48647-9
Pages: 80

Table of Contents

Copyright
Chapter 1. Introduction
 | Section 1.1. Agile and Plan-driven Methodologies
 | Section 1.2. How Time-boxed Iterations Help Us Handle Change
 | Section 1.3. Managing the Risk of Transitioning to Agility
 | Section 1.4. Phased Transition and Refactoring to Agility
 | Section 1.5. Outline of This Book
 | Section 1.6. References
Chapter 2. What Is Agility?
 | Section 2.1. Agility Is Not Binary
 | Section 2.2. How Much Agility Is Realistic Today?
 | Section 2.3. What Do We Need to React to with Agility?
 | Section 2.4. Agility Is Not an End State
 | Section 2.5. Agile Values
 | Section 2.6. Agile Teams
 | Section 2.7. Agile Management
 | Section 2.8. References
Chapter 3. Phase 1Getting to Fixed-length Development Iterations
 | Section 3.1. Start with the Coding Phase
 | Section 3.2. Plan and Release FunctionalityNot Components
 | Section 3.3. Example of Planning by Functionality
 | Section 3.4. Is It Refactoring or Rework?
 | Section 3.5. Preparing for Changes That Affect External Entities
 | Section 3.6. Common Pitfalls of Phase 1
 | Section 3.7. Evidence That Phase 1 Is Complete
 | Section 3.8. References
Chapter 4. Phase 2Measuring the Process
 | Section 4.1. Using Metrics to Affect Behavior
 | Section 4.2. Agile Metrics Philosophies
 | Section 4.3. What Is "The Goal"?
 | Section 4.4. What Should We Measure?
 | Section 4.5. Techniques for Defining Other Metrics
 | Section 4.6. Deploying Metrics
 | Section 4.7. Conclusions
 | Section 4.8. References
Chapter 5. Phase 3Refactoring the Process
 | Section 5.1. Are We Ready for Optimization?
 | Section 5.2. What Is a Process "Smell"?
 | Section 5.3. Picking Which Smell to Work On
 | Section 5.4. Making the Selected Change
 | Section 5.5. Measuring the Effect of a Change
Chapter 6. Process Innovations by Type
 | Section 6.1. Planning Innovations
 | Section 6.2. Estimation Innovations
 | Section 6.3. Process Management Innovations
 | Section 6.4. Analysis/Design Innovations
 | Section 6.5. Development Innovations
 | Section 6.6. General Process Innovations
 | Section 6.7. References
Chapter 7. Process Smells
 | Section 7.1. Non-value-adding Activities
 | Section 7.2. Smells in Deliverables
 | Section 7.3. Planning Smells
 | Section 7.4. General Smells
 | Section 7.5. References

Previous Page


Copyright

Dedication

I owe thanks to all of my family for their feedback on this work: my dad and his experience, my mom and her big dictionary, my sister, Julie, and her contacts, my daughter, Alexa, and her enthusiasm, and most importantly, my husband, Greg, and his insights into how to pursue this endeavor.


Chapter 1. Introduction

There have been a number of "agile" methodologies documented in recent years including Extreme Programming, Scrum, Crystal, Lean, and more. Each has strengths and demonstrated successes. Teams have used these methods to deliver high-quality software rapidly. In particular, teams using these methods have been able to adjust to changes in market pressures and deliver software in response to changing customer demands. However, for those engineers who are working in non-agile development organizations, moving to an agile process is a huge leap and brings significant risks. Agile processes require different skills in the engineers and in the management of the project. Such a radical change to the development process could result in delays and difficulty in delivering acceptable results. The enthusiasm behind the agile movement has generated a wealth of literature on various development and management techniques and philosophies that have been shown to be effective. The sheer volume of that literature can be overwhelming for people who are considering agility.

Imagine the typical software development team: they are working hard to produce a quality product that their customer wants, and they are using a process that is unique to their environment and customized to their culture and skills. The process they follow may be waterfall or simply ad hoc (for this example, it doesn't matter). One day, Joe Engineer, a member of that team, reads a book on an agile development process (it doesn't matter which one). Things seem so obvious! "We should ask the customer what he wants regularly instead of only at the beginning and end of the project. We should work in a collaborative environment where we maximize every engineer's skills. We should measure ourselves by the features we produce, not the milestones we pass or documents we write. We should put the parts of our system together as soon as possible to be sure that the code we've written really works. We should use tools like automated testing to help us guarantee quality, and we certainly should be allowed to refactor the parts of our system that need it."

Having had these revelations, Joe takes his enthusiasm to his colleagues and management. Although they have some reservations, they are willing to look into the possibilities. Other team members start reading books on other agile methods, and soon the team is overwhelmed. The processes are similar in philosophy but differ in their details. Which one should they pick? Then management begins to recognize the scope of the change being proposed. "These new methods require some new skills. Do we have team members who have this experience?" The team has to admit that they don't because they've been busy producing the product. The significance of the change in the process scares management (and some of the engineers). "How will we continue to produce the products that pay all of our salaries while we figure out how to make this transition?" "Are we sure that even if we make the switch, the benefits will outweigh the costs?"

No agile methodology is "best" or works for every organization. Selecting the methodology that adds the highest value by matching its strengths with the capabilities of your organization is non-trivial, and it is unlikely that any methodology you choose would yield the optimal solution for all of the issues that are particular to your organization. It would be far more useful for an organization to be able to incorporate the most valuable techniques as they pertain to its unique process, independent of any one methodology.

This book lays out a process to assist the organization's transition to agility with minimal risk. Although this "mix and match" approach may seem to add complexity to a transition from plan-driven to agile development, in reality it will reduce the risk of that transition by allowing a more customized, step-by-step approach.

The structures of agile methods are very different from traditional software development methods and require new skills in your engineers and your management. The goal of this book is to allow an organization the freedom to become agile without the fear that accompanies replacing all elements of the current plan-driven approach with a new agile methodology in a single step. That goal is supported by a transition framework that will help everyone (engineers, managers, customers, etc.) manage the process change in a way that maximizes potential benefits while minimizing risk. After agility has been achieved, a strategy for optimizing the process is presented.


Section 1.1. Agile and Plan-driven Methodologies

1.1. Agile and Plan-driven Methodologies

The most widely used software development methodology is the waterfall model that was originally espoused by Winston Royce[10] in 1970. His paper starts by describing a single-pass development cycle that evolved[1] into the waterfall model. Although software engineering practices have long been based on the single-pass development life cycle he specified, Royce's paper said that it was "risky and invites failure" for projects with any innovation. He pointed out that you aren't sure that anything will work until very late in the project. At that point, changes in the design could cause up to 100% rework.[2]

[1] The terminology for the analysis stage has changed, but the philosophy is the same as Royce's original diagram.

[2] Royce went on to propose a two-pass cycle with a number of other interesting innovations to reduce the risk. His insights are still relevant and worth reading.

Royce's solution to this fail-late methodology was to propose that we make two passes through the waterfall: the first pass focuses on the riskiest parts of the system, which results in essentially a (possibly throwaway) working prototype, while the second pass through the cycle actually results in the product. Royce's strategy was extended by Boehm's Spiral Model[4] that advocates prototypes, replanning, and risk analysis at every phase of the project. However, these methods still advocate specifying the entire system during the requirements analysis and design phases of development. The philosophy behind these methods is that if we plan carefully enough, we will be able to build the entire product without any rework after we enter the coding phase of development. Therefore, these methods are known as plan-driven methods.

In reality, in organizations that use plan-driven methods, most projects use repeated passes through the waterfall as they produce subsequent releases of the project. In doing so, they have acknowledged two things. First, today's systems are too complex to build in a single pass. They have complex interactions with the world and encompass ever-changing requirements, and these characteristics prohibit thorough up-front specifications. Second, market pressures require a company to ship product in order to survive. Developing the complete product defers income for too long. Instead, a critical subset of the required functionality is selected and put into Release 1.0. The team develops that release before time is allocated to plan the functionality of subsequent releases. By doing this, we have opened the door to rework because portions of the system may have to change significantly in subsequent releases, but this choice seems inevitable.

Agile methodologies have taken this iterative approach to development to its extreme. Instead of working on an entire release, they develop the system in small, fixed-length intervals called time-boxed iterations that are focused on delivering customer-visible functionality. In fact, it has been stated that these iterations are the "universal starting point for all agile software development approaches."[9] Although not everyone agrees on the optimal length of an iteration (recommendations range from one week to three months), the consistent factor is that within an organization, these iterations are of the same length every time.

It is very important that we notice the difference between an iteration and a release. Iterations are focused on delivering customer-visible functionality, and the goal is to show that functionality to the customer at the end of every iteration. Agile teams will produce workable functionality in every iteration.[3] However, an iteration does not have to be a "release." Although some teams have customers that really want access to every iteration, most customers do not want that rate of change to be delivered to them. In these cases, the results of a number of iterations become a release.

[3] Many teams take this to the extreme of ensuring that the product is always ready to release (called continuous integration). This ensures that they are continuing to make progress. Because nothing is "complete" until they see it work, they are sure that their progress is visible.


Section 1.2. How Time-boxed Iterations Help Us Handle Change

1.2. How Time-boxed Iterations Help Us Handle Change

In plan-driven methods, the scope of a release defines the length of time needed to produce the required functionality. In other words, the releases vary in length and in the scope of the functionality to be delivered. With time-boxed iterations, the iteration length is always the same, which defines the scope of functionality that can be developed in each iteration.[4] Essentially, agile methodologies reduce the project's development risks by allowing the time available in the iteration to define the scope instead of letting the scope define the length of the release. (Read that sentence again; it's important!) Using time-boxed iterations is the fundamental difference between agile and plan-driven methodologies.

[4] Again, releases may vary in length, but planning, tracking, and feature production are being done at the iteration level.

The next few sections detail the risks and benefits of time-boxed iterations. Agile methodologies require a very significant change in how we plan; however, as you'll see, there are many positive repercussions of this single change.

1.2.1. Risk Management via Estimation Accuracy

One of the biggest benefits of time-boxed iterations is that it improves estimation accuracy, which helps lower our risk of underestimating the task at hand. First, short iterations reduce the magnitude of our estimation errors. For example, a 10% error in a 12-month plan causes a 1.2-month slip, whereas the same error in a two-week plan causes only a one-day slip. Errors of that magnitude are much easier to manage.

However, the benefits of shorter, regular plans do not stop there. The basic fact that we are making smaller estimates reduces the error rate of our estimates. In general, the error in estimates increases with the size of the estimate. For example, it's a lot easier to recognize the difference between estimates of two and three hours than it is to distinguish 20 hours from 21 hours. Therefore, the absolute magnitude of our errors in estimation is likely to be much smaller if the length of our iterations is smaller.

In plan-driven development, estimating smaller tasks mitigates this non-linearity in estimation accuracy. Instead of estimating an entire release, the tasks necessary for that release are estimated individually, and the sum of those estimates is used as an estimate for the entire project. However, the assumption that those estimates are cumulative is questionable. Often, the actual length of the project does not correspond with the sum of the individual estimates of individual tasks. In most large releases, the tasks are related to each other, and therefore the errors in their estimates may interact. For example, if I forgot that one task would require a change to the database, I may have made the same type of error in the estimates of other tasks. This means that even if we make the tasks small enough to improve our accuracy, accumulating those estimates for a large release will induce more error. The bottom line is that estimating small tasks within small iterations will greatly improve our estimation accuracy.

With fixed-length iterations, estimation accuracy improves because we are estimating smaller things. However, that is not the only source of estimation accuracy improvement that results from fixed-length iterations. In addition, the rhythm of the iterations further improves estimating accuracy. After a few iterations, the team members learn how much they can complete during each iteration, and their intuition increases for estimations of that magnitude. The result is a reduction in the error of the estimates.

1.2.2. Reducing the Problem of Sequential Tasks

In The Goal [7], Goldratt gives an excellent example to show the problems with sequentially dependent tasks. Picture a Boy Scout troop walking single-file along a wooded trail. If the boys toward the front of the line are faster than a boy in the middle (who is named Herbie), the front part of the troop will pull ahead and will eventually be sitting at the end of the path waiting for the rest of the troop to emerge. Furthermore, the faster boys behind Herbie will be unable to achieve their maximum speed and will back up behind him. Regardless of the potential speed of these trapped boys, they will not be able to exit the path until Herbie is out of their way.

Essentially, the boys are a metaphor for sequentially dependent tasks in your development cycle, and the order of the boys matches the completion order of each task (i.e., the first boy represents the task that will complete first). The project is complete when the last boy reaches the destination. If there are sequential tasks and one is a Herbie (is delayed), the entire project will be delayed. Our plans may rarely be linear, but often tasks are dependent. Having a Herbie anywhere in your plan can greatly reduce your efficiency. The result may be idle people and altered plans.

It's also important to note that completing the early tasks (those that are ahead of Herbie) ahead of schedule might not alleviate the problem caused by Herbie. For example, if the Herbie task cannot start earlier, then it doesn't matter how early the tasks before Herbie complete. Underestimating Herbie still delays the completion of the project.

If you are planning a full release, then you are usually estimating tasks at the granularity of weeks, and it is safe to assume that the probability that any individual task will be underestimated is roughly the same for every task. As the number of sequential tasks in your plan increases, the probability that at least one of them will be underestimated (or delayed) approaches one, as shown in the chart below. Therefore, the longer the sequence of tasks is, the higher your odds are of delivering late.

Figure 1.1. Sequential tasks increase the probability of late delivery

Delivering the release as a sequence of iterations has the same effect as regular clearings along the path would have on the Boy Scout troop. If the boys had the opportunity, they could redistribute the weight in their backpacks at each clearing. Similarly, short iterations give us regular opportunities to adjust how we are approaching the problem. In addition, because each iteration is short, it is unlikely that Herbie can have much impact on the project, and the team can adjust before the next iteration begins.

The need for the traditional study of critical path analysis as a way of measuring and mitigating risk is a direct result of the length of the release. When we plan shorter releases, the number of dependencies between the tasks is reduced. That reduces the length of the critical path and the risk that we will deliver late. In fact, when iterations are small enough (less than a month), there are very few dependencies between the tasks, and we are not required to plan the order in which they will be completed. In effect, there will not be a single critical path. The team can see what dependencies exist and handle them without managerial input.

1.2.3. Feedback

One of the main goals driving the move to time-boxed iterations is to get feedback at regular intervals. By producing customer-visible functionality at every iteration, we allow the customer to evaluate the direction in which the product is developing and to change that direction if necessary. The team also has the opportunity to gather metrics about its behavior at fixed intervals, which greatly simplifies the detection of trends or anomalies. In fact, the regular rhythm of time-boxed development supports statistical process control much better than the long, variable-length releases of plan-driven development. The bottom line is that feedback is a cornerstone of all agile methods. We want feedback from the customer, from each other, and from the process itself. We want feedback about how effective our methodology is, how well our code works, the quality of our design, our individual performances, our performance as a team, and so on.

In fact, agilists are quite greedy about feedback: we want it as soon as possible. The short iterations guarantee reasonably quick feedback from our customers, but we also look for feedback in a number of the other techniques we deploy: feedback from each other at daily meetings, instantaneous feedback on our code from automated testing, regular feedback from the process as part of continuous integration, instantaneous design review feedback through pair programming, and so on. The value of feedback cannot be overstated: rapid feedback ensures that we notice when our performance is less than optimal and gives us the opportunity to fix the problem with a minimum of lost effort.

1.2.4. Is It Rework?

Some plan-driven organizations consider rewriting a piece of code as "rework," which is considered to be waste. Therefore, they go to great efforts to try to ensure that this never occurs. However, because agile teams plan and develop in short iterations, we clearly don't plan the design of the system for the long term. Therefore, it is likely that we will develop software during one iteration that will have to be significantly redeveloped in later iterations.

In fact, some agilists are decidedly shortsighted. Extreme Programming (XP) advocates do "the simplest thing that could possibly work" at each iteration without considering the functionality required by subsequent iterations. The justification is that we often are only guessing at the functionality that will be required, and requirements often change, so designing for those future requirements may turn out to be wasted effort. As an example, if a customer says the system only needs to remember five items, an XP team would store them in an array (or five variables) if that seemed the simplest solution. Later, if the customer required an arbitrary number of items to be remembered, the team would implement a more complex data structure like a list or hash map. If she never required more, the complexity of the hash map would be wasted, but if she did, the team would have some rework to perform.

Clearly, with short iterations, it is highly likely that code we develop for one iteration will need to be changed in later iterations. Plan-driven methods consider this to be rework and try to eliminate it. With those methods, changes late in the development cycle are risky and costly because they may require modification of the documentation and significant regression testing. In addition, changes made late in the development process are more likely to introduce defects and are therefore more risky. Agile methods have a number of strategies for reducing that risk, including automated unit testing, automated acceptance testing, and source code refactoring.

Essentially, agile methods weigh the savings resulting from the simple implementations against the costs and risks of needing to change the code later. Because these methods control those costs and risks, the benefits of reduced initial development outweigh the effort of "rework." In fact, agile teams do not consider making the necessary changes to be "rework" at all; those changes are just what the customer wants.


Section 1.3. Managing the Risk of Transitioning to Agility

1.3. Managing the Risk of Transitioning to Agility

The published plan-driven methods (waterfall, spiral, etc.) are very different from agile methods (XP, Scrum, etc.), and they require a significantly different set of management skills. In plan-driven methods, managers are responsible for planning and controlling the development activities. They spend much of their time making plans, verifying progress against those plans, and replanning. In agile teams, managers behave much more like technical coaches and are primarily responsible for identifying and eliminating obstacles that the team encounters. Clearly, agile managers require different skills than plan-driven managers.

The way plan-driven developers produce systems is significantly different from that of agile developers. Plan-driven developers produce lengthy requirements and design documents that are thorough and (at the time) complete. Agile developers produce only enough of those documents to understand what needs to be done. Plan-driven teams tend to partition the system into subsystems, and most developers work within a subsystem, whereas agile teams encourage everyone to feel responsible for the entire system. During implementation, plan-driven developers often develop their respective components (classes, pages, modules, etc.) in isolation and wait until that coding is complete to integrate those components into features. Agile developers work directly on features, programming in pairs in an open environment. Again, agile developers require different skills than plan-driven developers.

In addition, agile teams often interact with external organizations (marketing, customers, management, human resources, etc.) in different ways than plan-driven teams, so transitioning to agility can affect more than just your development organization. It may seem that such a dramatic change could threaten your ability to produce anything, but careful transitioning can reduce those risks and allow you to experience the benefits of agility quickly.

Most of us have been educated in plan-driven methods and have experience working in a plan-driven environment. Because the differences proposed by agile methods are significant, making the transition from plan-driven to agile development can be very risky and intimidating and is not something to be approached lightly.

Several strategies for making the transition to agility have been advocated. Kent Beck has summarized these specifically for XP[3], but the strategies he offers apply to other agile methods as well. Beck suggests three transition strategies: cannonballs, racing dives, and toe dipping. Initially, Beck advocated cannonballs: switching the entire process at once for one project within the organization, and after that project demonstrates success, using those engineers to carry the process into other projects. Although Scrum does not necessarily affect the development strategy, it does advocate overlaying Scrum in its entirety on top of the existing development strategy. In fact, some advocates of Scrum have suggested that the pilot project be the "single most difficult and critical project."[8]

Clearly, a radical change in process brings with it significant risk. If the learning curve is too steep, you could fail to deliver anything. In companies that have few projects, the risk may be life threatening. Many organizations have mitigated this risk by bringing in a consultant to help ease the transition (Beck calls this a racing dive). These consultants are well versed in the techniques of a particular methodology and reduce the learning curve by guiding the organization through the transition. Although this is a strong approach to jumpstart the transition, there is always the risk that the consultant may not help you internalize the change and, after she leaves, you will revert to your old ways.

The final alternative is toe dipping, in which the organization selects one or two XP practices to initiate their transition. After they are comfortable with those practices, they begin to incorporate other practices as they seem appropriate. Although this strategy reduces risk by preventing a dramatic change, it also may delay the benefits that agility can bring. With no experience or guidance, the team may not make wise decisions about which practices to incorporate and may not achieve the goals set for the change.

The strategy this book advocates is a phased transition that reduces risk and gives engineers the time to adjust to the changes. This strategy builds on the foundation laid by Don Wells in Beck's original XP text[2]. In fact, it is essentially a structured version of toe dipping. Wells' strategy was

  1. Pick your worst problem (the worst problem your process causes)

  2. Solve it the XP way

  3. When it's no longer your worst problem, repeat

Each of these statements raises interesting questions, especially when we are interested in agility in general as opposed to XP specifically:

  1. How do I know which problem is my "worst" and where my investment in change will give me the biggest payback?

  2. What are the proven ways other people have solved this problem?

  3. How do I know the change to my process has been an improvement?

This book provides a framework that will help everyone (engineers, managers, customers, etc.) manage the change process in a way that maximizes potential benefits while minimizing risk.


Section 1.4. Phased Transition and Refactoring to Agility

1.4. Phased Transition and Refactoring to Agility

This book is designed to help a plan-driven (or ad hoc) organization become a mature agile organization. This book does not advocate a specific agile methodology but instead provides a framework for optimizing your process by utilizing best practices from any agile (or non-agile) methodology. The transition strategy contained in the rest of the text is a surprisingly simple three-phase process. Organizations that already produce in time-boxed iterations can start optimizing at Phase 2.

Phase 1: Modify the implementation phase of development so that it is scheduled in time-boxed iterations and so that the team will produce customer-visible functionality with each iteration. Because that is the critical difference between plan-driven and agile organizations, it is a requirement that must be addressed before optimization can occur.

Phase 2: Measure the process. There are standard metrics that will lead to agility by helping you detect problems and evaluate possible changes to the process. In addition, an organization may need to hone its ability to define metrics based on its goals.

Phase 3: Refactor the process. After the procedure for delivering in time-boxed iterations is established and we begin to gather metrics reflecting our capabilities, it is likely that we will find that other parts of the process can be optimized. In addition, changes in requirements, personnel, competitors, and so on will continue to require optimization of your process.

This ongoing optimizing phase is patterned after Martin Fowler's source code refactorings but focuses on process smells[5] and process changes that address those smells. In the context of refactoring your code, a "code smell" is something that somehow looks "bad" in the code. Examples include methods that are too long, classes that are very tightly coupled, and methods with many parameters. In his revolutionary book[6], Fowler created an encyclopedia of such smells. For each smell, he gave one or more refactorings to address the underlying problem in the code. A refactoring is a mechanical manipulation of the code that does not change the external behavior but that cleans up the problem causing the smell.

[5] Elssamadisy and Schalliol[5] initially applied the concept of refactoring to the process by listing some "smells" and possible fixes from their XP experience.

Refactoring your process follows this principle: when something smells, search for the standard way to fix it. Many agile techniques have been beneficial on specific projects, but no method is a "silver bullet." These methods have used different techniques to solve similar process problems. Therefore, this text defines process smells and relates them to strategies that have been shown to work in agile (and sometimes non-agile) organizations.

Throughout this process, you're going to have to handle resistance to these changes. Auer and Miller[1] do an excellent job of identifying the types of resistance you'll probably see and strategies for dealing with that resistance. During the transition, it is especially important to pay attention to the effect that this shift in philosophy has on individual engineers. It cannot be stated too strongly that engineers in agile organizations approach development in a very different way from engineers in plan-driven organizations. Not only are there new development strategies like automated tests, source code refactoring, and test-driven development, but also engineers in agile organizations are much more involved in the overall design of the system, interactions with the customer, and planning. Finally, the focus on delivering customer-visible functionality differs from the focus on delivering architectural components. Engineers who have been successful in an organization's current environment may be threatened by the transition to agility. These concerns must be addressed for the transition to be successful.


Section 1.5. Outline of This Book

1.5. Outline of This Book

To give a solid foundation for the transition, Chapter 2 broadens the definition of agility beyond the traditional definition and provides a justification for the transition this book advocates. It also gives a brief overview of agile values because agile teams are generally structured and managed differently from plan-driven organizations. This overview is for background information only and refers the reader to other texts on this topic.

Chapters 3, 4, and 5 define the three phases of the transition toward agility.

Chapter 6 provides a topical index into the process innovations, which are grouped by the part of the process they affect. The goal of this chapter is to compare and contrast the process innovations that address similar issues. One of the risks of this strategy is that various parts of your process might be interconnected in a way of which you are unaware. For example, in XP, pair programming is an essential part of code review and a mechanism for communication. However, without team ownership of code, pair programming can only be applied in a limited fashion. Therefore, as you begin to refactor your process, it is important that you look for the broader effects that your change may cause. Chapter 6 is designed to help you find those relationships.

Chapter 7 defines the process smells and possible process innovations. Because each smell is really a symptom of an underlying problem, there is not a one-to-one mapping from smell to process innovation. This chapter suggests process innovations based on the suspected underlying cause of the smell.


Section 1.6. References

1.6. References

[1] Auer, Ken, and Roy Miller, Extreme Programming AppliedPlaying to Win, Upper Saddle River, NJ: Addison-Wesley, 2002.

[2] Beck, Kent, eXtreme Programming eXplainedEmbrace Change, Upper Saddle River, NJ: Addison-Wesley, 2000.

[3] Beck, Kent, "Getting Started with XP: Toe Dipping, Racing Dives, and Cannonballs," at http://www.threeriversinstitute.org/Toe%20Dipping.pdf, as of 1/7/2006.

[4] Boehm, Barry W. , "A Spiral Model of Software Development and Enhancement," Computer, Vol. 21, No. 5, 1988.

[5] Elssamadisy, Amr and Gregory Schalliol, "Recognizing and responding to 'bad smells' in extreme programming," Proceedings of the 24th International Conference on Software Engineering, ACM Press, New York, NY, 2002.

[6] Fowler, Martin, RefactoringImproving the Design of Existing Code, Upper Saddle River, NJ: Addison-Wesley, 1999.

[7] Goldratt, Eliyahu M. , and Jeff Cox, The GoalA Process of Ongoing Improvement, Great Barrington, MA: North River Press, 2004.

[8] Larman, Craig, Agile & Iterative DevelopmentA Manager's Guide, Upper Saddle River, NJ: Addison-Wesley, 2004.

[9] Poppendieck, Mary and Tom Poppendieck, Lean Software DevelopmentAn Agile Toolkit for Software Development Managers, Upper Saddle River, NJ: Addison-Wesley, 2003.

[10] Royce, Winston, "Managing the Development of Large Software Systems," Proceedings of IEEE Wescon, 1970.


Chapter 2. What Is Agility?

    Section 2.1. Agility Is Not Binary

    Section 2.2. How Much Agility Is Realistic Today?

    Section 2.3. What Do We Need to React to with Agility?

    Section 2.4. Agility Is Not an End State

    Section 2.5. Agile Values

    Section 2.6. Agile Teams

    Section 2.7. Agile Management

    Section 2.8. References


Section 2.1. Agility Is Not Binary

2.1. Agility Is Not Binary

Currently, processes are divided into two distinct categories: agile and plan-driven. Each has a community, a variety of practices, and a list of successful applications of those practices. With a few notable exceptions, there is very little overlap between these categories. This gives the appearance that agility is a binary attribute. However, agility is not an all-or-nothing affair that we can achieve through a single change in the development process.

Instead of asking, "Are we agile?" and trying to initiate a single, dramatic process change that will "achieve" agility, a more appropriate perspective focuses on "To what degree are we agile?" Within its community, agility has been defined as "the ability to both create and respond to change."[5] We can answer this question by measuring the length of time between a requirement change and when we deliver the updated functionality to a customer. This length of time is known in Lean Software Development as cycle time.

Figure 2.1. Apparent distinction between agile and plan-driven methods

Agile methodologies have been designed to have very short cycle times when compared with plan-driven methodologies. In general, agile methods advocate releasing new functionality in fixed-length iterations, and the iteration length defines their cycle time. This is the most significant difference between agile and plan-driven methods: agile methods have a fixed cycle time that is relatively short, which lets the team adjust to changing customer needs rapidly.

Plan-driven (and ad hoc) methodologies define the length of time between releases by the functionality they want to be included in the release. As a result, releases are not of a fixed length, so they do not have a consistent cycle time. However, as a starting point, every process has a (possibly variable) cycle time and therefore some (possibly low) degree of agility.

With this perspective, agility is not a binary attribute and does not mandate a dramatic change in your process today. The current process has some degree of agility (though it may be slow and unstable) and defines a starting point on the path to improved agility. The challenge is to maximize the strengths of the current process and to make changes to that process in a disciplined manner with specific goals in mind.


Section 2.2. How Much Agility Is Realistic Today?

2.2. How Much Agility Is Realistic Today?

Having acknowledged that there are degrees of agility, the relevant questions change significantly. Instead of asking, "Are we agile?" the question becomes, "To what degree should we be agile?" Increasing an organization's agility requires an investment that may be non-trivial and brings a certain amount of risk. The cost of change must be weighed against the benefits, including any reduction in development risks, to ensure the long-term viability of the organization. It is only beneficial to pursue agility in cases where increasing agility increases the capabilities of the organization. These decisions will require that we define what is needed for long-term viability and specify how to measure our progress toward that goal.

Fully embracing an agile methodology requires changing the way engineers allocate their time and how they approach all software development activities.

The management mechanisms and the techniques and strategies for developing software differ dramatically from plan-driven mechanisms. Therefore, effectively using an agile methodology requires new skills for the engineers, project managers, and the organization as a whole. This means that we also need to consider our organization's ability to achieve agility given its current skill set. So we need to ask, "To what degree can we be agile?"


Section 2.3. What Do We Need to React to with Agility?

2.3. What Do We Need to React to with Agility?

In general, the "changes" that agility refers to have been changes in requirements. Agile processes have been designed for situations when requirements are either not well known or quickly changing. Usually, "agile" refers to a process, but in a broader sense, agility denotes the ability to deliver functionality in a timely manner and the ability to adjust to externally imposed change. In these terms, "change" usually means changing requirements, but it can also mean changes in things like technology requirements, assigned personnel, or management.

In fact, an organization demonstrates agility, or a lack thereof, in response to a wide variety of changesnot just changes in requirements. For example, a plan-driven organization with a solid training and mentoring program may be quite agile when dealing with changes in personnel, but it is unlikely that it will be agile in response to changes in the customer's needs. Similarly, an XP organization may be quite agile when the customer's needs change, but the level of automation and uniqueness of their process may make them less agile in dealing with changes in personnel. For these reasons, we must ask, "What kind of agility do we need?"


Section 2.4. Agility Is Not an End State

2.4. Agility Is Not an End State

As Jim Highsmith says, "Agility isn't a one-shot deal that can be checked off the organizational initiative list. Agility is a way of life..."[5] Although a number of different agile methodologies have been specified and successfully deployed, it is important to acknowledge that there is no single methodology that is optimal for all organizations. Specific details of the process that is optimal for your organization depend on a wide variety of characteristics such as

  • The capabilities of your engineers,

  • Your customer's needs,

  • The relationship the engineering team has with other internal organizations like marketing and project management,

  • The physical environment your engineers work in, and

  • The technology in which you are developing.

In fact, as with plan-driven organizations, mature agile organizations are always looking for ways to improve the functioning of their team by modifying their development process. As an example of this maturity, in the first edition of Kent Beck's eXtreme Programming eXplained [2], he espoused XP as a specific methodology in the way he had originally developed it. The book specified exact details such as iteration length and recommended adoption of all of the basic practices without exception. By the second edition[3], Beck had more experience with more organizations, and he wisely revised that philosophy to allow organizations to tailor XP to their needs and capabilities. The goal of every quality software engineering organization is to mature to the level that allows the local optimization of their process.

Optimization of one's development process requires the ability to

  • Detect problems,

  • Weigh changes that could reduce or eliminate those problems,

  • Make the optimal change, and

  • Measure the effect of the change you made to ensure that the result was an improvement.

Although almost everyone in an organization will be able to list the problems, actually making the change can be very complex. With a list of problems and potential solutions, selecting a problem to address is not a trivial challenge. Process problems are often detected by different parts of the organization with differing interests. For example, marketing may be concerned with the ability to deliver functionality by a given date, while engineers might be concerned about a growing backlog of defects. In situations like these, the solutions to the problems can actually compete because addressing one problem may aggravate another.

The source of this tension may be that there is no common understanding of the direction of the organization. In order to make choices about which problems to address, we need to understand the goal of the entire organization (not just development) and weigh potential solutions against that goal. In Chapter 4, "Phase 2Measuring the Process," we will define that goal carefully and provide metrics that will help us achieve the goal. When you understand that goal, the optimal change to the process is the one that is likely to have the biggest effect on meeting that goal.


Section 2.5. Agile Values

2.5. Agile Values

The Agile Alliance, a non-profit group supporting agile activities that was founded by many of the agile leaders, has an explicit statement of values that they call the Manifesto for Agile Software Development [1]:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • 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, we value the items on the left more.

Cockburn[4] gives an excellent description of this manifesto and its subtleties. This manifesto demonstrates the extent to which agilists believe they have been handcuffed by plan-driven processes. These values are rooted in a long history of unsuccessful plan-driven processes and a belief that by changing the focus of the process, software development activities can be more successful.

In addition to the Agile Alliance, many agile methods and techniques include explicit value statements. For example, XP values include communication, simplicity, feedback, courage, and respect. Scrum values self-organization for the teamit does not specify anything about how the team should function during an iteration (which Scrum calls a "sprint"). They are free to use any methods they think will help them achieve the sprint's goal.

These values underscore key principles that are shared across most agile methods that will be described in the rest of this chapter. These values match an engineer's perspective quite well because they promote quality designs that meet the customer's needs.


Section 2.6. Agile Teams

2.6. Agile Teams

The behavior of athletes in team sports closely parallels agile teams in a number of ways (the Poppendiecks have made this same analogy to the Marines[6]). A competitive volleyball team prepares very carefully for a match. They work on understanding their strengths and weaknesses and those of their opponent. Given that information, they develop several strategies they think will be valuable. Essentially, this high-level strategy is their version of planning. The details of the game are generally left to the players. Although the coach can offer insights during a small number of timeouts, the team has to be able to analyze how the game is progressing and adjust to the play of their opponent. Even with the timeouts, the game unfolds at too high a speed for the coach to make every decision and give everyone new instructions. Although practices include skill development, the training of good players must include the decision process and strategies for adapting to a changing opponent. That way the players can adjust and handle the moment-to-moment issues during the game.

Although agile teams have not explicitly made the distinction between "planning" and "predicting," agile methods do include these differences in granularity. Selecting the functionality that will be included in an iteration is equivalent to the planning that the Marines do before a battle. The team, including managers, customers, and engineers, analyzes the potential functionality and their capabilities. The result is the strategy-level plan for the iteration. Although it technically includes estimates, they are at a level of granularity appropriate to the current knowledge of the situation.

After the functionality has been selected for the iteration, the team is responsible for determining how that functionality will be built and for handling unexpected situations as they arrive. Most team members have a computer science education that includes all of the design and problem-solving skills necessary to complete this task. Furthermore, the team usually includes members with more experience, so we can trust the team to adjust the battle tactics to achieve the goal set for the iteration.

Agile teams tend to behave as self-directed work groups[8]. This means that they determine the rules under which they will succeed. They specify any particular roles and the people who will serve in those positions. They also control the development processes and tools that they will use. They are self-organizing teams whose goal is building the functionality goal set for each iteration. They are also responsible for evaluating the level of their success and looking for ways to improve.


Section 2.7. Agile Management

2.7. Agile Management

The fact that the team is self-directed raises questions about the role of the project manager, but there are still leadership responsibilities that need to be filled. All of these leadership roles must be addressed with appropriate reverence to the agile philosophies of respect, communication, and feedback.

Most importantly, the transition to agility requires a champion to communicate the vision of agility and to support the team throughout the transition. Everyone will be learning new roles, responsibilities, and techniques, and they will need leadership with vision. Particularly in times of trouble, that clear vision will help ensure that the organization doesn't revert to their old ways. It's important that this leader be a role model of agile philosophies including respect and communication. Agility cannot be inflicted on an organization; this type of change will only succeed with a leader who provides the vision and guides the team as they define and implement the techniques to achieve that vision.

XP defines the role of the project manager as the interface between the team and the rest of the organization. The project manager tracks and reports team progress, and that can require some creativity as the organization transitions toward agility. The planning and progress being made is often hard to quantify with traditional milestones and deliverables, so reporting that progress is an opportunity to advocate for agility and educate the rest of the organization about the changes being made.

In an agile organization, planning isn't something that happens once and is finished. As Beck notes[3], "Planning is an activity, not a phase." The project manager is responsible for making sure that the plan is an accurate reflection of the team's current understanding of the iteration. As adjustments to the plan become necessary, the project manager listens to the team's assessment of the situation and helps the team adjust. The project manager role is very much a "lead by following" role; the team sets the direction, and the project manager does what he can to help the team succeed.

In Scrum, the role of project manager is titled Scrum Master[7], but it closely parallels the project manager in XP. The Scrum Master helps the team set the sprint goal and plan for the sprint. While the sprint is ongoing, the Scrum Master's primary role is to listen to the team's assessment of any impediments they are encountering and then work to remove those impediments. When the sprint is complete, the Scrum Master helps the team assess its performance and plan for improvements in the next sprint.

In some teams and methods, there is a separate role called product manager (or product owner in Scrum) that is responsible for setting the vision of the product being developed. The product manager prioritizes functionality requests to maximize the value of the features being developed and provides a connection from the team to the customer. When the team members realize that they have overcommitted an iteration, the product manager helps them to determine the functionality that should be deferred to the next iteration. If the team members have any questions about how a feature should work, the product manager finds the answers to their questions.

These are examples of the leadership roles that agility requires. However, the responsibility of these roles can fall to one or more individuals. A single person can serve as the project manager and the product owner, but that can lead to conflicts of interest. The project manager's role is focused on helping the team succeed, whereas the product owner is maximizing the value of the deliverable. These two perspectives can motivate very different actions, so it can be difficult for one person to weigh both perspectives carefully. When two people are not available, asking the team to provide the project manager role often works well. They can choose to select one person to play this role or share or rotate the responsibilities.

The leadership necessary for the transition to agility can come from someone playing the project manager role but can also come from any team member (or the entire team). Often this grassroots leadership can be more resilient and idealistic than when it comes from management. In fact, much of the agility movement initially came "from the trenches." More recently, management has been able to initiate the transition to agility with success when it embraces agile philosophies like respect and communication.


Section 2.8. References

2.8. References

[1] Agile Alliance, http://www.agilealliance.org.

[2] Beck, Kent, eXtreme Programming eXplainedEmbrace Change, Upper Saddle River, NJ: Addison-Wesley, 2000.

[3] Beck, Kent, eXtreme Programming eXplainedEmbrace Change, Upper Saddle River, NJ: Addison-Wesley, 2004.

[4] Cockburn, Alistair, Agile Software Development, Upper Saddle River, NJ: Addison-Wesley, 2002.

[5] Highsmith, Jim, Agile Project ManagementCreating Innovative Products, Upper Saddle River, NJ: Addison-Wesley, 2004.

[6] Poppendieck, Mary, and Tom Poppendieck, Lean Software DevelopmentAn Agile Toolkit for Software Development Managers, Upper Saddle River, NJ: Addison-Wesley, 2003.

[7] Schwaber, Ken and Mike Beedle, Agile Software Development with Scrum, Upper Saddle River, NJ: Prentice Hall, 2002.

[8] Thanhaim, H. J. , "Enhancing Innovative Performance of Self-Directed Engineering Teams," Engineering Management Journal, Vol. 32, No. 8, 1994, pp. 5763.


Chapter 3. Phase 1Getting to Fixed-length Development Iterations

    Section 3.1. Start with the Coding Phase

    Section 3.2. Plan and Release FunctionalityNot Components

    Section 3.3. Example of Planning by Functionality

    Section 3.4. Is It Refactoring or Rework?

    Section 3.5. Preparing for Changes That Affect External Entities

    Section 3.6. Common Pitfalls of Phase 1

    Section 3.7. Evidence That Phase 1 Is Complete

    Section 3.8. References


Section 3.1. Start with the Coding Phase

3.1. Start with the Coding Phase

Transitioning the entire process to fixed-length iterations will require new skills in order to ensure that you develop a quality design that meets the customer's needs. So, for now, leave your existing requirements specification and design activities as they are. The results of those activities will help you continue to produce a quality system while your team is learning the skills necessary for agile development. Not only does this reduce the risk of this change, but it also demonstrates that the team still values having quality in the design of the system. Here is a diagram of what your process will look like at the end of this phase of the transition.

Figure 3.1. Phase 1fixed length iterations during implementation

[View full size image]

The first step in moving toward agility is to make the coding phase of your existing process iterative. When you start the coding phase (or, in fact, any time during the coding phase), you should start producing customer-visible functionality in smaller, fixed-length iterations. As you continue with time-boxed iterations, you will discover other strategies to develop requirements and a quality design that will not require those activities to be separate development phases.

Starting with the coding phase also simplifies the transition toward agility because most of the coding and subsequent phases are internal to the development organization. Going to fixed-length iterations at that point does not require changing your relationship with external organizations like marketing and customers. They can feel comfortable that they have negotiated functionality in the same way they always have, which reduces the risk for them. Soon after you demonstrate the results of the quicker iterations, they will become comfortable with the new process and will be willing to accept more agile planning methods.

Taking this step will produce a fundamental change in how you do business. Remember that one of the prime motivators for fixed-length iterations was reduction in risk due to improvements in estimation. This change will cause you to make the leap from allowing scope to define release length to letting a fixed iteration length determine scope.

In each iteration, the goal is to produce some portion of actual functionality. This is a significant change in philosophy from the goal of passing milestones in a PERT chart. With each iteration, the only completed tasks that "count" are ones that produce customer-visible functionality. This doesn't mean that you don't have infrastructure-related tasks, but it probably means that those infrastructure tasks are smaller and are in direct support of visible functionality. For example, you won't have a task that implements the database-hiding layer in your architecture. However, if you are trying to allow the user to store and retrieve phone numbers, then you will have a task to develop the phone number portion of that layer. Remember: delivering functionality is the bottom line for your organization, so that's what you must focus on.

When you complete an iteration, let the team demonstrate the functionality to whoever seems most appropriate. Optimally, this demonstration should be made to the customer, but if that is not yet achievable, use management or marketing in that role. Although you need to be explicit about your understanding of the limitations of what you have developed, the demonstration is a ceremony marking the successes of the iteration. For teams that are used to waiting months or years to see the fruits of their labors, this meeting will allow them to feel the success of delivering actual functionality, which will give them motivation to continue to pursue the transition to agility.

With just this single change, the process now has a feedback loop. At the end of the first iteration, you can demonstrate functionality to the customer and receive feedback earlier. Now, instead of waiting through design, code, integration test, and system test for customer feedback, the customer (or someone representing the customer) can see actual product features very near the beginning of coding. This allows feedback and valuable insights into the direction that development should take. A fail-late process has become a fail-sort-of-early process (you'll do better soon!).

This new feedback loop is also critical to the rest of the transition process. With the advantage of almost immediate feedback, you will be able to make changes to the process while only risking one iteration of effort (as opposed to risking the whole project). The metrics generated by this feedback loop will enable you to evaluate the effects of those changes in weeks as opposed to months or years.

Clearly, this one process change is significant and includes some risk, but that risk is mitigated by two important choices we've made: we still have our requirements and design, and if things go south, we can fall back after only a few iterations.


Section 3.2. Plan and Release FunctionalityNot Components

3.2. Plan and Release FunctionalityNot Components

The key to agility is the goal of producing customer-visible functionality with every iteration. This means that we cannot plan the coding phase in the traditional plan-driven way. The pieces of work that we plan are not components.[1] Traditional planning would schedule engineers to work on individual parts of the system and, when they were complete, integrate them to make the system. For example, the plan would have one person (or group) develop a database interface while another person (or group) developed the GUI. Within each of these activities, people would be scheduled to develop (and maybe unit test) various classes. The weakness in this philosophy is that you don't really know whether something works until you integrate the components, so your feedback loop is very long.

[1] In object oriented projects, components are usually classes or packages, but the essential definition of a "component" in this context is a complete architectural portion of the system.

Instead of assigning people to individual components, agility requires that each planned activity have customer-visible functionality. To accomplish this, pick small pieces of functionality from your requirements document. It's likely that each of these is a "vertical slice" of your system and will require capability in components throughout your system. As shown in the following diagram, a customer-visible feature will require modification to or creation of a variety of components throughout the system. Because architectures are often considered to have layers, this is called a vertical slice.

Figure 3.2. A vertical slice of functionality

Even though it is tempting to schedule the components of a feature, do not. It is important that the engineers see that they are responsible for user-visible functionality. That is what connects the engineers to customers, and that connection increases your ability to deliver exactly what the customer wants.

When the team has picked a set of functionality that they believe they can complete in the time-boxed iteration, there is no need to schedule tasks of finer granularity. Let the team use any method they like to determine the components that need to be built and who will build them. Track progress only by functionality completed, and that will keep the team focused where you want them.

This strategy is making two important changes. First, the team's focus is moving from developing components to developing features. This is the key to agility. Second, the team is taking ownership for the development process, estimating effort, and scheduling tasks. This self-organization will be critical to optimizing the process and spreading agility beyond the coding phase of development.

It's important to point out that the change from planning by component to planning by functionality can be very threatening to some engineers. Engineers who have been developing within one part of the system may have to move out of their comfort zone. Although they can still focus on their portion of the system, they will have to work more directly with the rest of the system for the team to produce functionality. Some engineers will see this as an opportunity to influence a larger portion of the system, but others will react to this situation with trepidation. In the short term, you may be able to shield them from this change in philosophy. In the longer term, you might want to think about pair programming as a way to help them share their expertise with other engineers while extending their knowledge of the rest of the system.


Section 3.3. Example of Planning by Functionality

3.3. Example of Planning by Functionality

To demonstrate the difference between planning by components and planning by functionality, consider a project to build a tool to help individual investors track their stock market holdings. This application will allow users to enter information about their transactions and track the performance of their portfolios over time.

This system is likely to have an architecture made of three main components: the database, the business logic, and the GUI. The database will have to store information about stocks and mutual funds (names and price histories), lots (number of shares), and transactions (buys, sells, splits, dividends, transfers in, transfers out, etc.). There are many complex relationships between these items. If we keep daily price histories, this database could grow quite large, so it must be carefully designed. Similarly, the business logic for computing performance measures and managing a portfolio are non-trivial, and the GUI will have to not only allow the input of a wide variety of types of information but also clearly display statistical histories to allow the user to evaluate the performance of his portfolio.

The traditional way this project would be planned is based on the components that need to be developed. First, we would probably plan the three parts of the system somewhat independently,[2] so there would be database tasks, business logic tasks, and GUI tasks. Within the database tasks, we would see tasks such as "build the stock table" and "code the API to the stock table." Similarly, within the GUI tasks, possible tasks would be "code the stock purchase screen" and "code the market value chart screen." With tasks that are based on these architectural components, a task is "finished" when the developer says it is complete (or it passes some sort of review), but at that point, there is no way of knowing whether the code is complete (or functional).

[2] In fact, often the team is divided into sub-teams by these components, and although the sub-teams talk with each other, their deliverables are rarely explicitly connected on the plans.

Instead of planning by components, agile teams plan by functionality. At the beginning of the iteration, small pieces of functionality are selected and planned. For this example, an iteration might include functionality like: the user has to be able to purchase a stock that has already been entered into the system. Clearly, this will require development in all three architectural components of the system. For example, the database component will need to develop the API for a buy transaction (but not the rest of the transactions) and the API to create a stock lot (but not delete it or update its value over time). Similarly, the business logic component needs the error checking on the validity of a buy transaction but not the ability to track its performance over time. The GUI will require the development of a screen to allow the user to input the information about the purchase, but the rest of the application around that screen may be non-existent or mocked up if it hasn't been previously developed. The team may choose to specify and schedule these sub-tasks, but they do not have to. None of these sub-tasks is considered complete until the entire piece of functionality can be verified.[3]

[3] Given the specification of this task (which has no output required), the functionality can be shown to be complete by demonstrating that the data gets stored properly in the database by hand, if there is no existing GUI to show that.

There are two critical differences between planning by functionality and planning by component.

First, although individuals may be working on particular parts of the system, the goal is to produce the required functionality, and each engineer knows exactly how his code fits into that functionality. The engineer who is building the logic for the buy transaction in the database will know exactly how that interface will be used by the business logic in response to a particular input from the GUI. Second, no task is complete until the functionality is demonstrated, but because the functionality is relatively small, that will happen during this iteration. This ensures that not only are the individual components coded, but they also work together to make a functional addition to the system.


Section 3.4. Is It Refactoring or Rework?

3.4. Is It Refactoring or Rework?

Plan-driven methods were specifically designed to prevent rework and were based on the philosophy that if we planned carefully enough, we could ensure that the first time we developed the code it would be correct. Another way of looking at this was that the cost of a change to the system was thought to increase as the project progressed. Clearly, if we develop the system in iterations and specifically do not plan for subsequent functionality during those iterations, we will have to modify and possibly completely replace our code later in the project. This is something agile methods must address.

The first strategy for addressing rework is to modify the process so that the cost of a change is relatively constant throughout the development process. Much of the increase in cost that plan-driven methods experienced came from two sources: updating the documentation and the risk of increased defects resulting from undetected side effects of the change. Both of these costs increase as the system grows. Agile methods such as automated unit and acceptance tests and generation of documentation from the code are designed to reduce the costs and risk of rework so that they stay relatively constant throughout the project.

At the beginning of the transition to agility, you will have a design document, and as with the beginning of the implementation phase of plan-driven development, the code you develop should be driven by that design. This gives your code the longer-term perspective that most agile organizations require. As a result, the amount of rework that you need in early iterations will be low. However, as the system grows, the design of the code will deviate from the planned design. By that time, your team will need to develop skills and you will need to optimize your process further to maintain the quality of the design into the future.

The consistency of the cost of rework opens opportunities for improving the quality of the system. In all projects, plan-driven or agile, the quality of the code degrades if changes are introduced without considering the effect those changes have on the overall design of the system. Each change only increases the complexity by a small amount (an extra parameter here, slightly tighter coupling there). As we make more of those changes, however, the overall design of the system becomes increasingly complex and convoluted. This is known as software rot. Essentially, as we continue to add functionality to the code, it becomes increasingly fragile. This is a symptom of design debt, which is much like regular debtit accrues interest over time. Eventually, design debt must be paid back. Many projects have declared design bankruptcy and redeveloped their system from scratch. (Kerievsky[1] offers an excellent discussion of design debt.) Particularly in agile projects, it is critical that the team keep an eye on the overall design of the system; they must clean up (refactor) the code and pay back that design debt as they progress. The tests that we have developed in this and previous iterations[4] can provide a safety net so that we can make changes with minimal risk.

[4] The assumption here is that there was some existing unit/system test capability, and you must maintain that. The refactoring "Automated Unit Tests" will help you improve the robustness of those capabilities to support your refactoring activities.

Reeves[2] gives an alternative view of the development process. He compares developing software to building a bridge. When engineers design a bridge, they build many prototypes and refine the design until it specifies every bolt in the bridge. As the design increases in detail and prototypes are built, the engineers learn things that make them revise the design. When that process is complete, they pass the plans (the design document) to the bridge builders.

Reeves parallels this to software development where we can build prototypes and revise the design of the system to the same level of detail as the bridge builders (essentially to the point where building it is deterministic). The only specification Reeves could find that met that level of detail was the source code itself. Therefore, he postulates that the design process continues throughout the development of the source code. Essentially, the intermediate coding steps are prototypes from which we learn and improve the system. The only difference between this and bridge building is that we can build our systems many times a day because it only requires running the compiler, whereas bridges can only be built once. This difference means that our prototypes and our resulting product are built from the same specifications taking on the same form. We just need to remember that prototypes may require redesign before they can be products.

Reeves' argument holds whether the process is agile or plan-driven. He is arguing that the design thought process does not end with the traditional design document but goes on throughout the coding activity. Techniques like source code refactoring help us efficiently execute the redesigns and lower their risk.


Section 3.5. Preparing for Changes That Affect External Entities

3.5. Preparing for Changes That Affect External Entities

Although iterations within the development cycle can be internal to the development organization, connecting to the customer at this level requires external changes as well. In the long term, the way you communicate with upper management, quality assurance, and even human resources will change. Although those changes may take time, laying the groundwork now is important.

It is likely that the first externally visible change will be in the structure of the plans and status information that you share with management. You will no longer produce a detailed PERT chart showing the development of components and their integration. In fact, you won't want to show a long-term plan at all. This isn't going to be well received without some preparation! The best strategy for exposing this change is to give the new types of information in parallel with the old types. For example, if you have been responsible for producing a plan that included milestones and deliverables for the entire project, continue to do that (with possibly less attention to detail). In addition, report on the features planned for the current iteration or, better yet, those completed in the last iteration. After a few iterations, management will be much more interested in those feature lists (and priorities) than with the updated PERT chart. Soon the PERT chart will become unnecessary.

As these changes become more visible, people outside of the team will become interested in understanding the new agile process. Try to share information as much as possible. If you have a stand-up meeting in the morning or you run information/training sessions for your team, invite others to observe. You should open your planning sessions for observers and share your feature development status with anyone who is interested. The goal is to be as open as possible about this change. You need to advocate for agility by making sure that people understand the motivation behind time-boxed iterations and the goals that you have for making the change.

This change will seem very foreign to many people. Most people have been trained in the motivations behind plan-driven methods and why those methods should be superior to ad hoc development. There is a risk that people will think you have thrown away your process and are just hacking code. Part of the motivation for going to time-boxed iterations during the development phase is that you still have the results of requirements analysis and design. This should reduce the appearance that you are hacking code.

Wherever possible, demonstrate the discipline your team is using and the benefits this change causes. You can do this by showing deliverables that meet standards (design documents, code, etc.), by tracking metrics like code complexity and defect rates, and by demonstrating the robustness of the delivered functionality.


Section 3.6. Common Pitfalls of Phase 1

3.6. Common Pitfalls of Phase 1

There are three common mistakes that teams make during this first phase:

  • Scheduling components

  • Making the iteration length too long

  • Not closing the iterations

3.6.1. Scheduling Components

The biggest challenge in Phase 1 is learning to schedule functionality instead of components. One company making this transition selected functionality for each iteration but continued to schedule individuals by the components they were to produce or modify. The project was a subsequent release of an existing product, and their team had roughly 30 engineers who were divided into sub-teams matching the architecture of the system. As a result of that organization, the engineers had "specialties" and knew very little about the other portions of the system. Therefore, management thought that they had no choice but to divide the functionality into tasks for each sub-team. This meant that although the team was supposed to be delivering functionality, the individual engineers were still delivering components.

One of the important effects of scheduling functionality is that it connects every engineer with the customer. That makes the feedback that the team receives at the end of the iteration relevant to every engineer. Also, each engineer becomes aware of how his efforts and challenges affect the team's ability to meet the iteration's goals. In this situation, because the engineers were assigned to work on components, they never connected with the customer and did not see specifically how their activities affected the team's ability to meet its goals.

What alternatives could this team have used? The first thing to notice is that not all team members were involved in dividing functionality into tasks; the team leaders created the list of tasks that would be needed to deliver the functionality. This essentially shielded the team from the customer. Scrum advocates letting the team determine how the work will be accomplished. In this case, that means that the iteration's goals are given to the team, and all 30 engineers work together to figure out how they will accomplish those goals.

The size of the team made holding a single planning session that included everyone inefficient. Another alternative would have been to assign pieces of functionality to new cross-functional sub-teams. Each sub-team would have engineers who specialized in each portion of the system, and each sub-team would be given a subset of the team's iteration goals. From that point, each sub-team would be allowed to self-organize to accomplish its task. It is highly likely that the sub-teams would divide the functionality into tasks matching the architecture and the engineers' specialties. At this point, they would be scheduling components, but there is a significant difference: each engineer would see how his tasks fit into producing the customer's functionality goals. That would connect them with the customer. Also, because these smaller teams would be cross functional, and because they would be designing solutions that affect the entire system, it is likely that the knowledge about the different parts of the system would be shared, and they would become more facile with parts of the system outside of their specialties. Over time, their need to divide functionality into components would decline, and they would learn to stay focused on the customer functionality in the iteration goals.

The bottom line is that we want every engineer to be directly connected to the customer and the goals of the iteration. By scheduling only functionality and letting the engineers divvy up the work from there, even if the engineers end up working on individual components, it will keep the customer focus and connection that agility requires.

3.6.2. Making the Iteration Length Too Long

One team started this transition by selecting three-week iterations. They selected that length because they thought that would let them deliver enough functionality to impress their customer. They tried this for two iterations without success. In both cases, they made optimistic estimates (to try to increase how much they could promise their customer), overbooked their engineers (thinking that everyone codes for 40 hours a week), and overlooked some critical overhead in their process (their configuration management system required some serious hand holding to actually deliver the product).

After two iterations that didn't meet their goals, they knew they had to change something. Unfortunately, they decided that they had made too big a leap and changed the length of their iterations to five weeks.

The point that they missed was that those first two iterations had given them excellent feedback. If they had looked into the sources of their problems, they could have made changes to their process that would have increased their odds of success in the future. Instead, they fell back into their old ways by making the iterations longer.

The sad side effect of this change was that they made the iterations long enough that they could never complete one without replanning. Inevitably, before the five weeks were up, the customer would want something new, and they would replan. From that point, every time they missed a delivery (which was every iteration), they blamed it on changing requirements from the customer and therefore never really made much progress on improving their process.

The lesson here is that failing to meet the goals of an iteration is an opportunity for improvement. Look carefully at how the goals were set and what happened within the team during the iteration to find the sources of the problems. That's the best way to improve your ability to meet the goals of future iterations.

3.6.3. Not Closing the Iteration

A startup company that had grown from two to six engineers used this philosophy to transition from an ad hoc process to something with more structure that would not damage their ability to deliver functionality quickly. Initially, the team seemed to take to agile planning quite easily. They generated a set of story cards containing pieces of visible functionality and estimated and prioritized them. They even picked a set of cards for their first iteration.

However, in that first planning meeting, there were clues foreshadowing the problems they were going to have. One of the key engineers was going on vacation, so instead of two weeks, they decided to make the iteration last three weeks.

At three weeks, one of the lead engineers was saying, "We're going to close the iteration soon. The wife of one of the guys is having a baby, so we're waiting for him to get back." At four weeks, he was still saying that they were going to do it soon. At this point, they were well past developing the functionality that was to be scheduled into the first iteration and were just picking the next card off of the prioritized list to keep working.

They had made one significant changethey were scheduling by customer-visible functionality. However, they were definitely not working in fixed-length iterations. Instead, their plan had essentially degraded into an (almost endless) to-do list! They had not met the goals of the first phase of the transitiona problem they eventually repaired.

Let's think about what this team lost by not closing out one iteration and starting another: feedback! Closing out one iteration is a time for two very important kinds of feedback. First, we get feedback from the customer about the functionality we have delivered. All engineers get to see the customer's reaction to the functionality they produced, so they will understand the motivations for the functionality selected for the next iteration. Second, we get feedback on the process. Closing out the iteration is a time for the team to stop and think about how things went and what they would like to do differently in the next iteration. Remember Herbie and the Boy Scouts in the woods. Closing out the iteration creates a clearing along the path where we rethink our progress and prepare for the next section of the path. Team introspection is a critical part of improving our agility (and quality and happiness and...).

Although closing an iteration is important, starting a new one is also important. Letting the customer select the functionality for the next iteration gives everyone an opportunity to revisit that prioritized wish list of functionality. During that review, it is likely that things will get reprioritized, reestimated, deleted, or added. So starting the iteration gives us a chance to ensure that we are working on the most valuable functionality possible.

There is another benefit of closing out one iteration and starting another: rhythm! One of the things that makes agile teams efficient is that their life has a repeating rhythm to it. They learn how much functionality they can produce in that fixed amount of time and where they should be at various points within the iteration. They learn to foresee problems early and develop strategies for adjusting.

Finally, perhaps the most important benefit of closing iterations is to give the team a sense of accomplishmenta milestone of achievement to propel them along. Instead of working on an endless to-do list, the team has achieved the goals of this iteration and is prepared to embark on the next one.

This team's problem is rooted in the fact that they are a startup. They often work strange hours and are under pressure to produce some income, so they see anything that takes them away from their computers as detrimental to their productivity. Although they say they believe, the bottom line is that they did not yet see that the time spent closing one iteration and starting another would be recovered by the improvements that result from those activities.


Section 3.7. Evidence That Phase 1 Is Complete

3.7. Evidence That Phase 1 Is Complete

There are only two requirements to complete Phase 1: planning in fixed-length development iterations and delivering functionality instead of components. When you have completed at least one time-boxed iteration where you can demonstrate customer-visible functionality, you have completed Phase 1.

Remember that you must continue to focus on moving toward agility. Under pressure, it's normal to revert to your usual behavior, so continue to make decisions based on this question: Which option puts more functionality in my customer's hands at the end of this iteration?

The risk that normally comes with developing functionality in iterations is that the design of the code will degrade as changes are layered on top of each other. In the long term, you will use agile techniques like source code refactoring and automation to reduce this risk, but at this phase of the transition, you still have designed the system in the traditional way, so your code should be structured to allow those subsequent modifications. If you start seeing the quality of the design degrade, look to source code refactoring to help you resolve those issues.


Section 3.8. References

3.8. References

[1] Kerievsky, Joshua, Refactoring to Patterns, Upper Saddle River, NJ: Addison-Wesley, 2005.

[2] Reeves, Jack W. , "What is Software Design?" C++ Journal, Fall 1992.


Chapter 4. Phase 2Measuring the Process

Phase 2 of the transition toward agility is to implement some basic measurement of the process. Watching a few simple metrics over time will help the team know their capabilities and recognize potential optimizations to the process. It is true that people with experience in these areas can make some recommendations to the team based on their intuition, but these metrics will help even the inexperienced team focus on changes that will have maximum impact. The purpose of this phase is to add some detail to your feedback with carefully selected metrics.

Figure 4.1. Phase 2measuring the process

[View full size image]

This chapter explains not only the need for metrics but also some metrics specifically designed to help the team succeed. In addition, it gives ideas on ways to keep these measurement activities from requiring an undue amount of effort. As with all activities that agile teams undertake, we need to be sure that the time we spend on metrics activities is well spent and worthwhile.


Section 4.1. Using Metrics to Affect Behavior

4.1. Using Metrics to Affect Behavior

Metrics are essentially statistics that measure some aspect of our development process or the things we produce. Although there is a wide variety of interesting metrics, they can be divided into two categories: those that are fixed for a given iteration and those that the team can influence. For example, staff days per iteration is generally fixed at the beginning of the iteration,[1] but the amount of functionality the team can produce (this is sometimes called the team's velocity) is not fixed. Instead, the velocity is a measure of how the iteration is going (or how it went). The metrics that are fixed don't give us information about how the process is going, so we want to focus on metrics that the team or process can influence.

[1] Yes, we can hire more people in the middle of an iteration, but usually either we know they are coming or they arrive too late to be useful. Either way, their arrival doesn't change the plan in the middle of an iteration.

There is an old adage (whose source I cannot find) that says, "Tell me how you'll measure me and I'll tell you how I'll behave."[2] Metrics that affect behavior have been called biased metrics [5]. As an example of a biased metric, many teams track the number of running, tested features (RTFs)[4] in their system. This is a great way to get the team to focus on delivering functionality. In addition, RTFs decline if the functionality we add in this iteration causes existing features to no longer pass their tests, so there is a quality aspect to this measure. A chart showing this value over time will help the team focus on activities that are valuable.

[2] My father claims this quote is his and that its root is in how he raised me, but I think it originated with someone more famous than he!

However, using metrics to influence behavior must be done carefully, or you may get unexpected behavior. One company that was interested in training attempted to measure managers by the average number of hours of training his employees received each quarter. They also tracked overhead costs (of which training was a part) as a performance measure. As a result, some managers selected cheap training opportunities even if the person had received that training in the past. Clearly, these metrics were not causing the intended behavior.


Section 4.2. Agile Metrics Philosophies

4.2. Agile Metrics Philosophies

It is very easy for the activity of gathering metrics to take on a life of its own. In keeping with agile philosophies, we need to keep our metrics activities as lightweight as possible. We don't want to spend a lot of time gathering data, analyzing the data, or sifting through results. These guidelines will help keep our metrics activities in check:

  • Napkin metrics Every metric should be simple enough that you can explain its computation on a napkin in the cafeteria. Anything more complicated than that is likely to be gathered incorrectly or misunderstood and therefore used incorrectly. If your metrics become too complex, take a step back and rethink! There's probably a simpler metric that will reflect whatever aspect of the process you are analyzing.

  • Simplify data gathering Most data that you need for metrics can be gathered as a part of other activities. Valuable data can be found in your accounting department, your defect database, your customer service center, and your configuration management system[6]. See whether your build process, your defect-tracking tool, or your planning process can gather the data for you. If you're interested in the rate at which the system (or any part of it) is changing, put a script into the build process. If you want to track the time spent on each task, make it easy for the engineer to jot a value down when she's marking the task complete instead of making her track it through the week to put it in a report at the end of the week.

  • Rough numbers are good enough Always think about the precision (or lack of precision) that you need in the data you gather. Often, it's easier to gather coarser data without distorting the conclusions you draw. For example, a car speedometer has a 10% error rate, but it's good enough to keep us from speeding out of control. Engineers can report time spent to the half-hour a lot more easily than to the minute. If your estimation granularity is to the half-day or even to the hour, then reporting time spent to the half-hour is quite sufficient.

  • If it isn't changing, who cares? When you initially pick a metric whose goal is to change some behavior, its value should change over time. However, at some point, the team will have done all it can on that particular issue, and then the metric will level out. At that time, there's no longer any point in gathering and tracking that metric (though you may want to bring it back again at a later date). Similarly, metrics whose values are always 0 or 100% aren't useful either.


Section 4.3. What Is "The Goal"?

4.3. What Is "The Goal"?

The Goal [3] is an interesting and readable novel that helped revolutionize the manufacturing industry in the 1980s. It chronicles the turnaround of a manufacturing facility. It starts by showing a plant that is wildly out of control, unable to ship products anywhere near schedule and driven by the issue of the moment instead of a plan.[3] A guru guides the plant manager by asking leading questions and helping to define the metrics that drive the recovery. In addition to being insightful for manufacturing operations and offering many other management strategies, it is an excellent example of how the selection of appropriate metrics drives people to change behavior and move toward achieving "the goal."

[3] Sounds like a lot of software development projects I've worked on!

Although The Goal is set in a manufacturing facility, the process that enables the characters to save their facility (and jobs) is instructive. As with software engineering standards, manufacturing is a disciplined and metric-driven process. Applying a similar process to the definition of metrics to measure software development activities can lead to non-traditional metrics that can have important effects on development processes.

4.3.1. Goal Metrics for Any Business

For every viable business, the root goal of the organization is to make money. To measure our progress against that goal, we need metrics that measure against it.

Net profit is a metric that clearly correlates to the goal of making money. It is a good metric in that it is well defined and well understood, and the data it requires is generally available.

However, increasing net profit is insufficient to ensure that the organization is maximizing its profitability. Suppose you are considering making two changes that have the same effect on net profit. You would want to choose the one that requires the least investment. For example, if the changes were going to raise profits by $100 per month, but they required $1,000 and $5,000 respectively, it would be wiser to select the first change. The selection of changes becomes murkier if their effect on net profit and their investment costs differ. This can be addressed by selecting return on investment (ROI) as our second metric.

Net profit and ROI are insufficient to ensure success alone. Businesses that in the long term would have high net profit and ROI fail for lack of the cash necessary to execute their plan. Therefore, we need cash flow as our third metric.

Our strategic metrics are net profit, ROI, and cash flow. If we can increase the values of all of these metrics, our organization is moving toward the goal. However, it is important to note that we cannot optimize one or two of the values by sacrificing the others; raising net profit and cash flow at the cost of lowering ROI will not lead to long-term success.

4.3.2. Redefining the Metrics to Guide Behavior

Net profit, ROI, and cash flow are good metrics to measure the organization as a whole, but they have a serious weakness. It is difficult for people within the organization to see how their day-to-day decisions and behavior affect those organizational-level metrics. The day-to-day decisions are specific to the responsibilities of a relatively small portion of the organization. We need to find metrics that are equivalent to net profit, ROI, and cash flow but that relate more directly to the behavior of individual employees.

Consider these alternative metrics[3]:

  • Throughput The rate at which the company generates money through sales

  • Inventory Money that the company has invested in purchasing (or building) things that it intends to sell

  • Operational expense Money spent in order to turn inventory into throughput

If we can raise throughput, lower inventory, and lower operational expense, that would be equivalent to raising the three original metrics. Again, improving one of these metrics must be achieved without sacrificing either of the others because success depends on all three.

4.3.3. Connection with the Customer

The connection between our organizational metrics (net profit, ROI, and cash flow) and our more detailed metrics (throughput, inventory, and operational expense) is critical to making sure that every employee is working to the benefit of the overall organization. However, that relationship has an important side effect: at some level, it connects every employee with the customer. For example, in order to improve throughput, every employee must be aware of what the customer will buy and how their behavior is likely to affect a customer's urge to make a purchase. That connection with the customer is necessary to ensure that everyone is working to the maximum benefit of the organization.

In a plan-driven environment, there is very little connection between the team and the customer. A plan-driven development team talks with the customer rarely, if at all, and because the "orders" that the customer places are large (at least a release at a time), the team does not get the customer's perspective on the relative value of the features. The agreement is to produce features X, Y, and Z, but the team doesn't know which feature interests the customer the most. Conversely, an agile team has regular conversations with the customer and can see the relative value that the customer places on the various features. Appropriate metrics will only strengthen that connection.


Section 4.4. What Should We Measure?

4.4. What Should We Measure?

We have three metrics that measure the viability of any business:

  • Throughput The rate at which the system generates sales

  • Inventory The cost of anything you've built (even part way)

  • Operational expense Money spent to turn inventory into throughput

However, these metrics are difficult to connect to the activities of software development. We can start improving them by adding some detail specific to software development organizations:

  • Throughput The rate at which we generate income by selling the software we build

  • Inventory The money spent in development of functionality the customer has not yet purchased

  • Operational expense The cost to complete the development of the functionality required by the customer

We'd like throughput to go up while inventory and operational expense go down. However, these specific measures won't be particularly meaningful to the development team, and the team members won't feel a strong ability to influence them, so we need to go further.

For throughput, we need some measure of how the functionality we are developing relates to sales. Many agile teams have started estimating throughput using Ron Jeffries' Running Tested Features (RTF) metric[4]. This is a count of the number of features currently passing their acceptance tests. It is a great metric for helping your team to focus on producing customer-visible functionality instead of components.

However, RTF does not address the relative values of those features. Each feature adds one to the count regardless of the value the customer places on that feature. When applied within XP or Scrum where the planning process prioritizes customer requests, RTF might be sufficient. However, directly measuring the value of each feature would result in a more accurate estimate of throughput. In order to achieve that, each feature (story, user request, etc.) must be given a measure that reflects how much revenue it will generate. We call this metric "bells" (from the phrase "bells and whistles," meaning features that excite the customer).

Bells is a relative measure on a scale from one to five[4] reflecting the revenue the feature should bring. For a single customer operation, bells reflects the amount the customer would pay for the feature, with one meaning that the customer would pay very little and five meaning that the customer would pay a lot (or wouldn't buy the product without that feature). For a retail product, the number of bells that a feature is given reflects the extent to which the feature will attract new customers or upgrades from existing customers. For example, a feature that distinguishes your product from your competitors' and is highly attractive to your market audience would get five bells; a feature that is useful but unlikely to motivate many people to move to your next release would get one or two.

[4] XP already has the customer ranking the priority of stories on a scale of 1 to 3, but that ranking is not usually used in this manner. The scale of 1 to 5 gives a little more granularity to what is still a relatively subjective measure.

Now that we have a measure of the value of each story, the number of bells delivered per staff day approximates throughput (the rate at which we generate revenue). That's one metric definedtwo to go!

In the context of software development, operational expense is reasonably constant because it is dominated by personnel expenses that are determined almost entirely by the number of engineers on the team. In this case, the question isn't really how much we spend on the team, but how well we use those resources. We can account for operational expense if we have a measure of the efficiency with which we use our engineers. As efficiency goes up, our throughput increases while our operational expense stays the same. This would achieve the goal of an increase in ROI.

In order to plan, every feature (or story) must have an estimate for how long it will take to complete. Two units of measure are used for these estimates: ideal engineer hours and story nuts. Story nuts (which have been called many other things, including gummy bears) is a relative measure of effort, often on a scale of 1, 2, 4, and 8.[5] Ideal engineer hours is the number of hours the engineer estimates it would take if he had no interruptions and the design of the system supported the change he plans to make. In either case, these estimates give us a measure of the ideal effort each story requires. Given either story nuts or ideal engineer hours as ideal effort, our measure of efficiency is ideal effort per total staff days. As an example, the time an engineer spends filling out a complex status report will count as staff days but will not produce any functionality. This will reduce our efficiency.[6] That's two metrics definedonly one more to go!

[5] The logarithmic nature of this scale reflects the fact that people are better at estimating whether one thing is twice as big as another than at estimating on a linear scale.

[6] We'd better be sure that the report is useful because it isn't helping our efficiency!

The third metric we need to worry about is inventory. In software development, inventory is reflected by the amount of time from when we start working on a feature until that feature is delivered. The longer that length of time, the more inventory we will accumulate. Consider what happens as the length of an iteration increases:

  • Our feedback loop from the customer is lengthened. This means the effect of misunderstandings with the customer is increased. We can accidentally spend more time on a feature that isn't exactly what the customer wanted before recognizing the mistake.

  • The size of features we are going to accept is larger, so our estimation errors are going to be bigger. This means that we're likely to have to spend a higher percentage of time replanning.

  • If there is a problem with a feature, the length of time since we wrote the code is proportional to the re-learning that will have to be done to fix the problem. So fixing problems is more costly.

  • If the customer is unable to wait until the next iteration, we may have to replan to incorporate new requests in the middle of an iteration. If the iteration length were small enough, we could defer all requests until the next iteration.

  • Finally, if the iteration length gets too large, the customer's needs change, and he won't want the feature by the time we can deliver it.

These points show that in some ways, efficiency is affected by inventory, but making inventory explicit will help us focus on delivery speed.

Our metric reflecting inventory will be iteration length.[7] Lowering iteration length is equivalent to lowering average inventory. Although short iterations are the ideal, every organization has a limit for the minimum iteration length they can handle. In general, the iteration lengths are not shorter than a week; the overhead of planning and closing out an iteration makes iterations shorter than a week inefficient. However, delivering every week requires skills such as defining small stories, test-driven development, and source code refactoring. When you are transitioning to agility, it is unlikely that your team will have these skills. As they are learning the skills required by agility, the process must continue to have some plan-driven activities, and these will reduce the team's ability to deliver rapidly. This means that the initial iteration length will be longerperhaps a month or six weeks. Tracking iteration length as a metric reflecting inventory will encourage the team to look for ways to improve their ability to deliver quickly.

[7] This matches the manufacturing metric of cycle timethe time it takes to answer a customer request.

We now have three very dynamic metrics:

  • Throughput Bells per staff dayA measure of the rate at which we produce customer value

  • Efficiency Ideal effort completed per staff dayA measure of how efficiently we utilize our resources

  • Iteration length[8] Elapsed time of an iterationA measure of how quickly we can respond to a customer request

All of these metrics measure the performance of the team in its current environment (process, organizational structure, equipment, etc.) but reflect things that individual engineers understand and deal with daily. In fact, engineers are likely to have lots of suggestions for how to improve these metrics and are generally motivated to do so because the metrics reflect the quality of the environment around the engineers. For example, efficiency may be low because the configuration management system creates a bottleneck and stalls the engineers. They can recognize that situation and offer suggestions for how the problem could be resolved, and those resolutions would have a positive effect on efficiency. In addition to improving efficiency, that change also has a direct and positive effect on the engineer's environment.

We must note one important thing. Throughput is a better team metric in the short term than in the long term because there is a chance that throughput will decline as the project progresses. It may be that a number of highly valuable features that are relatively easy to develop[9] will be selected early in the project. This will lead to high early throughput. As the project progresses, stories may have lower value-to-ideal-effort ratios, which will result in lower throughput, but that change does not reflect poorly on the team. In effect, as throughput declines, it may very well indicate that the project has reached a point of diminishing returns. It can be a sign that the project should be terminated. Even though it may decline over time, the purpose of tracking throughput is to strengthen the connection between the team and customers. On any given day, the team can weigh decisions against the impact they will have on short-term throughput without worrying about its long-term decline.

[9] These are known as "low-hanging fruit." Apples that are easy to pick require less effort but are as valuable as the apples at the top of the tree.


Section 4.5. Techniques for Defining Other Metrics

4.5. Techniques for Defining Other Metrics

In addition to the overall metrics of throughput, efficiency, and iteration length, you will want to define metrics to measure specific aspects of your process. Definition of metrics is fraught with challenges, and poorly defined metrics can be detrimental to your organization. This section defines some techniques to help you define useful metrics.

4.5.1. Goal/Question/Metric

Goal/Question/Metric (GQM)[1] [2] is a structured method that helps ensure that the metrics you gather support your improvement activities. A plethora of metrics becomes available to you when you notice the data that you are already gathering. However, it is important that the metrics activity focus on improving your knowledge or improving the process. If it does not, the numbers will quickly become overwhelming, will require significant time to analyze, and will not be valuable for the organization as a whole.

In GQM, the metrics are defined in a top-down fashion. First, you specify the goal of this metrics-gathering activity. A goal specifies four details:

  • Purpose The purpose of this activity, which is usually "to improve" or "to report"

  • Object (Process) The part of your system or process that is under consideration

  • Issue The aspect of the object that is the focus of this activity

  • Viewpoint The perspective from which measuring should occur

For example, a goal could be "To improve [purpose] the accuracy [issue] of our task estimates [object] as seen by the development team [viewpoint]."

After the goal has been set, we develop a set of questions that helps us clarify the current state of that object and its performance. These questions come from three general areas (the sub-bullets are example questions that might be developed for the previous example goal):

  • How can we characterize the object with respect to this goal?

  • What is the current process for making estimates?

  • To what extent is the current process being followed?

  • How can we characterize the attributes of the object that are relevant?

  • What is the current error in our estimates?

  • What is the standard deviation in our estimate errors?

  • What percent of our estimates have errors that are beyond three standard deviations from the mean?

  • How do we evaluate the characteristics of the object that are relevant with respect to the issue?

  • Is there a trend in the error of our estimates? Are they improving or degrading?

  • What level of accuracy does the development team think is an appropriate target?

After the questions are complete, appropriate metrics can be defined for each question. Note that some of the "metrics" may be subjective and based on people's opinions about a situation. Sometimes that is the best way to answer the given questions. There may be historic data in your build process, defect tracking, or time tracking systems, but do not limit the options to those sources. Be sure that you select metrics that will give honest answers to your questions. You may also find that the same metric answers multiple questions.

4.5.2. Strategy vs. Tactics

The metrics discussion in Section 4.3, "What Is the Goal?" demonstrates a critical factor in the definition of metrics: the difference between tactics and strategy. The first metrics (net profit, ROI, and cash flow) are excellent metrics for the organization as a whole and provide a strategic vision for the organization, but they need to be translated into something relevant to the work of the employees in order to allow everyone to make tactical decisions that support the strategic vision. This distinction between strategy and tactics is critical to developing useful metrics.

When management wants to set a goal for the team, they can set strategic metrics. These metrics reflect the long-term goals of the organization. However, tactical metrics that support that long-term vision must be defined on a level that is relevant to the team. In fact, you are more likely to achieve your goals if you let the team define those tactical metrics.

For example, management in a retail software company may have a vision that requires a high level of customer satisfaction and may choose to measure that through a customer satisfaction survey. The team cannot affect the results of the survey directly, but they could choose tactical metrics like defect rates and bells per release in support of that long-term vision.

If an organization has more than two levels, the highest level defines the strategic metrics for the entire organization. The tactical metrics for each level become the strategic metrics for the next level of the organization. The following diagram provides an example of how an organizational strategic goal of customer satisfaction ripples through the organization.

Figure 4.2. Strategic and tactical metrics ripple through an organization

[View full size image]


Section 4.6. Deploying Metrics

4.6. Deploying Metrics

4.6.1. Team vs. Individual Metrics

One of the critical things to watch as you deploy metrics is whether you will measure the entire team or individuals. Remember that the performance of the team as a whole determines the team's success level, so we must gather team metrics. Most agile organizations only measure at the team level because the cohesiveness of the team is critical to its success and applying metrics at an individual level can undermine that cohesiveness.

If one member is not performing, the team will recognize that situation without metrics and should manage it themselves as much as possible. Often, applying metrics at an individual level can be seen as punitive and arbitrary. For example, if we used throughput to measure an individual, the metrics may imply that the people who took on the challenging tasks were not performing well. Although that example seems extreme, very few metrics capture the value of an individual team member accurately. I know of a company that measures individual engineers by lines of code produced, presumably with the goal of increasing the amount of software delivered. This is an excellent example of an arbitrary metric that engineers will resent and that will not achieve its goal. In addition to discouraging refactoring (which could reduce the total lines of code), this metric affected the tasks that engineers wanted to work on (easier tasks that required only copy-and-paste code were preferred). The result was tension within the team.

When you use a metric to measure an individual and that metric does not reflect that person's role in the organization, the metric is seen as arbitrary and is unlikely to cause the desired behavior. In the team that was measured by lines of code, the senior engineers who spent a good portion of their time mentoring the junior engineers and guiding the architecture of the system were unfairly punished by this metric.

However, all caveats aside, most organizations require some performance measurement on an individual level for annual performance reviews. If you must have a numerical or objective measurement of an individual, do not use the same metrics you are using to measure the team. Instead, let the individual help you define the metrics that will be used to measure him. For example, an engineer who is aspiring to technical leadership may want to be measured by the number of design decisions he participates in or the complexity of the tasks he undertakes. Another engineer who wants to expand his knowledge of the entire system may want to be measured by the number of classes he modifies throughout the year. In both of these examples, the individual metrics are tactical in nature, and the process by which you define these metrics can ensure that they support the team's strategic metrics of throughput, efficiency, and iteration length.[10]

[10] Note that metrics that were tactical for the team in support of the organization's strategic metrics have now become the team's strategic metrics with individual tactical metrics. This cascade of metrics can flow through many levels of your organization. The top layer defines strategic metrics, the next defines its tactical metrics, and those tactical metrics become strategic metrics for the next level down the organization.

4.6.2. Side Effects and Risks of Metrics

Definition of metrics requires careful consideration because metrics can have unexpected side effects. For example, one organization I worked with measured engineers by the number of defects they repaired. The goal was to reward the engineers who fixed problems. However, defects were often assigned to the engineer who developed the code. This meant that the metric inadvertently rewarded the engineers who created defects.

When you define a metric, you have to consider the behavior that would maximize or minimize its value to be sure that you will achieve your goal. In addition, be very careful about the interactions between metrics. There are times when improving the value of one metric will cause the value of another metric to degrade. Often letting the team set its own tactical metrics can eliminate these situations. Given strategic goals, the team knows best how to measure their performance against those goals, and if they understand the motivation for the metric, they are more likely to behave in support of the goal.

It is also important to be very careful about your definition of a metric. It must specify how the data will be gathered and analyzed to compute its value. This specification should also include the rate at which the metric will be measured. For example, if it will be part of a quarterly report, specify that the data will be gathered weekly and that the report will contain the data available one week before the report is complete. This will help ensure consistency of the metric's value over time and across the organization if necessary. Consistency will be critical because you will want to evaluate trends in these numbers so that valid conclusions can be drawn.

The underlying goal of any metrics activity is improving performance. Because metrics will drive decisions, it is critical that you define them carefully, gather them consistently, and watch for unexpected side effects. As with all agile activities, you don't define metrics once and leave them for eternity. You should always be watching those definitions and adjusting them as your organization changes.


Section 4.7. Conclusions

4.7. Conclusions

For Phase 2 in the transition to agility, the team's strategic metrics are

  • Throughput Bells/iteration

  • Efficiency Ideal hours/staff days

  • Iteration length The length of time between planning sessions

To complete Phase 2, you must be gathering these metrics and reporting their values at the end of each iteration. Watching them over time will help your team improve their agility.

In addition to these three strategic metrics, the team may want to choose tactical metrics in support of that strategic vision. They can use the GQM approach to develop metrics that truly reflect the information of interest. Being aware of the risks and side effects of metrics should help ensure that these metrics activities are useful, but remember our agile metrics philosophies:

  • Napkin metrics

  • Simplify data gathering

  • Rough numbers are good enough

  • If it isn't changing, who cares?


Section 4.8. References

4.8. References

[1] Basili, Victor R. , Gianluigi Cladiera, and H. Dieter Rombach, "The Goal Question Approach," Encyclopedia of Software Engineering -2 Volume set, pp. 528532, John Wiley & Sons, 1994.

[2] Briand, Lionel C. , Sandro Morasca, and Victor R. Basili, "An Operational Process for Goal-Driven Definition of Measures," IEEE Transactions on Software Engineering, Vol. 28, No. 12, December 2002.

[3] Goldratt, Eliyahu M. , and Jeff Cox, The GoalA Process of Ongoing Improvement, Great Barrington, MA: North River Press, 2004.

[4] Jeffries, Ron, "A Metric Leading to Agility," http://www.xprogramming.com/xpmag/jatRtsMetric.htm, as of 06/14/2004.

[5] Scott, Jan, "Metrics MotivationHow to use biased metrics to influence behavior and improve performance," Better Software, Vol. 7, Issue 9, 2005.

[6] Succi, Giancarlo, "A Lightweight Evaluation of a Lightweight Process," in Extreme Programming Perspectives, edited by Michele Marchesi, Giancarlo Succi, Don Wells, and Laurie Williams, Upper Saddle River, NJ: Addison-Wesley, 2003.


Chapter 5. Phase 3Refactoring the Process

The next phase of the transition is the ongoing optimization of the process. With the feedback you are getting from fixed-length iterations, you can analyze the parts of your process that are going well and the parts that can be improved. In addition, you can begin to look for process innovations that will accomplish your requirements analysis and design goals within your fixed-length iterations.

Figure 5.1. Phase 3refactoring the process and optimizing agility

[View full size image]


Section 5.1. Are We Ready for Optimization?

5.1. Are We Ready for Optimization?

Before entering the optimization phase, we must ensure that we are ready for it. Obviously, this requires Phase 1 and Phase 2 to be complete; we have to be delivering customer-visible functionality, and we have to be measuring the capabilities of our process.

After you have completed a couple of iterations that produced customer-visible functionality and you have gathered data to measure your throughput and your efficiency for those iterations, your organization is ready to optimize. After enough iterations have been completed, the values of the metrics settle down. This demonstrates that your team has become comfortable with the agile changes, but waiting for this sign is not required. In fact, your team will probably be making suggestions for ways to improve the process at the end of the first iteration.[1] Adopt those suggestions if it is very clear that the change will be beneficial.

[1] These suggestions are often related to planning and tool support. These areas will need adjustments, and the team usually has the intuition necessary to recommend things that will obviously be beneficial. Don't hold them back.


Section 5.2. What Is a Process "Smell"?

5.2. What Is a Process "Smell"?

In the context of this optimization strategy, a process "smell" is much like a code "smell" in refactoring code; it is something that you know is "wrong" in some way.[2] Just like in refactoring code, you can feel that something is wrong in the process, and it is in your best interest to repair the problem before it gets worse.

[2] The concept of "smell" comes from a parent's experience of knowing when something needs to be changed.

When we are writing code, particularly iteratively, we incur design debt every time we make a change without maintaining the overall quality of the design of the system. Design debt is just like financial debtit does not go away unless you pay it back, and it accrues interest if you leave it too long. The same thing happens with our development processes; we start with a process that we think will work, but then personnel, technologies, skills, customers, or other things change. As each change occurs, we accrue some process debt. The symptoms of process debt are process smells, and their odor increases with time. Therefore, just as we need to refactor our code, we also need to refactor our process.

In this text, process smells are defined by their symptomsthe negative effect that we feel. The root cause of these symptoms may be different in different organizations, so there will be a variety of process changes that may eliminate the problem. The challenge is to spend the time to find the root cause in your organization and select the most appropriate process innovation.

The issue here is acknowledging that the problem is in the processnot the people. For example, if your team is regularly unable to meet its commitments, the problem is not that the engineers are lazy or don't care. Most likely, the problem lies somewhere in the process you use to estimate and allocate tasks. I once attended a presentation about a PhD thesis that was based on the premise that organizations need a rigid process to force engineers to produce quality code. The speaker was assuming that engineers do not care about quality naturally. I have found that to be completely inaccurate. Most engineers care deeply about the quality of what they produce, but many feel unable to work at their highest level in the context of the demands from the process and management. As a result, many engineers get frustrated and burned out. If it appears that the team is not producing to a high standard, look for the part of the process that is hampering the engineers as opposed to looking for more process demands to inflict on them.


Section 5.3. Picking Which Smell to Work On

5.3. Picking Which Smell to Work On

Every change you make to your process has some risk. Making multiple changes at the same time multiplies that risk. In addition, if you work on more than one issue at a time, it will be difficult to isolate their various impacts and be sure that each was an improvement. Therefore, it's important that you pick one smell to work on at a time.

Given the opportunity, all of the stakeholders will detect smells, each of which is a potential improvement to the process. However, their perspectives on what is important will differ, and in fact their goals may be in conflict. The challenge is to pick the one smell whose resolution will have the maximum impact on your process and your ability to meet your goals and make that change. In order to do that, we need a process to weigh the alternatives and pick the one that will maximize the impact. For each change, we need to specify these items:

  • Description of problem A short statement of the issue

  • Process innovation The specific change being proposed

  • Costs to implement Including training, equipment, time, etc.

  • Expected benefit The effect this change will have on our metrics

  • Risks Things that could prevent the change from achieving its expected benefits

  • Time frame Any restrictions on the timing of the implementation of this process innovation, such as scheduling of training or purchasing of equipment

If there are multiple ways to address an issue, we need to complete this analysis for each possible process innovation.

The requirement to put a numeric value on the expected benefits can seem overly demanding, but the thought process necessary to develop that value helps us weigh the alternatives. We need to quantify the effect the change will have on throughput or efficiency. That essentially means that it must improve the rate at which we deliver functionality or eliminate waste within the process.

For example, if the smell was "Engineers were spending time waiting for the automated tests to run," and the process innovation proposed was "to upgrade the server on which the tests run," then the amount of time the engineers spend waiting now is an estimate[3] of the expected benefit.

[3] This estimate doesn't account for the impact of the interruption but is good enough to support the choices being made.

However, sometimes the impact of the change is less obvious. Consider another example where estimates for the effort required by stories are very inaccurate. One possible process innovation proposal would be to use a particular estimation technique to improve the accuracy of the estimates. In this case, the impact on throughput and efficiency is less direct; the time that we spend replanning or performing other adjustments when we realize the estimates are incorrect is the waste that we reduce.

This last example underscores the need for this analysis. Although the issue raised is the inaccuracy of our estimates, we have realized that the waste in the process is the replanning caused by the bad estimates. As is often the case, there are multiple ways to address this problem. An alternative to changing the estimation process would be to focus on the replanning process to see if changing it can make it more efficient or eliminate it.

An open and frank discussion by all of the people involved is the best way to find all of the viable alternatives and quantify their impacts. The easiest way to do this is to gather everyone (developers, customer, product owner, project manager, and anyone else with a vested interest)[4] in a room and use index cards. This meeting is known as a Refactoring Planning Meeting. During the meeting, anybody can propose a change by recording the issue description and the proposed process innovation on an index card. After a discussion of the situation under consideration, the group agrees on the expected benefit and risks and records them on the card. This discussion resolves any misunderstandings and ensures that everyone understands both the issue and the proposed process innovation. If an issue can be addressed by multiple process innovations, each proposed process innovation gets separate analysis and its own index card. As the discussions continue, index cards can be removed if the group finds a process innovation they prefer or decides that the issue is not really an issue at all (usually this means that you have found a new underlying cause, so you replace the current card with another).

[4] As with all meetings, too many people can be unproductive. Sometimes it is useful to regulate who can participate in the discussion if too many people attend. See the "Chickens and Pigs" philosophy in the Daily Scrum/Daily Standup Meeting refactoring.

As this process continues, you may find that there are things that need to be researched before you can pursue an issue. For example, if you are considering upgrading the test server, you may need someone to weigh alternative servers by specifying their costs and expected improvements in the run-time of tests. Where that research is deemed valuable (i.e., the group thinks the issue is important enough to pursue), the appropriate part of the organization should be responsible for doing the research. To plan for that activity, make it a task for the next iteration and, if that task is assigned to engineering, reserve that part of the team's velocity when selecting the functionality for that iteration.

After the cards are developed, they can be prioritized. Priority is affected by the expected benefits and risks, in addition to other factors. In particular, the time frame for the change may cause a high-priority change to be deferred. For most of the cards, strict ordering is not necessary. Partitioning the cards into high, medium, and low priority and ordering only the high-priority items is sufficient. The goal is to come to consensus about which process innovation will be implemented.


Section 5.4. Making the Selected Change

5.4. Making the Selected Change

There are many things to consider when making the change, and they are the same issues that have always been important when making a change to the process. Primarily, you should plan for appropriate training, the time that training requires, and the time that will be required for the team to adjust. Any change in the process requires adjustment, and generally that learning curve temporarily reduces the team's efficiency. Planning for those factors demonstrates to the team that the change is seen as valuable and that the organization supports the concept of continuous improvement.

If you don't plan for an adjustment period and instead ask the team to continue to produce at the same rate during a change, this may damage the team's ability to assimilate the change. All changes cause some level of stress, but requiring the usual productivity increases that stress. Under these circumstances, the team is likely to revert to their previous behavior, and the change will not take hold.

Even when changes seem to affect only the development team, it is important that management and the customer know about the change and understand the direction in which the team is heading. The effects of the change (positive and negative) will be seen outside of development, and the ability of the organization as a whole to support the change is dependent on the degree to which its members understand the motivations behind the change.

Although the goal of this entire book is delivering software with agility, the philosophies behind this movement can be applied almost universally throughout an organization. Recently, testing teams, marketing teams, and even accounting teams have begun to use agile strategies. Making connections to external organizations can help both groups find creative ways to promote agility and enhance the health of the overall organization.


Section 5.5. Measuring the Effect of a Change

5.5. Measuring the Effect of a Change

It is important to measure the effect of a process innovation for two reasons. First, any change we make can have a negative impact, even though we think that it will be a positive change. Before we decide to make the change permanent, we must ensure that its impact was positive. Second, selecting and making a change requires resources (i.e., impacts our efficiency), so we need to be sure that those resources are being used wisely. Quantifying the effects of a change verifies the quality of our improvement efforts and justifies continuing improvement activities.

Often the impact of a process innovation can be measured with the throughput and efficiency metrics, but in some cases, it is more insightful to define a metric specific to this change. In these cases, the index card from the Refactoring Planning Meeting translates almost directly into goals for the Goal/Question/ Metric (GQM) strategy discussed in Section 4.5.1. Recall that goals require four attributes: purpose, issue, object, and viewpoint. The purpose is generally "to improve." The card from the Refactoring Planning Meeting will provide the issue and usually the object. The only thing left to specify is the viewpoint from which this issue will be evaluated. Often, the viewpoint is the role played by the person who raised the issue. From there, you can use the GQM strategy to find metrics that will be insightful for this situation.

A single measurement cannot be used to measure the impact of a change. At the minimum, we need some measurement of the metric before the change and another measurement after the change to make a comparison. However, the conclusions that result from that analysis are very weak. All of these metrics have some inherent variability, so it will be difficult to know whether a change in the value of the metric is a random effect or a result of the process innovation being measured. Conclusions that are more robust depend on having data covering a longer period. Statistical process control can help with this analysis.


Chapter 6. Process Innovations by Type

This chapter organizes the process innovations into groups that address similar issues with the goal of comparing the alternatives.


Section 6.1. Planning Innovations

6.1. Planning Innovations

6.1.1. Agile Planning Background

Agile planning techniques are based on the assumption that we need a plan but that it is likely that the plan will change. In fact, some organizations don't "plan," they "speculate."[2] This underscores the fact that as the project continues, our knowledge of the system and its requirements evolves, and the "plan" will have to adjust to that new knowledge. In this way, plans "serve as a vehicle for embracing change, not blocking it."[1] In other words, a plan is a commitment that holds only while our knowledge stays the same. It is also a good way to measure how much our knowledge has changed and an indication of when we need to replan.

Acknowledging that the plan is likely to change as we learn more about the project implies that time spent building long-term plans is not time well spent. In one plan-driven organization where I worked, management maintained a planning device they called the Every Person Chart (EPC). It reported which project every engineer was to be working on during each week for the next eighteen months. Because projects were regularly "missing commitments" (i.e., project members were learning and therefore revising their plans), maintenance of the EPC took on a life of its own. A new version came out about once a week to which various constituents would react causing further revisions. This was an incredible waste of effort.

The flaw in the EPC was that it was planning at a level at which we didn't have sufficient knowledgeit's very hard to know the details (to the week) of a development activity that is eighteen months away. Agile planning adjusts the granularity (the expected accuracy of the estimates) of the plan depending on how close we are to achieving the plan. The plan for the current iteration will be built from estimates whose granularity is in hours, but we will make estimates at a much higher level (weeks or months) for high-level plans like release plans.

When we make iteration plans, the estimates on which they are based will have some error in them. As the engineers start to work on the tasks, there is some chance that they will learn something that changes the estimates. This does not mean they have made a terrible mistake; this kind of learning is expected in an agile team. Because iterations are short, we need to be able to recognize these situations quickly so that we can replan as necessary. Tools like Burn-down Charts help us recognize these challenges without requiring a lot of overhead.

The error in longer-term plans is likely to be significantly greater than the error in an iteration plan for two reasons: the cumulative effect of estimate errors and the granularity of the estimates. Longer-term plans generally are based on a greater number of estimates than shorter-term plans. Each estimate has some error potential, and those errors are cumulative in the sum of the estimates. In general, those errors tend to be underestimates (where the estimate is less than the actual) because engineers are optimistic and often don't anticipate the need for some portion of the development. This means that errors in our estimates don't in general cancel each other out but instead tend to be cumulative. The more estimates that are combined in a plan, the higher the likelihood is that the plan will need to be revised. In addition, the error in an estimate is roughly proportional to the granularity of the estimate. When we are estimating that a task will take four hours, the error is likely to be measured in hours, whereas an estimate of two weeks is likely to have an error that is in days or weeks.

In general, there are three levels of agile planning. At each level, we must specify the required functionality and other activities (like development of load tests, user training, etc.) that are required to produce that functionality. Product plans cover the entire product from the current state of the project through completion. Release plans specify what will be included in each published release of the product. Iteration plans specify the functionality to be developed in a single iteration. Not all agile projects use all three of these levels of plans.

To support agility without sacrificing plan quality, all agile planning techniques share a number of common philosophies:

  • Planning shouldn't take a long time.

  • The more stakeholders involved in making the plan, the better it will be.

  • The level of detail in the plan depends on the type of plan; short-term plans need more detail than long-term plans, and near-term plans need more detail than future plans.

As a result, most planning is done in meetings where the plans are structured so that they are visible to everyone and very easy to rearrange. In fact, many of the planning techniques involve index cards being arranged on a table or wall. The level of detail on the cards and the rules for how they can be manipulated depend on the chosen planning technique. Scrum, XP, Lean Software Development, and the Crystal methods all involve long-term and short-term planning on index cards.

6.1.2. Product/Release Planning

In Scrum, the product owner maintains the activities required by the project on a set of cards called the Backlog. These activities always have current estimates and priorities. This makes it easy to select the activities for the next iteration or for a release plan. For the iteration, the highest-priority activities whose estimates fit within the iteration velocity are the activities for the next iteration. Similarly, partitioning the list into sub-lists based on the velocity available for each release results in a release plan. In the backlog, higher-priority activities are more near-term activities, so they require more accurate estimates. Activities that have low priority in the backlog do not have to be specified in detail because it is likely that those details will change before the activity becomes high priority. Scrum does not specify a technique for finding and specifying the items in the backlog but allows the backlog to evolve over time. A single product owner who is responsible for the long-term vision of the project controls the backlog.

Although Scrum allows the backlog to be discovered over time, Crystal Clear offers Blitz Planning as a way for the stakeholders to find much of the product plan in an afternoon meeting. In addition to prioritizing functionality, blitz planning also specifies interdependencies between activities and includes this information in sorting the activities. Blitz planning also allows the stakeholders to group functionality into a release plan. In this way, releases can have logical goals. For example, marketing constraints may require that you put all of the advanced reporting features into a single release, even if not all of those features had the same customer priority. Because all stakeholders see all of the activities laid out during the meeting, these types of rearrangements are not difficult.

6.1.3. Iteration Scope Planning

Iteration planning requires two steps: determining the functionality to be delivered and determining how that functionality will be developed.

Selection of the functionality for an iteration requires a process that includes the customer, management, and the development team. The development team has two inputs into that process. First, they provide the estimates of the time required by each piece of functionality under consideration. This helps ensure that the estimates are realistic and that everyone has considered all of the activities that will be required.[1] Second, they specify the amount of development time they will have available for the iteration. This is called the team's velocity and may be measured in hours or other effort-related units. When the team sets its velocity, it can account for planned absences (vacations, doctor's appointments, etc.) and for internal activities (tool development, upgrades, or significant source code refactorings). Because these planning activities happen with every iteration, any functionality that has to be delayed doesn't get pushed back very far because the customer can choose to put it in the subsequent iteration when it is planned.

[1] However, as in longer-term plans, the estimates are often an accumulation of a number of rough estimates and will have some error component. They are only as accurate as the knowledge of the engineers allows and often include some measure of how confident the engineers are in the estimates in order to help the customer to manage the risk associated with the tasks they select.

In Scrum, the functionality to be delivered in the next iteration is just the highest-priority activities from the backlog that fit within the velocity of the sprint. In addition to that functionality, a goal for the iteration is specified that ties together the functionality being developed. This can be used later if the team runs into trouble. Although they may need to scale back the details of the functionality being developed, they continue to try to meet the general goal of the sprint.

In XP, the goal of the Planning Game is to maximize the value that the functionality has to the customer while making the risk explicit. The planning game allows the customer to specify all of the functionality and then select what they want the team to work on in the current iteration. Sometimes the planning game is used to select the functionality for a few iterations at once to give a slightly longer (but not usually release- or product-level) view of the project.

6.1.4. Iteration Planning

After the requirements of the iteration have been specified, the development team has to make a plan for how those requirements will be met. This is called the Iteration Plan. In other words, the development team needs a more detailed plan for the iteration. To promote ownership and accuracy in the plan, iteration plans are generally developed by the engineering team and not by its leadership. The iteration planning process is generally a structure that allows the team to generate the list of tasks required to develop the required functionality and determine who will be responsible for each task, but the formality (or lack thereof) of that process can vary significantly. Some teams follow a formal structure, while others use a more ad hoc planning philosophy. The decision for how to structure this process is generally left to the team.

The simplest iteration planning technique is the visible pull system known as Kanban Scheduling in which the team determines the set of activities that will be required to complete the iteration and posts them in a display. There is no scheduling of tasks. Instead, everyone selects a task whenever he is idle.

Generally, the tasks in the iteration-level plan should be able to be completed in between a half-day and four days, but the maximum length you can tolerate may depend on the length of your iterations. Scrum and XP develop their iteration plans using the Sprint Planning Meeting and Iteration Planning Game, respectively.

Although iteration plans are detailed in their specification and estimation of tasks, it is common to ignore the dependencies between tasks. In general, because the iterations are short and the team is working closely, there are few dependencies, and the team can handle those that exist without management intervention. This means that there is no need for dependency and critical path planning with PERT charts. Iteration plans generally only need to specify the tasks and who is responsible for each task in order for the iteration to go well.

The goal of iteration planning is for the team to develop a plan that it believes it can complete. Plans without commitment are not useful plans. If the team completes the planning only to discover that the tasks do not fit into the time given to the iteration, then we have an early indication that too much functionality has been committed for this iteration, and we can work with the customer to adjust appropriately.

The sprint planning meeting allows the team members to use whatever method they prefer to compile the list of tasks that will be required to meet the sprint goal. In addition, they are allowed to "self-organize" in that they determine how tasks will be assigned to engineers. In fact, the team members can choose to plan only the first portion of the sprint if they think that those early activities could change how they plan the later activities.

The iteration planning game is more structured than the sprint planning meeting; it includes specific strategies for developing the list of tasks, mapping tasks to engineers, and load-balancing the activities among the engineers. In particular, it is very clear about the development of estimates for activities: only after an engineer has chosen to work on a task can he give an estimate for the effort that task requires. This is a critical part of promoting the ownership of tasks and estimates that is core to XP's values.

6.1.5. Iteration Length Planning

To improve your feedback or maximize your efficiency, sometimes you need to Change Iteration Length, but sometimes Pipelining Iterations is a good alternative. In pipelining, portions of your development process are completed in sequential iterations. For example, if your product requires significant requirements analysis that cannot be completed during iteration planning, you could make the requirements analysis for the next iteration overlap the development of the current iteration as shown here.


Section 6.2. Estimation Innovations

6.2. Estimation Innovations

There are two general strategies for improving the accuracy of your estimates: help individuals learn to make better estimates or find ways to leverage the whole team's experience when making estimates. Individual Estimation Techniques can improve the accuracy of an individual's estimates. Delphi Ranking and Planning Poker are techniques that help a team derive accurate estimates from the estimates of individuals.

Surprisingly, some teams estimate more accurately when using "ideal engineer hours" as their estimation units, while others are more accurate with an abstract unit like "story nuts." If nothing else works, you could Change Estimation Units.

Figure 6.1. Pipelining iterations

Previous Page
Next Page


Section 6.3. Process Management Innovations

6.3. Process Management Innovations

6.3.1. Promoting Communication within the Team

One of the keys to agility is communication within the team. By definition, an agile environment means that things happen quickly, so it is important that information can pass easily among the team. The most obvious changes advocated by agile techniques are changes to the work environment itself. The first such strategy is to create an Open Workspace, which is an open, bull-pen-like development lab where everyone works when they are writing code. With no cubicle walls between them, everyone becomes more aware of what others are developing, and it is much easier for people to get help when issues arise. In addition, an Informative Workspace helps us display critical information in a way that keeps everyone up to date.

In addition to changes to the workspace, many agile methodologies require the team to review status every morning at a Daily Scrum/Daily Stand Up Meeting. At the end of each iteration, holding a Retrospective will let the team share information about what went well and what they'd like to change in the next iteration. These meetings are excellent opportunities not only for the team to share but also for the leadership to listen.

The agile philosophy of self-directed work groups also helps with communication. If you are abiding by that philosophy, then the team must be included in or have ownership of all planning activities. This is an excellent opportunity for them to see the details of the iteration.

6.3.2. Communication Between the Team and External Entities

It is often necessary that progress information be shared during an iteration. The simplest way to let outside people see how the team is progressing is by allowing them to attend planning meetings, Daily Scrum/Daily Stand Up Meetings, and Retrospectives. If they become a distraction at any of those activities, you might want to invoke the "chickens and pigs" rules from the Daily Scrum.

A simple indicator that is very powerful in its ability to show the team's capabilities and progress is a Burn-down Chart. With some initial explanation, it can take the place of more complex (time-consuming) reporting mechanisms.

Holding a Sprint Review at the end of each iteration not only can let the team demonstrate its success but also can provide a forum for discussing the direction of the project.

There is some disagreement about how much the team should be interrupted while an iteration is in progress. Therefore, you need to decide between Limited Steering vs. No Distractions.

6.3.3. Growing Good Team Members

To build a strong team and maintain the technical capabilities of each engineer, your team needs to focus on the development of each individual's skills. "Gold" cards are one way to allow each engineer some control over his technical growth.

Because of the focus on team progress and capabilities, one of the biggest challenges for the team can come when management requires individual performance evaluations, particularly if those evaluations are tied to merit pay increases. In response to these situations, teams have developed a number of Individual Evaluation Strategies.


Section 6.4. Analysis/Design Innovations

6.4. Analysis/Design Innovations

6.4.1. Requirements Analysis Innovations

Plan-driven activities like use case analysis and other UML tools need modification to fit into agile methods. Agile Modeling is a strategy for developing these models within agile philosophies. The core of Agile Modeling is that there are two purposes for modeling: understanding and communication. For example, one Agile Modeling practice is "Iterate to Another Artifact" and advocates changing the type of model you are working on when you are having difficulties because the change in perspective can help resolve issues. Similarly, the practice of "Create Simple Content" advises keeping the audience of the model-building activities in mind and only modeling to the level of detail that the audience requires. Following Agile Modeling practices can help ensure that the time spent developing (and possibly maintaining) models is valuable.

As an alternative to traditional requirements gathering, some agile methods develop Automated Acceptance Tests. These tests specify the external behavior of the system, often in ways a customer can understand, and they can be run automatically at regular intervals to ensure that the system meets those requirements. Having the customer develop these tests, as XP advocates, ensures that the tests encode the customer's requirements. If anyone asks, "What should the system do under these circumstances?" the answer can be found in the appropriate acceptance test.

6.4.2. Design Innovations

As with requirements analysis, Agile Modeling allows traditional UML designs to be used in a more agile way but does not ensure that the models match the code. An extreme version of Agile Modeling is Whiteboard Design, which advocates creating models on a whiteboard in support of a design discussion. These models have only the detail required by that discussion. When the engineers finish the discussion, they record the model by taking a photograph or using a recording whiteboard. Although these records are kept for reference, there is no expectation that the code will continue to match the design in the long term. In this case, the models are truly a mechanism to support the design process but are not documentation of the resulting design.

In situations where it is important to maintain accurate design-level documentation, Closed Circuit Engineering may be an appropriate choice.

Basic structural documentation with some usage documentation can easily be generated from comments in the code using Automated Documentation Generation like that provided by javadocs. These hyperlinked documentation hierarchies can provide the high-level view of the system that has traditionally been provided by design documents. However, because it is generated from the code itself and by comments in the code, it is more likely that engineers will keep the documentation up to date. Although the structural documentation generated is thorough, the behavioral documentation depends on the level of detail that engineers build into the comments.

Test-driven Development (TDD) takes a completely different view of design and design documentation. In TDD, automated unit tests are developed (only slightly) ahead of the code. In a sense, these tests document the design of the system because they specify how the engineer expected the code to be used. For example, a banking system could have an "Account" class that another class needs to interact with in order to make a deposit. The engineer developing the other class can look at the unit tests for the Account class to find code that makes deposits, rules about what kinds of deposits are supported, and what error conditions the code detects. In this way, these unit tests document not only the structure of the system (what methods exist in which class) but also behavioral patterns within the system (how a class will react to various method calls).

In situations where there are multiple strategies for how to address a requirement, an Impact Estimation Table is a technique that weighs the costs and benefits of each option to help in the selection of a technique. This is a somewhat time-consuming activity that should rarely be required, but it is sometimes useful. An alternative to selecting a single design is to use Set Based Decision Making to keep as many options open as possible. Because we are designing for the current iteration, keeping options available will help in later iterations. However, it's important to note that this does not mean we implement a design that contains functionality not required in this iteration. It is a technique based on delaying decisions until the last possible moment.


Section 6.5. Development Innovations

6.5. Development Innovations

6.5.1. Tool Support

There are a number of tools you can utilize to improve your agility. The most obvious is selecting the Configuration Management Patterns/Tools the team will use. This can eliminate significant amounts of rework and improve the efficiency of your team. In addition, it lays the groundwork for Continuous Integration (CI). CI means that changes to the code are integrated into the release as soon as the developer thinks they are complete. This reduces the cycle time and allows everyone to see how the iteration is progressing. In addition, it means that integration is completed in small steps, which significantly reduces its complexity.

Automated Unit Testing can be simplified with the use of existing testing frameworks like JUnit, CPPUnit, and NUnit. There are similar frameworks for almost every language in existence. Similarly, Automated Acceptance Testing is often accomplished with the Fit or Fitnesse tools.

6.5.2. Code Quality

The quality of the code and the system's overall design can be estimated with Code Metrics. These measures can help locate the sections of the code that are likely to be fragile and can give feedback on the design by analyzing the amount and types of coupling within the system. This information can help you target cleanup and testing activities to improve the return on those investments.

If the team is having trouble getting defects under control, Root Cause Analysis can help isolate the aspects of your process that might be the source of those defects.

Finally, the best thing the team can learn in order to maintain the quality of the code while doing iterative development is Source Code Refactoring. Refactorings are almost mechanical manipulations of the code that do not change its external behavior but clean up software rot before it overwhelms the system. There are a great many such refactorings, and knowledge of them will be critical to the success of any team using iterative development.

6.5.3. Communication

Coding Standards that require consistency in naming styles, structure of code, and types of comments can improve the code's readability and make it a better resource for the team. This needs to be done carefully because some standards require significant duplication of information.

Traditionally, Code Reviews have been used to ensure that a section of code (class, module, etc.) matches the required functionality and coding standards, but they are also a way to share information among the team. Many agile teams use Pair Programming as a strategy to get code review feedback instantaneously and thus improve the quality of the feedback and the speed with which the developer can respond to that feedback.

Another alternative to code reviews is Code Presentations where one member of the team presents some portion of the system to all of the members of the team. The goal of this presentation can be informational or as the beginning of a design revision discussion. Code Metrics that measure the rate of change in the source code or code quality can be used to target these presentations to parts of the system that are widely accessed or that may require redesign.

Finally, the philosophy of Team Ownership of Code gives everyone a stake in the quality of all of the code and encourages the sharing of ideas and information almost as team folklore.


Section 6.6. General Process Innovations

6.6. General Process Innovations

This section summarizes a few process innovations that did not fit into the other categories.

Many agile organizations use an Onsite Customer to ensure that questions about functionality can be answered quickly. In cases where that direct resource is not available, teams often designate a Customer Surrogate to play that role. Although this is not as useful as having the actual customer present, the person playing this role is responsible for knowing the customer's or the market's demands and representing that viewpoint to the team.

For a team transitioning to the open and trusting agile values, "Anonymous" Early Warnings is a temporary strategy that encourages people to provide honest status information without fear, and it serves as a way of building trust.

Metrics that are gathered over time can provide significantly more information than just the value of the number. Trends and outliers can be found using Statistical Process Control. In addition, these techniques can compute the bounds of your team's capabilities and compare them to your customer's demands to help ensure you can meet those requirements.


Section 6.7. References

6.7. References

[1] Beck, Kent, eXtreme Programming eXplainedEmbrace Change, Upper Saddle River, NJ: Addison-Wesley, 2000.

[2] Highsmith, Jim, Agility in Software Development, Upper Saddle River, NJ: Addison Wesley, 2002.


Chapter 7. Process Smells

This chapter provides an index into the process innovations by the smell being addressed. Each smell is identified by the symptoms that define it. Then, for each possible process innovation, the ways that the innovation might eliminate the symptom are discussed.


Section 7.1. Non-value-adding Activities

7.1. Non-value-adding Activities

7.1.1. Replicating Fixes to Multiple Releases

Symptoms

One of the most common ways to waste time is replicating fixes from one release to another. For example, many teams have two development streams: one for new features and one that is the previous release into which only bug fixes should be added. When a bug is fixed, the engineer has to be sure that it gets into both releases. As the code bases of the two releases diverge, the probability that the fix won't be the same in both releases increases. This means that the duplication is going to require even more effort than simply copying the fix to multiple release streams.

In addition to multiple releases of one product, this duplication can also be caused by the need to have multiple versions of the same release. For example, a web-based product and a desktop product could share a common core, but lack of tool support may cause the team to create two copies of that core.

Possible Process Innovations
Configuration Management Patterns/Tools

Many of these situations can be resolved by reducing the complexity of duplicating changes. Providing tool support for the branching and merging of development streams can be helpful in addressing this problem. The merging capability is particularly significant because it eliminates the need to put changes into both streams. There are many strategies for the creation (and subsequent merging) of streams. Tool support for the selected strategy can achieve a number of simplifications to your process. The main goal is to minimize the duration of parallel streams because that will minimize their divergence and simplify the merge process.

Continuous Integration

If you allow branches for individual development activities, it is important that you require that those individual branches be used for only one task each and that they be merged back into the main branch regularly. Again, this would reduce the duration of each branch and minimize the chance that a merge will require effort.

Source Code Refactoring

If having multiple versions of the system causes the duplication of streams, restructuring the code with the goal of isolating the differences from the shared portion of the system may reduce the duplication. Essentially, there should be a common core of files that are shared for both versions of the system. Two separate layers implement the differences between the systems. Refactoring to maximize the size of the core would reduce the duplication in the other layers and would therefore reduce the number of changes that have to be hand-copied.

7.1.2. Difficulty Resolving Design Issues

Symptoms

In plan-driven teams, design decisions are often left to a small set of architects. However, in an agile team, everyone is responsible for the quality of the design. This often leads to lengthy and passionate discussions weighing alternative designs. Even when everyone involved behaves in a professional manner, these debates can be fractious and time-consuming. There are specific strategies that can help the team resolve these issues more effectively.

Possible Process Innovations
Set Based Decision Making

When one design strategy is not clearly better than another is, it may be best to defer the choice between them. Instead of choosing one solution arbitrarily, the team can either implement the aspects the solutions have in common or implement both solutions in parallel. Often, the learning that happens during this process results in a design that is better than either of the original choices.

Impact Estimation Table

This is a technique to quantitatively compare the impact of various design decisions and their effects on meeting the customer's requirements. It is most useful in situations where the requirements are numerical (speed, performance, cost, etc.).

7.1.3. Unused Documentation

Symptoms

If your team spends time creating documentation that subsequently becomes unused, it is time to think about whether the effort used to create it was valuable.

I once worked for a telecommunications company that used a waterfall-type process. In the midst of the coding phase, the developers recognized that we needed a significant change to the high-level design of the system (functionality that was designed to be on one board in the system needed to be moved to another). When we discussed this with management, they told us to make the change to the code and not worry about the documentation. They said, "Don't worry about the documentationwe'll fix it up after we ship." This clearly demonstrated that correct documentation was not valuable (at least to management!). They believed that we could successfully code the change without first specifying its details, and they didn't care if the documentation didn't match the resulting code. However, it raises a number of questions: if we don't need the documentation, why did we spend months building it, and why would we bother to fix it up after we ship?

The creation of the document does have value if that process helps us refine our understanding of the system and gives us a direction. There is only an argument for allowing the first version of the document to go out of date if some other technique replaces its role as the code deviates from the original plan.

Possible Process Innovations

The general strategy in these innovations is to replace traditional documentation with something that is used throughout the development cycle.

Generation of Design from Code

Coding standards can go a long way toward helping generate documentation from code if they require that comments follow a format that allows a tool to extract the documentation from the comments. Although this is built into Java with javadoc comments, there are similar tools for almost every other language. Because the comments are usually in close proximity to the code, they are much easier for engineers to keep up-to-date than traditional documentation.

However, the documentation that is generated from commented code is often still at too low a level to provide an understanding of the high-level architecture. For example, javadocs will give a list of all of the classes in a package and let you see all of their external interfaces but do not provide a picture of how the engineers expected those classes to interact with each other. In other words, this technique gives us structural documentation as opposed to behavioral documentationunless the engineers include behavioral descriptions in their comments.

Automated Unit Tests

When an engineer develops automated unit tests for a class, those tests can provide an interesting addition to the class-level documentation. Essentially, the engineer is encoding the way he expected the class to be used, so this is behavioral documentation as opposed to structural documentation. When a new engineer needs to use the class, she can look at the unit tests to find examples of how the class can be used. If the team sets a goal of using the tests in this way, the resulting tests are generally both concise and precise! In addition, if we run the tests regularly, we know they must match the code, so they are documentation that never gets out of date.

Automated Acceptance Tests

Not all documentation that can be out of date is design documentation. Requirements documents also age as the system matures. At the post-mortem of one six-month (relatively short!) project, I asked the team if their system matched their requirements document. They replied with, "No, we've experienced feature creep and feature sleep!" They had features that the customer had not requested and were missing features that the customer had specifically requested.

One way to ensure that customer requirements match the system is to encode them as automated acceptance tests. Regularly running these tests ensures that they continue to match the system's behavior. This will prevent "feature sleep" because every feature will be encoded in one or more tests. Unfortunately, this does not prevent feature creep!

Whiteboard Design

If your team needs to perform some early design but does not need that documentation to last (because it is replaced by one of the preceding techniques), then it is often more efficient for a group of engineers to hash out the initial design as a diagram on a whiteboard. After they agree on this initial direction, it can be recorded as simply as taking a photograph. The goal is to make the process of developing the design as efficient as possible, and particularly if it is an initial design, encoding the diagrams in a CASE tool can be more cumbersome than necessary.

7.1.4. Extraneous Features

Symptoms

One aspect of agility that challenges some engineers is the idea that there are features that do not add value to the product. Because engineers enjoy the technology, they often think of additional functionality that does not seem to take much effort to build, and this results in feature creep. However, if we spend time developing a feature that the customer has not requested, that time is essentially inventory that we will never convert into throughput. In other words, it never helps our throughput and lowers our efficiency. Often engineers see the possibility of a feature that won't require significant development time and implement it even if it has not been requested. Even if the customer likes the feature, if it hasn't been requested, it isn't going to generate throughput. In order to have high efficiency (i.e., high agility), it is important that only the features that are requested get developed.

Possible Process Innovations
Planning Game or Product Backlog

Sometimes the root cause of extraneous features is a lack of understanding of exactly what the customer has requested. Using the planning game or having one person be responsible for maintaining the product backlog can help the team keep track of exactly what features have been requested.

Open Workspace and Pair Programming

Increasing communication among the team can help people notice when extra features creep into the system before the effort of completely implementing them has been spent.


Section 7.2. Smells in Deliverables

7.2. Smells in Deliverables

7.2.1. Fragile Code (Touching It Breaks It)

Symptoms

One of the first signs that might indicate software rot is when fixing one defect causes another. This is a sign of design debt that you have accrued because you are not refactoring the source code along the way.

Possible Process Innovations
Source Code Refactoring

Obviously, cleaning up the code will help prevent (or repair) software rot. When the design debt is large enough to cause fragile code, the bigger question is why the team is not refactoring with each change. The first thing to do is to ensure that the team has training and tools to support their refactoring efforts. In addition, refactoring has to be treated as a valuable activity that the engineers should undertake as a part of their regular development activities. Over time, engineers will begin to see refactoring as part of every task, and it will be included in the task estimates used in planning. Note that this means that engineers should not be pressured to give the lowest possible estimate because that will never include refactoring.

Automated Unit Tests

The existence of unit tests can help this situation in two ways. First, the presence of the tests gives engineers the confidence to make refactorings. As long as the tests pass, we can refactor without worrying about introducing defects. Second, as the percentage of our system that is covered by the tests increases, the probability that fixing one defect will cause another decreases. In many ways, the presence of the tests prevents software rot.

Open Workspace and Pair Programming

Sometimes incomplete understanding of exactly what the software is supposed to do is the cause of defects. Both of these techniques can promote communication and help detect these misunderstandings before they result in the creation of a defect.

Team Ownership of Code

As more people understand and work on each part of the system, the interactions within the software will be clearer, and the design will benefit from many perspectives. In addition, when the entire team works on all of the code, everyone's work is visible, and that motivates people to write clean code.

7.2.2. High Defect Rate

Symptoms

A high defect rate is clearly unacceptable. However, agile organizations have a very low tolerance for defects, so "high" is a relative term. In some organizations, the existence of even one defect is too high a defect rate. These organizations believe in "No Broken Windows."[3] James Q. Wilson and George Kelling developed the "Broken Windows Theory" in crime prevention. This theory stated that if a window was broken and not quickly repaired, it would embolden people to break more windows and escalate to more serious crimes. Rudolf Giuliani extended this in New York City. He believed that when people see the window in disrepair, they decide that the state of their neighborhood isn't important, and as a result, the state of the neighborhood degrades.

In The Pragmatic Programmer [1], broken windows are defined to be bad designs, wrong decisions, or poor code (not just customer-visible defects). Leaving even one broken window in your system gives the impression that quality doesn't matter, and the software begins to rot. No broken windows can be tolerated.

In fact, agile organizations have such a low number of defects that they do not require defect-tracking systems. Instead of tracking them, they just fix them. If you have more defects than you can repair in an iteration, you have a problem.

Possible Process Innovations
Pair Programming

One aspect of pair programming is that code review is occurring as the code is written. This is more effective (faster feedback) than traditional code reviews and can result in higher-quality code with fewer defects.

Automated Unit Tests

The unit tests not only help catch defects in the code being written but also ensure that previously written code has not been broken by the modifications. The result is a defense against the injection of new defects when trying to fix existing defects.

Source Code Refactoring

There is no better defense against defects than high-quality code. Because iterative development without refactoring raises design debt, be sure that everyone on the team is well versed in these techniques and that sufficient time is allotted to prevent software rot.

Code Presentations

If a small portion of your system contains a higher density of defects, a code presentation of it can help the team understand it better and develop strategies for improving its robustness.

Code Metrics

Source code refactoring and code presentations can be targeted to portions of the system that are likely to have defects by using standard code complexity metrics.

Test-driven Development

Taking testing one step further, test-driven development strengthens the design thought processes while resulting in fully tested code. It is not a simple strategy to learn, but it is very powerful.

Sprint Review

The knowledge that they will be demonstrating the functionality at the end of the iteration can motivate the team members to give priority to defect prevention.

Root Cause Analysis

If the team is uncertain about the source of the defects, root cause analysis can help you isolate the portion of your process where the defects are being injected.

7.2.3. Code Doesn't Match Design Document

Symptoms

In plan-driven development, the design document is supposed to provide a source of reference throughout the development of the system. However, as the implementation of the system progresses, the code usually diverges from the design in the design document. The result is a document that is no longer useful unless effort is expended to ensure that the changes made in the code are also made in the document.

One possible cause of this is that you are producing documentation that is not as valuable as the time it takes to create it. If that is the case, you should look at Section 7.1.3, "Unused Documentation."

Possible Process Innovations

The general strategy in these innovations is to replace traditional documentation with something that is closer to the code but that continues to provide the high-level view the documentation has traditionally provided. Putting the documentation closer to the code increases the likelihood that it will continue to match the system as it evolves.

To give these strategies some perspective, consider the argument Reeves makes in "What is Software Design?"[2]. He argues that ultimately, the source code is the design in that it is the instructions that we give to the compiler to tell it how to construct the system in the same way that bridge plans are the design that is given to the bridge builders to tell them how to construct the bridge. Although the code is sufficient documentation for the compiler, engineers generally need to see a higher level of abstraction to understand the high-level architecture of the system. The goal with these process innovations is to extract that higher-level understanding from something that is a part of the code.

Generation of Design from Code

If you think that your design documentation is valuable, but it ends up out-of-date anyway, the problem may be rooted in the ease (or lack thereof) of updating that documentation. If the documentation is "far" from the code (in a separate document and/or a very different format), it might be difficult for the engineers to translate the change they want to make in the code to the correct change in the documentation. In this case, embedding comments that allow the documentation to be generated from the code can replace structural documentation (which explains the classes and their methods).

Automated Unit Tests

You can put behavioral documentation "near" the code by building automated unit tests. These tests encode how the designer intended that code to be used. Therefore, the tests provide valuable insight when an engineer needs to write new code that interfaces with existing code. If she wonders, "How would I do X?" she finds the tests that encode that behavior and sees exactly the sequence of calls the designer expected her to use. Running these tests with regularity (possibly as a part of Continuous Integration) ensures that they are kept up-to-date with the code.

Test-driven Development

Extreme Programming has taken the concept of automated unit tests a step further to allow it to completely replace detailed design. XPers advocate writing the unit tests before you write the code. This makes you think about "How will the class be used" as opposed to "What does this class need to do," which can make your code much cleaner. In TDD, you write a test before you write the code that makes the test pass, and that ensures a very tight feedback loop during coding.

Closed Circuit Engineering

Even when engineers value the documentation, it is often difficult to update. Often, change control is more limiting on documentation than it is for code, and the tools that are used to update the design can be cumbersome. These can be hindrances to updating the document.

Many CASE tools support the ability to generate UML models from code and vice versa. If you follow the coding standard that allows this, it can be an effective way to update the design model. This can be automated to occur at regular intervals, which can alleviate the need for each engineer to work with the CASE tool, thereby eliminating change control and learning curve concerns.

Code Presentations, Open Workspace, and Pair Programming

Finally, the best way to promote communication among developers is an open workspace. If you believe that the code developed doesn't match the design because developers are not aware of what everyone is doing to the system, this is a great strategy to try.

7.2.4. Feature Creep or Feature Sleep

Symptoms

There is no bigger waste than spending an iteration building a feature that does not match the customer's expectations. If the team builds what the customer requested and then the customer changes his mind, it's not a problem. However, if the customer doesn't get what he asked for in the first place, essentially no progress has been made. Similarly, it is important that we meet as many of the customer's expectations as possible. Delivering exactly what was expected (no more and no less) builds a relationship of trust with the customer that will keep the customer satisfied in the long term.

Possible Process Innovations
Planning Game

The planning game is designed to promote communication between the team and the customer and to flesh out the details of the functionality to be included in the upcoming iteration. If you are using the planning game and still do not develop functionality that the customer is expecting, add more detail to the stories. You may need to go as far as drawing pictures or diagrams of what the customer will see.

Sprint Planning Meetings

Like the planning game, the first portion of the sprint planning meeting contains a discussion with the customer about the functionality to be included in the iteration. Again, adding details to the backlog items can clarify the customer's requirements. However, do not spend time adding details to items that are low in the backlog list because they are likely to change before they come up for implementation.

Onsite Customer or Customer Surrogate

Agile planning attempts to rapidly flesh out the details of a feature. However, as development of the feature progresses, the developers often have questions about exactly what the customer wants. Having an onsite customer allows the developer to get answers to those questions quickly so that development can continue. If an onsite customer is not a viable option, designating one personoften the product ownerto answer those questions can work well. This customer surrogate must be responsible for reflecting the customer's needs and should interact regularly with the customer about these issues.

Set Based Decision Making

Often during planning, there is some disagreement about the best way to provide some required functionality. In these cases, it is wise to allow the team to start implementation on a few promising alternatives to flesh out their details. This can help the customer see the alternatives and often results in an even better solution that takes the strengths of each of the alternatives.


Section 7.3. Planning Smells

7.3. Planning Smells

7.3.1. Unmet or Unachievable Plans

Symptoms

Although situations may arise that make the team unable to meet the plans for an iteration, this should be the exceptionnot the rule. If plans are regularly unmet, there is something wrong either in the planning process or in how the iteration is being managed.

Possible Process Innovations
Blitz Planning, Planning Game, Iteration Planning Game, or Sprint Planning Meetings

If the team feels that the plans are unachievable at the beginning of the iteration, then the planning process needs to be addressed. Two stages of planning may be at fault: the process of selecting functionality for the iteration or the process of defining the tasks necessary to build that functionality. Either of these processes could be producing unrealistic plans. Using one of the standard planning strategies listed above may eliminate the problem.

It's important to notice that the process of defining the tasks provides feedback about the quality of the process for selecting the functionality. For example, consider an iteration whose selected functionality consists of three features whose estimates sum to 20 ideal engineer hours, which fits into the velocity for this iteration. The team then decides there are six tasks that must be completed to build those three features. There is a chance that the sum of the estimates of those six tasks is greater than 20 and does not fit into the velocity for this iteration. Instead of reducing the estimates to meet the "commitment" to those features, the team should reestimate the features and initiate a conversation with the customer to renegotiate the content of the iteration. It is much better to recognize the situation and deal with it on the first day of the iteration than to hope for heroics from the team and miss the commitment at the end of the iteration.

Individual Estimation Techniques

Sometimes the problems with a plan are rooted in the inaccuracy of the estimates that the team is making. This may be the case if all of the planning sessions seem to be following a process and the team believes in those plans at the beginning of the iteration. Look at the previous couple iterations to see what percentage of tasks were inaccurately estimated. If the inaccurate estimates can be traced to individuals, helping those individuals to improve their estimates may eliminate the problem.

Group Estimation Techniques

Measuring the difference between estimated and actual effort over a number of iterations will give a measure of the team's estimation accuracy. If that accuracy is too low, changing the estimation process to allow broader input may improve accuracy.

Change Estimation Units

If the team continues to make inaccurate estimates, changing the estimation units sometimes improves accuracy.

Limited Steering vs. No Distractions

If the plans created at the beginning of the iteration seem achievable and estimation accuracy is high, it is possible that engineers are being asked to work on tasks not related to the iteration goals or that changes to those goals are being allowed during the iteration. The plans should include everything that the engineers will do during that iteration, and distractions should be eliminated in order to allow them to succeed.

Burn-down Chart and Informative Workspace

Techniques that allow the team and other observers to see the progress being made during an iteration can facilitate early detection of detractors so that those problems can be eliminated before they threaten the success of the iteration.

"Anonymous" Early Warnings

If the unmet commitments happen late in the iteration, it is possible that they could have been reported (and the team could have adjusted) earlier in the iteration. If there has been a climate of fear, anonymity (even if it isn't real) can encourage individuals to report problems earlier and begin to rebuild the trust that agility requires.

7.3.2. Extensive Replanning

Symptoms

Although replanning is a necessary side effect of learning more about what needs to be done, it can require significant resources and can disrupt the progress of the project. When a plan doesn't last longer than about one quarter of its length, you are replanning too often.

Remember that there are three levels of plans: release plans, iteration scope plans, and iteration plans. The level of detail increases as we progress through these planning activities. One source of replanning is having too much detail in the longer-term plans. The further away something is from being built, the less we know about it and the less detail we need (or want) in planning it. If you are regularly revising your long-term plans, they probably have more detail than your current knowledge warrants, and you should reduce the level of detail in them.

Possible Process Innovations
Burn-down Chart

When one engineer realizes that a task is going to take longer than expected, team leaders often feel the need to replan. However, tracking progress can give the team a feeling as to whether there is time available to recover from this situation. Given that information, the team can generally adjust when necessary without the need for official replanning at all.

Limited Steering vs. No Distractions

Replanning in the middle of an iteration can be caused by two things: the team learns something that changes their estimates significantly, or the customer asks for new functionality. When the team realizes they are not going to be able to meet the plan for an iteration, you have no choice but to do some sort of replanning. Try to keep it as simple as possible. However, you do not have to allow the customer to ask for new functionality. One strategy to prevent these kinds of replanning is to not allow anyone (customer, management, etc.) to change what the team is developing in the middle of an iteration. Although this obviously prevents replanning, it can also greatly improve the team's focus and therefore its ability to deliver.

Pipelining Iterations

Sometimes pipelining iterations can give the team the ability to research or prototype an architecture before the iteration in which it will be required. This can help you give estimates that are more accurate when you plan the iteration, which can help prevent replanning.

Change Iteration Length

If you are changing the iteration plan in the middle of an iteration in order to accommodate a customer request, one strategy can be to shorten the iteration length. If your iterations are a month long, but your customer needs to be able to request functionality and have it delivered within two weeks, then you'll have to replan in the middle of the iteration. If you change your iteration length to a week, then your customer can always put his new request into the next iteration, and you can meet his time requirements.

7.3.3. Lack of Long-term Vision

Symptoms

The focus on the current iteration can leave the team somewhat shortsighted. Although this has some positive effects, it can have two negative effects. First, it can leave the team with the feeling that there is no end in site. The engineers can begin to feel that every iteration is the same and that the iterations will go on forever. Second, the customer and the team can become focused on the little details of the functionality in the system while losing sight of other capabilities that would improve the value of the system.

It is important to remember, though, that any long-term planning is highly speculative and should not influence the designs being developed for the current iteration. Remember, in this iteration, we code only what we need for this iteration's functionality. We do not architect the system for requirements that we think might be coming later in the project.

Possible Process Innovations
Blitz Planning

Blitz planning is a strategy used to find all of the functionality the system will require and then, very roughly, divide that functionality into releases. Although it only requires a couple of hours, it can give the entire team good perspective on the project in the long term.

Backlogs

Maintaining a backlog with all of the functionality that people think might be in the system helps everyone (customer and team) focus on the bigger picture when selecting functionality to be developed in the current iteration. This can help prevent the team from tweaking existing features when implementing new features would be more cost-effective.


Section 7.4. General Smells

7.4. General Smells

7.4.1. Burnout

Symptoms

One of the worst smells a team can exhibit is burnout. One of the goals of the project should be to produce a well-functioning and productive team. When engineers become bored or disconnected from the project, their productivity goes down, and they can become a drain on the enthusiasm of the rest of the team.

Possible Process Innovations
Sprint Planning Meeting or Iteration Planning Game

One source of burnout can be a lack of belief that the project can succeed. Impossible schedules and unreasonable demands drain everyone's enthusiasm. These strategies can ensure that the team has input into the plan. This helps ensure that they believe they can succeed.

Sprint Planning Meeting, Iteration Planning Game, or Kanban Scheduling

These planning strategies have an interesting side effect: because each engineer is selecting the tasks he will be responsible for, this promotes ownership of the tasks and can be an opportunity to expand his expertise into new areas (provided he is allowed to give an estimate that includes appropriate learning time).

Sprint Review

Demonstrating the progress that has been made at the end of each iteration can build confidence and momentum.

Individual Evaluation Strategies

Strong management can aid the planning strategies in helping people extend their capabilities and interests. Appropriate individual metrics and evaluation can encourage everyone to learn about new technologies and new areas of the system, which will increase everyone's enthusiasm for the project and the team.

Source Code Refactoring

Working on code that contains "broken windows" can be demoralizing for engineers because in general they prefer to build and work on systems that are well-designed. Seeing a lack of quality in the code can make it seem like quality doesn't matter, so why should anyone bother improving things? In these cases, training in refactoring techniques and allowing appropriate time for the refactoring activities inherent in every development task can improve team morale in addition to improving the quality of the product.

Pair Programming, Team Ownership of Code, and Open Workspace

The cohesion of the team is one of the best defenses against burnout. All of these techniques promote team cohesion and encourage the team to prevent burnout on their own.

"Gold" Cards

Iterative development has a very strong and repetitive rhythm that can leave engineers feeling as if they are slaves to the process. Iterations become mechanical, and boredom can result. "Gold" cards encourage engineers to break out of the rhythm for more open-ended explorations.

7.4.2. Engineers as Bottlenecks

Symptoms

In traditional organizations, there are often engineers that are "experts" in specific portions of the system. Usually, they are responsible for all of the changes anyone makes to that portion of the system. In an agile organization, those "experts" can become bottlenecks. If an iteration requires significant changes to the expert's part of the system, too much of the work may require that expert's time, leaving him overworked and everyone else idle.

Possible Process Innovations
Pair Programming and Team Ownership of Code

Paying attention to agile values, the solution to this problem is to have the expert share her expertise with other engineers. When other people are comfortable with that portion of the system, the expert will no longer be a bottleneck (though she may still be the expert). Having the expert pair with a number of other people on tasks affecting that portion of the system will help other people learn to work on it. This will promote team ownership of code, which will reduce all of your bottlenecks.

Individual Evaluation Strategies

It's important to recognize that the expert may find sharing his information to be quite threatening. His status in the traditional organization came from the fact that he was the only person who understood that portion of the system. He needs to understand that the team is not trying to take his status away. The negotiations involved in developing the expert's performance evaluation criteria can help him learn to play a larger role in the design of the entire system and in the education of other team members.

Pipelining Iterations

Finally, if it is impossible for the expert's knowledge to be shared effectively, pipelining might help you spread his effort over multiple iterations and reduce his impact on any one iteration. However, this has some significant risks. First, he'll probably be developing code that does not have customer visibility, so he won't be getting any feedback. Second, this is going to require a longer-term plan that may turn out to be invalid as the customer sees the deliverables of each iteration. Finally, you have segregated that individual further from the team, which undermines the team's ownership of the system. This strategy goes against many agile values. It should only be undertaken when there is no alternative. At a minimum, pair another programmer with the expert in the hopes that the paired person will be able to bring the expertise back to the team.

7.4.3. Floundering

Symptoms

Floundering occurs when the team or an individual doesn't know exactly what needs to be done. In these cases, engineers are very good at looking busy but are not making optimal progress on the required tasks.

Possible Process Innovations
Spring Planning Meeting, Iteration Planning Game, or Kanban Scheduling

The primary source of floundering is lack of a specific iteration plan. Any of these techniques will let the team specify all of the things that need to be done in the current iteration and help them negotiate who is responsible for each task. These techniques only require an hour or two at the beginning of the iteration, and they let everyone see exactly what needs to be done for the entire iteration.

Daily Scrum/Daily Stand Up Meeting

Regular status meetings can reduce floundering by giving each engineer a regular opportunity to talk about anything that is preventing her from making progress so that the team or the team leader can help eliminate those problems. In addition, having to report progress to the team every day encourages people to stay on task.

Burn-down Chart or Informative Workspace

Making the status of the iteration easily available can help everyone see when progress is not as expected. Given that information, the team will readily detect any floundering and eliminate its cause.

Pair Programming or Open Workspace

Often, individuals flounder when they are having trouble finding a good design or making a piece of code work. Having teammates close by to bounce ideas around can help people get unstuck very quickly. In addition, there is a certain amount of peer pressure to keep working when colleagues are close by.

Backlog

When a team nears the end of an iteration, sometimes they finish tasks early and have nothing left to do. In these cases, having a backlog lets the team find another feature that the customer wants and that fits in the time left, so they can deliver one more feature. Alternatively, these lulls at the end of an iteration can be filled by having a list of non-deliverable tasks that would benefit the team. These could include things like researching a new technology or developing or deploying a technique or tool to help the development process.

Change Iteration Length

It is very hard to flounder when deadlines approach, so one strategy to manage floundering is to shorten the iteration length. This has two effects. First, it makes the estimates more accurate and therefore the plan more realistic, so the team knows better what needs to be done. Second, it makes the deadlines closer, so there is less room for floundering at the beginning of the iteration.


Section 7.5. References

7.5. References

[1] Hunt, Andrew, and David Thomas, The Pragmatic ProgrammerFrom Journeyman to Master, Upper Saddle River, NJ: Addison-Wesley, 2000.

[2] Reeves, Jack W. , "What is Software Design?" C++ Journal, Fall 1992.

[3] Tate, Kevin, Sustainable Software DevelopmentAn Agile Perspective, Upper Saddle River, NJ: Addison-Wesley, 2006.