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.
2. Fast Food vs. Homemade Agile Uncovering Better Ways of Delivering Software Jeffrey Davidson / @JeffreyGoodReq #dsmAgile / Sept 9, 2016
3. We are uncovering better ways of developing software by doing it and helping others do it.
5. reimagining Agile Proposing An Updated Set of Processes and Practices to Achieve High-Performance Delivery
6. reimagining Agile Proposing A Updated Personalized Set of Processes and Practices to Achieve High-Performance Delivery
8. Potentially Shippable Product Increment Time- boxed Sprint Backlog Items 24 hours Daily Standup Prioritized Product Backlog
9. We uncovered the only better way of developing software. Do it our way. You’re welcome.
10. Wow! This guy makes a lot of sense.
11. Hmm. I wonder what Jeffrey’s Agile would look like?
12. Performance High Performance Technical Stack Business Domain Teamwork Beliefs: 3 Keys to High-Performance
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
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
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)
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.”
17. Feedback Loops • When the Impact is reached • When a User Story is done • When we think we can improve
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 _______
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
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?
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
22. Potentially Shippable Product Increment Time- boxed Sprint Backlog Tasks 24 hours Daily Standup Prioritized Product Backlog
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
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
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?
26. Beliefs about Delivery / Excellence Practices Understanding & Organization Feedback & Improvement
28. We are uncovering better ways of developing software by doing it and helping others do it.