Hey folks... here is the deck I am doing this morning at Agile2010. I am pretty excited to do this talk... I finally feel like I've got the slide sequence and story right. It's amazing what a good night sleep will do for you! My talk is in E-2 on the Ballroom level, hope to see you guys there!
Subscribe to Leading Agile
There is a FREE event for Product Management types in Atlanta. The first ProductCamp Atlanta will be held Saturday, June 6, 2009 at the GTRI Conference Center (250 14th Street, NW, Atlanta, GA). You can find the details here… http://barcamp.org/ProductCampAtlanta.
They are looking for sponsors and session leaders. (Product Manager types LOVE Agile topics). Please forward this post to other people who might able to come to Atlanta for the event. This is going to be really cool, I have done a few barcamp type events and they are great learning opportunities.
Right now I am a strong maybe to go... my wife and I are leaving for Vegas (SQE Better Software Conference) the week after so I don't know what is going on with the kiddies that Saturday. If I were not travelling the week after... I would definately take a Saturday to go. I strongly encourage you guys to make this happen! Subscribe to Leading Agile
Subscribe to Leading Agile
In my post Second Order Agile Scaling, I suggested that building teams around capabilities was the first step toward untangling our portfolio management mess. The second step... and equally as critical... involves having the discipline not to start projects we don't have the capacity to finish. We know from our experience with small team agile that writing requirements we can't develop is waste. The exact same thing goes for building capabilities that can't be consumed by the project team or the business.
Agile portfolio management involves identifying our most pressing business problems... or most lucrative market opportunities... and coordinating the capabilities of the organization to deliver the highest return on investment with the least amount of risk to the business. Our agile organization is going to organize around capabilities... understand and measure the throughput of each team... and focus on delivering the highest priority projects first.
Let's consider a simplified model for what this kind of project intake and decomposition might look like...
Figure 1 shows how a project is identified, broken down, and assigned to teams through progressive elaboration of the requirements and design
Here is the idea behind this diagram... the business is constantly looking for things to fix and opportunities to take advantage of... opportunities that will align with overall strategy and objectives of the enterprise. The business knows that these opportunities are going to leverage the combined capabilities of several teams within the organization... but early in the life of the project... we are not quite sure which ones. How do the strategic planners know what the organization can deliver... and when... so they know how to make commitments to customers?
The answer lies in progressive elaboration of requirements... the progressive elaboration of the solution architecture... while restraining our tendency to over-specify the solution too early. We need to make commitments... while keeping our options open... while we figure out the details. Let's look at this in a little more detail...
Circle 1: Strategy and Enterprise Architecture
When projects arise for consideration by the business... there must be a team in place that is responsible for assessing the set of possible business solutions (requirements) and the set of possible technical solutions (design). This teams job is to consider the objectives of the business to identify a high level solution that can be delivered within the time and cost constraints necessary to deliver the expected value with minimal risk to our investment.
See my post called Software Requirements Balancing Act for a little more around what I am talking about here. Putting this into more day to day terms... we need to identify the major epics and themes that will make up the product requirements. We also... and this is really important.. need to identify the organizational capabilities (feature teams, component teams, or services teams) that will be leveraged to deliver those high level requirements. In my mind... I call this enterprise architecture... the set of big block decisions that the organization makes to constrain the set of possible technology outcomes.
Circle 2: Product Management and Software Architecture
Once the business has decided what it wants to do... it needs to engage the capabilities of the organization to deliver. The themes and epics are assigned to the Product Owner team to break down into user stories. If there is a need to manage technical dependencies between component teams or services teams... this is where you begin to establish the high level software architecture. Admittedly... I'm not talking much about building software yet... but I fully expect this level of the organization to explore options... and validate decisions... by building out and delivering working code.
The goal at this stage of the planning process is to bring our understanding of the problem space and the solution space down to the next level of granularity. Just as the strategy team and the enterprise architecture team collaborate to keep the requirements and solution in balance... the Product Owner Team and the architect collaborate to keep the user stories and software architecture in balance with the constraints established by the strategy and EA teams.
Circle 3: Product Ownership and Detailed Design
At this point, I am sure that you can see where we are going here....just like themes and enterprise architecture constrain the decisions of the Product Owner team... user stories and software architecture constrain the decisions of the capability teams. We are taking the problem from a very high level of abstraction... through progressive elaboration... to the point we are ready to assign user stories to a capability team where user stories can be specified, designed, and coded at the detailed level.
This is where the rubber really meets the road. This is where the actual capabilities of the business are delivered. You have a team of engineers collaborating with a product owner on a day to day basis... making the daily trade-offs to deliver within the constraints established by the Product Owner team and the Software Architect. Again... each higher order team constrains the decisions of the lower order teams... not in a vacuum... but collaboratively with an established feedback mechanism.
Constraints and Feedback
Figure 2 shows the flow of constraints down the chain with feedback flowing back up the chain.
In this model... business decisions have to be made up front at a pretty high level of abstraction... that's reality and we have to deal with it. Enterprise teams do not get a free pass to deliver whatever they want... after all... most business do not have an emergent business model... they operate under a goal oriented model. Teams deliver on the goals and strategic objectives of the larger enterprise.
These business decisions though need to be made at the appropriate level of abstraction so that the teams can inspect and adapt their way to delivery. The business establishes the constraints but the team is free to be agile within those constraints... they can do what they need to do to deliver on the higher order objectives.
Okay... so what if the constraints are invalid or limit our options in an inappropriate way?
The idea is to mitigate the issue within the capability team... or if possible... at the current layer of abstraction. When the problem transcends the ability of that layer to resolve... it gets escalated up the abstraction hierarchy and mitigated at the next higher level. As deep or as wide as your agile enterprise is... constraints come down the hierarchy... and feedback goes up the hierarchy. Each level is responsible for managing trade offs until you reach a point where the issue has to be taken up to the next level. Subscribe to Leading Agile
Subscribe to Leading Agile
Subscribe to Leading Agile
Subscribe to Leading Agile
When we talk about scaling agile... we are really talking about how to coordinate the activities of many small teams to do the business of the enterprise. The interesting thing is that we don't have to go from 6-8 people to thousands in one giant intellectual leap. There are plenty of problems to solve moving from only one team to as few as three or four.
How are we going to make sure that each of our teams are working on the right stuff and in the right order... how are we going to establish context and coordination? This post I want to explore a few models I've used over the years to try and solve this problem.
Scrum of Scrums
This seems to be the standard answer for scaling agile projects. Do you have more than one team? Easy... do a Scrum of Scrums. Great... but what does that mean? Who participates? How often do they meet? What are they tasked to do? If you have ever tried to answer this question for a real company... the idea can begin to break down pretty quickly.
The simplest implementation of a Scrum of Scrums involves the ScrumMasters from each of the teams getting together to deal with any cross-functional issues the teams can't deal with locally. This group meets daily and answers the same type of questions the team members answers during the daily stand-up... what did your team do yesterday... what did your team do today... are there any organizational impediments that will prevent your team from delivering the sprint? This group usually meets sometime after all the other Scrum teams have had their daily stand-up.
This is a pretty useful collaboration tool if the teams are largely independent from each other. Remember.... independent means that they share few dependencies. If the teams do not need to operate in a coordinated fashion, from either a requirements perspective or a technology perspective, this model can work pretty well. It can be used to manage minor dependencies, but the goal of the Scrum of Scrums is primarily to communicate between teams and provide support for other teams that might be struggling to meet their objectives.
Product Owner Team
We've talked about the idea of a Product Owner team at the single-team level. We established that the role of the Product Owner was often too big, and an abstraction of too many roles, for a single person to do effectively. This is a pretty common problem in a mid-size organization because there are lots of stakeholders. It is even more common in an organization when you have more than one team working to deliver an integrated product.
In this case, you might want to consider pulling the Product Owner team out of the single team and have them work across several teams at one time. In this scenario, the Product Owner team might have a Chief Product Owner, the Project Manager, the Business Analyst, and UX designers. Just like in the small team scenario, this team is responsible for grooming the backlog for each of the Scrum teams and making sure that there is sufficient information ready for the team to consume during sprint planning.
In this model, each Scrum team would have a proxy for the Product Owner team and likely its own ScrumMaster.
The Product Owner team would be a team of its own with a prioritized backlog and full time team membership although they will likely have responsibilities outside the team as well. The Product Owner team works with each of the proxies and ScrumMasters to make sure that they have sufficient information to act on their behalf. The members of the Product Owner team are available to all the Scrum teams... just not allocated full time like the proxies and ScrumMasters.
This model works best primarily when its requirements that need to be synchronized across Scrum teams. You'd probably use this approach with feature based teams that can work across the entire software stack. We are in effect building a team of folks that are responsible for all the requirements decisions that cannot or should not be made at the individual team level.
Product Owner Team with Architects
This is a variation of the Product Owner team that is really geared more toward Leffingwell's component team model. Because component teams don't work across the entire software stack... there are technical decision that will have to be made across teams. Interfaces will have to be defined... software contracts will have to be established... complementary technologies will have to be chosen.
Irregardless of component teams or feature teams... I tend to like this model.
From my point of view... it is always a good idea to have the technical folks collaborate with the requirements folks to make sure that the requirements space and the solutions space are kept in balance. Technical collaboration with the business is built into the very fabric of our small team model but has to be explicitly accounted for when we start scaling technical decision across multiple teams.
Just like the Product Owner team is responsible for the decisions that cannot or should not be made at the team level... adding the Software Architect to the Product Owner team creates accountability for those technical decisions that cannot or should not be made by the team.
And by all means... drive as many technical decisions down to the team as possible. This group of folks should only deal with the decisions that you don't want made by the team... because they are bigger than the team... because they are primarily strategic business decisions masquerading as technical decisions. I'll also add that these decisions should not be made in vacuum... they should be made in collaboration with the teams that are actual doing the work.
Integration Teams
If you've come this far... you might find yourself in a situation where you need not only requirements context and coordination... and technical context and coordination... you might need a team of folks that can glue it all together once it is built. You need a team that can integrate the components and you need a team of folks that make sure it all works together when you are all done. Not a trivial problem, huh?
Context and Coordination
You'll notice in these models... the more dependencies you have... the greater the context and coordination costs. And remember... at this scale we are only talking about 3 or 4 or 5 teams.
When you build your organization around small independent teams... where each team has autonomy to do what it needs to do to deliver against it's objectives... you really just have a special case of 'small team agile'. Product Owner or Product Owner teams don't make all that much difference to the enterprise. Your concerns are not making sure that everyone is working on the right stuff in the right order... you are more concerned with making sure that we are communicating and cooperating. This is not a trivial problem... it's just that the solution is not all that expensive.
When you start introducing dependencies between requirements, you have to make sure that everyone is working together to build the same product. At this point the Product Onwer or Product Owner team discussion becomes much more critical. You need a group of people that are charged with making sure all the teams are working together to build the right features, in the right order, and with the right level of common specification. Your context and coordination costs just went up a notch.
If your organization is so big, or so complicated, that you are really building systems of systems... you have a tremendous amount of dependence and interdependence across the product landscape. Each system may be a product in its own right and has to balance its own priorities against the priorities of the cross component features. Its no longer just that requirements are dependent on each other... your software architecture and technical infrastructure all has to be aware of what's going on. Your context and coordination costs have just gone through the roof.
Can this still be agile?
It depends on how you define agility. I believe that you can build your organizations around small self-organized agile teams. Where I get hung up is on the single wringable Product Owner making all the decisions. A few posts ago I made the distinction between Product Owners and Product Ownership. We need Product Owners... but more than that... we need organizational Product Ownership. Each team can be independent and agile within the boundaries established by the broader organizational objectives.
Agile organizations build capabilities around small self-managed agile teams. Product Owners and ScrumMasters guide those teams. That DOES NOT mean that these teams get to build whatever the heck they want with no guidance from the larger organizational entity. Product Ownership involves establishing the broader requirements context and coordinating how our small agile teams work together to deliver the business value expected from a larger, more complex enterprises. Subscribe to Leading Agile
Subscribe to Leading Agile
I did a post late last year called The Secret to Organizational Agility. In that post I suggested that for a company to be truely agile, they had to break dependencies at all costs. I got a bit of flack for that post... the general consensus being that organizations were full of dependencies and we had to manage for that reality.
No argument from me there.
I maintain though that if you really want to be an agile organization... if you really want to be responsive as a company to changing market conditions.... you must find a way to break as many dependencies as you possibly can. Any dependencies you leave in place are going to incur a cost... a tax if you will... on your organizations ability to adapt to changing conditions.
That begs the question then... just how agile do you want your organization to be?
When we leave dependencies in place, the inputs to one team will be constrained by the output of the other teams. This is why Larman and Vodde make such a strong case for feature teams in their book "Scaling Lean and Agile Development". When you can have a single team work across the entire software stack under the direction of a single business stakeholder... that is pretty darn agile.
When we are talking about a large application where feature sets have to share common behaviors or a common look and feel, you are creating dependencies that reduce the team's autonomy. When you have component teams that are building component features, features that will ultimately be integrated into some larger customer facing feature... you now have dependencies that limit the decisions each team can make about the product.
Said another way, one team's outputs will become the inputs for each of the other teams.
There will be greater context costs because you'll have to put structures in place to align your teams with the objectives of the organization. There will be greater coordination costs because your teams will have to operate with an awareness of each others activities. Subscribe to Leading Agile
Subscribe to Leading Agile
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://www.leadingagile.com/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://www.leadingagile.com/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://www.leadingagile.com/2009/02/product-managers-and-product-owners.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://www.leadingagile.com/2009/02/filling-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://www.leadingagile.com/2009/03/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://www.leadingagile.com/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://www.leadingagile.com/2009/03/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://www.leadingagile.com/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://www.leadingagile.com/2009/03/teams-are-building-blocks-of-agile.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://www.leadingagile.com/2009/03/product-owner-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! Subscribe to this blog
Subscribe to Leading Agile
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. Subscribe to this blog
Subscribe to Leading Agile
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. Subscribe to this blog
Subscribe to Leading Agile
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 ;-) Subscribe to this blog
Subscribe to Leading Agile
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:
Product Ownership by Committee with the PO, the Project Manager, the BA, and the Designers as all contributing members.
Subscribe to this blog
Subscribe to Leading Agile
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. Subscribe to this blog
Subscribe to Leading Agile
At this point in the discussion, it probably makes some sense to sync up a bit.
We started off looking for where all the traditional software development roles fit in Scrum. In the process we concluded that many of the roles are either the direct responsibility of the Product Owner or abstracted from the team behind the Product Owner. This conclusion is both powerful and problematic.
The Product Owner is a powerful construct because it solves two significant problems for the team. By virtue of having total ownership of the product direction, the Product Owner sets context. They give the team a single place to learn what needs to be done and why it is important to the business. The Product Owner also provides for coordination. They get to set priority and decide when the team has met its objectives.
Think about what happens when we don't have a Product Owner working with the team. We might have excellent technologist, but no sense of the bigger market picture. If we sub out the Product Owner for a Business Analyst or Project Manager... we get the some of the coordination... some of the context... but little of of the vision. If we just have a Product Manager, we get much more of the context... but we are going to loose quite a bit of the coordination.
We lose the Single Wringable Neck. We must have both context and coordination for a successful agile team.
The Product Owner is problematic on several fronts. Most organizations have not hired single individuals with the breadth of skills necessary to fill the position. These skills rest with specialists... Business Analysts, Project Managers, and Product Managers. Do we convert these people to Product Owners? Can we train them with the new skills required to be a successful Product Owner? Will the organization trust these folks to be that Single Wringable Neck?
What if we hire from the outside? What do we do with our talented, dedicated, and most importantly.... knowledgeable traditionalists? Do we just let them all go? Is our organization structured such that a single person can do everything necessary to provide context and coordination for the team? Will we will able to find enough super human product owners to drive our mission critical products? What do we do while we are in transition?
This issue is BIG for small teams and mid-size organizations. It is even BIGGER for companies that want to do an enterprise agile roll-out. These are places where context will never be set by a single individual and coordination must happen on a much grander scale.
Let's Start Small
We'll start by looking at context and coordination issues on a small team and see what happens as that team tries to scale.
This picture describes our simple agile scenario. We have a single Product Owner working with a small team of 6-8 people... for this example, a team of generalists.
From the team's point of view, the Product Owner has 100% responsibility for defining the context for the team. They create the product backlog, determine acceptance criteria, get the backlog ready for the team to build, and work with the team on a day to day basis to develop the emerging product. They own the product vision in its entirety.
In this example, the Product Owner also owns coordination. They set the priority of the backlog and thus the build order. If any trade-offs need to be made during the sprint, the Product Owner gets to make the call. At the end of the sprint, the Product Owner decides if the feature meets the acceptance criteria defined at the beginning of the sprint. They get to say when we are done.
Think about the kind of organization we are describing... probably a small start-up with a single visionary leader and a team of developers. There is no time or money for any unnecessary overhead, it is all about getting the product ready for market. There is no accountability to anyone other than the single stakeholder.
You might also see this model used on a small departmental IT project... someplace where there are no dependencies on any other part of the organization. This could be something like a small departmental website or maybe a homegrown accounting solution. These scenarios are optimally agile and optimally unconstrained... but do they reflect the reality of most organizations adopting agile? Probably not.
Next post, we'll add some stakeholders and start to scale the size of our project. Any thoughts on what happens to our single point context and coordination model? Subscribe to this blog
Subscribe to Leading Agile
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. Subscribe to this blog
Subscribe to Leading Agile
Last post we explored what roles fit nicely in our existing Scrum roles. We also identified a few that didn't. We explored the role of ScrumMaster and Team and talked about which roles seemed to make sense in a Scrum context. Today we'll take a look at the role of Product Owner and see if we can find a home for a few of the others.
Most teams start with the assumption that the Product Owner role should be filled by the Product Manager. I think that is a reasonable starting point but let's look at how Wikipedia defines the role of a Software Product Manager:
A Software Product Manager is responsible for researching, selecting, developing, and placing a company’s products. This role considers numerous factors such as target demographics, competition, and how well the product fits in with the company’s business model. A software product manager takes this high level understanding of market needs and translates these needs into Product Requirements Documents and Software Requirements Specifications. Product Managers ensure that the resulting product is deployed successfully and meets the initial specifications.
That captures some of what a Product Owner does, but probably not everything. Jack Milunsky posted a nice summary last week of the Top 10 Activities of the Product Owner over on Agile Software Development. I don't want to rehash Jack's post here so I recommend you hop over and take a look at that post if you need a refresher. I trust that many of my readers probably have this idea under control ;-)
When you look at all the things an agile Product Owner is doing for the team you see pretty quickly that the role of Product Owner is really much, much more than that of a traditional Product Manager. From the development teams perspective, the Product Owner has responsibility for everything from executive sponsorship to planning and scheduling. They are responsible for managing expectations, status reporting, requirements definition, and even quality and user acceptance. To quote the Scrum guys, they are the Single Wringable Neck.
That is quite a bit of responsibility for one person... for one role... on an agile project. Is it possible that we have found where Scrum put all our missing roles?
Product Owner as Project Manager
Much of what we think of as Project Management is actually assigned to the Product Owner in Scrum. They are responsible for assessing the needs of the project stakeholders and making sure those needs are documented, prioritized, and communicated effectively to the team. The Product Owner is responsible for identifying and managing tradeoffs to deliver the release within the time, cost, and scope expectations defined by the business. All pretty straightforward Project Manager stuff.
Product Owner as Analyst
The Product Owner role is expected to translate requirements, much like a traditional business analyst or designer, into language that a developer is going to understand and can build into the product. They work daily with the team to explain and clarify their emerging understanding of the requirements. They make sure the requirements meet acceptance criteria and get to decide ultimately if features are ready for release.
This sounds a whole lot like why we had Systems Analysts and Business Analysts in the first place? Is it possible that the user experience and user interface should be designed by the Product Owner as well? If not the Product Owner, who else?
NOTE: For a really cool treatment of this topic by a true expert, take a look at Jeff Patton's recent post on called the Product Owner and the Product Shaped Hole. Jeff touches on a few themes I am exploring here but I have no idea if he would agree with where I am going in this post.
Product Owner as the Business
By virtue of owning the product backlog, and having authority to set priority, the Product Owner abstracts and plays proxy for quite a group of traditional project stakeholders. The Product Owner represents in Scrum all the interested Product Managers, the marketing team, the sales team, the support organization, the implementation group, and the training organization. They are the Vice Presidents and the Division Leaders... the CIO, the CFO, and the CEO
... all rolled into one nice, neat, tidy package for the development team.
Really? You might need to unpack this a bit...
In other words... and I'll say it more explicitly this time... it is my premise that in Scrum, the Product Owner either has the responsibility for, or is an abstraction of, every other role not previously accounted for in discussing the ScrumMaster and the Team. The Product Owner is the Project Manager, the Business Analyst, the System Designer, the User Experience Architect, and every other Business Group... all rolled into one. The role is really supposed to be omnipotent and omnipresent.
What do you guys think? Have we found our missing roles? I think so. You might be thinking at this point that I have overstated my case... maybe I have. I know there are many teams out there with Project Managers and UI Designers and Analysts that probably think they are doing Scrum just fine. Maybe there are... but I bet Scrum didn't tell them how to do it, and furthermore, I bet they are assuming additional coordination and communication costs to make it happen.
Over the next few posts we'll explore when and why the single Product Owner approach works. We'll also talk a bit about when and how the Product Owner abstraction breaks down. I'll begin to share with you some of the things I have tried over the years to minimize coordination cost and a few ideas for what I might try next time. I'll also be interested to hear about some of the things you have tried and how you think about the role of Product Onwer.
Thanks for hanging with me so far... Subscribe to this blog
Subscribe to Leading Agile
