Prioritizing Effectively as a Team

[article]
Summary:

If you’ve ever worked on a development project, you know you can never be that sure that everything will be completed on deadline. By prioritizing actively, you can change success from something binary—either we make it or we don’t—into something more gradual. By doing this, you increase the chance of succeeding in delivering something. If you prioritize really well, that something may even turn out to be far more valuable than anything you penned down in your initial plan.

A common reaction to the product owner role is to see it as too big for a single person. If the idea were that one person should do everything from guiding the vision to writing user stories, I would agree. But that’s not how I see the role; I see it as one component in getting to effective teamwork.

A colleague of mine once came into the office reeking of frustration. He told me what had happened. Hoping to get some help, he had just spoken with his project manager about needing clearer priorities.

“Too much is going on right now,” my colleague had said. “We’re not getting anywhere—we’re just skidding around. If you could help us prioritize, that would really help.”

“Well,” the project manager said, “we don’t really need to prioritize because everything has to be done by March 31.”

I have to confess that my first thoughts about that project manager weren’t particularly nice. However, as I kept thinking about the absurdity of the answer, I found one way to understand the project manager’s perspective: If you know beyond a shadow of a doubt that everything will be done by March 31, then prioritization isn’t that important. After all, everything will be done, so why worry about the order of doing things?

If you’ve ever worked on a development project, you know that we can never be that sure that everything will be completed on deadline. You also know that there are many factors in organizations that push us to act as if we were that sure. Uncertainty, mildly put, is seldom a welcome state, so woe unto those who mention it.

Unfortunately, if you want to be agile, you have to not only mention uncertainty, but also engage with it head-on. Unlike the project manager in the story above, an agile product owner can never hide behind the answer “Everything has to be done.”

If you are even slightly worried that your cherished plan might not play out as desired, you need to do very active and continuous prioritization work. Good prioritization is what lets you ship by the deadline even though some stuff turned out much trickier than you expected it and half of the initial requirements have been swapped for something completely different.

By prioritizing actively, we can change success from something binary—either we make it or we don’t—into something more gradual. By doing this, we increase our chances of succeeding in delivering something. If we prioritize really well, that something may even turn out to be far more valuable than anything we had penned down in our initial plan.

In other words: In development work, prioritizing well is the key that lets us survive in spite of budgets, deadlines, and unknowns.

The challenge is that prioritizing is really difficult. Prioritization in an agile context means seeing both the bird’s-eye view of things and the nitty-gritty details as we discover them. In practice, this often means the task of prioritizing is too difficult to be done well by a single person. Here are just some of the skills needed:

  • Deep insight about the needs of the people on the receiving end
  • Understanding how the business works
  • Analytic thinking
  • An understanding of what is technically possible
  • The ability to learn rapidly in order to cover important knowledge gaps
  • Knowing what other constraints are in play

Luckily, we’ve known for a long time what to do when faced with what at first seems like a need for a superhero. We use a team instead. I’m not thinking of a product owner team, here. I’m thinking of a well-formed, cross-functional, and multiskilled development team. Such a team can contain within it all the skills needed to manage the challenging task of discovering, analyzing, and prioritizing the true requirements.

So, why do we need a product owner if the entire team does work that just a minute ago looked like product owner responsibilities? We still need a product owner because the job of the product owner is not to serve up requirements; it is to make sure the team is thinking about and working on the right things.

Still, as soon as we switch to team mode, a new challenge arises: We need to find a way to think effectively together. When done right, thinking together feels like a creative wonderland. When done badly, it feels like a frustrating and wasteful misuse of everybody’s precious time.

Product owners who want to make use of the entire team’s thinking abilities need to learn some truths:

  • A good product owner has enough knowledge and understanding to make excellent prioritization decisions.
  • A great product owner feels such strong ownership of the product that he or she is willing to invest great effort in making sure we don’t just make the right decisions, but also that we make them in the right way. In the end, true responsibility for the product is something that needs to be shared by all involved in creating it, and that only happens if we manage to engage the entire team fully.
  • A fantastic product owner grows the entire team’s knowledge of the problem domain over time so that everyone understands how prioritization needs to be done. This helps avoid a situation where the product owner becomes a bottleneck in daily decision-making.

For nontrivial products, effective agile prioritization needs to be a team’s work. Because the task of breaking down the work into small bits is so hard, the knowledge of the entire team is needed. The goal is to take a myriad of interacting factors and wrestle from them a clear and shared prioritization. Again, this does not mean always working in consensus mode. Skill, deep understanding, and great facilitation go a long way toward ensuring we move ahead intelligently and quickly. Still, sometimes we get stuck, and then it’s useful to have the product owner make the call, if only to break the logjam and do something.

In searching for efficiency, some agile teams unwittingly sacrifice the cooperative and conversational ideals that agile was founded upon. They assign roles, play parts, and prepare for the inevitable blame game. Sure, thinking together is hard. And sure, sometimes we can succeed by improving efficiency and clocking more hours. However, if we can build our skills and get over our feelings of discomfort, thinking together may just turn out to be our strongest competitive advantage.

In practice, this all means that for a trivial product, the product owner may very well be the one person who analyzes and presents requirements to a few developers. But in a just slightly more challenging product, it’s more helpful to see the product owner as someone who focuses on the overall direction, and the entire team as responsible for talking to customers and capturing those conversations as user stories.

When the product owner is seen as someone who should feed requirements to developers, the role becomes overburdened by the sheer amount of work and the complexity of it.

A more effective way to use the product owner role is to see it as responsible for engaging the whole team in discovering and pursuing a grander goal. Such a shared and exciting goal is what makes a group gel into a team, guides it toward the right product, and makes possible those tricky tradeoffs that let us be really agile—in the true sense of the word.

User Comments

2 comments
Doug Shelton's picture

Tobias:

I think I understand and agree with your contention that the "team" (and by that, I'm assuming you mean the folks actually working on producing the product: developers, DBAas, QA, etc.) needs to help the PO articulate the requirements as they can bring in understanding of technical issues, dependencies, etc that the PO may not have.

However - I think you've gone "too far" on this line of thinking when you state "But in a just slightly more challenging product, it’s more helpful to see the product owner as someone who focuses on the overall direction, and the entire team as responsible for talking to customers and capturing those conversations as user stories." [bolding is mine].  

Why?  Developers already have their hands full., and I do not agree that they should expand into the realm of collecting requirements from other customers in an agile development environment.  Rather, I'd recommend that in such cases, the Product Management area needs to beef up its staffing and get more POs in the mix to do this work - and the team may need to be divided into multiple teams to collect and code those diferent requirements - OR - the other POs can feed the info into the Team's PO who continues to act as the one SPOC for the Team's requirements.  Having multiple people collect and feed requirements into a dev team - whether they are POs or Dev team members - is always confusing and often leads to arguments over priorities, etc., although I'd recommend that if this does happen, it should be POs and NOT developers, who have their own set of dev tasks to work on.

June 19, 2014 - 9:21pm
Tobias Fors's picture

Doug - thanks for commenting and sorry for not replying until now. Beefing up the product management area is one approach. The thoughts in this article come from my experiences over the years with organizations that have tried that approach and struggled with it.

The main problem I see clients struggle with is that of developing and spreading the knowledge needed to build a successful product or system. The approach with one party that prepares the work and one party that executes it is certainly the traditional and well-known one. I guess it doesn't have to happen, but I've seen this break down and become an inefficient relay race with ensuing finger pointing one too many times. That's why I often prefer to see full teams that take a shared responsibility for creating the knowledge needed for a successful product.

When it comes to confusing over priorities, I think that is a separate question. Priorities can be made clear and agreed upon even in a team environment where the full team (or a larger portion of it than usual) participates in the work of understanding the true needs of clients and users. We use mechanisms like shared planning sessions (as in Scrum) and visualization of ongoing work (as in Kanban) to make this happen. This makes it safe for more people to engage in the essential knowledge-creating conversations.

July 29, 2014 - 3:02am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.