To be an Agile PMO means that you need to understand agile and Scrum and speak to the language of the teams. Many PMOs insist on getting reports and updates in traditional formats that don’t work for agile teams.
This is NOT an Agile PMO
I was working with an Agile coaching client this week. Even though they are a large and conservative firm, they want their technology teams to become more Agile. They have just a few Scrum teams at this time representing perhaps 20% of their IT portfolio.
I was meeting with the PMO to review the required documentation for the Scrum Teams. The PMO produced a spreadsheet showing 100 different artifacts that every Scrum team needs to produce to meet their audit requirements. 100!
It was as if the PMO said, sure you can use Agile techniques to build solutions, but you still need to produce every artifact you would have had to produce had you used our waterfall/SDLC approach. They were not acting as an Agile PMO.
Clearly, this client is rooted in the traditional approach to software development. And while they aspire to become Agile (whatever that means to them), they haven’t taken the time to really understand agile and to do the hard work necessary for their Agile teams to succeed, including eliminating unnecessary process and documentation. They are stuck in their old ways and the pendulum would need to swing a long way in the other direction for them to succeed with Scrum.
Ironically, I have another client where the pendulum has swung fully the other direction. Since they “went agile” 4 years ago, the technology teams don’t produce any plans or documentation.
There is no evidence that the teams are following a consistent process as you would expect from someone using Scrum. The PMO head is asking questions about governance and the IT group collectively shrugs and says, “but we’re Agile now”.
In the first case, the PMO is requesting an amount of process and documentation from the Agile teams that is clearly burdensome. In the second, the Agile teams lack process and have no governance at all.
Is either of these approaches effective? Is there a better approach that is somewhere between these two extremes? Is there a reasonable number of measures or questions that is between 0 and 100?
I believe there is a reasonable number and it is 10. I believe there are 10 key questions that the PMO should be asking each Agile Team.
In this post, we will look at my recommended 10 questions and how those 10 questions address the needs of the second client described above, the client whose agile teams have gone dark. We will address the “100-artifact” client in a future post.
10 Questions an Agile PMO can Use with an Agile Team
The following questions are in the language of the Agile Team, and teams should be able to respond. Below this list I’ve provided a detailed explanation of each.
- Who is on your Team?
- When is your next release?
- What is the velocity of your team?
- What is your planned cost, and what have you spent so far?
- What Scope are you going to deliver in your next release?
- Who is prioritizing the Scope of the next release?
- Who reviews and accepts your work?
- How are you managing your issues and risks?
- What processes are you following?
- What are you learning, and what improvements are you making?
#1 – Who is on your Team?
- Ideally, the agile team is stable and each team member is 100% dedicated to just one team. If this is not the case, the Agile team should explain why not.
- Team members should be identified by name.
- Teams should be appropriately sized – I like the 7 +/- 2 guideline.
- The team roster should drive the people budget for the project.
- If the resources are not fixed and 100% dedicated, budgeting and tracking costs may be an issue. This also impacts the team’s velocity which is used to predict when the team will release.
#2 – When is your next release?
- Agile teams plan by the release. The release may be driven by scope (we will release when we have built all of X), or by date (we are going to release on June 1). In either case, they should have a plan for the release date, and they should be tracking against that plan. Many teams use some form of release burndown or burnup.
- Release dates will get more accurate as the team iterates. The velocity of the team is one of the keys to successfully predicting release dates.
#3 – What is the velocity of your team?
- Velocity is a measure of progress against the backlog items. Teams generally measure this in terms of story points, though story counts or even count of backlog items could be used. This is a key contributor to the time for the release and the overall cost.
#4 – What is your planned cost, and what have you spent so far?
- The planned cost is tied to the release date, the team roster, and any non-people costs like HW.
- Most Agile teams I’ve worked with don’t think they have to worry about costs. They have a fixed number of people on the team and no non-people costs. For them, the planned cost is simply the run rate of the team for the duration of the release.
- The actual spend to date may be a little more challenging for an Agile team but someone has the data. And I think it is important for that someone – whether it is the Product Owner, the Scrum Master, or the Development Manager – to be keeping track.
#5 – What Scope are you going to deliver in your next release?
- Some Agile teams will respond to this question by saying, “we are Agile, we don’t know what the scope is”. Which is BS and they know it. Agile teams need to have a set of target set of features or functions that they are going to deliver. There is no blank slate, and teams don’t make things up as they go. That would not be Agile.
- If there is a fixed date, then scope may be the constraint that is allowed to flex. There still should be a target and teams should be able to state with some level of accuracy which features they will accomplish by the next release, based on their velocity
#6 – Who is prioritizing the Scope of the next release?
- The person prioritizing the scope is the one who is steering the development.
- In Scrum, there is a Product Owner who is representing the voice of the customer. They are in tune with end user, external customer, or market needs and building the exact solution that incorporates the features and functions most valuable to those end users. They do this through the use of the prioritized product backlog.
- Sometimes there is a proxy for the Product Owner. The proxy may be part of the technology organization and they strive to represent end-user needs. The farther away the proxy is from the true customer or end user, the more likely that there will be gaps between what is desired and what is delivered.
- In the worst case, the team is deciding on the features themselves.
- The person prioritizing the scope is the one who is steering the development.
#7 – Who reviews and accepts your work?
- This question relates to the previous one. In the best case, it is the Product Owner that represents the customer who is reviewing and accepting the items delivered by the team.
- If the team accepts their own work, or no one does it, then that would be a major risk.
#8 – How are you managing your issues and risks?
- Agile teams take ownership of their issues and risks. In Scrum, the Scrum Master helps the team to resolve or escalate impediments so that they can be as productive as possible.
- Agile teams may also have a project or program manager helping them with risks and issues.
- Teams that are not directly managing issues and risks will have low and unpredictable productivity.
#9 – What processes are you following?
- Most Agile teams today follow Scrum, though there are other viable approaches such as Kanban or XP. In any case, the team should know which framework they are following.
- For each framework, the team should be able to demonstrate how they are following it. If Scrum, do they have set iterations, are they using the Scrum meetings (every sprint), the artifacts, and following the roles?
- If the team is using Kanban, who is prioritizing their work? Are they limiting WIP and measuring cycle time.
- If the team is claiming to be agile but not following a framework, that is a problem.
#10 – What are you learning, and what improvements are you making?
- Agile teams frequently pause and inspect their processes and make changes to improve. Scrum has a built-in process for this called the retrospective. Most Kanban teams incorporate a similar exercise.
- Teams that are using the retrospective will have improvement items every sprint. These are not necessarily confidential, though they may not make much sense or be useful to anyone outside the team. Still, the Agile PMO can ask for them.
- If teams are not conducting retrospectives, and not taking actions, then they are missing out on a key part of the Agile framework.
This is my list of the 10 things the PMO should ask if they are striving to be an Agile PMO. These could easily be turned into a scorecard that could be used to assess teams. What do you think? Did I miss something important? Are there other items that should be included?