Upload
neil-killick
View
1.945
Download
0
Embed Size (px)
DESCRIPTION
My talk at Agile Singapore and Agile Scandinavia.
Citation preview
Neil Killick, Agile Coach / Trainerneilkillick.com / iterative.com.au neil_killick
Copyright Neil Killick, Iterative, 2013
the #NoEstimates debate
Alternatives to Agile
Estimation and...
WHAT IS
Like “Agile”, it has come to have many definitions and interpretations.
What is #NoEstimates?
A conversation, started on Twitter, about ways in which software can be delivered with no estimates.
Birth of #NoEstimates
A collection of opinions and practical advice from practitioners who deliver software with no estimates.
What drove the debate?
A diverse and much needed debate about when it is appropriate to use estimates in software, and what form these should take.
It’s now become...
Neil Killick Chris Chapman Henri Karhatsu
Woody Zuill Vasco Duarte
The #NoEstimates Crew
WHAT ISEMBRACE AGILE PRINCIPLESFOCUS ON VALUEDELIVER SMALL SLICESDELIVER EARLY & FREQUENTLYCUSTOMER COLLABORATION
Common Ground
thicsmpiricismmergence
3 E’s of #NoEstimates
ETHICS - Cycle of Mistrust
Trust breaks down
Deliver the wrong thing, or late
Focus on schedule
Commitments of scope and time
EMPIRICISM - Working software allows us to monitor progress and manage risk in a new way.
EMERGENCEof cost and value aswe get feedback from users and market.
Which is more predictable --A team that estimates or one that doesn’t ?
Predictability
● DETERMINISTIC AND REACTIVE● FOCUS ON SCHEDULE / PLAN● SCOPE DRIVES DECISIONS● LOTS OF WIP IN ATTEMPT TO “GET IT ALL
DONE”● NO METRICS, OR INAPPROPRIATE ONES
Team #Estimates
High variability12 days
1 Day
● PROBABILISTIC AND PROACTIVE● FOCUS ON TIME AND CASH CONSTRAINTS● ITERATE DESIGN AND DECISIONS● DELIVER WITH FLOW / LIMIT WIP● ACTIONABLE METRICS (e.g. STORY CYCLE
TIME DISTRIBUTION) USING A “SLICING HEURISTIC”
Team #NoEstimates
Better Predictability
3 days
1 Day
● EXPLICIT POLICY FOR BREAKING DOWN WORK AND MEASURING HOW LONG IT TOOK (CYCLE TIME)
● STARTS AS A SHARED DEFINITION OF WORK TYPES (e.g. THEME, FEATURE, STORY, etc.)
● SLICE ALL UPCOMING WORK SIMPLY AND SYSTEMATICALLY FOR “SMALL-NESS”
What’s a“Slicing HeuristicTM”?
● Given Bob is a registered user,
When Bob logs in
Then he should be logged in.
● Given Bob is logged in,
When Bob chooses Profile
Then he should see his profile.
Example -Max 1 User Scenario
Slice into2 separate stories
Slice those stories further
● Agility relies on small chunks, so useful to have a consistent and explicit way of creating them
● Improve ready-ness and done-ness
● Focus on delivering more frequent slices of value
● No need to explicitly estimate or re-estimate
Why use aSlicing Heuristic?
● Story points are ambiguous, time isn’t
● Explicit policy, so can be inspected and adapted to narrow control limits
● Outliers can be addressed at standup or retro
Why use aSlicing Heuristic?
● Exposes goals from solutions and vice versa● Slices not necessarily “smaller” than thing we
sliced, but multiply our options
Slicing creates options
● KEEP TEAMS TOGETHER● ENABLE CONTINUOUS DELIVERY● NO LONG PROJECTS / PROJECT THINKING● DRIP FUND (MULTIPLE OPTIONS)● BUILD THINGS ON DEMAND, DELIVER AS
SOON AS THEY ARE READY● FLEXIBLE CONTRACTS
Portfolio #NoEstimates
Present a business case
Approved as viable option
Team assignedTimeboxed experiment
Is initiative still valuable
enough?
NO
Initiative prioritised
YES
+ Team(s) if required
Frequent delivery
& feedback loop
Stop
Choosing what to do
Scaling up and down
Questions
What is and isn’t estimating, given people form and act on expectations of an uncertain future every day?
Question 1
● Estimating = Giving ranges of actual or relative time based on past observation, WIP, team size, etc.
● Guessing = New teams, with competing priorities, asked to give single dates in unfamiliar domains
● There is nothing intrinsically wrong with estimating, so long as we:○ Understand its limitations○ Use it only in appropriate situations○ Don’t rely on it for big up front decision making○ Update our estimates (and everyone’s expectations)
based on real data frequently
Answer 1
Why would we choose not to judge likely outcomes if worthwhile human endeavours necessarily carry risk?
Question 2
● #NoEstimates is about alternatives to estimating the cost of delivering software, not the value it generates
● We must hypothesise (estimate) the value of things in order to decide if we will pursue them
● My argument is that rather than estimate cost we can control (fix) it in “drips” using fixed Agile teams
● Delivery of working software allows us to reassess value iteratively based on the reality of user / stakeholder feedback and market conditions
Answer 2
If we elect not to take on the risk of predicting an uncertain future, who do we think should, and why?
Question 3
● We should embrace the delicious uncertainty of software, be excellent in what we do and aim to delight rather than “meet requirements”
● Software products and services have ongoing value, so the final cost and value can never be known up front
● We can’t fix price and scope, but we can work collaboratively and continuously with our customers to build the best possible result for budget or time constraint
● We can provide flexible pricing and termination options to our customers based on similar past work
Answer 3
Off the shelf library software costs $50k.We could try building our own at $2,500/day but might fail.What should we do?
Question 4
● Answer depends on many things like whether we have an established team, are we capable of delivering features every few days, etc.
● Need to establish the problem rather than decide between solutions; Do we need the software at all?
● What are the consequences of spending more than the OTS product costs? Is the $50k a constraint?
● How would ongoing maintenance costs compare?
Answer 4
● 4 weeks not far into the future, so probably have an instant sense of “Is it possible?” and“Can we build something better?”
○ Do we know enough about the domain?○ What are minimum features we need?○ How many people do we have? ○ Do we have any other WIP?
Answer 4 (contd)
Neil Killick, Agile Coach / Trainerneilkillick.com / iterative.com.au neil_killick
Copyright Neil Killick, Iterative, 2013