How to Own a Really Big Complex Product #agile2010
Last Updated on Thursday, 15 November 2012 12:38 Written by Mike Cottmeyer Thursday, 12 August 2010 10:42
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!
ProductCamp Atlanta
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Tuesday, 19 May 2009 01:00
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!
Learn More
More Second Order Agile Scaling…
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Thursday, 30 April 2009 07:27
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.
Learn MoreSecond Order Agile Scaling
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Wednesday, 22 April 2009 11:42
First Order Agile Scaling
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Friday, 17 April 2009 06:56
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.
Learn More