Evolve to continuously obtain feedback and improve
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 these it is unlikely they
will not change over the life of the project.
Therefore divide the project up into short time boxed iterations to demonstrate incremental value and obtain early and
continuous feedback. Shift the focus of the iterations as the project evolves.
The intent behind this principle is continuously obtain feedback and improve the product and the process being applied
by the project team. Not only the product evolves, but also the team finds better ways to work together and get
involved with stakeholders.
When you provide structure and create a mindset for continuous feedback and improvement, changes are accommodated more
easily. Feedback is captured early and often, being then absorbed by the project. High priority risks are confronted
early in the project, and by constantly identifying and attacking risks, there is more certainty about project progress
and quality. The process followed by the team can be adjusted accordingly to leverage lessons learned and accommodate
project pace and needs.
Practices
Execute your project in iterations
Developing a system in a single linear pass is difficult and makes it expensive to incorporate changes and new
knowledge. Worse, it can delay the discovery of risks.
Therefore, divide your project in a series of time boxed iterations and plan your project iteratively. This iterative strategy allows you to
incrementally deliver capabilities – 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 issues can be
addressed and improvements made at a lower cost, while you still have budget and time left to do so, and you have not
gone so far ahead that major rework is required. Iterative development supports rapid and timely feedback so the
software can be continuously improved along its development lifecycle.
Focus iterations on meeting next management milestone
Without a focus to bring closure to important project issues such as requirements and architecture, a project can
appear to making progress while risks and unresolved issues pile up. Without the correct focus it is difficult to
manage change.
Therefore, group the iterations into phases with the focus of the iteration on the objective of the phase. The project is
divided in four phases (Inception, Elaboration, Construction and Transition) each having clear, specific objectives –
the team focus and allocation of work will vary from phase to phase. Phases are further broken down into time-boxed
iterations.
Each phase has specific milestones with objectives to be achieved in that phase. These objectives support
business decisions that need to be made at the end of each phase. The understanding of whether the project is
progressing well or not is based on measurable objectives expected at each milestone.
Manage Risks
Postponing the hard work for later in the project significantly increases the risk of project failure, as uncertainty
arises. Ignoring or procrastinating on dealing with risks may lead to investing in the wrong technologies, a bad
design, and/or a set of requirements that may not address stakeholder needs. Unaddressed risks may mean running a
project with staff that does not have the skills required to do the job, or that you build an application different
from the one that stakeholders expect.
Therefore, attack risks or they will attack you! Continuously identify and prioritize risks, devising
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 is
baselined.
At the beginning of each iteration, the entire team should consider what risks they are facing, and make a list of top
risks, or revise an existing list. Make each team member’s and stakeholder’s responsibility to have the courage to
speak up and openly discuss risks as well as have the courage to not criticize the people who do speak up, even though
the risk may point at a flaw in their area of responsibility. For each risk, articulate a plan for tracking and
mitigating the risk.
Continuously identifying risks and devising strategies for mitigating them dramatically increases changes of project
success (see Balance principle for more information on risks).
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. Changes can be made early in the project usually to a very limited cost. As you
progress in your project, changes become increasingly expensive.
To satisfy customer needs, you typically need to introduce changes to the project, but the customer has to be aware of
the impact those changes bring to the project cost and schedule. If needed, document the changes. For informal
projects, a discussion with stakeholders may be enough.
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 (see Concept: Change Requests and Guideline: Assign Changes to an Iteration for more information).
Also important, understand the impact of not making the change. It’s all about how you balance the various
stakeholders’ priorities in your project (see Balance principle for more information).
Measure progress objectively
If you don’t objectively know how your project is progressing, you don’t really know if it’s 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. Define a set of objective metrics to collect during an iteration (e.g. requirements that were implemented and
validated, number of defects issued vs. fixed) and review them as part of the iteration assessment. Do not rely on single metrics, rather use a basket of metrics
and look for trends. See Guideline: Types of Metrics for more details.
With continuous feedback done on working software – supported by documentation and plans when needed – there is a
better understanding of project progress. Course corrections are done as needed to successfully complete the project.
The overall plan is coarse-grained, whereas each individual iteration plan contains the activities planned for that particular iteration.
Objective measurement of progress helps you to manage cost, schedule, people, and priorities.
Continuously re-evaluate what you do
Mistakes and errors are made during a project and if we chose to hide those mistakes then we risk repeating the same
mistakes. In addition, repressed social dynamic issues can poison the team. Therefore, create a safe environment where
people are willing to confess and share their mistakes with other team members. When conflicts do occur use the
experience to build relationships. See Collaborate principle for more information.
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 in a daily basis, when the team gathers together
to share the status of individual responsibilities and identify and address issues (see Task: Monitor and Control Project for more information).
At the end of iterations, assess
the status of what has been done and look for areas of improvement that can be addressed right in the next
iteration. Have a retrospective review at the end of the project and capture lessons learned to run next projects in a
more efficient way.
If we always challenge what we do, and seek new innovative ways to develop software, we can improve how we work, thus
leading to improved project results.
|