Project Management Institute

Project management for agile software projects


More and more software projects are adopting agile software development practices to deliver successful projects. Agile books and publications emphasize the role of the Developer. By mapping A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 9 core areas of knowledge to agile principles and best practices this paper will outline the Project Managers role and how Agile can help your software projects deliver success.


Project Management Institute (PMI®) does not mean Waterfall Methodology:

PMI Body of Knowledge provides a wealth of knowledge and best practices on how to manage a project. These best practices are not focused on a specific type of project or industry. By providing the common phases of a project; initiate, plan, execute, control and close PMI provides a framework. This framework provides common vocabulary for Project Managers and allows project stakeholders to identify what phase a project is in.

At first pass, this seems like waterfall; define all requirements up front and get sign-off. Once requirements are locked down, design the implementation, then build it, then test it, integrate with other software projects at the end and finally show to project customers for approval – a very sequential process. For experienced Project Managers, sequential projects like this are seldom the reality.

Agile Project Management as it applies to the core PMBOK® Guide areas

Integration Management – Integrate early and often

A key tenant of agile is to identify your risks and address those early. In most software projects, integration is an unpredictable and stressful time in the project; integration is risky.

Integration is most risky when teams work in silos (or components) developing their part of the project and after local development and test is complete end-to-end test begin. When teams work in this manner, there are countless variables that can make integration unpredictable; network set-up, hardware issues in lab, permissions, interface changes that weren't managed to name a few.

Tips to manage integration in your software project:

  1. Treat an interface like a contract - Interfaces form a type of contract between teams and systems. Define these requirements early and manage changes carefully. When defining requirements don't forget to consider success and failure scenarios, network and hardware requirements, load, performance and other non-functional requirements.
  2. Interfaces first – build and test the interface early in the project. This provides several benefits including taking on the risky items early in the project when there is time to react. The team can verify assumptions made in the requirements. Working across teams can also establish great working relationships with partners early in the project.
  3. Build interface emulators – Emulators test the system as it is intended to be used. By creating these test harnesses, your project has a means to de-couple systems allowing more degrees of freedom thus reducing risk. A good emulator tests both success and failure scenarios.

    a.  Emulator for your partner(s) – Create emulators that simulate the inputs/outputs you expect from partners. This allows your project team to comfortably make change and quickly verify that this doesn't de-stabilize the larger project.

    b.  Emulator for your system – Creating emulators that simulate your system inputs/outputs has two main values. First, early in the project, your team may not have all the system functionality to build the final interface. Creating an emulator allows you to test integration before the entire system is ready. Second, share your emulator. Provide this to your partner teams as an extension to your interface agreement. This not only helps your partners, but it provides a great troubleshooting mechanism. If partners are having issues, they can verify issues with the emulator. This can insulate the project team from randomizing support issues

    c.  Is this throw away work? Definitely not! Use these emulators in your BVT (Build Verification Tests). By investing in automating your test cases, you'll be able to manage change much more easily throughout the project lifecycle.

Scope Management – Change Happens, embrace it!

How often have you worked on a project and heard “yes, that is what I asked for, but it isn't what I want”. Change is a certainty a software team can expect. Agile promotes processes to be flexible with change. By building a process that provides fast feedback loops, stakeholders are more involved and changes can be added more easily.

Tips to manage change in your software project:

  1. Iterations and Sprints – Whether your team uses Scrum, MSF (Microsoft Solutions Framework) or no formal methodology, use quick iterations to build working software and get feedback. Use the feedback to create deliverables in your next sprint.
  2. If it is tough to plan 4 weeks, cut your iteration down to 2 weeks. There are two benefits to this. First, the shorter the timeframe, the less uncertainty you'll likely have. Second, shorter iterations force the team to decompose work into smaller deliverables. Smaller deliverables should be easier to estimate.
  3. Hands On Demos: At the completion of each iteration, let your customers interact with the software as part of regularly scheduled demonstrations. Listen carefully to the questions asked; these can be the catalyst for new requirements.

Time Management – Estimating & Time Management

A good agile team is predictable and reliable in its delivery. The basis for setting and managing expectations is the iteration (in scrum, this is called a sprint). A project will be made up of 1 or more iterations. Iterations by definition are time-boxed and usually ranging in length from 1 to 4 weeks in duration. If a team can reliably deliver value within one iteration, it is far more capable to deliver a full project. On the other hand, if a team is struggling to meet expectations within an iteration, it will also be challenged to deliver based on longer timelines.

Estimating work is a key success in any project. Short iterations provide benefits in estimation accuracy by providing regular feedback on how well the team is doing at estimating work. At the end of each iteration, the team should evaluate itself on how well it estimated and identify how it can improve with the next iteration. A Best Practice for estimating within agile teams is using Story Points.

Deciding what to work on is defined by the business or Product Owner. Deciding how much can be done during an iteration is defined by the project team. After the team completes a couple iterations, the team will have a baseline of how much work can be done in an iteration. This is the team's velocity. The team is now able to balance its capacity with business demand. As a new iteration is planned, the team should only take on as much estimated work as they've delivered in the past.

Iterations provide excellent project trending. An Agile project, like most projects start with a defined scope and estimated effort to complete that work. With each iteration, the Project Manager can track the progress in a Product Burndown chart. If the project is not tracking to plan, the Project Manager has all the usual tools to begin mitigation planning and expectation management.

Cost Management – Shippable Software Every Iteration

For many projects, time and the number of resources are the primary cost variables. Projects that ship later than planned will naturally cost more. By embracing the idea that at the end of each iteration your team is ready to release the team increases the ability to convert from building value to deploying a solution.

Tips to help you be ready to ship with each iteration:

  1. Define a DONE list. The team should create a checklist of what the team needs to complete for an iteration to be complete. Some examples of done might be; test cases written and executed, automatic deployment to test lab and BVT tests pass, or demo to stakeholders.
  2. Build end-to-end scenarios with each iteration. By focusing on end-to-end scenarios a stakeholder can determine at any time when the feature is ‘good enough’. This puts the project stakeholders in control of how much time and energy to put into a single feature at the expense of other features.

Quality Management – TDD, Test Automation and Frequent Builds

Agile principles have some of the biggest advantages when it comes to Quality Management for your software project. Concepts like TDD, Test Automation, and Continuous Integration all help ensure the quality is always delivered.

Manufacturers and Lean Manufacturing practices ensure quality by establishing checkpoints throughout the process. Widgets are validated against specification (or control limits). Agile promotes the same concept, by always testing and integrating; a team can be confident their work meets customer expectations.

Tips to manage quality in your software project:

  1. TDD (test driven development). Build software with test cases in mind. Before the functional code is written, write and execute the automated test cases. Since functional code is not yet written, the test should fail and this confirms the test case works as expected.
  2. Automate test cases. The most important test cases to automate are your Priority 1 test cases. As your code base grows, the test effort will increase as well. If the team invests in automating the test cases, a growing code base is much more manageable and more cost effective to maintain over the long term.
  3. Implement automatic build, deployment and Test process (known as Continuous Integration). With each new build of your software, your system should automatically deploy the new code base into the test lab and run a defined set of P1 or BVT test cases. By doing this regularly (at least daily), the team has confidence that the most recent changes have not de-stabilized the larger project and meet a minimum quality bar. If the build or test cases fail, treat this as a high priority item to fix as quickly as possible.

HR Management – Leadership & the Self-Managed Team

High Performing teams seem to be a natural by-product for teams focused on continuous improvement. The core essence is to have a team that is accountable to itself and reflects on success and failures. Project Managers can have a very influential role on the dynamics of the team. The PM needs to ensure each iteration has a retrospective with meaningful and actionable outcomes. In some cases, the PM will need to be the facilitator and in other cases the PM can be a participant. The key is to recognize the strengths of the team and develop an environment where critical and honest feedback is valued.

Communication Management – Daily Stand-ups, Stakeholder Demo and Working Software

There are several forms of communication that need to be managed as part of a complex project. Agile provides a few handy ways to effectively communicate with team members and immediate stakeholders. Here are a few;

  1. Daily Stand-up meetings are intended to be short meetings for the working team to identify progress and blocking issues. If this meeting regularly takes more than 15 minutes, evaluate the topics discussed and try to find ways to cover just the basics. Meeting daily is also essential, each day the team should make progress on their tasks. The daily meeting is a chance for the team to be accountable to each other, not necessarily to the management team. Three common questions asked during this meeting are: What was accomplished since the last meeting? What is planned before the next meeting? Are there are any blocking issues?
  2. Demonstrate progress to stakeholders frequently. Allowing stakeholders to interact with real working software is a great way to get feedback and let the stakeholders see progress made. Engaging stakeholders first hand with real working software is one of the most effective ways to provide updates on progress.
  3. A Product Backlog Planning Session provides a great opportunity for stakeholders to prioritize what the engineering team should work on next. By meeting before the start of each sprint, project stakeholders have a chance to review progress and decide the priority of work the team does next. This provides a natural way for stakeholders to be up-to-date on progress and status.

Risk Management – Driving Between the Guard Rails

The fundamentals of risk management do not change with agile. An agile best practice is to work on risky items early in the project. At the start of a project, the team should identify the top project risks and identify mitigation options. Working on this early in the project lifecycle provides time to react to estimation errors. Additionally, if a Project Manager leads a team to integrate early and often, implementing continuous integration, and hold retrospectives at the end of each sprint, many risks will be mitigated before they have a chance to evolve into real issues.

Procurement Management – Agile and Your Contracts

Contracts come in all shapes sizes and types. My best advice is to weave the best practices mentioned above into your contracts and deliverables. Focus on good communication, early integration and hands-on demos will help keep several teams closer aligned to a common deliverable.

Beck, Kent (2005) Extreme Programming Explained, Upper Saddle River, NJ : Addison-Wesley

Beck, K.; Beedle, M., van Bennekum, A.; Cockburn, A.; Cunningham, W.; Fowler, M.; Grenning, J.; Highsmith, J.; Hunt, A.; Jeffires, R.; Kern, J.; Marick, B.; Martin, R.; Mellor, S.; Schwaber, K.; Sutherland, J.; & Thomas, D. (2001) Manifesto for Agile Software Development. Retrieved on 6/6/2007 from

Cohn, Mike (2004) User Stories Applied for Agile Software Development, Upper Saddle River, NJ: Addison-Wesley

DeCarlo, Douglas (2004). eXtreme Project Management: Using Leadership, Principles, and Tools to deliver Value in the Face of Volatility, Somerset, NJ: Jossey-Bass

Schwaber, Ken (2004) Agile Project Management with Scrum, Redmond, WA: Microsoft Press

©2007 Stein Dolan
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, GA, USA



Related Content

  • PMI White Papers

    How Agile are Companies in Germany?

    By PMI Cologne Chapter Until recently, Agile was considered as a set of principles and practices relevant only to software development projects. However, Agile is now spreading to other parts and types of organisations,…

  • PM Network

    Agile Capacity

    By Parsi, Novid Wrong resources? Right resources at the wrong time? Both can cripple project momentum—and send shock waves across the project portfolio, even threatening the organization's bottom line. And the…

  • White-Paper-Cologne-thumbnail.jpg

    How Agile are Companies in Germany?

    By PMI Cologne Chapter Until recently, Agile was considered as a set of principles and practices relevant only to software development projects. However, Agile is now spreading to other parts and types of organisations,…

  • Design Thinking to Improve Your Agile Process

    By Vukosav, Denis Agile project teams interact with users and deliver incrementally. This paper is an introduction to how design thinking, combined with agile, will further reduce the risk of failing.

  • PM Network

    Practical Guidance

    By Fewell, Jesse The debate about processes—when to follow them versus when to bend them in favor of deeper principles—has been an age-old, fundamental tension in project management. Those of us contributing to A…