Filling the Leadership Vacuum

That was a pretty bold statement I made last time around.

Here it is again in case you missed it… My premise is that the Product Owner in Scrum embodies many of the roles we see in a traditional software project; they are the Project Manager, the Business Analyst, the System Designer, the User Experience Architect, and every other Business Group (sales, marketing, support, etc.) all rolled into one.

A long time ago on a project far, far away…

Let me tell you guys a little story. When I was first formally introduced to agile… I was working with a team that was doing XP. These guys were responsible for working with business strategists to create new products for markets that didn’t exist yet. Agile was the perfect approach because there was so much uncertainty and there was no choice but to learn by doing and adjusting based on what they learned. Static requirements just didn’t exist.

I am going to oversimplify the story a bit, but this team created a product that went big time and they got sucked into the mainline business… they were no longer a research team. As the product got more and more successful, the team grew and needed some more structure and organization. They needed to scale… and that was how I got pulled in.

I was pretty open, and had some background in iterative methodologies, but had basically been schooled in the ways of traditional project management. In my early days with this team I kept feeling like they thought everyone was a developer (or at least that developers could do everything on a project… the whole generalist thing). It also seemed to me like the Product Owner was too simplistic a means of dealing with the business. There was no way that the Product Owners could make every decision that we were expecting them to make.

This agile approach had clearly worked for them so I started searching for answers and bought every book I could get my hands on to understand what was going on. I needed to know how these folks had come to these conclusions about software development methodology. I was trying to figure out how and why all this stuff was supposed to work. Along the way I formed few opinions about why agile was defined they way it was and what the movement was fundamentally trying to accomplish.

Product Owners fill the leadership vacuum…

Most businesses cannot make up their mind. Most organizations lack vision… they lack leadership… and they lack direction. Unfortunately, many development teams are on the receiving end of this void. Many development teams are asked to estimate projects with unclear requirements knowing full well the business is going to constantly change it’s mind. They know these changes are going to have profound impact on the software they are building.

Furthermore, they know that while the business is changing its mind, the business will hold the team accountable for delivering on time and on budget… against a constantly shifting target. Many teams are in an impossible situation managing against unrealistic expectations.

Think about what we are really saying with agile in general, or Scrum in particular:

Give me a team full of really talented developers, give us as few constraints as possible, put us all in the same room, and don’t bother us for weeks at a time. Give us a single person to make all the business decisions (the Agile Product Owner) so we don’t get yanked around and we’ll agree to be accountable to that person, and that person only. We’ll make all the decisions about how the code gets built and how the team operates, but as a trade-off for this level of autonomy, we’ll deliver working software in short bursts… and let you change your mind as much as you want.

Not a bad deal if you ask me. The cool thing too is that it works… but it has its limitations.

…but let’s get back to the point

This is a great model for a single team or a group of teams that are truly autonomous. Once you scale past two, maybe three teams, or when teams have to work with each other in a coordinated fashion, the single omnipotent Product Owner model begins to break down. It is too much for a single person to wear so many hats across so many project or product teams.

Once the Product Owner delegates some of their responsibilities to other Product Owners, a Project Manager, an Analyst, or a Designer… the contract that Scrum makes with the organization breaks down. You have to have introduce coordinating processes, and this introduces waste… and reduces autonomy… and reduces agility. You no longer have a Single Wringable Neck.

Next post we’ll look to explore several models I’ve seen work on teams of various sizes and explore some models for how we should view the Product Owner at scale. We’ll begin to explore some organizational models that support the traditional Product Owner concept and some organizational models that will require you to adapt from basic Scrum. As always, I am interested in your comments.

One last thing before we close….

As I mentioned last time, Jeff Sutherland was in town last night. I was very fortunate to get an invite to dinner with Jeff and a few of the folks that hosted the event. I had a great opportunity to talk about these ideas with one of the guys that actually invented all this stuff. We talked about how teams are re-purposing some of their traditional roles for Scrum and how a few of the teams Jeff has worked with are dealing with these communication and coordination issues.

I left feeling pretty good about my approach here and validated there is a real issue that needs to be addressed. We need more people writing and talking about this stuff. Small is beautiful, but we can’t pretend that big doesn’t exist.