My last blog was focused on what I learnt about the Scaled Agile Framework (SAFe). The theme quote for that blog was:
“If you’ve lost the ability to do small things then you’ve not scaled, you’ve just gotten big and slow!!!”
So what are the small things we should do well at the team level or at scale? Breaking the work up, avoiding big batches, and letting the work flow was one of the recommendations.
This blog will focus on the integration of techniques to deliver goal-orientated scope (that breaks up the work) and take a look at how you might start to visualise and manage the flow at the portfolio level.
Delivering Goal-Orientated Scope
I am using an infographic as the tool to illustrate the integration of scoping techniques such as Impact Mapping and Story Mapping promoted by Gojko Adzic and Jeff Patton (respectively). The illustration is not an introduction to those topics (use the links to find out more) but instead a guide to the integration of these techniques, represented on a single sheet, with some key supporting messages.
My first experiment is to ask you to click on the infographic and digest it on its own without additional narrative.
Walking the Infographic
Now for some additional narrative on the illustration:
Scope Initiatives and Goals
We start in the top left hand corner with an example of the types of initiatives that typically instigate the delivery of new scope. Each of these initiatives should translate to goal(s) that need to be achieved so they converge into a set of Goal definition(s) in a common format.
Portfolio Backlog (Goals)
Each goal defines a problem to be solved, who it targets, and how success will be measured. This list of goals form the portfolio backlog; it is a prioritised ordered list. The method and cadence for prioritisation is not defined, but it would require the engagement of senior stakeholders and prioritisation policies would need to be explicit and transparent. Translating all initiatives into goals starts to break up larger batches (e.g. projects), these goals can then be prioritised amongst the other goals to be achieved. This helps to ensure we are working on the smallest most valuable thing, and avoid commiting capacity to long running projects, where some of the scope can often be of lesser value.
The next highest prioritised goal is analysed using an Impact Map. This looks at the impacts to behaviour needed to help achieve the goal, along with the deliverables that will support those changes. Each level in the map can be prioritised independently to help focus in on the deliverables that might have the biggest impact.
The impact map helps define the problem to be solved, connecting deliverables to behaviour impacts to goals to be achieved. Assumptions that have been made are visualised through the map. Can any of these assumptions be validated ahead of further work? This is an opportunity for “problem interviews” with a wider set of customers to confirm the problem and validate some of these assumptions.
Metrics have been defined at the goal level; it may be appropriate to break down these measures to individual deliverables that contribute to the goal. A separate table showing how the success for each deliverable will be measured may be required.
As we further analyse the scope to be delivered, we uncover whose life will be touched by the changes to be made. Stakeholder analysis involves continually understanding, cataloging, classifying, prioritising, engaging and empathising with the people that matter.
Program Backlog (Deliverables)
The selected deliverables form the program backlog; it is a prioritised ordered list. Not all deliverables from an impact map may get selected to enter the program backlog.
Scoping and Story Mapping
The next highest prioritised deliverable(s) are analysed through scoping workshops where customer segments are narrowed and personas created. Story Maps are created for each deliverable. Working backwards from outcomes the desired user activities are visualised and supporting system epics created (user story format). Using the visual prioritisation on the story map lines are drawn to indicate Minimum Viable Products (MVPs) outlining the smallest possible thing that could be built and released. MVP’s may cut across more than one deliverable (e.g. across Story Maps).
The story map, along with other supporting artefacts (e.g. UX wireframes, workflows etc.) start to form solutions to the problem being solved. Assumptions will have been made, so this is a opportunity for “solution interviews” with a wider set of customers to seek validation ahead of building the next MVP.
Release Backlog (MVPs)
The identified MVPs form the release backlog; it is a prioritised ordered list. Not all MVPs from the story map may get selected to enter the release backlog. The backlog will be hierarchical in nature, items high in the backlog will be more granular (e.g. story level) and those lower in the backlog more coarse grained (e.g. epic level).
Architectural spikes may be included in the backlog for risks already identified and prioritised accordingly. Non-Functional Requirements (NFRs) may manifest themselves as individual backlog items or as constraints applying to all backlog items.
MVPs prioritised for delivery
When a delivery team becomes available for delivery (capacity is created) they would pull the next prioritised MVP from the release backlog creating their next team backlog for delivery.
Foundation activities focused on reducing risk will be undertaken before development iterations get underway. Mature long-lived teams with established practices will have some of the identified activities already in play.
Development Iterations, Release and Validate Learning
Start to build MVP increments within your adopted “build-measure-learn” implementation. The infographic does have an emphasis on specification by example as part of defining scope (NB. there are further practices after “refine the specification” not represented in the illustration).
The MVP released does not have to be a “big bang” approach; it can be controlled (feature toggling) and targeted to particular customer segments, or time periods, to capture specific measurements and compare alternatives (e.g. A/B testing).
Validated learning is key; comparing actual metrics to expected outcomes can provide new knowledge and truly validate assumptions. With this new learning what adaptions are required? Do goals need to change? Are amendments to existing impact maps, deliverables and/or story maps required? What’s your next MVP?
How would you visualise and manage this flow at the Portfolio level?
Here is an example Kanban view of how you might start to visualise and manage this flow (click on it to see it in more detail).
In the example all cards that relate to the same goal are in the same colour and some columns have a Work In Progress (WIP) limit set.
Teams will still operate their own team level story walls for the MVP they are working on.