Slides as presented at the 2020 Ágiles Latam Conference.
Abstract:
Barry O’Reilly exhorts today’s leaders to “break the cycle of behaviors that were effective in the past but are no longer relevant in the current business climate, and now limit or may even stand in the way of your success.” After more than two decades of writing, refining, grooming, estimating and documenting user stories, it’s time to unlearn them.
In a vast and sad irony, user stories have become the heavyweight documentation and process that they were meant to replace. This session proposes that we strip away the accrued behaviors and get back to the heart of agile and focus on delivering — and measuring progress by — working software.
Falcon's Invoice Discounting: Your Path to Prosperity
Stop writing stories, start validating working software
1. STOP WRITING STORIES, START
VALIDATING WORKING SOFTWARE
matthew.r.philip@accenture.com
@mattphilip
2. 1.LEARN MORE EFFECTIVE WAYS OF COLLABORATING
2.LEARN HOW TO CREATE A TEAM OF PRODUCT
MISSIONARIES INSTEAD OF MERCENARIES
3.LEARN HOW TO IDENTIFY PROBLEMS AND GOALS
AND INVITE TEAMMATES TO SOLVE THEM
4.UNLEARN BEHAVIORS THAT INHIBIT AGILITY
Goals for today
3. THE EPIC HISTORY
OF AGILE
CIRCA 2001
Dark Lord
of Waterfall
Agile Alliance of independent thinkers
4. BUT THE HEARTS OF MEN
ARE EASILY CORRUPTED…
The User Story
5. AND SOME THINGS THAT SHOULD NOT
HAVE BEEN FORGOTTEN WERE LOST.
HISTORY BECAME LEGEND.
LEGEND BECAME MYTH.
AND FOR 20 YEARS, THE SPIRIT OF
AGILE PASSED OUT OF ALL KNOWLEDGE.
8. SOMEBODY CAME UP TO ME AND SAID, ‘WE
WANT TO DO SOFTWARE DEVELOPMENT BUT
WE JUST CAN’T STAND ALL THIS
CEREMONY AND THIS AGILE STUFF. WE
JUST WANT TO WRITE SOME PROGRAMS.’
TEARS CAME INTO MY EYES… HOW CAN IT
BE THAT WE’RE RIGHT BACK WHERE WE
WERE TWENTY YEARS AGO?
— Kent Beck
12. THE MOST EFFICIENT AND EFFECTIVE
METHOD OF CONVEYING INFORMATION
TO AND WITHIN A DEVELOPMENT
TEAM IS FACE-TO-FACE
CONVERSATION.
Manifesto for Agile Software Development
19. • VELOCITY/POINTS
• STORY COUNT
• STORY CYCLE/DELIVERY TIME
• UTILIZATION
• ESTIMATED QUALITATIVE VALUE
• ESTIMATED QUANTITATIVE VALUE
• VALIDATED VALUE
HOW IS
YOUR TEAM
MEASURED?
22. 1 BUILDING THE WRONG THING OR THINGS PEOPLE DON'T NEEDBIGGEST
WASTE IN
SOFTWARE
DEVELOPMENT?
23. THERE IS NOTHING SO
USELESS AS DOING
EFFICIENTLY THAT WHICH
SHOULD NOT BE DONE AT
ALL.
— Peter Drucker
24. HOW MUCH HOW MUCH TIME, EFFORT AND
CONVERSATION DO YOU AND YOUR TEAM SPEND…
DEALING WITH USER
STORIES AND OUTPUTS
VALIDATING WHETHER
YOU’RE SOLVING BUSINESS
PROBLEMS AND REALIZING
OUTCOMES
?
25. STORY-BASED ANTI-PATTERNS
• This story isn’t
estimated.
• There’s no way
that’s a five.
• I think we need a
spike before we do
that.
• What am I going to
accomplish today?
Story #654 and
maybe start on
Story #679.
• I can’t estimate
that if I don’t know
the solution.
• Can you update
your cards,
please?
• Tell me what to
type in the
description.
• These acceptance
criteria are in the
wrong format.
• That’s a task, not a
story.
• Can you please
add the details?
• Can you make a
story for that
before I do it?
• Is this a bug or a
feature?
• This story won’t fit
in the sprint.
• I’m not sure we
can commit to
that.
• That wasn’t in the
story.
• The PO is out
today; you’ll have
to wait.
• Let’s schedule a
meeting to refine
those stories.
• We can’t work on
that until it’s been
refined.
• We can't interrupt
the sprint for that.
PROCESSES AND TOOLS COMPREHENSIVE
DOCUMENTATION
CONTRACT NEGOTIATION FOLLOWING A PLAN
27. BREAK THE CYCLE OF BEHAVIORS
THAT WERE EFFECTIVE IN THE PAST
BUT ARE NO LONGER RELEVANT IN
THE CURRENT BUSINESS CLIMATE,
AND NOW LIMIT OR MAY EVEN
STAND IN THE WAY OF YOUR
SUCCESS.
— Barry O’Reilly
29. 1.CLEAR PRODUCT VISION AND GOALS
2.ENABLING CONSTRAINTS AND EXPLICIT FREEDOMS
3.TRUST AND PSYCHOLOGICAL SAFETY
4.LOW LEVEL OF WORK IN PROGRESS
5.TIGHT FEEDBACK LOOPS
Rely less on user stories
31. PRODUCT PRINCIPLES/
PRODUCT MANIFESTO
• Build Something People Want
• Sell the innovation, not the product
• None of the work we are doing to
develop the product is an end in itself
• Think about who we want our customers
to become:
• Less frustrated by a lack of visibility
into what is going on with their team.
• Masters of their own information and
not slaves
• Relaxed, productive workers
32. PROBLEMS TO SOLVE
As a bank analyst
I want to see my reports in a grid view
So that I can view details quickly.
Reduce the analyst’s time to look up a
bank’s financial report.
USER STORY PROBLEM TO SOLVE
34. WE NEED TO GIVE
DEVS FREEDOM.
— Client Product Owner
35. AS A SOFTWARE TESTER, I MAY
WANT TO STOP USING USER
STORIES SO THAT I CAN CREATIVELY
EXPLORE THE SYSTEM TO LEARN
HOW IT ACTUALLY WORKS AND TO
INVESTIGATE UNDER WHICH
CIRCUMSTANCES IT MIGHT FAIL.
— ILEANA BELFIORE
36. EXPLICIT FREEDOMS AND
ENABLING CONSTRAINTS
Freedoms:
• Collaborate with anyone in the organization
• Commit whenever you want
• Use any framework
Constraints:
• Use a technology that we already support
• Spend up to $5000
• Make sure someone else works with you
51. TRUE BUSINESS VALUE CAN BE
DETERMINED ONLY AFTER DELIVERY
TO THE CUSTOMER. CHOICES ABOUT
WHAT TO WORK ON AND WHEN, THEN,
ARE REALLY JUST YOU PLACING BETS
ON WHAT YOU THINK THE CUSTOMER
WILL FIND VALUABLE.
— Dan Vacanti
52. GOAL: GET IT TO
THE END USER AS
SOON AS POSSIBLE.
— Client Product Owner
53. FOR 6 MONTHS, I HAVE EXPERIMENTED
IMPLEMENTING WITHOUT USER STORIES
FOR SMALL INCREMENTS, JUST BEGIN
BY THE PROBLEM TO BE SOLVED,
PROPOSE, SHOW WORKING SOFTWARE,
COLLECT KEY USERS' FEEDBACKS AND
ADJUST. AND IT'S WORKED VERY WELL
IN MY CONTEXT.
— Agnès Vugier
54. 1.FEWER MEETINGS
2.MORE EMPOWERED AND ENGAGED TEAMS
3.BETTER SOLUTIONS
4.FOCUS ON THE RIGHT THING: VALUE
5.MORE SATISFIED CUSTOMERS
Takeaways
LESS RELIANCE ON STORIES =