Agile Chronicles

Getting Back in the Game

Okay... time to recap where we are with this whole Scrum Roles/Product Owner/Scaling Agile discussion. My hope was to drop in this morning with a new post... to finish an article I started writing before leaving for the Scrum Gathering. I've got to be honest... I was lost. I needed to get my head around where I'd been and where I was headed. I figured you guys might need a refresher as well... so here we are... a recap of my last 10 posts ;-)

Are Scrum Roles Really Sufficient?
http://blog.versionone.net/blog/2009/02/are-scrum-roles-really-sufficient.html

This was the first post in our series, and I have to admit... I wasn't sure exactly where we were going at this point. Every team I work with or coach is trying to map their existing organization to Scrum and there just aren't enough places to put everyone. Maybe I am making this too hard. Maybe everyone gets this but me. I am getting a sense that the simplicity of Scrum is actually making things hard on people. It seems we need someone to tell us where all our current team members fit... or at least how they might fit and how their jobs are changing.

ScrumMasters and Team Members
http://blog.versionone.net/blog/2009/02/scrummasters-and-team-members.html

I've been thinking about the role of ScrumMaster for a while and tended to equate it with the role of the Agile Project Manager. So many traditional project managers think this is where they fit in Scrum... but ScrumMaster is not always the right role. In some ways the ScrumMaster has part of the job of the traditional Project Manager, but not all the job. If it is not all the job... where did the rest of the PM job go? This post also touches a bit of the Team Member role. The team has always been pretty straightforward to me... developers and testers... but what about the BA? The designer? The UX folks?

Product Managers and Product Owners
http://blog.versionone.net/blog/2009/02/product-owners-and-product-managers.html

Much like the ScrumMaster/Project Manager dilemma, many organizations want to equate the Product Owner and the Product Manager. Again... the roles here are really different. Trying to force fit the Product Manager into the Product Owner role is causing trouble on most of the teams I work with. In this post I introduce that the Product Owner is actually one big abstraction for everything outside the development team. They are everything the development team doesn't want to deal with.

Filling the Leadership Vacuum
http://blog.versionone.net/blog/2009/02/filling-the-leadership-vacuum.html

I've been wanting to say this one out loud for a long time. Many teams are struggling because the business wants certainty from the developers but they themselves don't have much of a clue about what they want to take to market. That's fine... they don't have to know exactly what they want... they shouldn't have to have that figured out up front.... they just can expect to know exactly what they are going to get and when they are going to get it. Close customer collaboration between agile teams and the business helps solve this problem. The role of Product Owner is there to provide direction to the team... to be accountable for making business decisions... to make the hard trade-offs.

The Reluctant Product Owner
http://blog.versionone.net/blog/2009/03/the-reluctant-product-owner.html

Here we introduce a theme that I plan to carry forward into all the remaining posts in this series... the idea of context and coordination. Context provides information about what we are doing... coordination provides information about who is doing it and when it needs to be done. This is a pretty simple problem at the team level and is the sole responsibility of the Product Owner. The challenge that most enterprises face is that they are solving a scaling-agile problem at the same time they are trying to adopt agile. As an industry, we don't have much experience at this, and we don't have much experience doing it well.

Product Owner by Proxy
http://blog.versionone.net/blog/2009/03/product-owner-by-proxy.html

As we scale into the enterprise, the role of the Product Owner gets too big for a single person. We have talked about the role of Product Owner containing elements of Product Management, Business Analysis, Project Management, and UX design. They are abstracting the needs of the business stakeholders from the team and translating those needs into actionable requirements. One of the scaling patterns I often see is to name a Product Owner proxy for the team. Typically this is the BA or tactical Product Manager but I have also seen the Dev Manager, Architect, Team Lead, or Project Manager play this role.

The Product Owner Team
http://blog.versionone.net/blog/2009/03/the-product-owner-team.html

Here we introduce the idea that the Product Owner role often needs to be a team of people... all responsible for making sure the team has actionable user stories that can be consumed in the sprint. This team can be led by a Chief Product Owner that delegates responsibility. I tend to want this group to be part of the team, working with the developers and QA folks on a day to day basis. This team has the additional responsibility of making sure the product backlog is groomed and ready for sprint planning. On some teams that responsibity might be held by a single Product Owner... on some a Product Owner and BA... on some teams a Product Manager, BA, Project Manager, and several designers. It's all very situationally specific.

Feature Teams or Component Teams
http://blog.versionone.net/blog/2009/03/feature-teams-or-component-teams.html

This post get's off the core topic a bit... but I have a good reason for going here now. We have to decide what are teams are going to build. Do they build features or do they build components. The answer to this question is going to depend heavily on the scale of the product you're taking to market. Smaller teams... smaller organizations... it is much simpler if you can use the feature team approach. At some scale though... you will have to figure out how to do agile using component teams. The idea of having a small team of people capable of working across the entire architecture breaks down at scale for many reasons.

How you answer this question is going to impact how you ultimately scale the Product Owner role.

Teams are the Building Blocks of Agile Organizations
http://blog.versionone.net/blog/2009/03/teams-are-the-building-blocks-of-agile-organizations.html

Many teams struggle adopting agile because they can't or won't enforce the team concept... they want to optimize the organization's resource utilization rather than maximize the team's throughput. Any conversation about scaling agile has to begin with the idea that team's have capabilities and teams have throughput... not individuals. The Product Owner role becomes about making sure that the teams have the right context and the right coordination... that they are working on the right things in the right order.

Product Owner or Product Ownership
http://blog.versionone.net/blog/2009/03/product-owners-or-product-ownership.html

If you can buy that the Product Owner does not have to be a single person... you can start to think less about finding a single Product Owner. You can think more about aligning your business around its most important objectives... you can start thinking about product ownership. Decide first if you need feature teams or component teams... next realize that teams have capacity, not individuals... understand that teams have throughput. At that point we are left with deciding how we are going to apply our teams to solve our most pressing business problems.

Product Ownership at scale becomes less about a person... less about a particular role... and more about business alignment and prioritization... more about context and coordination.

Okay... now I'm ready to take this thing forward!

Who Do You Have on the Bus?

My wife and I are really different people.

We are a classic case where opposites attract. I am a risk taker who generally doesn't give a rat about what people think. My wife is a rule follower and a people pleaser. I like to shake things up and Kimi likes to keep the peace. I like to think about the big picture... Kimi likes to live in the details.

Neither of us is right or wrong... it is just who we are. It's really fascinating to take a step back and think about how each of us was raised and how our experiences have shaped our perspectives on life. It can be really exciting when we are able to align our goals and leverage our individual strengths and talents to accomplish great things. While we are very different... our strengths can be very complimentary.

That said... it has taken us years to understand this about each other. It did not happen overnight. It has required a strong commitment to our marriage and a willingness to work through the tough problems. It's has not always been easy but it has always been worth it.

This kind of struggle isn't limited to our marriages and our personal lives. All of us bring these same kinds of issues to work with us everyday. We bring all our personal baggage... our upbringing... our life experiences... and our career history into every interaction. These things shape our professional outlook... our tolerance for change... our ability to deal with uncertainty. When you are talking about knowledge workers... we bring our whole person... baggage and all to the office everyday.

What do you do if you have people on the team that are not well equipped to deal with uncertainty? What if that was just how they were raised and how their experiences shaped them personally? What if these folks value predictability and process rather than inspection and adaptation? What if these people are getting in the way of your agile transition? Is it possible for everyone on the team to embrace the profound cultural shift that agile is asking us to make?

This is a question I really struggle with.

We can all change if we want to change. We can all reinvent ourselves... but no one can do it for us. No change initiative is going to release us from the bonds of our family upbringing... our cultural heritage... years of positive reinforcement or a lengthy track record of success doing it the traditional way. This is the stuff that makes agile hard... business is changing faster than many of us are personally prepared to adapt... maybe faster than we actually *can* adapt.

With the economy struggling and even more disruptive change on the horizon... we have to ask ourselves how long we can wait. Marriages are bound by love... and if you are so inclined... bound by God. What are the ties that keep our companies together? Are they strong enough to weather the storm? Should they be? Are we committed enough to give people the time they need to adjust to this changing reality? If so, at what cost?

If Scrum is a mirror... what is Scrum telling is about the people we have on the team? Can agile save everyone or is it time to find the people that want it now? How we answer that question might just make all the difference.

Scrum Gathering Agile Architecture Talk

One more post about the Scrum Gathering last week and then we'll get back to our discussion of the Agile Product Owner. I've got at least three or four or ten things left to say on that topic, but like I said last time... things are just nuts right now.

The first day of the gathering... the first session of the day... was hosted by Jim Coplien and Jeff Sutherland. The talk was called 'Not Your Grandfather's Architecture'. That talk was one of the first times I have heard someone make the case for intentional upfront architecture on an agile project. Prior to that talk... most of the agile architecture discussion seemed to be driven by Scott Ambler and Dean Leffingewell. It was cool to hear another side... especially being presented at a Scrum Gathering.

My primary takeaway from the talk centered around a few comments made by Jim Coplien. Jim compared architecture to DNA and design to the expression of individual genes. He was making the point that function emerges... not form. Jim stated that the tradtional Western notion that form follows function was just not true.

Jim encouraged the audience not to play stupid, to build on what you know. If there are key decision that need to be made and you know the answer... don't pretend you don't. Jeff Sutherland reinforced that point by talking about how PatientKeeper spends months doing analysis and prototypes before scrum teams start building out features. Both speakers drove home the point that the mind of the end user needs to be embedded in the software and teams need to focus on useable software... not just working software as the Manifesto tells us.

So... I personally agreed with much of what Jim and Jeff had to say and found it refreshing that this point of view was being discussed at the gathering. My experience has taught me that in any moderately complex organization, certain key decisions must be made up front regarding the software architecture... so this talk particularly resonated.

Last post I mentioned (in reference to one of my #scrumgathering tweets) how I felt about this whole agile architecture debate. One of the downsides of thinking out loud... and in public... is that sometimes you have to *actually* defend your point of view. Dave Nicollete called me on this whole architecture thing a few days ago... and now I owe him a response.

Here is Dave's comment to my last Scrum Gathering post:

"... in the many discussions and debates about agile methods and architecture, people just assume everyone knows whether they are talking about enterprise architecture or solution architecture. Often, when you scratch below the surface of an argument on this topic, you find one person was thinking of enterprise architecture and the other was thinking of solution architecture. Which of these do you think doesn't lend itself to an emergent approach, and why?" - Dave Nicolette

Here is my take on the software architecture thing in a little more detail. I tend to talk about architecture and design on three levels: enterprise architecture, software architecture, and detailed design. I have found these three levels useful to explain a few key concepts:

Enterprise Architecture represents the key decisions around the business platforms and technologies the organization is willing to support. Wikipedia quotes a formal definition of Enterprise Architecture from the MIT Center for Information Systems Research as "the organizing logic for business process and IT infrastructure reflecting the integration and standardization requirements of the firms operating model".

Software Architecture is the set of high level design decisions the organization makes when choosing what components will be used to create the software product and how those components will interact with each other and the outside world. Going back to Wikipedia, the software architecture of a program (or a computing system) is the "structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them".

Detailed Design is pretty much everything else underneath the software architecture. Detailed design is the sum total of all the other decisions, most of the decisions actually, about how the software will actually be constructed behind those higher level external interfaces.

Jim Coplien made the comment that you cannot refactor across class hierarchies. I am not a hard core technical guy but I think what Jim is saying is that Enterprise Architecture decisions need to be intentional... Software Architecture decisions need to be intentional... we inspect and adapt and refactor our way through the details behind the class hierarchies. In reality, these higher level decisions are really business decisions expressed in technology rather than technology decisions in and of themselves.

There is a fine line between the right level of up front planning and too much up front planning. It can be a slippery slope. As a project manager I simply want the team to understand what I call the 'big block architecture', what changes are going to be made in each of the blocks, and what the lines between the blocks mean. It is amazing to me how often teams cannot explain this basic level of information to me early in the project. Not understanding this has wreaked havoc on every moderately complex project I have ever worked on.

Okay... so there it is. There were lots of other cool points made throughout the talk but I think I've gone on long enough. Next post... we'll get back to the Product Owner stuff.

Orlando Scrum Gathering Recap via Twitter

Man... what a crazy week and half. January, February, and most of March were pretty laid back. The last few days though have gone totally nuts. Last Sunday I left for the Scrum Gathering in Orlando. Great conference but stuff really piled up while I was away. I got back with lots of urgent things needing attention. I did my best to manage it down in the two days I had before heading off into the woods for Scout camping this weekend. Phew!

It's now Sunday afternoon... I'm back in town... and sitting comfortably in one of my favorite coffee shops. I am very happy to be warm and dry and that my wife has cheerfully agreed to give me some time to go off and think agile thoughts. After wrestling around for a bit trying to decide how to best spend these next few hours... I've decided to talk a little about the Scrum Gathering... while it still counts as recent history.

This was my first Scrum Gathering and I want to say that I really... really... enjoyed the event. Most of the big name speakers did their thing on Day One. That included guys like Mike Cohn, Alistair Cockburn, Ken Schwaber, and Jeff Sutherland. Jim Coplien had never really been on my radar before last week but he is now. Very interesting fellow.

Day two was all Open Space. If you have never been to an Open Space conference... you have to give it a try. My first Open Space was the Agile Coaches Camp in Ann Arbor, MI last year. I thought the format seemed like a potential train wreck, but by the time it was over, I was hooked. I left that first Open Space with great insights from real practitioners and a handful of great new friends I am still in touch with. Day Two of the Scrum Gathering did not disappoint at all. I gravitated mostly to the talks on scaling agile and product ownership... surprising, huh?

I would have suggested a Product Owner talk myself but Lowell Lindstrom beat me to the punch.

Day three was mostly concurrent sessions led by a group of practitioners from around the globe. I bounced in and out of many of the sessions but was feeling particularly distracted that day. I really wanted to spend more time talking to people.... just like in the Open Spaces, most of the really good talks happen over beer at the end of the day. Speaking of which...

I got to meet and spend time with several of my favorite bloggers... Mike Vizdos... Tobias Mayer... and Mishkin Berteig just to name a few. Hung out quite a bit with Michele Sliger, Stacia Broderick, Sanjiv Augustine, Dave Prior, and Jesse Fewell from the Agile PMI Virtual Community. I spent one entire evening talking to Alistair Cockburn and the next night talking with Lowell Lindstrom. I had no idea Lowell was one 'declined invite' away from being an original signatory on the Agile Manifesto. Pretty cool.

I really enjoyed all the Twitter traffic going on during the talks. I found the commentary totally awesome and it was cool to keep up with all the sessions going on at once. I am *SURE* there is *SOME* value in being totally present for the talk I am actually in, but I would still like to figure out how to be in more than one place at one time... so this helped. If you want the full set of Tweets from the conference, go to http://search.twitter.com and lookup #scrumgathering.

I personally posted questions and cool quotes from the speakers while I listened to their talks. Here are a few that I thought were particularly interesting:

Quitting and being done are different things. I think this one came from Jeff Sutherland... it could have been Jim Coplien.

Patientkeeper spends months doing analysis and prototypes. This was from Jeff Sutherland and was interesting to me because we tend to think in agile that the ideas just appear or emerge from the ether.

Coplien is directly contradicting Martin and the emergent architecture paradigm. Need more discussion around this. This was an observation from me. I had not been clued into the whole Bob Martin/Jim Coplien debate on architecture. I tend not to believe in emergent architecture in complex organizations. I liked Coplien's point of view.

PMI CEO says to the Scrum community... quit your whining and get on with it. It is time to get onboard, huh? I personally thing we both have some things to learn from each other.

I am getting the sense that there are elements of Scrum that Schwaber and Sutherland fundamentally disagree on. Another conversation I was apparently not fully clued in on.

Anyone else staying up too late this week and not getting enough sleep? Okay that was me again.

Requirements grooming is collaborative. Schedule requirements workshops throughout the sprint - Paraphrase from Roman Pichler talk

Perfection is not a state it's a process - Jim Coplien

Hunt for the people that want it now - Alistair Cockburn. I liked this one because we had talked about a similar topic a few evenings before. Agile is a mirror. Sometimes it will tell you that the wrong people are on the bus.

What is your vision for a transformed world? I think that one came from Schwaber. Why are we doing agile anyway?

Don't accommodate that pain in your butt, fix it. This is a paraphrase from Ron Jefferies. When agile shows you a problem, don't change agile to deal with it. Fix the damn problem. Profanity mine.

No good idea can be judged by the number of people that get it - Ron Jeffries. I have never been afraid to disagree with everyone... and that doesn't always mean I am wrong ;-)

You can't teach courage, you can teach action in the face of danger - Ron Jeffries. Awesome!

My only regret was that I did not get down to H2O early enough to play a game of Werewolf. I got to sit in on the tail end of one... but afterward people wanted to go to bed. Go figure. Next time Vizdos... next time.

Product Owners or Product Ownership

Last post we explored the idea that teams are the elemental building blocks of agile organizations. We talked about how teams need steady inputs if we are going to expect steady outputs. Towards the end we concluded that the Product Owner in Scrum is that single person responsible for making sure the team has what it needs to deliver working software.

In most organizations, the Product Owner is pretty simply acting as a buffer between the team and the business. This is a nice clean solution for the team... but what about the Product Owner? Did we actually solve the problem or just transfer ownership?

If our cloud of stakeholders can't make up their mind about what they want... if there is no vision and they can't give clear direction to the Product Owner... the team will come to a standstill. The Product Owner will be unable to keep the backlog full of groomed features. The team will be unable to deliver working software.

What I am suggesting here is that we don't really so much need Product Owners... what we need is Product Ownership. We need a business that can make up its mind about what it wants to build and then translate strategic direction into products, projects, and ultimately backlog items our teams can build.

Right now teams are struggling. The are struggling not so much becuase they can't figure out how to write code... do continuous integration... test... or conduct a retrospective. They are failing at agile because we have pushed the alignment problem outside the team to a business that is not prepared to adequately provide a solution.

Solving this problem is going to be integral to any discussion of scaling agile.

Decisions, Decisions, Decisions

Deciding between feature teams or component teams is the first design decision you'll make as you build out your organization. Deciding on the right teams to build those features or components is the second.

Without a firm commitment to establish teams, decide what they are going to work on, and to coordinate their backlog... making sure they are always working on the highest value stuff ... your agile transformation is going to struggle. These decisions are foundational to everything else we are going to talk about.

From here out our discussion is going to revolve around figuring out how to give our teams the right stuff to work on.... coordinate their activities... do it in a way that best delivers on our organizations goals.... while minimizing the cost of context and coordination.

See You In Orlando!

 Have a dose of Agile Chronicles LIVE and in person! Both Mike Cottmeyer and Lee Henson will be at theupcoming Scrum Gathering in Orlando March 16th - 18th. If you are at the conference and you run into either of us, please do say hi and let us know who you are. It is always nice to match a name with a face and see the person who you are talking to.

As always, visit our table at the reception and grab some really cool VersionOne swag! Mike and I are always looking to strike up a good Agile conversation so we really do look forward to seeing you there! If for whatever reason you cannot be there, do not worry! We will have lots of chances to catch up at other conferences throughout the year. In other words, we hope to see you all there!  

Teams are the Building Blocks of Agile Organizations

If you are going to embrace any form of agile, you need to start by thinking about your teams as the elemental building blocks of your agile organization.

Teams are Elemental

Regardless of whether you decide to organize around feature teams or component teams, you need to look at the team as the fundamental unit of organizational capacity. Francois Bachmann from SprintIT has a great way of saying this... build projects around teams... don't build teams around projects.

We've got to stop thinking about how we are going to resource level across teams... or how to optimize the utilization of individuals within teams. Instead, let's think about how we can increase the performance of the team overall. Let's think about how we can develop better capabilities, greater technical prowess, and better working relationships between team members.

Great teams deliver great software... period.

With the team as the elemental unit of throughput... and knowing that over time we can establish a stable team velocity... we can begin to think about becoming predictable as an organization. We can start to see our teams as the building blocks around which we'll construct our agile organization. We'll be able to deploy teams of teams that solve our most critical business problems.

Normalizing Inputs

Think of a team as a black box that has both inputs and outputs. The primary input to the team is the prioritized product backlog. The output of the team is working software on regularly defined intervals. In order to get working software on regular intervals, you have to have a steady input of prioritized product backlog ready for the team to work on.

It is up to the business to normalize the input to the team if they expect to get a predictable output. If you put crap in the system... you are going to get crap out of the system. No groomed product backlog... no working software.

So from the teams perspective... all the normal agile stuff applies. Apply all great engineering practices... do the visual progress indicators... collocate... have daily stand-up meetings... do team building... and conduct retrospectives. That is the stuff inside the box. Regardless of scale... the team is king. They are an empowered, self-directed, self-manged unit of organizational capacity.

Everybody outside the team is responsible for making sure the teams have the proper inputs so that the business can get predictable outputs. The business has to act like a UPS that protects the team from unexpected spikes and brownouts. Scrum calls this function the Product Owner. I don't care so much what we call it... or who does it... we just need to make sure somebody or someone does it.

Context and Coordination

Regulating inputs to the teams means providing context... what we are going to do and why; as well as coordination... when we are going to do things and in what order.

Over the past few posts... we established that the Product Owner in Scrum is the single person that acts as our UPS for the team. We've already explored how in any moderately complex organization, this role is too big for a single person to handle. What I am saying here is that naming a single person to play the role of Product Owner is not nearly as important as fundamentally making sure that each of our agile teams has stable input.

We need stable input so the teams can deliver predictable and coordinated outputs that align with the broader organizational objectives. This is not a product owner problem, it is not a team problem, it is a business alignment problem. Abstracting this problem behind the Product Owner concept only hides the mess.

This problem is further exacerbated as we start putting multiple teams together in order to deliver on broader organizational objecives. Remember... the problem is not finding single person to serve as a Product Owner... the problem is making sure that teams of teams have proper context and coordination.

Feature Teams or Component Teams

Okay... for the sake of this post, we are going to put aside our discussion of the Agile Product Owner.

For now, we need to talk about some basic patterns for scaling agile projects. To talk about how we are going to scale, we need to talk about how we are going to organize. We'll pull it all back together in a post or two.

Agile software development is all about small teams. So... what is the ideal agile team size? As far as I am concerned there is no hard rule, but most folks I talk with recommend somewhere between six to eight people. Smaller is okay... larger, not so good. There are just limits to how well more than six to eight people can really communicate with each other.

So what happens when you have a project that needs more than six to eight people? Well... you break the larger team up into several smaller teams. Makes sense, right?

To me, this is where agile starts to get really interesting. When you have more than one team working on a single project, maybe even a single code base, what is the best pattern for splitting the teams? There are two primary schools of thought.

Organize Around Features

The traditionally taught... and almost universally accepted... approach for organizing agile teams is to organize around features. For a very thorough explanation of feature teams go find the book "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde. According to Larman and Vodde a feature team is a "long lived, cross-functional team that completes many end-to-end customer features, one by one".

Highsmith states in "Agile Project Management" that "Feature based delivery means that the engineering team builds [customer centric] features of the final product." I cheated here a little and grabbed the Highsmith quote from the Larman and Vodde book also. I figured it was okay because I read the Highsmith book too ;-)

Larman and Vodde summarize the ideal feature team as cross-functional, cross component, and co-located. They are working on complete user functionality, the team is made up of generalizing specialists, and typically six to eight people in size. In other words, our prototypical Scrum team.

The authors also point out several challenges with the feature team approach.... which I really appreciated by the way. Common barriers include... concurrent access to code, shared responsibility for design, difficult to learn skills, and organizational structure. Their assertion is that with modern tooling these challenges can be overcome... but it could take years.

I have to admit... this is clearly the most straightforward... and probably most effective way of organizing agile teams... but it makes some assumptions about your teams and your engineering practices. Like all assumptions, these need to validated. For a complete treatment of the feature team concept, go find the book... it is a good read.

Organize Around the Architecture

A more controversial approach to scaling agile teams can be found in Leffingwell's book "Scaling Software Agility".

Leffingwell introduces the idea of a design/build/test component team. The component team shares many of the same attributes of the feature team in that it is small and contains all the skill-sets necessary to delivery the user story. Leffingwell's component team is empowered, self-organized, and self-managing. In short, they are a typical Scrum team. But... and this is a big but... they are working on component features... not end user features.

This is really the exact opposite of what is recommended by Larman and Vodde. A feature team would be made up of specializing generalists from each of the component teams. These specializing generalists would have collective responsibility for delivering the customer centric feature end to end. Not quite the same as a component team, huh? I told you this was going to get interesting.

Where Leffingwell is going... is that at some level of scale... on some projects (let your imagination run wild here)... the system WILL get big enough that a single Scrum team cannot contain enough specializing generalists to cover a single feature. In some systems... not all, but some... we are dealing with a systems of systems. Some organizations... some products... require a systems of system.

Just to be fair... go get Leffingwell's book too... it is also a good read.

It's a Tough Call

So... our first really important decision is to figure out if the feature team approach is going to work in our environment or if we need to go with component team model. Personally... I tend to start with the feature team approach and only move toward components if I have to... but the decision is very situationally specific.

To make this decision you'll have to explore the diversity of your technology... how well your system is designed... what tools you have to manage your code base... the size and competence of your team... how much work the organization is running concurrently... and the quality of your automation.

You'll need to get real about the politics and power structures in your organization. You'll need to look at how well, and how empowered, all your cross-functional feature teams can operate. You need to take a hard look at what scale your feature teams WILL break down... at some scale they WILL break down. Is scaling to this level something we need to address now or can it wait?

Next post we are going to explore what being agile means to you. We'll think about just how agile you want or need to be. There are a few key questions around this topic that you'll have to ask... and answer... before we can decide how you are going to scale. The post after that we'll plan to pull it all together ;-)

The Product Owner Team

To this point, we have identified that the Agile Product Owner is an abstraction of many of our traditional roles in waterfall software development. The Product Owner is the Product Manager, the Project Manager, the Business Analyst, the Designer, and a whole list of other business stakeholders.

We have explored that this is a BIG job and VERY different from the role of the Product Manager. We have suggested that not many folks have the breadth of skills for this role... or the time available to do it well.

Many teams will insert a Business Analyst as proxy in an attempt to give the team the day to day direction that they desperately need. The problem with this approach is that the Business Analyst, or any other role aside from the Product Owner, is not the Single Wringable Neck... they just don't own the product.

A proxy can give the team direction but are not responsible for making the critical decisions when things need to change. They have to go ask someone... and that someone is usually the real Product Owner. Separating the real Product Owner from the team WILL slow the team down and you WILL risk building the wrong product.

It encourages too much separation of concern. What we really need is a shared accountability model... a team of people, each of whom work together as part of the team... all accountable for delivering on the role of Product Owner.

Product Ownership by Committee

Simple Shared Product Ownership instead of the BA as Proxy

Right now, this is only a slight modification of the BA as Proxy Model. Rather than the BA acting as the Single Wringable Neck, both the Product Owner and the BA are available to the team. The Product Owner is there to articulate the vision and prioritization... the BA to work daily with the team to translate requirements. There is a partnership between the Product Owner and the BA, where both work for the team to get the team what they need and when they need it.

This is a subtle but significant difference from the BA as Proxy model. We have to have the Product Owner operate as a full time member of the team... they cannot delegate this critical function... but we need to get them some help.

Think about this for a minute... what is a Product Owner doing when not working directly with the team? They are out working with stakeholders, identifying product requirements, prioritizing the user stories, and getting the user stories ready to be consumed by the team. Most Scrum people call this grooming the backlog.

Let's think about another one... what does the team need before they can accept a story into the sprint? They need a clear articulation of the business need, they need the acceptance criteria (the definition of done), and they need a foundational architecture on which to build the feature.

So... if getting the story ready for the team involves having a solid understanding of what it means to be done... and it assumes the existence of a baseline architecture... do we suppose that the Product Owner is getting all this worked out during the sprint planning meeting? Do we expect that user stories are some ad-hoc stream of consciousness based only on what the Product Owner learned after the last sprint review? Absolutely not.

Clearly the Product Owner is working out ahead of the team, making sure that they are building on a firm foundation of understanding... and that DONE is well understood.. and the features are in alignment with the stakeholder objectives. That is NOT the same as a big up front design... it is rolling wave... it is done at a high level of abstraction that gets more precise and more specific as we go.

If the Product Owner is allowed to think and plan ahead of the team, why not a group of folks that are part of the team... responsible for getting stories ready just ahead of the sprint? That is what I mean by a Product Owner team.

Introducing more roles into our Shared Product Ownership Model.

If we can stomach a shared role made up of Product Owner and BA, could we expand the cloud to include some design folks... or even God forbid... a Project Manager? Could we maintain a model where each person brings their specialty to bear, working with the organization in their unique way... and providing guidance to the team based on their area of expertise? I think so.

An Expanded Model in Practice

What that looks like in practice is a team of people, each with their individual responsibilities, almost like a subcommittee within the team... each representing their own particular view... all responsible for collectively grooming the backlog on an ongoing basis:

• The Product Manager has responsibility for working with stakeholders to identify requirements and set priority.

• The Project Manager maintains a view of the overall objectives and helps manage resources, capital expenditures, external dependencies, and touch points with the team.

• The Business Analyst is responsible for documenting acceptance criteria and documenting the conversations around the user story. They also become the primary point of contact for requirements clarification during the sprint.

• The Designer might prep some screen shots, wireframes, etc. to give the team an idea of the look and feel of the new features.

The Product Owner chairs the process, they remain the Single Wringable Neck, but have a support staff to help them research, document, and manage the inputs to the team. These people have responsibilities outside the team, but are razor focused on why they exist... to provide a well groomed backlog to the team... full of user stories that are ready to be pulled into the sprint. Each is available to the team during the sprint and all are collectively responsible, with the team... to deliver the sprint.

Business needs go into the process... actionable, buildable user stories come out of the process. Entire team accountable for getting to done. Pretty simple, huh?

Product Ownership by Committee with the PO, the Project Manager, the BA, and the Designers as all contributing members.

So... one more time, our Product Owner team is responsible for taking input from the broader organization, bringing their knowledge and expertise to bear on the problem, and working with the others on the team to craft a tangible message to the team to define context and provide coordination. Remember my last post? It all comes back to providing context and coordination.

More overhead? Yes. Necessary given the complexity of the task? Yes again. We can insist on a single product owner, but in many cases, I think we'll fail.

Many of you guys might be thinking I'm making this too complicated I understand that is a risk. I am waiting for the Kanban guys to tell me about flow... there is a place for that within teams and across teams. I am waiting for someone to weigh in that this team of people cannot be held jointly accountable.... I hear you, but without shared accountability we all fail. I understand all these arguments but we need answers.

We have not even begun to talk about agile at scale. We have not introduced multiple teams, let alone multiple teams that have to operate in a coordinated fashion. We need to talk about organizations, organizational backlogs, and portfolios. This construct is probably too complicated for a single team... but we need a model that scales. This is going to get worse before it gets any better.

Next post... we'll talk about how our shared Product Ownership approach scales to multiple independent teams and multiple interdependent teams. This is where the real fun begins. As always... thanks for listening.

Product Owner by Proxy

Last time around we introduced the idea of context and coordination. Context gives us mission and purpose... it tells us what to do. Coordination gives us a sense of timing and sequence... it tells us the most important thing to work on next.

Our agile Product Owner is responsible for establishing context and coordination for the team.

As products grow in size, as we add more stakeholders into the mix, the context of the solution grows, as does the need to coordinate across a broader cross-section of the organization. Scaling the Product Owner role is the fundamental problem we are trying to solve when we talk about scaling agile.

Balancing the Needs of Multiple Stakeholders

Once we get larger than a start-up company or a departmental IT initiative, the Product Owner becomes responsible, not just for deciding what to build, but for assessing the requirements of all the interested parties... balancing their often competing objectives... and deciding what goes in the product.

The Product Owner might have ultimate say, but they are no longer the only person with influence on the direction of the product. Other folks get to weigh in.

The Product Owner abstracting a cloud of interested stakeholders for the team.

To get a visual on the type of organization I am talking about, you might consider our small start-up software shop from the last post. Their product has taken off and the stakeholder list has grown to include a group of investors, a sales and marketing team, a training and support organization, and a more diverse user community. Lots more people have an opinion on what direction we take the product... some of them are spending money to make it happen.

The Product Owner balancing the competing needs of several stakeholder groups and negotiating the optimal feature set. This creates more shared accountability and dilutes the Single Wringable Neck model.

Faced with increasing external complexity, the Product Owner has to spend more time managing the expectations of the customers and the business. Because the Product Owner is trying to understand and manage the demands of a more diverse set of stakeholders, they often lose their ability to work closely with the team.

When this happens, the team loses context... and the team starts coordinating their work based on their best guess about what is important. The Product Owner is no longer driving the development process... they have deferred that responsibility to the team. This is probably one of the worst places for an agile team to find itself.

The relationship between the Product Owner and the Team has broken. We need some way to repair the situation and keep the team building the right software. The stakeholders are going to continue to put demands on the Product Owner's time and attention and their availability is going to continue to be at risk.

Product Owner By Proxy

Often the solution is to insert a Business Analyst, a Project Manager, or even a senior developer as the Product Owner. This division of labor becomes necessary because the job has gotten too big for a single person to perform the role. The real Product Owner focuses on customers (and other stakeholders) while the day to day interactions with the team are delegated to the proxy.

This diagram show the BA as the proxy Product Owner for the team. The Product Owner becomes only a part time participants on the team and the BA fills the role of providing context and coordination for the team

As we mentioned in the last post, and alluded to here... Product Owner proxies can keep the team moving but will ultimately degrade the accountability the Product Owner has for the emerging solution and degrade the quality of the information available to the team.

Unless the proxy is truly empowered to make binding decisions on behalf of the Product Owner, I am not a big fan of this approach. More often than not, the proxy is just NOT the Single Wringable Neck. You can hold them accountable, but unless they get to really decide what happens with the product, accountability is going to break down... they will defer to the real owner every time.

Someone on the team has to be empowered to set the context and must be there to coordinate for the team... without that, getting DONE gets nearly impossible. How many teams have a backlog of completed features waiting for the Product Owner to accept them. Believe me, it happens... and it is a real problem for many teams.

We need a better solution than absolute insistence on a single Product Owner model... or even a proxy. Next post we'll look a simple team based Product Ownership approach.