Agile Acquisition & Project Management

The Agile Manifesto

Developed by the Agile Alliance, the manifesto outlines four tenets and twelve principles which emphasizes a customer centric development approach for software.

The four tenets are:

1. Individuals and interactions are valued over processes and tools
2. Working software is valued over comprehensive documentation
3. Customer collaboration is valued over contract negotiation
4. Responding to change is valued more than following a plan

The twelve principles of the Agile Manifesto are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face to face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical detail and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviors accordingly.

The following compares and contrasts various aspects of Traditional Project Management with those of Agile Project Management:

Agile Project Management Framework

There are five different phases of the Agile Project Management Framework. These phases include:

• Envision: Determine product vision and scope, the project community, and how the team will work together
• Speculate: Develop a feature-based release, milestone, and iteration plan to deliver on the vision
• Explore: Deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project
• Adapt: Review delivered results, the current situation, the team’s performance and adapt as necessary
• Close: Conclude the project, document lessons for future improvement and celebrate

Stages of The Agile Roadmap

• In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organization’s strategy, and who will use the product. On longer projects, revisit the product vision at least once a year.
• In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise the product roadmap at least twice a year.
• In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five sprints. Create a release plan at the beginning of each release.
• In Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration.
• In Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.
• In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders.
• In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint.

Agile Project Management Roles

It takes a cooperative team of people to successfully complete a project. Agile project teams are made up of many people and typically include the following five roles:

• Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer’s needs and priorities. The product owner works with the development team daily to help clarify requirements and shields them from organizational noise. The product owner is sometimes called a customer representative. The product owner, above all, should be empowered to be decisive, making tough business decisions every day.
• Development team members: The people who create the product. In software development, programmers, testers, designers, writers, data engineers, and anyone else with a hands-on role in product development are development team members. With other types of product, the development team members may have different skills. Most importantly, development team members should be versatile, able to contribute in multiple ways to the project’s goals.
• Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator. Scrum masters are servant leaders, and are most effective when they have organizational clout, which is the ability to influence change in the organization without formal authority.
• Stakeholders:
• Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project’s outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies. For agile projects to succeed, stakeholders must be involved, providing regular feedback and support to the development team and product owner.
• Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level. Although agile mentors are not responsible for executing product development, they should be experienced in applying agile principles in reality and be knowledgeable about many agile approaches and techniques.

Lessons Learned

In 2008, the Honorable former Under Secretary of Defense, Acquisition, Technology & Logistics (USD AT&L) Dr. Jacques Gansler gave a briefing to the Naval Postgraduate School in which he stated the following Spiral development findings to date:

• Requirements— Users must allow more flexibility with their requirements
  • Users must accept less capable systems (80% solution) earlier, then evolve to desired level in later blocks
  • Acquisition team must develop a long-term system view, not a narrow focus on current spiral
• Budgets
  • Total program cost estimating is more difficult due to requirements evolution
  • Cost must be viewed as a design constraint--otherwise program baselines may be less well defined
  • Must budget for R&D in future blocks while current block is underway
• Logistics
  • Spiral development creates greater demands on logistics concepts
  • different system configurations impacts on sparing, training, maintenance, etc
• Test and Evaluation
  • Early operational feedback to shape development and formal testing
  • Test community must view partial capability of early blocks as a success
• Program Management
  • Generates higher intensity of contract action
  • Requires different skill mix in program office
  • Planning for Spiral “N+1” is a critical Spiral “N” task