More Second Order Agile Scaling...

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

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