FullStack Labs

Please Upgrade Your Browser.

Unfortunately, Internet Explorer is an outdated browser and we do not currently support it. To have the best browsing experience, please upgrade to Microsoft Edge, Google Chrome or Safari.
Welcome to FullStack Labs. We use cookies to enable better features on our website. Cookies help us tailor content to your interests and locations and provide many other benefits of the site. For more information, please see our Cookies Policy and Privacy Policy.

Agile vs. PMO - Are They Mutually Exclusive?

Written by 
Paul Hahn
Delivery Manager
Agile vs. PMO - Are They Mutually Exclusive?
blog post background
Recent Posts
Getting Started with Single Sign-On
Choosing the Right State Management Tool for Your React Apps
Accessibility in Focus: The Intersection of Screen Readers, Keyboards, and QA Testing

With Agile gaining more prominence, the roles of Product Manager and Business Analyst have changed - but how has the function of the Project Management Office changed? This post explores the topic and provides examples of how FullStack Labs has achieved a robust yet flexible operating model including all aspects.

Table of contents


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.


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

Paul Hahn
Written by
Paul Hahn
Paul Hahn

As an organized and driven person by nature, project management was a natural fit for me. I'm loyal and innovative, and I bring a passion for consensus to ensure everyone is on the same page for every project, turning individual members into cohesive, high-performing teams. I've led groups at a wide variety of organizations, from Hewlett Packard to AMC Theaters to the State of North Dakota. I love making sense of things and generating insights to help individuals and organizations make data-driven decisions, fostering knowledge sharing and individual growth — and most importantly, making customers happy. When I'm not liaising between clients and developers or searching through databases with Power Query, I love to cook.

People having a meeting on a glass room.
Join Our Team
We are looking for developers committed to writing the best code and deploying flawless apps in a small team setting.
view careers
Desktop screens shown as slices from a top angle.
Case Studies
It's not only about results, it's also about how we helped our clients get there and achieve their goals.
view case studies
Phone with an app screen on it.
Our Playbook
Our step-by-step process for designing, developing, and maintaining exceptional custom software solutions.
VIEW OUR playbook
FullStack Labs Icon

Let's Talk!

We’d love to learn more about your project.
Engagements start at $75,000.