Orlando... Miami... Vegas... Chicago

It is shapng up to be a pretty busy conference year.  

As you guys know I got a last-minute opportunity to attend this past Scrum Gathering in Orlando.  It was such a great experience I could't shut up about if for almost two weeks.  Well... I got a similar last-minute opportunity to head down to Miami for David Anderson's Lean/Kanban conference.  I've been thinking quite a bit about lean portfolio management over the past few months and I am excited to get to attend.  I have to tell you, it's really nice to be able to attend some of these conferences... not as a presenter... not as a booth babe... but as someone with something to learn.  If history repeats itself... I'll have topics to write on for weeks!

From what I understand... there is still space... and that means you can go too!  David has a great set of speakers lined up and it is going to be an awesome event.  Click here for more information and links to register...  

 

http://www.leankanbanconference.com/   

 

Mike's Upcoming Talks...

 

A month or so back I mentioned that I am doing my Agile PMP talk at the Better Software conference in Vegas.  SQE puts on great conferences and I am excited they are letting me be a part of this one.  The Better Software conference is not specifically an agile conference... but from the looks of the agenda... agile continues to be a hot topic.  The interest in agile amongst the traditional crew is overwelming.  I am looking forward to some great conversation.  

 

If you are not going... you should really reconsider.  If you are on the fence and need more information... check out their website for all the details:

 

http://www.sqe.com/BetterSoftwareConf/

 

Last year I proposed six talks for the Agile 2008 conference up in Toronto... I had three selected.  This year I submitted seven... and so far only have one selected.  Guess what... it's the Agile PMP again!  The good news is that my materials are already prepared and I am getting a lot of practice delivering that talk!

 

Two of my talks I have not heard anything back on and I am guessing they are maybe on the border waiting to see if any of the other selected speakers don't accept their invitation. Regardless... I am as pleased that I'm speaking again this year for the Agile Alliance.  Agile2009 is another must attend event... so if you have not registered... get busy.  You can find more information on the program and links for registration at:

 

http://www.agile2009.org

 

Lots of Talking in Atlanta too...

 

A couple of weeks ago I did my agile offshore talk for the local Scrum group and my Agile PMP talk for the local PMI chapter.  The PMI talk was a lunch session with over 160 people... by far my largest audience yet.  Over the next few weeks I'll be on an Agile PMI panel at yet another PMI Atlanta event.  I've also got a few local companies that want me to come out and talk to their PMOs about agile.

 

Its all good stuff and I am very happy to have the oppotunity to get out and spread the word.   If you happen to be at one of my talks... please come by and introduce yourself and let me know what you think.  Looking forward to meeting all of you!

Subscribe to Leading Agile Subscribe to Leading Agile

Second Order Agile Scaling

A post or so ago we talked about first order agile scaling... moving from a single agile team to more of a team of teams concept... one where each of the teams has to work together in a coordinated fashion to bring a product to market.  The degree of coordination is predicated upon how independent the teams are from each other.  The more dependencies between the teams... the greater the context and coordination costs.

 

This post we are going to lay the foundation to build on some of our first order scaling concepts.  We are going to introduce the idea of capability teams, explain why tradtional portfolio management fails, and introduce the notion of agile portfolio management.  Our goal is to be able to build out a delivery organization that is broader than a single product.  Second order agile scaling involves running multiple projects through your development organization simultaneously.  

 

Capability Teams

 

We've talked about the idea that agile organizations coordinate the work of many small teams to deliver on the broader objectives of the enterprise.  We've also talked about the idea that agile teams can be organized around features or components... maybe even services (think SOA).  Regardless of what we have our teams work on... regardless of what we have them organize around... we are fundamentally bringing folks together to deliver capabilities to the enterprise.  These capabilities can be deployed whenever and however to deliver on the highest priorities of the business.

 

This is a very different approach from how we traditionally manage our project portfolios.  

 

Most of us think about deploying people and skills to do work... to perform activities.  If we are going to deploy people to do activities... we have to predict and plan and document so that they unambiguously know what we need them to do.  Becuase we have specified so much, it is tough to hold the people accountable for outcomes.  Dennis Stevens touches on this concept a bit when he talks about white space in projects.  Who manages the work that happens between the lines in our project plan?    

 

Rather than deploy individuals to do tasks, agile organizations deploy teams to deliver capabilites.  When we think about the capability as the outcome rather than the completed task, we can hold team team accountable for delivery... and let go enough to allow them to get the job done.  The teams fills the gaps... they fill the white spaces.  

 

From an organizational perspective... from the point of view of the portfolio... I need to be able to assess organizational capability... understand how fast I can deliver those capabilites to the business... predict when certain capabilities will be delivered... and understand how to pull the capabilities together to deliver our strategic initiatives.  We are intentionally broadening our definition of agile output from our traditional notion of a delivered feature to that of a delivered capability.  

 

Why you ask?  Well... at scale... it might not be an end to end feature a team delivers to the business.  Organizational capabilities and how fast I can deliver them... how fast I can integrate them...  are all that I fundamentally care about at the portfolio level.  When we plan around capabilities... througput can normalize over time.  Planning around individuals and tasks is consistently erratic and unstable.

 

Why Project Portfolio Management Fails

 

Traditional project portflio managements fails becuase it focuses on the optimal utilization of individuals rather than focusing on the delivery of capabilities to the business.  

 

The application of people to work packages naturally results in periods of high activity and periods of lesser activity for the individuals on the project.  Because our focus is almost always on the task utilization of the individual and less on the capability througput of the team... we look for something else to keep that person busy.  

 

Since we have some folks with a little unallocated time... we go ahead and get started on the next project.  It doesn't matter that the first project hasn't finished yet... we need to keep people working on stuff.  So.... our second project has started but doesn't have all the resource necessary to finish.  Furthermore, we have created dependencies between our first project and our second project.  To deliver either of these projects on time, we have to be on schedule with both.

 

It is hard enough to keep one project on schedule, let alone two.  What about when we try to get started on three projects... or four projects... or thirty projects?  Trying to model and manage the resource allocations across all these projects is mind-numbing.  Trying to predictibly deliver any of the portfolio projects is equally challenging.  Running behind on any of the portfolio projects puts them all at risk and invalidates all our detailed planning.  A single change creates a cascading ripple through the entire portfolio and everything has to be recalibrated.

 

You want to talk about dependencies and context and coordination costs?  The cost of traditional project porfolio management is through the roof, and often so disconnected from what is actually going on at ground level, it is an ineffective management tool at best... and at worst... down right deceptive.  A convenient and costly fiction.  

 

Agile Portfolio Management

 

Building teams around capabilities is the first step toward untangling our portfolio management mess.  Not starting projects we don't have the capability to finish is second.  The trick becomes how to intake projects... decide how to break them up... figure out how to distribute them across organizational capability teams... manage the flow of value through our capability teams... and forcast when capabilities can and will be delivered to the business.   

 

Next post we'll blow this out a little tie it back to some of the concepts we talked about in the first order agile scaling post.      

Subscribe to Leading Agile Subscribe to Leading Agile

The Software Requirements Balancing Act

In my last post... First Order Agile Scaling... I made a quick comment that I think needs further explanation. I said that 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. I've said that so many times to myself and my customers that I think I take some of this language for granted. Reading over that post... I wanted to put a few more words around what I am thinking here.

Business Problems and Market Opportunities

When we first consider doing a software project, we typically have some business problem we are trying to solve or some market opportunity we are taking advantage of. Those problems and opportunities exist outside of how we choose to solve them. Requirements describe how the business wants to move forward in the market. The requirements space is the set of possible requirements that could satisfy that market need.

Likewise... architecture and design describe how the requirements are going to be implemented in technology... but at the end of the day... we are really just describing in technical terms how we are going to solve the problem identified by the business. The solutions space is the set of possible solutions that could meet the requirements and satisfy that business need.  

Balancing the Triple Constraints

Given unlimited time and money... the business can choose to solve the problem any way they see fit. There are no constraints on the set of requirements the business can choose from. Similarly, given unlimited amount of time and money, the technology folks can implement whatever cool stuff they want to satisfy the business requirements.  Its not often though that we have unlimited time and money to solve the problem. 

Typically the opportunity has a potential market value and costs have to be minimized to reduce risk so we are confident of a return. It's likely we have a narrow window of time to realize that return before a competitor gets there and delivers first.  Many teams operate as if there are no constraints on the time and cost. Business people go off by themselves to develop requirements that have little chance at all of being delivered within the budget constraints. Technology folks then go off and specify designs that will never be able to be done on time.

Collaborate Early and Often

Balancing the requirements space and the solutions space is my way of saying that business people and technology people need to collaborate... from the very, very beginning of the product definition... on what they are going to build. Once the product folks start thinking of what they want to implement... the technology people need to weigh in about the kinds of solutions those requirements are going to imply.

We need constant communication... and frequent iteration... continuously allowing our emerging understanding of the requirements be in balance with our emerging understanding of the solution. We need to let our emerging understanding of the requirements be shaped by what it is going to take to build it. We need to let our emerging understanding of what we want to build be shaped by what the business needs, what it is willing to spend, and when it needs to be delivered.

Again... this is one of those things that is built into the very fabric of the small team agile concept. It is another one of those things that needs to be explicitly addressed when we start talking about scaling agile.

Doing it in Practice?

What does this look like in practice?  Simply have the business people sit down with the technology people and explain the business problem... and their vision for how to solve it... all in terms of high level requirements. The technology people have a day or so to go off and think through their palette of possible solutions. The technology folks come back and explain their high level solution... how it satisfies the product vision... and a ballpark idea of how big the project might be and how long it might take to complete.

If we are not in sync... if the requirements and the solution are not in balance... iterate the process allowing what we know about the solution space influence the requirements. Come back to the table and start the process over... either until we have convergence... or we realize that there is no solution that can deliver the product vision within the time and cost constraints established by the market. By bringing the requirements vision and the solution vision into balance at the early stages of product conception... no one ever gets too far off before we have the opportunity to reset everyone's expectations.

Subscribe to Leading Agile

Subscribe to Leading Agile

First Order Agile Scaling

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

Survey Time!

There are a couple of survey's going on that you guys need to be aware of... and more importantly... to take a few moments to go and fill out.

The first one I want to mention is a salary survey from VersionOne and ASPE. IT Salary surveys are nothing new but none of them so far have really focused on the specifics of the agile community. This is a great opportunity to see how our industry in doing and how we compare to other IT professionals.  In reality... I am really just hoping that all you guys make a bunch more money than me and I can use your data to make a solid case that I am underpaid ;-)

Okay, really... let's put our data together and see where we stand, and hey, and if a few of us are able to get a raise out of the deal... all the better! You can click here to take the salary survey... http://tinyurl.com/agilesalary

The second survey I want to mention is being conducted by a fellow blogger Jurgen Appelo over at NOOP.nl. Jurgen has been prolific lately with top 100 blog lists and top 50 twitter lists. When not compliling top 100 lists, Jurgen writes on agile management and is prone to go on long rants about complex adapative systems and other nonsense (just kidding Jurgen!). Every time I get mentioned on one of Jurgen's lists, I get a 10% bump in traffic and usually pick up a few subscribers so I guess I owe him, huh?

Jurgen isn't satisfied with the other agile surveys and has a few questions of his own he'd like answered. He is interested in what practices are most closely associated with agile... what practices are most important... and what practices are most commonly applied. These are great questions so please take a moment to head over to NOOP.nl and read Jurgen's post... follow the directions... and complete the survey.

Here is a link to Jurgen's post with the survey information http://www.noop.nl/2009/04/the-big-agile-practices-survey.html

Thanks for supporting the agile community and for taking a few moments out of your day to help a couple of worthy causes!

Subscribe to Leading Agile Subscribe to Leading Agile

The Secret to Organizational Agility (Revisited)

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

Agilability: A New Blog About Agile at Scale

As someone who has not been blogging all that long... I remember vividly what it was like to have 10 subscribers. That said... if I know a promising new blogger... I like to help them out a bit by pointing my readers to their stuff.

A buddy of mine Lee Cunningham from Taleo just started a new blog called Agilability. Aside from having a really cool name, this blog will be another resource for those of us wrestling with scalability issues in the enterprise. Lee has been in the agile game for quite a while and lives this stuff on a day to day basis. I am looking forward to what he has to say.

Check out his first post at http://agilability.blogspot.com/

Subscribe to Leading Agile
(You'll have to visit Agilability to subscribe to Lee's blog ;-) Subscribe to Leading Agile

The Product Owner at Scale

Okay... everyone caught up now?

It was kind of neat to spend the time yesterday going back over all those old posts and interesting to see how the process of writing this out has shaped how I look at the whole Product Owner and scaling issue. The timing of the Scrum Gathering was good too. It was nice to get down to Orlando and talk to folks about how they are applying this stuff out in the field.

Last time around I said that the Product Owner at scale was really an issue of Product Ownership in the enterprise. How are we going to get all our teams working on the right things so we end up with a cohesive and integrated product? The key to having this conversation at an enterprise level is to have a thorough discussion around how we are going to handle the three key enterprise Scrum teams: the design scrum... the development scrum... and the QA scrum.

Product Ownership becomes a matter of deciding how to identify all the backlog items, at the beginning of the project, so we can effectively assign work and make sure the entire scope of the project is accounted for.

The role of the Product Owner... or the Product Owner Team is to break each backlog item into a design story... a development story.. and a test story. This is critical for normalizing the input to the team and making sure that each team has plenty of backlog items to work on... and most importantly... the right backlog items to work on... in the right predetermined order!

I mean... how can you write software before you have created the specification? At some point this becomes just common sense!

That said... because of the nature of Scrum at enterprise scale, some teams will inevitably have less to do at certain times in the project.

It was really cool to hear Ken Schwaber (during his keynote at the Gathering) finally discuss that to effectively scale Scrum, we need to put more definition around how to matrix people and teams across multiple projects. Ken's point was that multiple project assignments and matrixed management is the only way to normalize velocity in an enterprise Scrum implementation.

Next post we'll talk about the other mission critical teams that enable enterprise Scrum. We'll talk about the BUFD scrum team... the Governance scrum team... the PMO scrum team... and the centralized process improvement scrum team. We'll introduce some key tooling concepts like the Scrum Market Requirements Document and the Enterprise Scrum Gantt Chart.

Remember... if you do a daily stand-up and call requirements backlog items... you are probably doing Scrum! See you guys on the 2nd.

Subscribe to this blog Subscribe to Leading Agile

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://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

In case there was any confusion...

If you are not familiar with Mike Vizdos and his Scrum cartoon series, you have to head over and take a look. Someone forwarded me this picture apparently after reading my last blog entry. I thought I would include it here in case there was any confusion ;-)

You can see the cartoon in its orginal location at http://www.implementingscrum.com/images/070604-scrumtoon.jpg. You should plan to spend an hour or so if you decide to visit. The cartoons are addictive!

Subscribe to this blog Subscribe to Leading Agile