Many project portfolios now includes a mix of project types and methodologies, such as traditional waterfall projects, agile-based projects, six-sigma projects and ‘stage-gate’ projects for new product development. I’m continuing my agile PPM myth busting series today addressing the third most common fallacy: Agile and Traditional Practices Aren’t Compatible.
Project management leaders have, for the most part, embraced agile practices and have attempted to redefine their roles to focus less on planning and controlling agile projects, and more on providing an environment to allow agile projects to succeed.
However, even with this willingness to adopt agile, integrating agile projects into a PPM framework has proved challenging for many organizations. Project managers are being faced with different (and often conflicting) methodologies, metrics, and controls. In addition, some teams are adopting ‘hybrid’ processes that include elements of waterfall and agile methodologies and are confused about how to rationalize seemingly incompatible methods. To solve these challenges, PMOs require an updated framework that incorporates agile practices, provides clarity to project teams on how to communicate project health, and provides predictability and accountability to executive stakeholders.
Integrating an agile project methodology into a PPM framework is no different than integrating a more traditional project methodology, with four exceptions:
(1) Agile teams work best when executives and project managers don’t stifle the agile process. Imposing unnecessary stakeholder reviews, checkpoints and data capture requirements on an agile project will reduce the effectiveness of the team. Of course, if major decisions need to be made with executive input or the agile project has dependencies on other projects, stakeholder meetings will be necessary, but these should be the exception, not the rule.
(2) Agile projects measure progress ‘story points’ complete or business value delivered. This is a fundamentally different way of tracking progress than using a task plan and measuring task hour completion. In addition, a project manager assigns tasks to owners in a traditional project, whereas agile teams are often self-organizing, so tasks may be reassigned at any time by the team to ensure project delivery is on track. This difference requires that metrics for ‘project health’ and ‘percent complete’ are tracked differently from projects based on task hours.
(3) Given the task assignments within an agile team are dynamic, it’s unwise to assign a resource part-time to an agile team as this breaks the self-organizing model. Instead it’s better to treat agile teams as a unit and assign resources to them full-time (with the exception of resources such as technical architects and DBAs, which are typically spread over multiple projects).
(4) Finally, regular reviews of agile projects are more focused on ‘working software’ than reaching pre-determined milestones or delivering project documentation. Reviews should be tailored to the type of project to ensure they are valuable to the team.
It’s true that some agile practices have fundamental differences with some traditional project management practices, for example the planning and executing process groups in the Project Management Institute’s (PMI) Project Management Book of Knowledge (PMBOK). However, it’s untrue the two types of practices can’t be combined to create a powerful project management framework.
For instance, agile practices are usually silent on project intake or project initiation processes, and traditional practices for project cost, communications and risk management are often more mature than the corresponding practices in agile. An experienced project manager can add practices from the PMBOK or similar methodologies to support agile projects without disrupting the culture and work practices of an agile team.
Have you brought together agile and traditional practices successfully? Let me know!