You are on page 1of 28

We are uncovering

better ways of
developing software
by doing it and
helping others do it.
Fast Food
vs.
Homemade Agile
Uncovering Better Ways
of Delivering Software

Jeffrey Davidson / @JeffreyGoodReq


#dsmAgile / Sept 9, 2016
We are uncovering
better ways of
developing software
by doing it and
helping others do it.
reimagining Agile

Proposing An Updated
Set of Processes and Practices to
Achieve High-Performance Delivery
reimagining Agile

Proposing A Updated Personalized


Set of Processes and Practices to
Achieve High-Performance Delivery
Daily
Standup
24 hours

Time-
boxed
Sprint
Backlog
Items

Prioritized
Product
Backlog
Potentially
Shippable
Product
Increment
We uncovered the
only better way of
developing software.
Do it our way.
You’re welcome.
Wow!
This guy makes
a lot of sense.
Hmm.
I wonder what
Jeffrey’s Agile
would look like?
Beliefs: 3 Keys to High-Performance
Technical
Stack

High
Performance
Performance

Business
Teamwork
Domain
Start How You Mean To Go: 4 Practices

Daily clean Automated


code testing

Search for Automated


improvement build process

These practices will slow us to


start,
And accelerate us forever more
Understanding is Everything: 3 Levels

• Results in terms of
Impact measurable change
• Not a scope item list

broken into

User • Customer viable


• Have Acceptance
Stories Criteria

completed via

• Testable / Provable
Daily Slices • May not be customer
viable

At the end of every day I


finished something that
makes a tangible difference.
Work Organization
Activity 1

Time
Role Task 1 Role Task 2 Role Task 3 Role Task 4 Role Task 5

Task Detail Task Detail Task Detail Task Detail Task Detail
(User Story) (User Story) (User Story) (User Story) (User Story)

Task Detail Task Detail


(User Story) (User Story)

User Stories are organized into a Story Map,


which serves as
ª Guide to Investment Experiments
ª Planning Runway

ª Roadmap
Ceremonies: Only When Required
for for for Finding
Understanding Validation Improvement

Impact X X
Story Map X X
User Story X X X
Daily Slice X X
Release X
Impact 10% Party

Recommended: Every time the team delivers measurable impact to


the customer or business process there shall be a “Gathering of Joy.”
Feedback Loops
• When the Impact is reached

• When a User Story is done

• When we think we can improve


Slices
• Planning your daily slice requires
everyone involved in that slice
and may not require the whole team.
• If it takes too long to plan your daily
slice, do it differently. For example:
– Try slicing differently
– Try planning your daily slices simultaneously
– Try less planning, more building
– Try _______
What, Not Who: team stuff
• Skills, not roles
– I expect to have the right technical expertise to
understand business needs, develop in our
technical stack, and validate our deliverables

• Cross-functional is better than silos


and sole-functional
– It’s a journey. You can grow into it over time.

• No defined team size


How Big Is It: determining project size

What about Estimation?

– After the team has agreed to the story map,


they may estimate user stories in terms of daily
slices
– Daily slices may be added up within the story
map to determine estimated project size,
release dates, or other metrics
– Anyone may request a re-estimation from the
entire team
How Big is TOO Big?
We don’t know (!!), but maybe when:
• Daily slices take more than 5 people
• User stories take more than 20 – 30
daily slices
• User stories take more than 3 weeks
• Releases take more than 3 months
Daily
Standup
24 hours

Time-
boxed
Sprint
Backlog
Tasks

Prioritized
Product
Backlog
Potentially
Shippable
Product
Increment
The Agile Landscape v3 Developed by Christopher Webb

Scaled Agile Framework (SAFe) Disciplined Agile Delivery (DAD)


Rightshifting Management 3.0

5C’s of 3 Levels Portfolio WSJF Agile Architectural Strategic ART SAFe Program 4 versions Fixed Software Hybrid Product Architecture Risk Value Coordinate Marshall 4 Mindsets Turn Delegation Kudos Meddlers Moving
10
Agile Portfolio, Backlog portfolio runway Theme Budget Patterns Planning of lifecycle Delivery Development waterfall Mgmt Team Driven cycle Activities Model up the Poker Cards (change Intrinsic Motivators
Mgmt Program, Focus
Program Date Context practices Team good card game) desires
Team Increment Framework
Communities (SDCF)
of Practice Beyond Budgeting
Organise Top down Feature Area Scrum Improvement Feature Overall Innovation &
by Product of Service Planning Parallel Goal Geographically
+ Bottom team Teams Retrospective Independent Diagram distributed
Sprint
customer
value
Up adoption Owner Scrums
Potentially Business EPIC
Scaling Testing development Leadership 7 Tests
of a new
Schneider
Culture
Theory X vs. Collaboration,
Theory Y Cultivation, and
map 3 levels coaching (org, team, tech) (GDD)
Shippable Product model Model Competence
Large Enterprise
Architectural
Scaled Scrum (LeSS) EPIC Lean Deming Theory of Constraints
Multi-team Vision Contract Cause Casual 5 Dysfunctions of team
design Page Game effect Loop Minimum
workshop diagrams Diagrams Viable Minimum A3 ADKAR Survey TOC Poisson Plant Types Team ImprovementExploratory 6
Actionable Sigma
Product Viable Change thinking Cumulative eNPS KATA Days
Cynefin Metrics
Project (MVP) FDD process Distribution
Inspections Kaizen
Charter
System NFR
5 S’s
Overview
Understanding Sense making
page Object SOLID UML Domain Buffer 5 Whys 8 Wastes Kaizen Kaizen PDCA
Design Thinking complexity (Data precedes Lean
Requirement Relational principles Diagram Object Mgmt burst blitz (Deming cycle)
(Framework framework) Coffee
Focal precedes data) Area Mapping Modelling Theory of
Question Constraints Kanban
Feature naming
Tiger Team template Muda,
Hypothesis Value stream Voice of Limit WIP Visual waste 3 bin Make Lead Cycle time
ShuHaRi Muri,
Idea Statement mapping Customer Product Development (FLOW) & waiting system Policies
Mura
time
Explicit
Design collaboration Flow Control DevOps
Brief session
Low Decision Product Personas Rules of Parking Story 3C’s Queuing Manage & Continuous
Fiedelity Affinity Tree Vision Simplicity Lot Mapping Theory Measure Kanban board Production Testing
Implement Evolve
Prototypes Clustering (elevator Flow
Divergent / pitch) feedback experimentally
Convergent Brainstorming Feature Set (combined, Feature loops
Story Definition of Ready
Thinking vertical, horizontal) Auto-scale & Heal
Hierarchy Daily Task
Perspective Context Relational Meeting Board
Mapping Mapping Mapping eXtreme Programming (XP) Agile 3 qns
Top 5 (ideas)
Modelling User Story
Refinement Optimal Feature Toggling
6 Levels of JIT Model Simple CRC Cards Sustainable Metaphor Spikes Team PBR Meeting Batch
Why-How Change Empathy Planning Storming Design Pace INVEST Story Fast Feedback Sizes
Canvas Product Splitting 12 Cardinal Sins
Laddering Maps Owner
Stakeholder
Mapping Ecosystem Scrum Release
Map Card sort Planning iterations Programming Feedback JIT Small
Rotation Onsite Loops Ad-Hoc Definition Dreyfus Usability
of Done Model releases
Design Customer Testing
retrospective Frequent Agile Release
Principles Hackathon Product Sprint Sprint releases
Storyboards Backlog Planning Backlog Test Driven Dev Trains (ART)
Human Centered Design Barmai
User (1&2) Shift
Testing index Test Acceptance Source Continuous Release
Five E’s Poker Relative Estimation Acceptance 7 qns of Context Left
estimates Testing Code Integration Train
2x2 Matrix Journey Time Planning Criteria context Driven
Guided Define Facilitated Doblin’s 10 Development Refactoring Mgmt Engineer
Maps box driven Testing Velocity
Tour Success workshops types of approach testing
Story Marick’s Test Driven Continuous
SPICE innovation definition
telling Test Development Deployment
Delivery Document Retrospective Burndown Release on
Chart Categories Test
Control Pack Revert Refactoring Prerequisites Sprint Demand
Business Business
Dynamic System Development Method (DSDM) Map Automation Automated
Review Monte
Model Niko-Niko Carlo Build
Vision (Showcase)
Canvas Calendar Automated visual
Business Risk Log Delivery Baselined MoSCoW Reflective Config
Feasibility Project Solution dashboard
Case Improvement Mgmt
Assessment approach Plan Requirements Architecture Independent 5 Mikado Version Artefact StandardisedIntegrated Dynamic
questionnaire Goal Naively Focusing Dependency Reflection Cumulative Control Mgmt Promotion Testing Environments
Steps Map Workshops Flow Path
Trade off Prince2 / 4+1 View Emerging Update when User Diagram Componentised
Sliders Mikado Method Architecture Branching
Waterfall architecture Design if hurts Case Strategy
(code Automated Test
craftsmanship) Code Coverage Virtualisation
RUP
Osmotic Incremental Focus Scale Walking Delphi Information Exploratory Incremental Team Safety CDEL
Communication Re-architecture Period method by Skeleton estimation Radiators 360 degree Architecture Safe (user method
(2hr) colour reviews space solution) selection Mock Objects
Crystal
Initiate Discover Deliver Release
2016 Deloitte Consulting Pty Ltd.
Technical
Stack
Impact

User Stories

High
Performance
Daily Slices

Business
Teamwork
Domain

Daily clean Automated Always Feedback


code testing

Search for Automated


improvement build process
How About You?
What ideas do you have?

• What are your core beliefs about


delivery / excellence?
• What are your must-have practices?
• How do you ensure understanding?
• How would you deliver value?
Beliefs about
Understanding
Delivery /
& Organization
Excellence

Feedback &
Practices
Improvement
We are uncovering
better ways of
developing software
by doing it and
helping others do it.

You might also like