slicing for organisational agility - a #noestimates method
Post on 09-Apr-2017
4.554 Views
Preview:
TRANSCRIPT
Neil Killick, Portfolio Manager
neilkillick.com neil2killick@gmail.com @neil_killick
Slicing for Organisational Agility
usingThe Slicing Heuristic
A #NoEstimates Method forFaster & More Predictable Delivery
Copyright Neil Killick, 2015
Not another story slicing talk!
FAST Shinkansen trains can reach speeds of up to 320km/h
PREDICTABLE 13 trains per hour between Tokyo & Osaka (train every 3-5 mins)
In 2014, avg delay was 54 seconds, including uncontrollable causes such as natural disasters
RELIABLE5 billion passengers, 150 million per year
How did they do it?
❏ Built dedicated lines for high speed rail, so not slowed down by slower trains
❏ No road crossings
❏ Specially designed tracks
You can’t just make a train faster or more reliable.
You must create a network for fast, reliable trains.
Agile is ordering tapas til you’re full, not ordering a 10-course meal.
Is Agile Estimation really helping us?
❏ Predictive❏ Optimised for speed❏ Points are abstract❏ Focused on cost❏ Developer-centric❏ False sense of security
So, What is a Slicing Heuristic?
❏ An explicit policy that describes how to "slice" work to help us achieve:❏ Faster time to market*❏ Better predictability**
❏ How?❏ Define work with a consistent & shared language❏ Replace deterministic estimation rituals with:
❏ Slicing rituals❏ Empirical measurement of actual cycle times for all work types
slicing…[creating] relatively thin, broad piece[s] cut from an object having some bulk or volume…
[ref: yourdictionary.com]
heuristic...any approach to problem solving, learning, or discovery that employs a practical methodology not guaranteed to be optimal or perfect, but sufficient for the immediate goals.
[ref: Wikipedia]
How To: 5-step cycle
1. Define & agree work types
2. Agree slicing policy for eachwork type
3. Slice work, Just-In-Time
4. Do work + measurecycle times
5. Inspect & adapt policies
Initiative
Capability
Feature
Story
BuildSlice
MeasureLearn
1. Define & agree work types - An example
❏ Initiative - Strategic theme, likely to last several months or longer
❏ Capability - Desired customer outcome, likely to last several iterations
❏ Feature - Proposed solution to deliver a capability, likely to last a few weeks
❏ Story - User capability needed to make a feature, likely to last a few days
2. Agree slicing policy for each work type
❏ Define when to stop slicing
❏ State desired cycle time & variation
❏ Make policies explicit & visible (HT Kanban Method)
Initiative
Capability
Feature
Story
❏ Max 3 Capabilities❏ Cycle time < 6 months❏ Std dev < 3 weeks
❏ Max 2 Features❏ Cycle time < 2 months❏ Std dev < 6 days
❏ Max 4 Stories❏ Cycle time < 2 weeks❏ Std dev < 3.5 days
❏ 1 Acceptance Test❏ Cycle time < 3 days❏ Std dev < 0.5 days
3. Slice workJust-In-Time
❏ 1 card for each work item coming into the system
❏ Conversations between appropriate people at appropriate cadence for each work type
❏ Remove/de-prioritise options
❏ Organise remaining options into appropriate work typese.g. push things back upstream
InitiativeCapability 1 Capability 2 Capability 3
Feature1
Feature 2
Feature1
Feature 2
Feature1
Feature 2
Story1
Story2
Story3
Story4
Story1
Story2
Story1
Story3
Story2
Story2
Story1
Story1
Story3
Story2
Story4
Story1
Story3
Story2
To Do Doing Done
= 1 elapsed day
Easy to add a dot at daily standup, or just update the data daily in a spreadsheet
Story 1 Story 2 Story 3 Story 4 Story 5
Elapsed days 2 3 1 1 2
Days
Stories
We need this data!
4. Do work + measure cycle times
5. Inspect & adapt policies
❏ How long is it taking to deliver work?
❏ Analyse statistical patterns for work types
❏ Do we have desired speed to market?
❏ Do we have desired level of predictability?
What might happen?
1. Work takes longer than desired (high cycle time)
2. Work is unpredictable overall (high variation)
3. Work is unpredictable within a work type
4. New work types emerge❏ e.g. MVP/MMF
5. Work type is retired❏ e.g. move to FDD, no more stories
High Cycle Time
We can try...❏ Creating clearer story definition &/or acceptance criteria (Definitions of Ready
& Done)❏ Better acceptance tests upstream to clarify all user scenarios, e.g. 3 Amigos❏ Slicing work more ruthlessly for simplicity and unambiguity❏ Reducing WIP at one or more levels
Leading to:❏ Simpler stories, more options & lower risk
❏ Shorter feedback loops for faster learning & delivery of customer value
❏ Reduced delays such as hand-offs, story defects, other queues & dependencies on people outside of the team
Variable Cycle Time
We can try...❏ Being more consistent in the way work is defined & broken down❏ Keeping WIP consistent❏ Minimising distractions
Leading to…❏ Managers can use empirical data for more predictable delivery
forecasting, rather than relying on crystal ball gazing by the team
❏ Reduced stress on the team
❏ Increased transparency & trust with stakeholders
Benefits
❏ Empirical❏ Optimised for
conversations❏ Time is a universal unit❏ Promotes collaboration
“up the chain”❏ Build the right
thing (right solution for right problem)
❏ Control risk (cost/schedule)
Initiative
Capability
Feature
Story
❏ Max 3 Capabilities❏ Cycle time < 6 months❏ Std dev < 3 weeks
❏ Max 2 Features❏ Cycle time < 2 months❏ Std dev < 6 days
❏ Max 4 Stories❏ Cycle time < 2 weeks❏ Std dev < 3.5 days
❏ 1 Acceptance Test❏ Cycle time < 3 days❏ Std dev < 0.5 days
*Faster time to market
❏ Slicing makes work simple & unambiguous - naturally leads to “small”
❏ Slicing reduces risk
❏ Slicing exposes options that we can throw away or delay
So, making slicing an explicit, measurable activity across our portfolio is likely to increase speed to market.
**Better predictability
❏ Work at all levels can be forecast using empirical data
❏ Makes portfolio views extremely useful
❏ Instantly know that e.g. a feature is 2-4 weeks
❏ Collaboration & quality of conversations are improved
So, making slicing an explicit, measurable activity across our portfolio is likely to increase predictability.
All we need is a continuous improvement mindset.
And a method.
BuildSlice
MeasureLearn
1. Define & agree work types2. Agree slicing policy for each work
type3. Slice work, Just-In-Time4. Do work + measure cycle times5. Inspect & adapt policies
DISCLAIMER
This will only work if you try it.
Neil Killick, Portfolio Manager
neilkillick.com neil2killick@gmail.com @neil_killick
Copyright Neil Killick, 2015
top related