Concept: Evolve to continuously obtain feedback and improve

Introduction

It is usually not possible to know all stakeholders' needs, be aware of all project risks, comprehend all project technologies, or know how to work with your colleagues. Even if it were possible to know all of these things, they are likely to change over the life of the project. Therefore, divide the project into short, time-boxed iterations to demonstrate incremental value and to get early and continuous feedback.

The intention behind this principle is to continuously get feedback and to improve both the product and the process of the project team. When you provide structure and create a mindset for continuous feedback and improvement, changes are accommodated more easily, feedback is captured early and often, high-priority risks are confronted early in the project. By constantly identifying and attacking risks, there is more confidence in project progress and quality.

Not only does the product evolve, but the team also finds better ways to work together and get involved with stakeholders. The process followed by the team can be adjusted accordingly to leverage lessons learned and adjust project pace and needs.

Practices

The next sections describe the practices associated with this principle.

Develop your project in iterations

Developing a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new knowledge. Worse, it can delay the discovery and mitigation of risks, because development efforts are scheduled later in the lifecycle.

Therefore, divide your project into a series of time-boxed iterations, and plan your project iteratively. This iterative strategy enables you to incrementally deliver capabilities (such as an executable, usable subset of implemented and tested requirements) that can be assessed by stakeholders at the end of each iteration. This provides rapid and timely feedback loops so that issues can be addressed and improvements made at a lower cost. Also, this is accomplished while you still have sufficient budget and time left to do so, and you have not gone so far ahead that major rework is required. Iterative development enables teams to continuously improve software throughout the development lifecycle.

Focus iterations on meeting the next management milestone

Without a focus to bring closure to important project issues, such as stakeholder concurrence regarding scope and proving the proposed architecture, a project can appear to make progress while risks and unresolved issues pile up.

Therefore, divide the project into phases (such as Inception, Elaboration, Construction, and Transition), with each phase having a clearly visible management milestone. The focus of each iteration within a phase is on achieving that milestone.

Manage risks

Deferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such procrastination may lead to investing in the wrong technologies, a bad design, or a set of requirements that may not address stakeholder needs.

Therefore, attack risks early, or they will attack you. Continuously identify and prioritize risks, and then devise strategies to mitigate them. Determine the focus of iterations based on risks. For example, architecturally significant risks should be addressed early in the project, no later than the end of Elaboration phase, when the architecture has been proven and baselined.

At the beginning of each iteration, the entire team should consider what risks they are facing, and update the risk list. Make it each team member’s and stakeholder’s responsibility to have the courage to speak up and openly discuss risks, as well as to have the courage not to criticize the people who do speak up, even though the risk may point to a flaw in their area of responsibility. For each risk, articulate a plan for tracking and mitigating the risk.

Embrace and manage change

Change is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will result in a bloated, deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a change is made, the more the change is likely to cost.

Therefore, both embrace and manage change. Embracing change helps you to build a system that addresses stakeholder needs, and managing change allows you to reduce costs and improve predictability of those changes. Changes made early in the project can usually be made with limited cost. As you progress in your project, changes can become increasingly costly.

To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware of the impact that those changes have on the project cost and schedule. Understand the impact of a change in the current phase, and isolate team members from disruptive changes during the current iteration. Change requests are reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration.

If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.

Measure progress objectively

If you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding. Uncertainty and change make a software project’s progress difficult to measure objectively, and people have a most amazing ability to believe all is well in the face of catastrophe.

Therefore, get a clear picture of project status by objectively measuring progress. The best measure of progress is the delivery of working software, which is something that you do by taking an evolutionary approach. You can also define a set of objective metrics to collect during an iteration (for example, requirements that were implemented and validated, number of defects issued compared with number fixed) and review them as part of the iteration assessment. Do not rely on single metrics. Rather, use a combination of metrics and look for trends.

Continuously re-evaluate what you do

People make mistakes during a project. If we chose to hide those mistakes, then we risk repeating the same mistakes. In addition, such repressed social dynamic issues can poison the team.

Therefore, on a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team to track status and identify risks and issues. This can be done daily when the team gathers to share the status of individual responsibilities and identify and address issues. At the end of iterations, assess the status of what has been done and look for areas of improvement that can be addressed in the next iteration. Have a retrospective review at the end of the project and capture lessons learned to run future projects in a more efficient way.

If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads to improved project results.