top of page
  • Writer's pictureAstutely Obtuse Staff Writer

Beyond Agile: Part 1 | Slow Your Roles

The very first thing we need to discuss here is one regarding what roles are important to fill when forming a new project team. We are going to discuss four leadership members (as well as their overlap) and four support team members that will set an ideal foundation for your new Project Management Office.

One thing that should be noted, we are assuming you already have executive buy-in, and therefore understand the basics of what an executive sponsor would do… they are an executive… that is sponsoring the PMO… yeah. We are also assuming that you have enough business acumen to understand that there is a difference between a project manager and a functional manager.

Running a Team Lean

One of the criticisms of Agile is how quickly a team can become bloated. There are many levels of people that are responsible for extremely specific things. I worked with an organization that had an Executive Sponsor, a Project Sponsor, a Project Owner, a Product Owner, a Project/Product Analyst, and a business analyst (as well as the standard hierarchy of the PM and dev teams). As the organization grows, these individual roles become more important, but for many organizations (even large ones if we’re being honest) can get away with fewer roles.

The key to understanding what is needed when setting up a new PMO, or making improvements to your existing project team, is to fully understand what goes into a project team, the things that must be addressed, and who is responsible for each item. There can exist significant overlap between these roles. As a result, you might cater your starting team to fit the size and need of your organization.

The Leadership Roles

The reason we refer to these roles as being “leadership” roles, and not necessarily key roles as many guides do, is because we believe that these roles are responsible for driving specific aspects of the project. They go beyond just supporting the success of the project but take a more active role in pushing it forward. It doesn’t mean, however, that they are the most important part. Every role we discuss has its importance.

Product Owner

The product owner is frequently misunderstood by many organizations. A previous organization that I worked with, insisted that the PO was nothing more than someone who prioritized the various requests from organizational management. Another company that I had interviewed with, insisted that the PO was the sole manager of the direction of their software; their role was to direct the future of the product without the insight of the users.

Here is what the PO should be responsible for:

  • Advocating for the end user—The PO should be directing the work being done on behalf of input they receive from users. They are the bridge between project and end-user.

  • Partnering with management—A PO should be able to work as an equal with management of all levels to understand organizational and team-specific goals.

  • Ensure that project requests align with organizational strategy—It can be very easy for requests to not fall in line with the organization's strategy. The PO should always check that the work being proposed aligns with it.

  • Prioritize that which needs to be done—The PO should be the source of truth of what needs to be done and in what order.

Depending on the size of your organization a PO can share significant overlap with a business analyst, and to some extent overlaps with a PM.

Project Manager

The PM frequently is considered the linchpin of a project. While there might be some truth to that, I’m here to tell you that PMs are not fucking magic. The one gripe that I’ve heard from many PMs is that they have become a glorified secretary in their organizations. They no longer are managing any aspect of the project; they only provide updates and make schedules. Any ability to manage the work being done, so as to assure that the project will be done on time and on budget, has been taken from them in favor of consolidating control higher up.

Here is why the PM position is important, and why taking control away from them can be damming:

  • Have a high-level view of the project—The PM needs to have a very broad understanding of everything that is happening on the project.

  • Know where everything is at—The PM needs to know the progress of the work being done. Further, they need to understand where the completed work sits as far as the entirety of the request.

  • Handle scheduling and resource assignment—Part of knowing where the project is at is being able to allocate resources, schedule work, and move things around as needed. They need the managerial control to be able to make these decisions as they come up, and not have to go through a strangled process to get approval from a VP before even thinking about making adjustments.

  • Communicate with project partners/the company—It should go without saying, that the PM should be the one handling the communication of where the project sits with the key project partners. Who would better know these things, other than a PM

  • Institute and enforce control systems—This can take many different forms. A big part of control systems is adequate communication and stakeholder engagement (see above). In previous articles we discussed Colomboing and everything being an emergency top priority; the PM should be the one responsible for ensuring that these don’t happen, or lessening the effects of these problems.

I’ve witnessed some success in overlapping the PM and the PO positions, especially regarding prioritization and strategic alignment. More closely, I’ve seen overlap between the PM and the BA positions. In general, it has led to burnout, but on smaller teams the PM has been successful in handling the big five responsibilities that a BA has.

Business Analyst

Frequently, the BA position is defined as having five specific responsibilities, introduced to me as the “big five” BA responsibilities. These five will be covered in more detail in another article, but for reference they are: Need identification; elicitation; requirements communication; modeling and documenting; and requirements management. The BA is probably the most important participant in a project team, as they act as a subject expert, a utility player, and a direct source of organizational communication.

The BA should:

  • Work closely with the PO—The BA needs to be able to identify the problem that is being solved (the reason there is a project at all). This means they need to have a full understanding of what the PO sees as the direction for the product. The PO and BA should be total besties.

  • Work with anyone and everyone who has insight—Fleshing out the request is the key to being a successful BA. It’s why I say they are a subject expert. After discussing everything with key players, the BA should be the most knowledgeable about what is needed.

  • Write documentation—Seriously, the BA is going to have significantly more insight into what is needed than anyone else at the outset of a project. They should be documenting needs, discussions, decisions, flowcharts, relational diagrams, timelines, etc.

  • Work closely with QA and user testers—Ultimately, the work being done needs to meet expectations. The BA should be working with the QA and user testers to ensure that they understand the acceptance criteria, potential edge cases, concerns, or anything else that might have an impact on the quality of the end product.

  • Be able to fill in where needed—This is a controversial take, but as a BA you should be able to step into another role if it is needed. Again, the level of knowledge that a BA has suggests that they should be successful acting as a QA if needed, or running standup for a PM, or taking over for a PO when determining the needs of the users.

As mentioned in the last bullet point, the BA has significant overlap with almost every role on a project team. This doesn’t mean they are dispensable, however. No, it means they are fucking important! I know what you’re asking, “why the shit would we need a BA, if we already have these other roles that overlap?” I’ll tell you why... because they supplement the other roles. They are able to elevate the success of the other roles, in ways that they can’t do on their own. It is a specialized role because it’s not highly specialized… if that makes any sense.

A woman saying "not in the slightest"
Shit, and I thought I was on a roll

Quality Assurance Analyst

All right! Time for the controversial role, Quality Assurance. I’ve had many a discussion with higher-ups that like to argue that QA is a superfluous role. That testing should be done by the project team doing the work (this comes up a lot in software engineering), and the BA should be responsible for ensuring that the acceptance criteria is being met, so why do we need QA?

Well, I’m here to tell you that!... you might be able to get away without QA, but!... but… stay with me, they can provide a lot of benefits to your PMO. Let me explain.

A boy saying "Yeah, I'm kind of vital"
And so humble

QA is so much more than ensuring that acceptance criteria are met. They encompass an overall strategy that ensures that what is produced meets a minimum standard of safety, and that everything works in harmony. The problem with having developers do their own testing is that their focus needs to be on the work they completed. A QA can quickly identify what potential failure points exist, and how the work affects other components. They can also focus on things that would be outside of a developers influence, like potential security issues, compliance issues, and project process failures.

The QA position can be heavily customized to fit the need of your team. They shouldn’t ever be considered disposable, however. Their role encompasses:

  • Identifying bottlenecks in the project process—The QA team is going to be focusing on work that is coming down. They interact with the BA to get any testing documentation, so they have an idea of the work coming down, and what will be needed to test it. If they see that some work is coming down to them on time, while other items are taking longer, they can let the PM know that there is a slowdown because of X problems.

  • Edge/Corner testing—The weird shit frequently gets overlooked by developers. They are not always privy to the workflows or typical use cases of the work they are doing. A QA analyst can be an expert on this subject and quickly identify the weird shit that might happen, so that a broken piece of the project isn’t allowed to go to production.

  • Focus on the outputs—Strangely, this seems to be something that is forgotten. A QA can do what individual developers can’t: focus on what the output of the culmination of the work is supposed to be. It’s not just unit/regression/smoke/or any other type of testing. It is about focusing on the output, what is the big picture here? Is the whole of the work what is needed, and does it work.

How QA fits in with the bigger picture is arguable. I would suggest that having someone who is quality focused, and cognizant of the problems that might exist both on the project and with the process as a whole can be extremely useful. I know that many feel that the QA position is not needed, and can be replaced by other team members, but this is my counterargument: why wouldn’t you want someone on the team that can be a champion of continuous improvement and quality product?

A man saying "Nothing much happens without me"
I've changed my mind, fuck QA

The Support Roles

Support roles are just as important as your leadership roles. The primary difference is how they take shape. While leadership roles refer to a specific individual or team that is driving the work being done, support roles are more related to specific responsibilities that can be shared by one or by many people across multiple different divisions, teams, and even organizations.

So, don’t fucking discount them just because they come second in the article. The key to successfully leveraging these support roles is to support them in any way that you can.

The Project Developers/Engineers/Workers

Let’s be honest, the people building your product are the most important people on the entire team. Why then, are they down here with the support roles? Well… it’s complicated.

Take for example my work with a start-up game studio. The owner/CEO was a PO, QA, and developer. I was a PM, BA, QA, and tech lead. The other individual hired was a developer and QA. Take another example; a project team works with an outside vendor to handle all of their development work. You won’t be setting this team up as part of your PMO, and ultimately that outsourced team is there to support your project team.

Without the people building your product, you have no project. So how do we support them?

  • Check-in frequently and regularly—Go beyond the bullshit scrum ceremony. Make sure that they have everything they need. Put them in contact with those who can help them if they need anything. Give them documentation, training, whatever. Just make sure that when you check-in, you are really reaching them to ensure we are all on the same page

  • Design a process that suits them—Holy shit-snacks, I can’t believe that this is an actual problem. I worked with a team that was performing standard tasks. Everything was understood, very little risks, virtually no unknowns. The IT Manager insisted that we follow an Agile approach, but for the developers, a simple traditional methodology would have been much more successful. They told him that, but the manager continued to push Agile, which severely slowed everything down, and created massive problems. Fit the work to the way that the producers are better able to work.

The Client/Stakeholders/Customer/Benefactor

Randal from Clerks saying "this job would be great if it wasn't for the customers"
Truer words have ne'er been spoken

Without argument, this group is the single most important group of people in the entire project process. They are the reason you have a job. A lot of conflict can occur because of these individuals, and frequently it can be out of your hands.

I don’t know a single project worker that doesn’t have a story about a stakeholder that doesn’t involve them taking a shot of strong whisky and a fuck-ton of fucking swearing.

Much of the issues with this group can be mitigated using the strategies that we proposed in the articles on Colomboing and everything being an emergency top priority. However, there are other things you can do to support this group, beyond just engaging with them, and strategically controlling the conversation.

  • Don’t wrap bad news in flowers—A fellow alumnus of mine liked to speak in “Southern colloquialisms,” and shared this bit of insight. Too many times PMs are terrified of delivering bad news, and I can understand why, but don’t try and spin the bad news as something not as bad.

Prince John saying "Maybe if you tell me the bad news in a good way, it won't sound so bad"
The VP wants to see you hanged, hahaha

What is lost here, is the importance of the information you are trying to deliver. If things are not working out as planned, the stakeholder needs to fucking know. Just tell them. Who knows, they might have insight into how to get things back on track. Trust that they are not an evil idiot that is only trying to make your life miserable.

  • Only engage as much as they want—Much like designing a process that works with your development team, it’s important to design your feedback to fit your client. If they want weekly email updates, send them a weekly email update. If they want a biweekly end-of-day phone call, call them biweekly at the end of the day. If they want a daily video of you performing an interpretive dance portraying the progress… uh… have a video chat with them daily.

Subject Matter Experts

When we start talking about knowledge, we frequently break knowledge into two types: explicit and tacit. Explicit knowledge is any knowledge that has been documented and shared; it is accessible to anyone as it has been explicitly laid out for all to access. Tacit knowledge refers to anything that can’t be articulated, like experience, competence, psychic abilities, or other hidden knowledge that comes as part of their past experiences.

Gus from the TV show Psych saying "you shouldn't criticize the guy without knowing his origin story"
My origin story involves bad decisions, a vinegarroon, and a mini sculpture of Carmen Miranda

When it comes to SMEs, it’s important to be able to identify them, otherwise, they aren’t very useful. Knowledge management is an entire subject in itself, and I could go into disgustingly great detail, but I will say this one thing: if no one knows who the SMEs are, the SMEs are completely fucking useless.

What can you do to support your SMEs?

  • Make them known—As mentioned above, if no one knows who the SMEs are, they are useless (editors note: the exact wording was “completely fucking useless,” come on… be better). It doesn’t matter how you make it known, but your SMEs shouldn’t be considered tacit knowledge. Document it, put it on a post-it note on everyone’s desk. Have a tattoo artist put it on everyone’s forearm.

  • Don’t overwhelm them—Holy shit, these poor motherfuckers. So many SMEs I’ve talked to end up becoming the one go-to person that answers everyone’s questions. Don’t do this. Spread that shit out. Your SMEs are going to be taking on other responsibilities as well (presumably), and therefore you shouldn’t take them away from that work too much. One thing recommended by us, and those smarter than us is to set aside time for your SMEs to work with other people who might need it.

  • Create a knowledge base—I don’t really care how you do it, but just do it. A lot of what SMEs are relied on for are things that should be documented somewhere anyway. Why then, are they still being relied on for this shit? Shouldn’t it be documented somewhere? Aren’t we making tacit knowledge explicit when we can? Well? Get on with it...

Team Leads

I know what you might be thinking, “team lead sounds like a specific role and one that should be considered a leadership role.” Well, you are sort of correct. When we talk about team leads, we are not talking about a specific leadership position, instead we are talking about those who act as leaders on the team. They are not always in leadership positions, in fact, frequently these individuals are just a team member that is acting as a mentor, an encourager, and a force for good on the team. In my experience, SMEs are frequently also these types of leads. So, how do we support those who are doing a pretty bang-up job supporting others? Glad you asked!

  • Encourage the shit out it—Seriously. Encourage it to any extent you possibly can. Enroll them in leadership programs if they want. Mentor them in the ways of transformative/steward leadership practices. Let them know how grateful you are for their support of the team.

  • Do for them what they do for the team—Even therapists have therapists. Don’t let these team leads swim out there on their own. Support them, mentor them, encourage them, be a positive force in their work-life.

Defining Roles

Lastly, it is so important to ensure that each person’s roles and responsibilities are clearly defined. None of this “we’re agile so we don’t define the roles so that everyone can fill in anywhere like a goddamn hippy commune.” The benefits of having clearly defined responsibilities have been measured and discussed ad-nauseum. So, I leave you with this insight from the National Institute of Corrections Evidence-Based Decision Making white sheet (editors note: fucking what? Institute of Corrections? We’re trying to propose that we don’t treat workers like prisoners, you couldn’t find a better source?)

Teams function most efficiently when members share a common understanding of each others’ roles and responsibilities. Indeed, one of the reasons why teams fail is a lack of clarity among team members regarding their respective roles, responsibilities, and the expectations they hold of one another when working together to accomplish their vision, mission, goals, and objectives. When roles and responsibilities are clearly defined, team members are more productive. There is less duplication of effort; less confusion, disappointment, and frustration; and greater productivity. When roles and responsibilities are clearly defined, team members look beyond their own individual positions and learn to understand, respect, and value the unique contributions of one another, and they recognize that the overall success of the team is a function of shared responsibility and ownership.


Recent Posts

See All


bottom of page