- Embarking on Your First Iterative Project
- Adopting an Iterative Approach Iteratively
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Adopting an Iterative Approach Iteratively
One of the most powerful things about iterative development is that it provides a platform for continuous process improvement. The adaptive nature of the management and development processes means that you can do more with your project's agility than just respond reactively to change—you can also respond proactively to the lessons learned and the trends exhibited by the project to continuously improve the project's working practices and performance.
Understanding Where to Start
Although we hope that by this point in the book you accept that iterative development and iterative project management are useful tools to deliver better results, we recognize that you cannot get there all at once. Your initial iterative projects are unlikely to exhibit all the desirable characteristics described in Chapter 2, "How Do Iterative Projects Function?"—let alone measure them. In our experience it takes the typical project team at least three evolutions to start to exhibit all the desired behavior and establish themselves as experts in iterative development. Iterative development covers a broad set of behaviors and cultural values that emerge over time when teams are focused on results. In choosing an approach to phase in improvements, we have found the model depicted in Figure 11-3 useful when thinking about what improvements must come first.
)
Figure 11-3 The Foundations of Software Development
As shown in Figure 11-3, the foundation of iterative development is provided by a shift in project management focus away from creating detailed plans and measuring activities against these plans to results-oriented project management. As we have discussed in earlier chapters, software development is inherently creative and somewhat unpredictable. This means that the precisely appropriate approach is also not entirely predictable. Focusing attention on setting the right goals for each iteration and measuring achievements against those goals is the first and most important step in adopting iterative development.
Introducing effective practices in the areas of release engineering and change management (specifically basic versioning, baselining, and control over the things the project is producing) is essential to supporting this shift to becoming "results oriented." The ability to manage change across iterations (to determine which changes should be addressed in each iteration) and the ability to create executable releases (which requires a reliable build process) are essential to being able to make the shift to delivering objective results.
These basic skills can take you a long way, and in fact they provide most of what you need to perform maintenance and defect fixing across a series of iterations. This covers a great deal of software development activity, and most organizations would gain tremendous benefit if they only did these three things well.
If you are involved in new product development or are making larger and more significant evolutions to the software, you will need to add some additional skills, primarily the ability to understand needs and define requirements (referred to as "Requirements" in Figure 11-3) and requirements-driven testing. If you need to build a completely new solution, you will probably not have the luxury of building upon an existing architecture. You will need to have a more disciplined way of forming the architecture of the system and translating requirements into designs.
As the solutions become more complex, you will need to draw upon all these skills in a fully iterative approach that is able to dynamically respond to new risks and find creative solutions to new problems.
The main reasons for presenting this model are first, to illustrate that most projects can get a lot of value from a basic focus on the fundamentals of results-oriented project management, release engineering, and change management without formalizing the approaches used for requirements, testing, architecture, analysis, or design, and second, to demonstrate that improvements in requirements management, testing, analysis, or architecture must be built on a good foundation of the "lower-order" techniques.
Improving Practices Iteratively
When applying this model to make improvements in a gradual or "progressive" manner, you should not strive to first become "perfect" at the lower levels before moving up to the next level. Instead, we recommend the approach depicted in Figures 11-4 to 11-6.
)
Figure 11-4 Improvements in the First "Cycle"
We recommend introducing new practices iteratively, in a sense taking a "slice" of a set of the overall practices that are to be introduced and implementing them in a series of iterations. We refer to this "slice" as an "improvement cycle," which could be a single iteration or could be as long as an evolution depending on the scope of the improvements being made. An improvement cycle consists of one or more iterations over which you will introduce some changes and then measure the results. The concept of an "improvement cycle" aligned with a specific set of iterations enables change to be introduced gradually and in a controlled way so that you can make sure that a more basic set of improvements has been successful before you introduce additional change.
As noted in Figure 11-4, early improvement cycles introduce simple concepts such as the notion of an iteration as a time box in which specific results are achieved. The shift to a results-oriented perspective from an activity-oriented one is important, and it represents a big leap for many people, so you don't want to confuse people by introducing lots of other changes at the same time. We have found that the improvements listed in Figure 11-4 tend to be the most important changes to introduce first.
The early improvement cycles are specifically not focused on formality or matters of style because this tends to derail success and gets people focused on formality and not results. The key point is to introduce some improvements from each "level" in a lightweight way and only to the degree that the changes improve results so as not to introduce too much change at once. Figures 11-5 and 11-6 show that as the team becomes comfortable with basic skills, the scope of the improvement effort can expand. Improvement cycles continue as long as the team feels that the improvements are adding value and reducing risk.
)
Figure 11-5 Improvements in Subsequent Early "Cycles"
)
Figure 11-6 Improvements in Later "Cycles"
Specific improvements are driven by issues identified in iteration assessments to keep them focused on practical project needs. This approach enables the team to make progress and improve results while still getting useful work done. The boxes in the figures indicate the kinds of improvements that are typical in early and later improvement cycles.
The essence of this approach is to introduce techniques in each improvement cycle to address the specific needs of the team rather than adopting a set of techniques wholesale. This enables the project team to show results while they are improving rather than letting the improvement effort stand in the way of producing results. This overcomes much of the traditional resistance to change.
Learning by Doing
The advantage of this approach is that people learn by doing, and they learn only what they immediately apply. The conventional wisdom (as practiced in much of the industry) is that change is introduced by defining the new processes, selecting supporting tools, and then training everyone on the new processes and tools. As it turns out, this approach actually increases the risk that the change will fail—the opposite of the intended result.
Training is necessary but on its own is not sufficient and is often over-emphasized at the expense of informal experiential learning. To understand why, let's consider five stages of learning: [3]
- Knowledge— Basic knowledge of the concepts and the facts
- Comprehension— Demonstrated understanding of concepts
- Application— Ability to apply concepts in simple contexts
- Evaluation— Ability to apply judgment on when and how to apply concepts to more complex contexts
- Innovation— Ability to extend concepts to new contexts
All that can be expected from a training class is to convey basic knowledge and maybe to provide some practice in applying the concepts. Time and experience are needed for the change to actually take hold in the day-to-day activities of the team. Only when this occurs is the change successful.
To achieve sustainable results, change must be driven by doing real work. There are several reasons for this:
- People don't like to change, but they will change if they can see that change leads to positive outcomes. "Positive outcomes" means different things to different people. For management, it might mean more reliable schedules and improved delivery capability. For the people on the project, it might mean improved career development or improved quality of life. Successful change initiatives usually require the majority of stakeholders to achieve some positive result. The sooner positive results are shown, the sooner support for the change builds.
- Even positive changes are initially disruptive; few situations are so bad that change is not initially destabilizing. In addition, most changes take some time to produce results. While the changes are underway, a reserve of "good will" is gradually consumed until results become visible. The longer the change takes to show results, the more "good will" is consumed. While "good will" exists, the organization can afford to be patient, but after it is exhausted, impatience takes over and the change effort typically falls apart. The problem is that organizations that need to change the most typically have the lowest reserves of good will. As a result, it is essential that results be demonstrated throughout the change effort to maintain the momentum of change.
- Real change only occurs when people's daily habits change; habits change only with time and practice. As a result, change based on "telling and teaching" almost never succeeds. Real change requires "doing."
Achieving improved results is not inconsistent with introducing change. In fact, achieving improved results while doing real work is essential to achieving sustainable results and is at the heart of the iterative approach. At every iteration assessment, lessons will be learned and acted upon to improve the project's performance and results. By its very nature, iterative and incremental development encourages learning by doing for everybody involved in the project, which enables the approach to support its own adoption and improvement.
The Role of Coaching
When a new way of working is introduced, it is important to support the transfer of knowledge and application of new ideas. Workshops are an effective way to do this because they enable people to learn in the context of doing real work, and they accelerate the rate at which people can be productive using the new techniques.
To feel confident in the change, people need to be able to focus on "doing" and not be distracted by "figuring out what to do." Experienced practitioners who lead people through the new behaviors, getting them to apply the new process by doing, must provide guidance and coaching. Having experienced coaches available to the project team provides confidence in the outcome by providing experienced resources for the project team—people who have already been successful on other projects. A sense of confidence in the outcome is essential to building resilience within the team so that team members can recover from the inevitable setbacks that occur in any change effort.
To facilitate experiential learning, coaches enable the team to focus on "execution" instead of process definition. In addition, there are several other benefits of this approach:
- It builds support for the change by creating real success early.
- It lets team members focus on "learning by doing" rather than sending them to classes and hoping they can put the knowledge into action on their own.
- It builds expertise within the team so that over time the team can support the new way of working without external help.
- It reduces the risk of failures, delays, and quality problems resulting from the team's learning by doing.
- It accelerates the learning process by eliminating much of the uncertainty, discussion, and trial-and-error associated with learning by doing.
Some coaching is usually necessary to enable project team success. This will vary from team to team, but typically follow-on workshops are used to develop skills needed to execute the iteration plan. For example, in the Inception phase, project teams will need to understand how to understand the problem and create a vision for the solution; a workshop led by an experienced facilitator is often the most effective way to make progress toward this goal.
Sometimes the best coaches are on your own team in the form of the more experienced team members. Encouraging team members to work together to build team skills that improve team results also reinforces team cohesiveness. This does not happen accidentally, however; you will need to encourage it and plan for it.
Using the Iteration Plan to Provide a Roadmap for Change
The most effective method for introducing change is to tie the improvement effort directly to the work being performed. The most effective way to do this is to use the project and iteration planning effort (which must be done anyway) to drive the introduction of the new techniques just ahead of their need.
We have found that doing this through a series of focused workshops and subsequent hands-on mentoring jumpstarts results and facilitates skills transfer. For planning evolutions, an initial full-day workshop to bootstrap the development plan and the initial iteration followed by half-day workshops at the start of each iteration to review results from the previous iteration and plan activities in the upcoming iteration has proven to be most effective. The structure and contents of these workshops is as follows:
- Early in the evolution, a workshop is needed to create the development plan and the initial iteration plan and to outline the approaches to be adopted to requirements and change management (often in the form of requirements management and change management plans). Iteration plans are defined so that just enough process is introduced to meet the objectives of the iteration and support the goals of the current "improvement cycle." In this way, the project team learns the new ways of working by applying them.
- At the transition between iterations, a workshop is needed to review iteration results, plan the next iteration, and identify issues and action plans. This can include making mid-project adjustments to the process used by the project, adjusting approaches as well as the pace of change. Sometimes the change will be too slow and the pacing can be accelerated; other times the project team will feel that the change was too fast and the improvement plans for future iterations will need to be scaled back.
The key to making improvements is to use the iteration plan itself to map the change activities as well as regular project activities. Change activities need to be viewed as integral to the project—tasks that the project does to achieve better results, not something external that detracts from results. If we don't believe that improved results will be derived from a change, why would we want to pursue it?
The iteration plan can be a powerful reinforcement to the change—or the means by which the change is undone: if the plan supports the change, it will tend to succeed, but if it fails to reinforce the new desired behaviors, the change will not happen no matter how much support is otherwise given.
As we have discussed, the project is structured into a series of iterations that establish a kind of heartbeat for the project, enabling it to set intermediate milestones to check progress, to establish points at which non-essential requirements can be scoped out, and to enable mid-course corrections to the project plan. This also acts as the heartbeat for change, enabling 1) short-term improvement objectives to be set, implemented, and assessed, 2) the change to be tested, and 3) mid-course corrections to made to the improvement plans.
Finally, planning is nothing if the execution of the plan is poor. Some people act as if a good plan will implement itself. In reality, a mediocre plan with excellent execution is better than an excellent plan with mediocre execution every time.