The Agile PMLC (Project Management Life Cycle)

Many companies readily admit that the concept of Agile development for software projects fits into their desires to react quickly to changing market forces and their desires to improve speed to market for many corporate initiatives. As competition is a key driver in business, lots of companies attempt to make the switch to Agile to achieve, in some cases, a sustainable competitive advantage, and in other cases to just keep pace with opponents to forego losing market share.

Despite the support from senior leadership, and the assigned resources to be successful, many organizations are experiencing difficulty adapting to an Agile framework. A common challenge businesses face involves actually incorporating Agile projects into an already existing and highly structured Project Management Life Cycle (PMLC). The concept of Agile is a mental shift and is often perceived as minimally documented just-in-time software development and thought to lack the structure of traditional waterfall projects. Many Agile projects are run outside of the PMLC because they do not map to it as easily as do waterfall projects. However, I argue that the Agile framework fits into the PMLC overlapping both the Project Planning and Project Execution phases.

I had a client that has a PMGO (Project Management Governance Office) in place which provides structure for how projects should be run, emphasizing a PMLC for projects to follow. This structure does not readily accommodate for Agile projects; however, as a Scrum Master, I implemented a blended approach to fit my Agile project into their predominately waterfall processes.

Project Initiation is project initiation. All projects, whether business process reengineering, traditional waterfall software development, or Agile software development, should produce documents which satisfy the initiation phase of the project. This includes the Project Charter, Work Breakdown Structure, Risk Analysis, Communication Plan, and Stakeholder Analysis. The Communication Plan for my project included descriptions of all of the Agile ceremonies necessary for running the project: Product Backlog Development, Backlog Grooming, Backlog Release Planning, Sprint Pre-Planning, Sprint Planning, Daily Stand-up, Sprint Demo, Sprint Review, and the Sprint Retrospective. The Project Initiation phase should also capture all of Scrum Team’s methodology for Estimating stories, A Themed View of the Product Backlog (which serves as the Work Breakdown Structure), and a timeline outlining the weekly activities for each Sprint.

Project Planning for an Agile project is composed of the specific Release Plans for the project, laying out the forecasted stories for each Release. The forecasted Stories are identified based on the projected velocity for the Scrum Team. The velocity is determined according to the number of Developers and Quality Assurance Analysts assigned to the team and the time box allocated to the Sprint. Other Agile activities in this phase include Sprint Pre-Planning and Sprint Planning which tightly align to Detailed Planning in the PMLC. Project Execution for my Agile projects is an iterative phase which is repeated with each Sprint. The Monitoring and Controlling during my Agile project is done through several activities: Daily Stand-up, Weekly Status Reports, and through the Sprint Demo, Sprint Review, Sprint Retrospective, and Burn-up Chart which are all conducted at the end of the Sprint.

During the Project Execution phase, I use the Weekly Status Report as the artifact to manage the project issue log, log all project risks, track resource utilization, track costs, and to report any changes in the technical direction of the project. Lastly although Sprints are iterative forecasts of proposed work efforts, Schedule Variances can be reported at the Sprint level by measuring the Team Velocity against the actual Story Points accomplished during the Sprint.

Change Management is interwoven into the framework of an Agile project. At the end of each Sprint, the Team participates in a Sprint Review. During this ceremony, the existing technical direction of the project is evaluated against the learnings the Team accumulated during the Sprint. As a Team a decision is made whether to modify the technical approach or to remain on track with the existing direction. As it relates to the scope of work effort for each Sprint, the Product Owner simply prioritizes the Product Backlog with the User Stories that are most important for the project. Sprint Pre-planning Meetings are when the Team reviews the newly prioritized User Stories and discusses the impact to the existing technical direction. Ultimately, any features which are deprioritized below the agreed to Product Release milestone will move into another iteration unless additional resources or time are added to the project. With change being addressed in this manner, the need for formal Change Management processes becomes reduced. However, it is wise to document shifts in direction to capture the decisions made by the Team during the project.

Lastly, it is my experience that Project Closure for Agile projects do not typically deviate from the PMLC standards defined by the PMO/PMGO. Lessons learned from the individual Sprint Retrospectives should be aggregated into a single artifact. Furthermore, any formal sign-offs from the Product Owner to signify that the individual milestones occurring during the project were satisfied should also be combined into an artifact. I also recommend that a larger scale Retrospective be conducted as a helpful way to capture improvements for the Agile process for new projects within the organization.

Figure 1 below depicts how an Agile framework overlays the PMLC.

By overlaying the Agile Ceremonies into the PMLC, the Scrum Master/Project Manager is able to effectively adhere to the existing organizational PMLC structure, thus meeting Project Management Office (PMO) standards. The only real difference is the location of the documented information and the name of the artifact. The addition of the Agile artifacts to the PMLC will aid the organization’s ability to learn as the number of Agile projects increase; moreover, the move to Agile would not eliminate the level of documented communication typical of most waterfall projects. 

This lens for viewing the Agile framework through the context of the PMLC should now equip you to gain greater traction as you implement your Agile PMLC. Good Luck!