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.