How to Manage an Agile Project

A common root cause for crisis in an Agile project is lack of common understanding of project drivers and constraints. The common understanding is missing because

• Roles and related tasks are not fulfilled
• Communication horizontally & vertically is not adequate
• Planning & follow up is missing.

What to agree before a new project starts

Project Type

Agree on the type of the project. That will define how the project must be managed. That will also help to agree on compromises during the project.

• Fixed scope project, meaning for example replacing an old system 1:1.  
• Fixed time project, meaning for example replacing an old system with end of life on a specific date 
• Remember that a fixed budget and a fixed team becomes a fixed time project, because the burn rate for budget is constant
• Combination with flex on scope and time, where often both budget and progress are estimated regularly per stage or Sprint.

Roles

Once the project type is clarified you must clary the team structure and roles:

• What's the role of Scrum Master and Development Team in this particular project? Do all the stakeholders share the expectations?
• Is there a Product Owner (PO) or a Product Owner Team? How are they available? What's the role of PO in this project? Do all the stakeholders share the expectations?
• Does the Product Owner need training and/or coaching? Who takes a responsibility?
• Is there a Project Manager or Product Manager? How does those roles align with the Development Team and the PO?
• Does the Development Team(s) have all the competences they need go from from concept to production? Are there shared specialists between projects? What is their availability? (e.g. Business and Service Design, UX, Architects etc)?

Release value early and often

No matter size of the project, the project will have more than two releases planned. Releases are used to involve real user groups and customers to contribute, give feedback and commit on project goals.

Every project is unique. Therefore, customer feedback must be gathered as soon as possible and throughout the project. Otherwise, project will be a sure failure. Continuous integration and continuous development are all good, but this is about having users to provide feedback.

Delivering early and gaining early feedback reduces project risks by validation of assumptions and making sure project is solving the right problem in right way.

Create a Plan

• What is the project vision, schedule, budget, team structure etc.
• What are the main features and architecture.
• What and when are the main releases.

All plans have risks. It is rather certain you will not hit the original content, schedule and budget once the project is finished. For a plan you may use stretch objectives and confidence levels. They will help you to create and communicate the plans. They also help you to manage risks. Best plans are created incrementally and they are made to be changed based on the learnings, i.e. iterative & incremental planning.

Measure the Project Progress

The project progress should be measured constantly. You should check at least weekly if the near-term and long-term targets are still valid.

Agile Project Management aims to keep the ongoing iteration or Sprint fixed. Project should be able to release the must have features during the Sprint. One of the most common risks is that the Spring Goal is not reached.

Be aware of the Team Availability. Check your availability and capacity in every Sprint Planning Session. Often, even if developers are 100% available for the project, their work consists maintenance tasks. It is common that a developer uses up to 50% of time for fixing bugs of old features. Absences can be also caused by vacation, allocation to other projects, training sessions, etc.

Once the Sprint is released, have a Retrospect and review what was the velocity of the team and you will be able to plan the next Sprint better.

Plan also for the maintenance from the beginning of the project - involve customer and our Continuous Services.

Minimum set of Project Metrics

Measure to understand, not to judge.

Each project shall use metrics to gain understanding of current status, to see if decided changes are effective and to forecast future.

Measure and track at least the following metrics:

• Cycle time. Cycle time tells how long it takes to complete a standard size task.
• Throughput or Velocity. This tells you how many standard size tasks your Development Team and complete in certain time period. Velocity is commonly used in Scrum to measure throughput of a single Sprint. If not using Scrum, consider using throughput; how many tasks are delivered per week.
• Track constantly actual Cycle Time and Velocity to learn and improve your estimates.
• Create a cumulative flow diagram (CFD). A well maintained CFD will tell you everything regarding project progress: Size of a Backlog, amount of new tasks, cycle time, lead time, work in progress, remaining to be done.
• Track team morale at least monthly to ensure they are confident, enthusiastic, proud and high in team spirit.
• Extend your metrics over time if needed. You may consider measuring technical stuff like build time and test coverage. You should consider measuring user satisfaction and reviewing user feedback. When going forward with the functionality, you may need to start measuring bug metrics, like bugs found before release and bugs found after release.

Summary

1. Create a Release plan, which tells clearly your vision, roadmap and increment plan. It can be just a simple picture, which is easy to update.
2. Create a Budget. Again a simple picture is enough to tell if the project is running on budget and how much money is left.
3. Measure Cycle time and Velocity. You can again track start and end dates of features with post-its on a wall, simple chart or a picture easy to update.
4. Use a Cumulative Flow Chart to calculate at least weekly how many items are in each state.