Saturday, March 29, 2014

SAFe Release Planning Tip 5 - Know your capacity constraints

One of the magical side-effects of building stable teams is the fashion in which it simplifies capacity planning.  No longer is it a question of project managers wrestling with "resource-levelling" in MS Project to ensure maximum utilisation.  Instead of the "resource" being our fundamental unit of capacity, the team replaces it.

SAFe takes this to the next level by composing a group of teams into a release train - allowing us to move beyond team capacity to train capacity.  Traditionally, this view of rolled-up capacity is impossible since team capacity is measured in story points and different teams use local definitions of a point.  Albeit contentiously, SAFe resolves this by suggesting the adoption of normalised story points - allowing us to roadmap based on a "Points per PSI" capacity for the train.

The selection of feature mix to take into a PSI utilises the following elements:

  • Train capacity (how many/how big)
  • Capacity allocation (proportions for different feature types)
  • WSJF (prioritisation of features within each class of capacity)

To illustrate using the "GeekBooks" online bookstore metaphor from the Leading SAFe simulation, picture the following:

We are employing three classes of capacity with allocation based on our opening business strategy:

  • B2C (Purchasers of books) (50%)
  • B2B (Suppliers of books) (25%)
  • Architecture (25%)

Following relative sizing and WSJF assessment of the features in the Program Backlog, we might have the following:



Assuming a train capacity of 500 points for the PSI, the following would be selected for PSI planning:

  • B2C (Flexible Search, Book Browsing, Shopping Card) (240 points)
  • B2B (List New Title, Alter Pricing) (120 points)
  • Architecture (Active-Active, Internationalisation (120 points)

But there's a catch.  This wonderfully clean formula only works if the train contains nothing but Feature teams and any team can pull any feature.  In a world with multiple flavours of feature team you now have capacity constraints based on feature flavour.  If you further complicate it by having component teams, you must also factor in component capacity constraints.

Imagine that the release train has the following makeup:

  • 2 x B2C Teams (capacity 100 points each)
  • A B2B Team (capacity 100 points)
  • A middleware component team (capacity 50 points)
  • A "Back-end" component team (capacity 150 points) 

Whilst the initial strategy assumed 3 classes of capacity driven purely by economic strategy, in reality we have 4 flavours of capacity constraints.  We can still "roll the dice", enter PSI planning and wait for the management problem solving session to apply tradeoffs between economic priorities and real constraints.  I've been there, and the power of the event is that it helps you navigate exactly this situation.

But ... we can also smooth our life out with a little more up front feature refinement.   If we know we actually have 4 types of capacity constraint, why not take our feature-level estimation down one layer of granularity.  Applied to the first example, we might see the following:



We now know our previous feature set requires the following:

  • 150 points of B2C capacity (under by 50)
  • 90 points of B2B capacity (under by 10)
  • 70 points of middleware capacity (over by 20)
  • 190 points of back-end capacity  (over by 40)

At this point, there are various ways to respond.  Deferring the active-active feature is obvious.  Finding a small "client-side only" feature would make sense to take advantage of our spare B2C capacity.   In reality, the management problem solving session at the end of Day 1 deals with a scenario this simple easily.  However, we still have no idea what other problems will be exposed during the draft plan preparation process.   Additionally, teams will have wasted breakout time that could easily have been avoided.

Conclusion Part 1

When preparing for Release planning recognise your underlying capacity constraints.  Whilst avoiding the temptation to go too far with up-front estimation, find a middle ground such as illustrated above.  It should well and truly be above the level of "individual specialists", but deeper than "train story points".  Further, recognise that in the presence of numerous component teams normalised story points are of limited value.  They're a very useful tool (and worth the danger) when you have fungible feature teams, but almost irrelevant with a heavy component team mix.  Your real need is "rolled up capacity by class of constraint".

Conclusion Part 2

Whether you have composed your people into feature teams or component teams you will almost certainly have these constraints for your first PSI.  You are most likely starting with a group of specialists who have not yet begun to generalise.  The key difference is this.  As long as you have component teams, you will live with the constraint as your specialists will remain specialists.  If you make the effort to move to feature teams, they will gradually erode the constraints as they take shared ownership and learn from each other.

Sunday, March 23, 2014

SAFe Release Planning Tip 4 - Consider "Feature Breakouts" as well as "Team Breakouts" if you have component teams

SAFe proposes a number of team flavours.  All are cross-functional insofar as they are able to "Define, Build and Test a thing of interest".  The suggested "things of interest" are:

  • Features
  • Products
  • Components
  • Subsystems
  • Interfaces

Realistically, the flavours can be further condensed into either  "Feature" or "Component".  A "Feature team" can fully deliver a "Business Feature", whereas a component team can typically only deliver "technical components of a Business Feature".  On the other hand, component teams can quite often fully deliver "Architectural Features".

Countless books, articles and speeches have been devoted to the benefits of Feature teams, but the reality is many if not most trains will launch without them.  Most will contain a mix of "psuedo-Feature teams" which can nearly deliver a business feature and supporting component teams.  Typically, 3 factors contribute to the presence of component teams:

  1. Insufficient people with a given specialisation to provide one for each team
  2. Technical and environmental constraints 
  3. Lack of conviction of the benefit to aligning at the team level around valued outcomes rather than technical proficiency

The net result is that the vast bulk of features will require contribution from more than one team.  Typically, the "pseudo-Feature" teams will take ownership of business features and look for contributions from the component teams.  The component teams, on the other hand, will often take ownership of architectural features and expect to provide contributions to the business features.

In the context of SAFe release planning, this can all too easily create the following scenario when the Team breakouts start on the afternoon of day 1:

  • From 1:00-3:00 the "psuedo-Feature" teams work with their product owners and managers to understand the business features they are tackling and break them down into stories.  As they work, they identify needs they'll have from the component teams and assumptions as to what form they'll take and they place these in a pile ready to hand over.  They may visit the component teams during this time, but are likely to be given short shrift as the component teams are deep inside "their own features".
  • From 1:00-3:00 the "Component" teams work with the architects on the architecture features in the program backlog and break them down into stories.
  • From 3:00-4:00 the feature teams land on the component teams with a pile of stories they need estimated and scheduled.  The component teams, with little understanding of the context, look at the stories and say "they're wrong, we're going to need to rewrite them" .. while the feature teams say "but we need you to estimate and schedule them so we can lock in our plan".
  • At 4:00, the draft plan review exposes a litany of unvalidated assumptions and bottlenecks around interactions between the feature teams and the component teams.
  • On Day 2, the feature teams and the component teams work together to translate the feature team needs into technical stories for the component teams to deliver .. with the product managers and owners relying on the feature teams to represent their needs as they've "already conveyed the business context and don't understand the geek-speak".

What I suggest is to both leverage flow-based planning as described in Tip #3 and different types of breakouts.  As part of your program backlog preparation, identify the features which are heavily interdependent across teams.  When choosing the priority order for planning, consider planning these features first.  Inevitably, you will wind up with a plan where the scheduling of these features dominates and the more contained features are scheduled opportunistically into the gaps left.

When breakouts commence, rather than going directly to team breakouts go to feature breakouts.   Your "pseudo-feature" teams pull features, and collect representatives from each component team to join them for the initial breakout.  The focus of the feature breakout is then:

  • Establish shared understanding of the feature
  • Elaborate any further feature acceptance criteria as necessary
  • Break the feature down into team-based stories with high-level acceptance criteria
  • Identify key dependencies between stories that cross team boundaries.

Once the heavily interdependent features have each been through their feature breakout, return to team breakouts - with team members taking their stories with them.  Once back in the team breakouts:

  • For each feature from a feature breakout:
    • Members share the stories created during the feature breakout with the rest of the team, obtaining further clarifications as necessary
    • Estimate as a team
    • Load stories into sprints in-line with inter-team dependencies
    • Close the feature out on the program board
  • Progress through feature breakdown and planning for remaining features team owns. (Those with little or no dependencies on other teams).

Personally, my experience with trains containing a mix of feature and component teams has been that you wind up with features which are "rocks" and "pebbles".  Those features which span multiple teams for delivery tend to be the rocks that dominate your PSI plan.  Once you have these, you find the more contained "single team features" become the pebbles that are slipped through the gaps in your PSI left after the rocks.  Making sure you bring a mix of "rock and pebble features" into the PSI priority list is the first enabler, and adjusting your breakout structure can become a huge time saver both within PSI planning and execution.

What's next?