Are you Agile or Waterfall?
Are you Agile, or are you, waterfall? Scrum or Kanban? PRINCE2 or PMBOK? Recently my LinkedIn feed seems to be full of these ‘X vs. Y’ debates.
I have long puzzled about why we are so tribal about the various delivery methods, approaches, and guidance that exist. Perhaps it is because of a desire to differentiate ourselves or to align with people with a similar perspective on organizing for delivery. Maybe it is because having invested in expensive training and consultancy; individuals feel compelled to create self-reinforcing loops to ensure the framework that they have certified in continues to be valued.
The rise of the APMO
The term APMO has been appearing recently, distinguishing normal PMO (whatever ‘normal’ means) and the Agile PMO. According to Scaled Agile Inc. in its SAFe 5.0 framework, the APMO supports portfolio operations and program execution. It goes on to state that the Agile PMO:
Facilitates the portfolio sync
Works with the LACE (Lean-Agile Center of Excellence) to develop, harvest and apply successful program execution patterns across the portfolio
Facilitates lean budgeting and coordinates portfolio governance
Fosters decentralized planning and operational excellence
Fosters more agile contracts and leaner supplier and customer partnerships.
While some of these responsibilities are focused on agile and lean, the overall aims are broadly the same as the aims of any other Project Management Office. Given there are more similarities than differences, why would a department attempt to constrain itself to only working with agile approaches?
Of course, the tribal mentality is nothing new. Indeed it would have been a useful trait for developing the species thousands of years ago. Maybe it still is today. But PMO professionals need to be mindful of this so-called In-Group Bias and rise above it if they are to become business catalysts and help their organizations become effective at delivering a return on investment.
With evermore PMOs operating at the strategic or enterprise-level in organizations, it is more important than ever that they are what I like to call Framework Pragmatists. To be completely framework-agnostic would be inefficient – delivery needs to be within the confines of the organization, which means adhering to organizational governance and principles. Depending on the industry your organization operates in, there may also be legislative governance to consider. There is no doubt that PMOs can drive serious efficiency by defining an organizational framework that helps Project Managers and delivery leaders to navigate the business and reduce the risk of initiatives falling foul of data governance legislation, or capitalization rules, for example.
But frameworks need to be pragmatic enough to accommodate the best delivery methods, tools, and techniques for the job. I’m not just talking about whether projects should be ‘Agile or Waterfall’. The best techniques from both can mesh together to great effect. Contrary to what some would have you believe, there is nothing wrong with a project being run using a ‘Wagile’ approach! A simple example is the use of Agile Retrospectives. These powerful ceremonies ensure lessons are learned quickly and that corrective actions are taken during projects, rather than being filed away for the next time a similar project comes along. The Retrospective format can be applied in any team and at any time. It works just as well for operational teams as it does for Scrum teams and PRINCE2 projects. We should not allow our bias to limit the use of Retrospectives to our Agile teams. There are numerous examples of ceremonies, tools, and techniques that can be applied to great effect in a variety of different contexts, and Project teams should be encouraged to read widely and mesh methodologies together for optimum results.
But there is a broader perspective too. Increasingly Enterprise PMOs (EPMO) have training and coaching remits. Many also have a remit for process improvement. These activities mean PMOs are increasingly becoming involved with optimizing operations, as well as optimizing project delivery. Again, PMOs should be able to draw from a lake of knowledge and encourage operational teams to adopt techniques that are used by project teams and vice versa. Agile is an excellent example of where this can happen. While project-people tend to think of Agile as a project delivery method, its roots are firmly in the world of manufacturing and product development. The tools of the factory floor were adapted for use on software projects to significant effect, and now we are starting to see those refined toolsets being taken up elsewhere in the business, such as in Marketing and HR. Mature Enterprise PMOs are able to act as a catalyst, not just for projects delivery, but operational delivery too.
Blurring the lines between Project delivery and Operational delivery can be a good thing. People with a projects’ background are prone to see everything as a project. However, we also understand that projects are deeply inefficient vehicles for delivering value. High numbers of projects fail, deliver late, or way over budget. To some extent, this is understandable. Projects are risky by design and cut across established (and efficient) business processes. If PMOs can identify ways to operationalize the delivery of some project work, then it is logical to assume delivery will be cheaper and faster. There are several ways that this can be achieved: for example, creating dedicated Product Delivery Teams who deliver new functionality while undertaking maintenance/hygiene tasks. Such Product Delivery Teams use Kanban boards to prioritize and track work, drawing heavily from manufacturing techniques such as JIT and Lean.