Agile + PMO = Love!

But then, love is always complicated!

This is a topic that will probably not catch a lot of attention. Because those who do Agile don’t want to hear about PMOs (too rigid, tend to kill agility, useless, etc.) and those in PMOs don’t want to hear about Agile (no planning, no documentation, no management, etc.). Bad news for all of you! The world has changed and you have to work together. An example of how world has change is that the stereotypes mentioned above apply less and less.

And speaking of stereotypes, let’s talk about some that concern Agile. If you work in a PMO, this might clarify a few things for you.

• Agile is total freedom, chaos even! In Agile we empower people to act independently but within some boundaries. There are two elements to consider here: the empowerment and the boundaries. The Agile team will never decide about the product (that typically comes from the product owner), they’re just given little freedom so they can think of better solutions to achieve results. And they receive enough power to be able to make some decisions which otherwise would take too much time and involve other people unnecessarily.
• Agile methodologies are not real methodologies! Yes, they are! You do not need 500 pages to convince people of the seriousness of a methodology. They are lightweight (not light!) because they do not want to constrain people too much. If you give people a process for every breath they take you turn them into process operators. With Agile we want people to add value while using some just enough structure (that is methodology and processes) that would work for them instead of slowing them down.
• Roles are very unclear! The fact that most organisations implement Agile roles poorly doesn’t mean these roles are not properly defined. Example from experience: more than 80% of those who say they do Scrum do not have a Scum Master and a Product Owner in place. When you decide you want to do it, you really have to do it. Simulating a Daily Stand-up won’t do it.
• Agile is easy! Well…It usually takes a complete change of how the performing organisation is thinking and behaving. And this effort may easily be spread across a few months and even ears.
• Agile may work for a small project but it will never be a company-wide So, what is the alternative then for the whole company? Taking 3 months to make any decision? Finding the best excuses for failing on customer satisfaction? Agile might in fact be the salvation for many organisations. Want proof? Look at all the struggling industries out there trying to survive in a more and more customer-centric world and more and more powered by AI.

It may sound very strange and maybe some of my fellow agilists will not agree but many of these challenges can be easily fixed or at least improved by working closer with PMOs. But let’s look into the PMO-related stereotypes now. If you’re and Agile guy, this should make you think about how much you need a PMO.

• They’re useless! Most of them are actually very supportive. They can make your life much easier by providing support and consultation. Not to mention resources, tools and proven best practices.
• It’s the Police! Even if that were true, can you imagine a world with no police? And what did we ever do to deserve “less” police? You need order, you need calm and you need somebody to keep an eye on how things go. It’s for you own benefit.
• Control freaks! If they are freaks then yes, it’s bad! But for most it is just making sure that whatever we decided to do, we’re actually doing. Quite often we fear control because of our own failure to perform. Controlling is what catches you when you are not doing what you were supposed to do. Think high-school exams!
• They only care about compliance! Well, somebody has to! When you’re too busy with the day to day business you might be tempted to cut corners, maybe make some sacrifices, be too creative and it is always good to have somebody out there who will watch out for you.

Let’s see now how these two worlds can work together. Particularly since in reality there are just one world. We’ll look at some examples considering typical PMO functions (supportive, consultative, controlling, compliance) in collaboration with some standard Agile practices. Here they are:

• Client relationship. Although Agile comes with some clear roles (ex. Product Owner), processes (ex. Sprint Review) and artefacts (ex. User Stories), an Agile team will usually inherit organisation’s way of doing business. PMOs can help a lot when it comes to sponsorship, account management, escalations not to mention the protection when the Agile will…fail fast! PMOs can also help with the translation and explanation of some very agile terms like iterative product development, product increment, customer demos, etc. so those on the other side actually understand what they mean.
• In spite of some 70 years of experience, some people still look at Agile as something new, a trend that will go out of fashion soon. Or like it’s just some kids playing. Involving a PMO with the right structure and governance can turn Agile into a serious option for many customers. Agile, by itself is fun and efficient. With PMOs backing it can also be trustworthy and credible.
• Customer feedback. Many organisations complain about not being able to talk to customers face to face. They usually blame management for not allowing it or corporate policy. PMOs can be a very powerful ally who can move things faster into the right direction. They can come up with the right processes to do it, the right sponsorship and ensuring it has the right impact.
• External dependencies. Those who are doing Agile know how hard it is to achieve flow (delivering continuously without any blockage) and how damaging it is when something happens and that flow is blocked. And, in most cases it is caused by some external factor or dependency. A solid PMO can support with putting the right agreements (SLAs) in place and the right governance so it is actually respected.
• Empowerment. It’s never easy to let it go and it’s never easy to take full responsibility. With a more structural approach, typical for a PMO, the organisation could strike a balance between empowerment and risk management. And done gradually, of course.
• Training. It is shocking how poorly trained people are when it comes to Agile. Especially those who supposed to be doing Agile. Even if they are, quite often it is just an isolated training experience with no connection to the overall personal development strategy of the corporation. Again, great opportunity for collaboration with those in charge of the project management practice and its maturity.
• Mindset. Many people agree that doing Agile involves a change in the way of thinking but very few are actually doing something about it. The benefit of having the PMO involved, maybe even make it PMO-driven, is that it would make it more strategic, more structural and better resourced. Safer and more secure also.
• Failing fast. Since we talked about the mindset we also need to mention failing fast. PMOs have the power to turn this approach based on experimentation, suppositions and fast failing into something that is truly company-wide and more aligned with the corporate values and practices. In the end, this is how you create a culture of innovation and creativity.
• Planning. PMOs usually serve as an intermediary between management who wants predictability (deadlines, budgets, etc.) and the reality which is more agile than you would expect. You can explain to an Agile team the need for some predictability and work with them to focus more on releases and roadmaps rather than iterations. You can also sell some of the benefits of the “as-you-go” planning to management and work with them to embed some flexibility into their long-term plans and commitments.
• Conflict management. Everybody has conflicts, extremely few have a conflict strategy. So, the moment you have a conflict in your team, it all comes down to WSTL (“who screams the loudest”). This becomes even more critical when the conflicts involve people from different teams or departments and because they usually turn into fights, everybody loses. Having a clear strategy, endorsed by a PMO will give everybody the guidelines about how aggressively you can defend your ideas, how critically you can challenge others and how much you have to obey without questioning.
• Reporting. You say Gantt chart, I say burn-down chart. Maybe if we could just talk about why we really need those reports, we could actually come up with something useful. From Agile you can learn that documentation, including reports should be produced only if it provides some value to somebody and not in excess. It’s a mean to an end. From PMOs you can learn that some people might have different communications needs and you have to be respectful of that and provide them with the right information, in the right format and when they need it. In every company, a clear and honest discussion about project metrics and KPIs is in order.
• Tools. PMOs can be very valuable partners when it comes to getting the right tools. Particularly if the need just occurred and there was no way you could have planned it and budgeted it from the beginning. While the project team – Agile or not – only looks at one project, their project namely, a PMO might consider this as a long-term investment with a much larger ROI. And they can be easily convinced to invest in some tools that will improve the efficiency of project management activities. Not to mention the effort to implement the tools and train people to make the most of them. If you want an example, here a simple observation from the real world. From all those who use Jira, only a handful are aware of what it can actually do and even fewer are using it at its full capability. Probably they just thought they needed a tool to track post-it’s electronically.
• Best practices. A very big concern in many organisations is that they have people with great experience and people with almost no experience when it comes to doing Agile. And, for some reason, they have a hard time making those experiences available and shared throughout the company. POMs can help a lot by creating the environment, the tools and the culture of sharing best practices. And it is not that much about sharing some experience (nobody needs another SharePoint!) as it is about getting it across, understanding it and incorporating it in your practice.
• Visibility. One thing I discover very often when I deliver Agile courses is that people who work for the same company, usually discover what they colleagues are doing during the course. And they do admit that they do not talk to each other. And there’s a lot of highly valuable information to be shared: what has worked well, issues, risks, challenges, problems, best practices, etc. Having somebody in charge of cross-project communications would definitely help a lot. And that sounds like a job for a PMO.
• Corporate strategy. Most Agile teams still maintain the old thinking, our job is to execute whatever they tell us to execute. While there is definitely some value in execution, it is much more valuable to understand the reasons behind execution. Unfortunately, too often, nobody shares those high-level ideas with a team. Maybe they are aware of the project’s vision but most people totally miss the strategy of the company they work for. While being impacted every single day by that strategy. A PMO can educate people on how the company is organised, what are the priorities, what are the KPIs, what is important and what is not. And next time an executive says “Sorry, I don’t have the budget!” you can actually understand what they mean.
• Methodologies. For most people doing one methodology right is hard enough. However, for optimal results you must at least understand other ways of managing projects too. When you work in project management your job is to deliver project-based work and results and it is very helpful to develop a fluency in more than one methodology. Invariably you will have to “interface” with other teams who might use other methodologies or frameworks. PMOs could be great teachers or at least promoters of this learning and exposure.
• Control. Yes, that’s correct, control! We love “feedback” but we hate “control”. Maybe because we associate “feedback” with “we can improve” and “control” with “I might get caught”. It doesn’t matter how you call it, somebody should tell you when you are doing it right and when you’re not. As someone who’s doing Agile, I would be very happy to delegate the controlling to someone else from outside (like a PMO) who’s not directly involved and who can keep me on track. Even if sometimes the news might not be very pleasant.
• Compliance. We all hate it but we all need it. The problem is that we don’t always understand it. It could be because nobody bothered to explain it. It could also be that people just take it for granted and don’t try to understand it. But once you go deeper you realise how important it is. A big breakthrough for many people is applying Agile practices to compliance projects. Which normally leads to getting the results you want (being compliant!) faster and also a bit cheaper.

Obviously, this list can continue with countless examples of how PMOs can embrace Agile practices and agilists can better understand how PMOs can help them in their Agile journey.

In conclusion, every possible collaboration or lack of can be seen as a threat or as an opportunity. While there might be some threats out there, we get much more benefits from considering the opportunities. And from those opportunities derive the benefits. In the end, it is all about delivering benefits, isn’t it?