Concept: Evolve to continuously obtain feedback and improve |
Divide the project up into short time boxed iterations to demonstrate incremental value and obtain early and continuous feedback
Relationships
Related Elements | Risk Management
Main Description
### 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. 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: Manage Iteration 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.
More Information
Concepts | Risk Management
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright