Archive for October, 2014

SAFe Value Delivery & Capability Runways

October 26th, 2014 No comments

Some people are adamant that every Program & Team backlog item must deliver tangible user/customer value (INVEST). There is no room in the Program or Team backlogs for extraneous items that need to be performed as part of the supporting work. Training? Either reduce your velocity or add it as tasks to ‘Value’ stories.

The argument might go something like, “You can’t have ‘As a developer I need training in XYZ so I can deliver the ABC Feature.’” and “’As a Program we need a System Test Environment for the Release so we can perform System tests’ is not a story.”

“These are all tasks, so add a task to each story or just do them in your ‘buffer time’”, or “Everyone has to attend that training, so just reduce the Planned Velocity for the sprint by 8 points.”

While there are cases where these should be tasks, there is no prescribed approach other than “don’t add a story, don’t size it, it is not adding Value.”

In SAFe, we read that the Sprint Backlog contains ALL the things that need to be done, whether it be User Stories, Refactors, Defects, Research Spikes or other Technical Debt. Although it doesn’t specifically state anything about ‘foundational’ items such as building the test environment or generic training, should these be treated differently?

Clearly these Backlog Items do not directly produce user-centered functionality, yet they are there and do offer value (if not, then why do them?). Further, I think you can appreciate that these Items should have their own Conditions of Satisfaction and are not simply Tasks.

While this might seem like a style choice that, as long as it is consistently applied across all teams in the Release Train, isn’t a big deal, I think that it raises a broader question and exposes an opportunity regarding how we determine what we work on and how we define and measure Value.

So what do we mean by ‘Value’?

In a Value Stream, we are typically interested in all the activities related to understanding needs, building and deploying solutions that provide value to End Users, Customers or even Internal Business Processes. To this end, in SAFe, we discover Value Streams and manage backlogs of Features at the Program level, derived from Epics, that we believe will deliver value, and we manage Team Backlogs at the Team level that contain the Items that need to be done in order to deliver those Features.

The really nice thing about this is that the Program Backlog unambiguously carries the Value Items. The Features. As such, we can compare the values of Features, we can be clear as to which Epics they contribute and we can do fancy prioritization using WSJF. We can spend our money wisely. The Conditions of Satisfaction for a Feature drive the Teams’ Backlog Items. We can measure and discuss the done-ness of Features with the business. We can establish a Program Velocity based on Feature delivery. Effectively this is a measure of Value Velocity. Great!

What about a Team’s Velocity then? What good is that for?

Do I measure a team’s value contribution by only counting stories that delivered end user functionality? The Team’s Velocity is all about predictability. The team wants to know how much ‘effort budget’ it can spend in the sprint. The Team’s responsibility (includes the PO) is to establish the optimal set of Items that will deliver the highest Value for the Program. Remember, the whole Program is sprinting together.

By the way… if we disassociate Feature Points from Story Points, we overcome the need to normalize Story Points; each team can do whatever they want to establish their unique velocity; we just need predictability at the team level. The Program’s Capacity and Velocity can be expressed in Feature points. With Feature Points, we can avoid Features being sized using a 10x factor, and Epics equal to 4000 story points. (my work colleague Jim Schaeffler, SPC, has some interesting ideas on how to measure Feature Points)

Value & Runways:

When we look at SAFe, we notice that there are some special Features denoted in red; Architectural Features. These have been derived from a variety of sources: Architectural Epics that define Enterprise-Level Intentional Architecture, Program Vision and Roadmap intent that expose the need for Architectural Features, and specific emergent design challenges.

In SAFe we want our architectural implementation to be just enough and just in time. We want to avoid Big Up Front Design (BUFD). SAFe uses the term ‘Runway’ to connote the laying down of ‘consumable architecture’ just far enough ahead of the development of the Features that require it. I would rather it be a ‘Railway Track’, given that we have a Release Train… but no matter. The point is that while some of these ‘special features’ do provide direct end-user Value in terms of commercially-important capabilities such as Performance and Security, many provide a supporting or enabling role related to quality and integrity of the system, which are deemed to be of Value and worth spending team effort on.

You knew that already. So why bring it up?

When we need to improve our Architectural Capability, we lay down our Runway. I think SAFe might benefit from recognizing that there are other ‘Capability Runways’ that need to be in place before a Feature can be delivered: ‘Knowledge (know how) Runway’, ‘Technical Infrastructure Runway’, ‘Physical Environment Runway’, ‘Organizational Runway’.

The company could express Strategic Intent by inserting ‘Capability Epics’ into the portfolio. These can be budgeted (because they don’t come for free) and aligned and prioritized against the classical ‘Business Value’ Epics so that the company has the resources and necessary environments in place to support its goals. The Features would be prioritized into the Program Backlogs just like Architectural Features are.

So… when a team asks what to do about training that they have to take in order to understand a new aspect of their work, you can tell them to add a sized Backlog Item that is tied to a Feature for this PI, such as F5005-Automated Test Training. Such a Feature would have a clear value proposition and Conditions of Satisfaction; after all, we are spending precious team time on achieving the capability.

Perhaps, when they ask about setting up an Environment Story, you can point them to a Feature for the Infrastructure Capability Runway that they can link to.

I can imagine that Capability Runways would be very active in the early days of SAFe adoption, for example, eventually settling down to contain Capabilities that are required to deliver classical Value for a Value Stream or to accommodate a Corporate Initiative as part of continuous improvement.

What do you think about the concept of Capability Runways? Do you think it would be useful to be able to explicitly plan and understand the impact of building a capable workforce with suitable environments?