Fast Food Agile

Are you hungry? Eat this pre-processed, fast food hamburger!
Still hungry? Add a large order of French Fries!

New to iterative software? Use Scrum!
Tired of Scrum? Use Kanban!
Got lots of teams? Use SAFe!

We know a healthy diet values natural foods over the simplicity and ease of fast food. Similarly, many agile techniques are much more valuable than the simple, fast food version of software development everyone is teaching.

Over the last 15 years we started relying on other people's best practices instead of developing better ways of delivering software. We are using solutions developed for a different team, in a different decade, in a different company, in a different industry. There is such a rich tapestry of ways to build software and we are stuck eating software's version of fast food.

This interactive session discusses a bunch of different Agile techniques and when they are useful. Then we will look at just how different agile might be if we picked only the most appropriate items. Lastly, you will work with a few peers to determine if you need to swap a few techniques, or even build a personalized version of Agile, specially designed to help with your situation.

Transcript

1. We are uncovering
   better ways of
   developing software
   by doing it and
   helping others do it.
   

   View Slide

2. Fast Food
   vs.
   Homemade Agile
   Uncovering Better Ways
   of Delivering Software
   Jeffrey Davidson / @JeffreyGoodReq
   #dsmAgile / Sept 9, 2016
   

   View Slide

3. We are uncovering
   better ways of
   developing software
   by doing it and
   helping others do it.
   

   View Slide

4. View Slide

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

   View Slide

6. reimagining Agile
   Proposing A Updated Personalized
   Set of Processes and Practices to
   Achieve High-Performance Delivery
   

   View Slide

7. View Slide

8. Potentially
   Shippable
   Product
   Increment
   Time-
   boxed
   Sprint
   Backlog
   Items
   24 hours
   Daily
   Standup
   Prioritized
   Product
   Backlog
   

   View Slide

9. We uncovered the
   only better way of
   developing software.
   Do it our way.
   You’re welcome.
   

   View Slide

10. Wow!
    This guy makes
    a lot of sense.
    

    View Slide

11. Hmm.
    I wonder what
    Jeffrey’s Agile
    would look like?
    

    View Slide

12. Performance
    High
    Performance
    Technical
    Stack
    Business
    Domain
    Teamwork
    Beliefs: 3 Keys to High-Performance
    

    View Slide

13. Automated
    testing
    Automated
    build process
    Search for
    improvement
    Daily clean
    code
    Start How You Mean To Go: 4 Practices
    These practices will slow us to
    start,
    And accelerate us forever more
    

    View Slide

14. Understanding is Everything: 3 Levels
    Impact
    User
    Stories
    Daily Slices
    • Results in terms of
    measurable change
    • Not a scope item list
    • Customer viable
    • Have Acceptance
    Criteria
    • Testable / Provable
    • May not be customer
    viable
    At the end of every day I
    finished something that
    makes a tangible difference.
    broken into
    completed via
    

    View Slide

15. Time
    Work Organization
    User Stories are organized into a Story Map,
    which serves as
    ª
    Guide to Investment Experiments
    ª
    Planning Runway
    ª
    Roadmap
    Activity 1
    Role Task 1 Role Task 2 Role Task 3 Role Task 4 Role Task 5
    Task Detail
    (User Story)
    Task Detail
    (User Story)
    Task Detail
    (User Story)
    Task Detail
    (User Story)
    Task Detail
    (User Story)
    Task Detail
    (User Story)
    Task Detail
    (User Story)
    

    View Slide

16. Ceremonies: Only When Required
    for
    Understanding
    for
    Validation
    for Finding
    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.”
    

    View Slide

17. Feedback Loops
    • When the Impact is reached
    • When a User Story is done
    • When we think we can improve
    

    View Slide

18. 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 _______
    

    View Slide

19. 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
    

    View Slide

20. How Big Is It: determining project size
    – 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
    What about Estimation?
    

    View Slide

21. 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
    

    View Slide

22. Potentially
    Shippable
    Product
    Increment
    Time-
    boxed
    Sprint
    Backlog
    Tasks
    24 hours
    Daily
    Standup
    Prioritized
    Product
    Backlog
    

    View Slide

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

    View Slide

24. High
    Performance
    Technical
    Stack
    Teamwork
    Business
    Domain
    Impact
    User Stories
    Daily Slices
    Automated
    testing
    Automated
    build process
    Search for
    improvement
    Daily clean
    code
    Always Feedback
    

    View Slide

25. 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?
    

    View Slide

26. Beliefs about
    Delivery /
    Excellence
    Practices
    Understanding
    & Organization
    Feedback &
    Improvement
    

    View Slide

27. View Slide

28. We are uncovering
    better ways of
    developing software
    by doing it and
    helping others do it.
    

    View Slide