Guest post by Scott Dunn, Rocket Nine Solutions

“We have too many things going on!” I hear this often from developers, product owners, even management. The problem is that we might be enabling this problem unknowingly (that does not, by the way, go away by itself). Depending on your role, I have three ideas for three different people: (1) the team, (2) managers and the PMO, and (3) the ScrumMaster.

At the team level, this complaint of too m­any projects or initiatives is very common. When I was a manager, my people would come up to me and say, “Jim in Marketing thinks I should be working on his request; Leonard just told me his changes were needed yesterday; and yet, we’re not even halfway done with Scotty’s list. Can you please tell me what’s the priority??”

Now that we’re doing Scrum, the priority is clear, right? There’s only one stack-ranked list from which to work. That gives us clarity, focus, limited work in progress, short feedback loops with everyone, and an increment of done-done potentially shippable software. Hallelujah!

Only, this is often not happening. No single list for a person, no limit on the work, no singing Hallelujah. The majority of companies and teams I’ve worked with miss out on this incredible win because they break a fundamental principle of Scrum… The team members are shared, or maxtrixed, with other teams or projects.

When stakeholders or management come to the product owner with a new request, the response from the product owner should be, “Let’s talk about where it fits in the backlog. Thanks; I’ll see where goes,” or perhaps, “Please tell me where it goes.”

Instead, these requests sometimes go to management or the PMO, and the manager or program manager says, “Okay, I’ll grab some people and get right on it.” But they’re grabbing people who are on dedicated Scrum teams. “Oh, that’s right – we’re doing Scrum. Okay, I’ll grab some people and form a new Scrum team and get right on it.”

And we’re back to people asking what’s priority, because “Jim thinks his team needs me about 75%, Leonard just told me their team needs me 100%, but my current team isn’t even halfway done with Scotty’s list. Can you please tell me what’s the priority??”

This matrixing is costing us not only in frustration at the team level. It’s costing us real dollars. According to a recent post on, research shows the cost estimated at $450 billion dollars a year globally. How? A 40% drop in productivity, 50% longer to complete a single task, and up to 50% more errors. Doesn’t sound like something we want to do, right?

Too many things going on.

So what can we do to improve right now where we’re at? There are a couple of immediate actions, and perhaps a bigger, and more valuable, solution long-term.

First, product owners…

Tell the requestors “No.” In Henrik Kniberg’s wonderful overview video of the product owner role, he says practicing saying “No” goes a long way. I typically respond with a different version – “Yes, AND…” That is, “Yes, AND if you show me which of your previous requests this new request is more important than, we can do it at that point.” With tougher stakeholders, I’ll admit that I have said, “I’ll put it in the backlog right away!” I would do that (I don’t run around lying to executives), but I would sit on the request and wait if this the request was “urgent but not important.” Or perhaps they would soon be distracted by some new, bright and shiny thing. Ideal and healthy? Perhaps not. But there are some places that I felt I had to pick my battles and use my time responsibly and effectively for more value elsewhere in the company. And dealing with pushy or whiny Ryan from Department B wasn’t always it.

Managers and the PMO

Second action is for managers and the PMO – tell the requestors “No” by not starting up yet another team. The truth is, if you have 100 developers and testers in IT, then you should have about 10-14 teams. The numbers tell us that matrixing is costing us a massive lack of focus. It also costs you in lost opportunity. Rather than simply delivering the most valuable thing in a month, we often deliver the 1st – 12th most valuable things at the end of a year, with not much business value or feedback in the middle of that year. And value degrades. A customer-requested feature delivered long past peak demand is just not as valuable as delivered at the height of market/customer demand.


Thirdly, ScrumMasters and internal agile coaches should tell the requestors, “No,” by talking with stakeholders and decision makers about these costs. Over and over again, I hear those guiding the agile adoptions at their companies tell me they’re in a matrixed organization. They admit that they know it’s bad, but they’re hoping it will change. If we could be honest for a moment, if you’re in this situation, how long has it been this way? How long have you been hoping for change? As a change agent, have you shared this information with them? Is there any buy-in, a timeframe, or roadmap for change in this area? Most commonly, real organizational change (such as how work is fed to teams from the program and/or portfolio) begins with understanding and support from top executives and stakeholders.

One example of a framework for alignment at these levels is the Scaled Agile Framework® (SAFe™), which provides some nice guidance for addressing this problem. First, we work in terms of value streams, which certainly something the business should relate to, and all contributors within that value stream are on teams. A level above the team’s Product Backlogs is a Program Backlog with a product manager who is the single point of accountability for this larger span of work. Although this can be handled in pure Scrum with a chief product owner, figuring out how to implement this can be quite difficult. The following can take years, if ever, to figure out on your own (especially without external coaching, which most aren’t fortunate enough to have:

  • The “what” of a portfolio, strategic themes, vision and roadmap
  • The “how” of actual coordination and ynchronizing the work of many teams
  • Governance such as architecture or UX

SAFe gives you a running start in these critical, but typically shelved, areas.

Even more helpful to help executives understand and support agile is that SAFe gives a simplified and easy-to-understand (ok, easier) context and plan for your stakeholders and other key roles from whom you need support for change. Keep in mind that many feel that we are in the Late Adopter (from the Technology Innovation Adoption Curve) state of agile. These Late Adopters are typically risk-averse, don’t like change, and would like a plan – at least to start with. To tell them, “We’ll self-organize around how to do agile here and we’ll figure it out,” is probably not something they want to hear.

I hope you found some ideas in this article that you can take action on and help others in the organization do the same. If so, we can all get back to the good stuff – meaningful, challenging work that delights stakeholders and customers.

Join the Discussion

    There are currently no comments.

    96 − = 90