Agile Teams – Serving Many Masters?

In many of the organizations where we consult, teams have a plethora of stakeholders to serve, each of whom has their own set of project requests, features, defect fixes, etc. The nice, simple model of “one team with one project” often does not apply.

Or to put it another way, agile teams must often serve many masters. Balancing out the needs of all of the stakeholders, getting good requirements from a variety of customers, and determining priorities across stakeholders are typically challenging. Even determining the one single voice who will speak on behalf of the stakeholder community can be difficult.

We get a lot of questions regarding the scope and timing of these and other product owner activities. Working with several clients on these topics recently, I thought that I would put out a few notes on the kind of structure and rhythm that seems to be working for us.

The Uber Product Owner or Chief Chaos Officer

Imagine a corporate website, either internal or external. Perhaps a single development team performs updates and maintenance to this website. But there may be many potential ‘product owners’ and it is not clear who is in charge. Marketing has stuff that it wants on the website, sales has entirely different stuff that it wants, various business units want their own stuff out there, HR has yet more stuff, and IT has its own stuff that it wants to do from a technical standpoint. Add to this that there may be a production support and operations team that has set maintenance windows for production update. Let’s say that the web team is allowed to make production drops once a month.

Each of these potential customers like marketing, sales, HR, etc may have their own projects and their own budgets and they would each engage the single team that is responsible for maintaining the website. And the team has fixed delivery windows when they can make updates so they may need to batch up several small projects into a single release.

In this environment, there may not be one clear product owner who really owns the corporate website. The website may be a shared communications resource that everyone uses and as such, there are many potential customers/stakeholders. Each of these stakeholders is also potentially a product owner for their own individual web projects. Yet someone needs to coordinate, prioritize, and trade off across all of these efforts and coordinate with the development team. Also, ideally, the team would want to engage with each of these potential product owners in a common way.

Enter the uber-product-owner or chief chaos officer. We often suggest that one person, and I pity that person, coordinate across all of the various customer product owners so that the team can coordinate, communicate, prioritize, and schedule across the entire portfolio of web project requests. This is basically a portfolio management function. And while many organizations have portfolio management systems, most are not aligned very well with the agile delivery cycle. (See our Cutter paper ‘The Agile PMO’)

No doubt some of you will say that the whole structure around the ownership of the website is wrong and I might agree. But the problem that I have laid out above is a very common one.

Regular Portfolio Review
We usually suggest that clients start with a monthly review of the overall demand portfolio. We suggest that the uber-product-owner herd all of the stakeholder cats together and lay out a timeline on a large whiteboard. We then write up each project request or major enhancement request on a card and start to put them on the timeline. Doing this, we can quickly lay out the major projects/features/efforts over the next N months. If we have some team velocity numbers and if we have early rough estimates of the projects/features from the teams, we can start to have discussions across the stakeholders regarding how much work can fit within a sprint. For example, if each sprint can hold 50 points of work, then this gives us a fixed capacity per sprint. This fixed capacity forces the various stakeholders/product owners to ‘negotiate’ amongst themselves about whose features are going to get done now and whose features are going to have to wait. THIS SHOULD NOT BE IT’s DECISION!

The business really should own the clear development and communication of project priorities and sequence. Having a bunch of business owners come in and dump a bunch of project requests on IT and then just telling IT to ‘figure it out’ is a major abdication of business leadership and responsibility in my opinion. I usually take this sort of behavior as an indication that the business owners themselves do not agree on the priorities and are just passing the buck.

Anyway, out of these lively portfolio discussions, we hopefully have clear objectives, clear priorities, and approximate timelines across the stakeholder community for the next several releases. We should now have a sequence of projects that makes sense to the business but is still in keeping with the team’s capacity. These priorities and timings should then be communicated broadly. And hopefully there should be no need to continuously revisit the priorities for at least for another month or so!! I would suggest setting these portfolio reviews up as regular recurring meetings and that you find a wall where this information can be permanently displayed to all.

Requirements Maturity
Now that we have the request priorities established across the portfolio of projects we can now delve into the details of each individual project or request. I would see our business analysts then getting in one-on-one sessions with each individual product owner that has any work coming up in the next several sprints. They would work together to nail down the requirements in good user-story format, work out user interface issues, develop acceptance criteria, discuss workflows, etc. In some cases, you might want to get a developer involved early to make sure that they are capturing the right info and addressing the right issues. For larger efforts, our BA and the product owners will need to be working several sprints in advance, getting requirements ready and to a decent state of maturity so that the requirements are ‘sprint-ready’.

As consultants, we have been seeing a lot of mediocre requirements lately. You really can’t give vague requirements to a team and expect good working software that meets your needs to come out in the first pass. Now you certainly can use agile’s iterative nature to discover the requirements but it may take several passes to get a feature just right. And of course our development team and our customers can work together in real time cycles of iterative requirements discussion within the sprint. We have no problem with any of these approaches. But it is problematic when a product owner gives vague requirements as inputs and yet expects perfect output every time. We can either spend the time up front developing better requirements or we can spend the team’s time discovering requirements. Unfortunately, there is still no free lunch. Our uber-product owners need to set appropriate expectations with the various stakeholders on how the process works and make sure that the project-specific product owners are aware of their responsibilities.

Sometime before the actual release planning, I would then have the uber-product-owner and the project-specific product owner engage with senior development team members to get their feedback on the requirements, scope, expectations, feasibility, etc so that we can make sure that there are no major issues before we go into release planning. If the developer identifies major gaps, we still have some time to do some additional research before release planning.

Release Planning
At release planning, we already have the priorities established and we already have at least some detailed requirements for each of the projects or enhancements in the release. Each product owner that has work slated for the release then presents the goals and the user stories to the team. The team estimates the stories and engages in Q&A with the product owner. We continue with this activity until we have filled the release up to capacity. Note that we may need to do estimation twice for each project/enhancement. We’ll need one rough estimate up-front for portfolio planning purposes and then here again prior to the release for a final and probably more accurate sanity check.

Execution
Now the release is underway. The uber-product-owner and the true product owners for the projects that are in this release need to continue to be available for Q&A and for interim review, testing, and feedback.

Repeat
With this release underway, the cycle then goes back up to the start again, reviewing the portfolio of projects again, adding in any new requests, re-prioritizing and re-scheduling with the stakeholders as necessary to prepare for the next release and the cycle starts again.

Most of the literature out there assumes “one project and one team” but we are finding that it is often the case that our teams need to support multiple projects from multiple stakeholders simultaneously. We can still manage to capacity and we can still have clear priorities across projects but we will need to take our planning and estimation and prioritization up a level in order to support these kinds of shared services teams.

Thanks,
Roland Cuellar