Agile Teams – Serving Many Masters?
One Team with Many Projects
The Uber Product Owner or Chief Chaos Officer
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.
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!
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.
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.
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.
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.