Many people are attempting to use agile sprint- or iteration-driven processes to build products in environments where traditional waterfall project management processes are built into the culture. Looking at the apparent cognitive dissonance between the two models, many people give up. There is no need to give up, but there is need for creative thinking. Frankly, agile projects are being successfully conducted in these environments every day. I’ve led such projects myself repeatedly.
This post discusses a simple visual model I have used with several clients that shows how to get this to happen relatively smoothly. For the purposes of this post, I’m using Scrum as the agile framework of reference. A similar approach can be used with other iterative methods and frameworks.
This model is designed for use in large complex hierarchical organizations where traditional project management is currently established. It is not necessarily intended to be implemented as shown below if there is no traditional project management model in place unless the following are true and there is a sense that implementing a traditional project management model is the best approach to deal with these cultural realities:
- There are many active stakeholders inside and outside the organization (as in government) who will require regular attention during the project, often in public forums.
- There are many layers in the organization that all need to be communicated with regarding the execution of the project (as in large healthcare companies and banks).
- There is significant business process change that needs to be accomplished along with the development of a product. There are emerging agile change management and governance models, but they are not the subject of this post, and widely accepted agile frameworks, such as Scrum, do not appear to manage business process change well.
The graphic above shows the traditional five phase project management model (with Executing and Monitoring combined). Note that the roles shown above beyond the Scrum roles and the Project Manager are aligned with a specific N-Tier IT organization. I’ve used this model in a number of organizations and adapted it to a number of organizational roles.
Projects structured around this model have historically been predictive and “waterfall” in nature. As this post will show, pulling the project management activities up to a higher level, as described in The Software Project Manager’s Bridge to Agility by Sliger and Broderick, allows both the project manager to assure delivery along the traditional project trajectory and allows the Agile Team to continue to iterate, inspect and adapt, and progressively deliver on changing customer needs across the lifecycle of the project. Scrum sprints are superimposed on the last portion of the Planning phase and extending to the Closing phase.
The Initiation phase contains activities during which the organization is determining whether to do the project. Agile visioning activities may start in this phase. This is also the phase in which the Project Manager or the PMO advocates for using agile processes. The project charter document describes:
- the project purpose and scope at a high level,
- high level cost/benefit, risk and issue analyses,
- high level assumptions at chartering time,
- budget for the work to be done,
- very high level requirements (a few bullets),
- current high level risks and issues,
- and identifies the sponsor for the project.
Charters are meant to be maintained throughout the project. It will serve you well to state this fact and how it will be done in the charter itself.
During the Planning Phase project planning documents are written at a high level—just enough content to provide a context for the agile process to work in and to help the organization and stakeholders understand how the project will be executed and monitored using high quality agile process, principles, and practices within the traditional project management framework. Aspects to consider are:
- the role definitions, both traditional and agile,
- how budget, schedule, and scope will be maintained,
- how reporting and statusing will occur and who will be responsible for which kinds of reporting and statusing,
- an overall stakeholder communication plan,
- how risks and issues will be identified and managed including how impediment management plays into this,
- business transition management planning,
- deployment planning,
- training plans,
- how change control will work in concert with agile processes,
- how high level decisions will be tracked,
- and a project management process quality management plan.
At this point you may be envisioning a document hundreds of pages long. No. For instance, in one government homegrown web application project involving one Scrum team and an entire state of stakeholders which finally cost nearly $5M and involved extensive legal interactions the project plan was four pages long. The documentation embodied in ongoing reporting and backlog development to support requirements traceability, coding, testing, and maintenance which evolved over time as a result of the project execution activities was extensive.
As shown in the diagram above, the agile Planning Day activities straddle a portion of the Planning and Executing/Monitoring phases to indicate that the Scrum Master, Product Owner, and Team roles are staffed, visioning is complete, and the initial Product Backlog is developed before sprinting begins. Depending on the project context, including the comfort level of the Team and Product owner, the Project Manager may attend or debrief Planning Day activities with the Product Owner.
Executing and Monitoring activities on the part of the Project Manager may include:
- monitoring the sprint and release burndown charts,
- monitoring bug trends,
- monitoring and negotiating contracts for any contracted staff or vendors involved in the project,
- attending external stakeholder meetings,
- attending steering committee meetings and representing project level risk and issue metrics and budget and schedule metrics, if a steering committee is in place,
- handling organizational impediments passed out of the Team via the Scrum Master,
- updating high level plans,
- monitoring risk and issue lists for aging and thoroughness of mitigation and resolution activities,
- supporting the sponsor and Product Owner (if not the same as the sponsor) in external communication activities,
- assuring business process change management is moving along at a rate that will allow the business to implement the product as it becomes available,
- supporting the Scrum Master in assuring adequate engagement and staffing of the Product Owner role,
- maintaining and presenting any PMO-level dashboards that may be required in collaboration and alignment with the Scrum Master and Product Owner,
- and (if not handled by the Product Owner) maintaining and reporting on the budget.
In the Closing Phase, the Project Manager (depending on the nature of the organization) may be engaged in such activities as:
- completing and communicating the overall project metrics report,
- assuring that an overall, project-wide lessons learned meeting is held and reported on,
- assuring that maintenance agreements and warranty agreements are honored by vendors,
- assuring that maintenance staff (if different from development staff) are fully engaged and that knowledge transfer is complete to support any enhancements or defects that come up after the product is fully transitioned to maintenance,
- closing out contracted staff contracts, if necessary.
- assuring that the organization is aware of all resources being returned to the organization after the development cycle is complete.
Agility is not an all-or-nothing-out-of-the gate proposition in large, complex organizations. A strong grasp of both traditional and agile methods and the intentions behind them as well as the organizational context you are working in will serve you well. And, there’s always more to learn.
