Agile vs. PMO - Are They Mutually Exclusive?

Overview

Since PMI published an article in 2012 about the role of the Project Management Office in Agile projects, several more opinion pieces have emerged exploring the same topic. However, many still treat Agile and the PMO as mutually exclusive. This is not the case, and it’s not how FullStack Labs operates. As a software development company started in 2014, FullStack Labs began as many small companies do—developers and technical personnel running projects. There are still a few projects running this way, but the value proposition of project management as a separate functional role has really taken hold, allowing our developers to focus on doing what they do best: producing amazing code.

As the company grew and platform support expanded to include React, React Native, Python, Node.js, Ember, Vue, Angular, Ruby on Rails, and custom software development, FullStack Labs started bringing on hybrid Business Analyst/Project Managers, including me. One of the reasons I joined FullStack Labs was the very well-thought-out playbook designed to maximize the success of software development projects. As I onboarded, I came to really appreciate how FullStack Labs’  operating model answers the question posed in the title of this blog post and shows how Agile and the PMO can not only work together but work well together.

Check out this other FullStack Blog post to see how to run successful software-development projects!

PMOs used to produce rigid frameworks, and the maturity of a PMO was often measured by how many templates and processes/procedures existed to manage Waterfall projects. As the role of the PMO has adjusted to support Agile projects, the core function remains similar: establishing standard tools and templates. However, teams have greater empowerment to determine how best they want to work with each other. The following Agile PMO DON’Ts are pulled directly from PMI’s 2012 article:

Top 8 “AGILE DON’Ts”

1. Don’t Equate Activity to Progress
   Agile projects not only manage change but expect and allow for it. We have a thorough estimation process at FullStack Labs, but the estimate is not necessarily set in stone because almost every project has some adjustments to scope as clients demo the product as work is performed. We measure committed time from team members using Toggl tasks which are then tied back to JIRA user stories and rolled up to feature epics. Ensuring that JIRA cards move to the Done lane on the task board is the goal of all team members, making sure that standards of excellence are met.
2. Don't Prioritize Full Resource Utilization over Project Delivery/Velocity
   Context switching erodes performance. Cognoshr.com indicates that one extra project reduces productivity by 20%; by the time you’re at three projects, productivity has been cut in half. Having the right team composition and utilization is key to minimizing the impact of context switching. Eeking out an additional 5-10% of utilization to reach 75%+ may not necessarily result in greater revenue. We strive to keep team sizes very small by assigning resources so designers and developers are as dedicated to projects as possible.
3. Don't Start All Your High-Priority Projects at the Same Time
   This requirement is more geared towards internally-facing organizations but also applies to internal initiatives within consultancies. Having too many projects in flight can lead to resource bottlenecks and context switching. We prioritize internal initiatives based upon potential impact and use resource down-time between projects to address internal needs. There is a JIRA board for internal improvement ideas. The CIO and CTO, along with other leaders, assess alignment with strategic goals, business value, feasibility, and more to determine which initiatives make sense to pursue.
4. Don't Allow Unapproved Projects to Start or Continue
   This is less of a concern when an organization is a software development company like us. For traditional companies, this is where the PMO really shines: having a well-defined approval and startup process is key to preventing the growth of phantom projects. Our playbook lays out a detailed estimation process involving many levels of the organization—an estimate is not approved until it goes through each part of the process. Because of how closely we manage time entry and how time entries are tied back to JIRA cards which are very closely aligned with estimates and approved work, phantom work is less of an issue here at FullStack Labs. Regular productivity reports help keep team members on track. For instance, there is a project dashboard generated at the end of each two-week sprint showing committed versus actual time spent by individual staff at various levels helps to address productivity issues.
5. Don't Prioritize Processes and Forms over Delivering Value
   Here’s where most PMOs and Agile projects tend to be at odds. We have set processes for estimating and starting a project and a few core tools and forms around which time tracking, productivity, invoicing and billing are conducted. But outside of that teams are empowered to decide on what processes and tools work best for them. From a tools perspective, we have found some commonality in popular tools used (see this blog post for details) to work remotely, but by no means are they a requirement. It is likely easier to demonstrate the process variances by example: one project stores all internally-facing documents in a specific location on Google Docs with a well-defined document structure, but for a different project the team found that posting important information and files used throughout the project into the internal Slack channel worked best for them. The velocity on the latter project is very fast and the team would not be as productive trying to shoehorn into a set structure. The focus is more on delivering high-quality software to our clients than it is on a rigid framework for doing so.
6. Don't Use the Command-and-Control Leadership Style
   FullStack Labs uses a hybrid approach to manage the entire portfolio: regular touch-points from PMO leadership with project managers and then each project manager works with their product team and other stakeholders as needed. There is an expectation of daily stand-ups, weekly client-facing meetings, and regular demos, planning meetings, and retrospectives but teams are given the freedom to increase frequency and determine the method that works best for them. Keep in mind that we have some projects still being led by developers and some being led by project managers.
7. Don't Think You Can “Do Agile” Without Training or Coaching
   FullStack Labs has a very well-documented on-boarding process for their employees: specific content exists for designers, developers, business analysts, and project managers. The process flow is well-documented in both our Playbook and our internal Wiki. The New Employee quiz helps HR determine retention of the material and focus follow-up instruction as needed. Project managers help reinforce time-tracking and ticket-management processes because people tend to forget if training occurred some time ago.
8. Don't Focus on Agile Techniques and Ignore the “People and Culture” Transformation
   Even during my interview, I could tell that FullStack Labs had a unique culture. There is a strong push for ownership and “default aggressive” when pursuing high quality here at FullStack Labs that matches my personality perfectly. The level of passion each person brings is evident in the work we do. Our happy customers are proof positive that the culture works well for this software-development company. The adoption of Agile is not a problem here, but is still hard for many companies to achieve. I can say from my experience that culture change to fully adopt Agile principles works best from the very top. For example, our CTO and CIO both have a long history in software development and are a large part of the reason why Agile is such an important part of the culture here. They participate in everyday meetings because Servant Leadership is such an important part of the FullStack Labs culture. Team members help each other out as needed and project managers are expected to remove team blockers.

Conclusion

As you can see, FullStack Labs has a strong Agile core and hybrid PMO operating model. Top-down Agile principles and servant leadership have allowed a company culture to be created where everyone works together even though we work on different projects. Portfolio and program management is possible because of the core tools and processes established by the PMO, but teams are empowered to choose the operating methods that work best for them. This balance has enabled us to produce high-quality solutions for our customers. Having an established core set of tools, coupled with reinforcement through training and governance, enables reporting, performance tracking, invoicing, and billing. The rest is left up to teams to decide what works best for them. Click here to see the amazing members of our team.

Related blog post: Staffing Developers for Software Projects