Tweet
Tweet

Slide 1

Slide 1 text

© KAKEHASHI Inc. Our Scrum without Estimates, and into the Trunk-based Development 2024-07-11 @ DevOpsDays Taipei 2024 SHIIBA Mitz

Slide 2

Slide 2 text

© KAKEHASHI Inc. SHIIBA Mitz ௣༿ ޫߦ ● Osaka, Japan ● TypeScript, Java, CI/CD, Scrum, DevOps ● Software Engineer at KAKEHASHI Speaker at ● DevOpsDays Tokyo 2024 ● Regional Scrum Gathering Tokyo 2024 ● Scrum Fest Osaka 2021 (Keynote) 𝕏 @bufferings

Slide 3

Slide 3 text

© KAKEHASHI Inc. Overview

Slide 4

Slide 4 text

© KAKEHASHI Inc. KAKEHASHI “Inventing a sustainable medical ecosystem” ● A healthcare tech startup in Japan (2016~) ● Multiple products for pharmacies ● 350+ employees (as of 2023-12) ● Agile/Scrum

Slide 5

Slide 5 text

© KAKEHASHI Inc. My Favorite Story Our PM (Product Manager) visited a customer pharmacy and brought back their feedback. We deployed the new version to production the very same day. The customer was surprised and delighted. Photo by Elisabeth Arnold on Unsplash

Slide 6

Slide 6 text

Part 1: Scrum without Estimates

Slide 7

Slide 7 text

Our choice: No Estimates

Slide 8

Slide 8 text

Our choice: No Estimates 😲

Slide 9

Slide 9 text

Our starting point: We trust everyone 
 to do their best 
 for the Product Goal.

Slide 10

Slide 10 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Scrum

Slide 11

Slide 11 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Scrum

Slide 12

Slide 12 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Scrum

Slide 13

Slide 13 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Scrum

Slide 14

Slide 14 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Scrum It isn’t much different!

Slide 15

Slide 15 text

Why No Estimates?

Slide 16

Slide 16 text

Why No Estimates? Estimates don’t add value for us. They often make things worse.

Slide 17

Slide 17 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Product A web service for patients and pharmacists.

Slide 18

Slide 18 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Product A web service for patients and pharmacists. ● Uncertainties in requirements: ● Built on several hypotheses.

Slide 19

Slide 19 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Product A web service for patients and pharmacists. ● Uncertainties in requirements: ● Built on several hypotheses. ● Technological uncertainties: ● Adoption of new and unfamiliar technologies.

Slide 20

Slide 20 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Product A web service for patients and pharmacists. ● Uncertainties in requirements: ● Built on several hypotheses. ● Technological uncertainties: ● Adoption of new and unfamiliar technologies. ● Unknown unknowns: ● Things we weren't even aware of.

Slide 21

Slide 21 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Software Development Image from https://thecynefin.co/about-us/about-cynefin-framework/ (Accessed on 2024-07-01)

Slide 22

Slide 22 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Software Development In the Complex domain, we don’t know the right answer until we act. Image from https://thecynefin.co/about-us/about-cynefin-framework/ (Accessed on 2024-07-01)

Slide 23

Slide 23 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Estimates are Guesswork Instead, focus on progress and transforming unknowns into knowns. This approach drives us towards the Product Goal.

Slide 24

Slide 24 text

© KAKEHASHI Inc. Photo by Tara Glaser on Unsplash

Slide 25

Slide 25 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Our Dedication Remains the Same with or without estimates.

Slide 26

Slide 26 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Estimates obscure the Product Goal. We tend to look at the gaps between estimates and actual progress.

Slide 27

Slide 27 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Why No Estimates? ● Estimates are just guesswork in the Complex domain. ● Our dedication remains the same with our without estimates. ● Estimates obscure the Product Goal.

Slide 28

Slide 28 text

No Estimates Enables us to focus on the Product Goal, Ensuring that we deliver maximum value to our users.

Slide 29

Slide 29 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Alternative to Estimates Instead of estimates, we perform two specific activities.

Slide 30

Slide 30 text

© KAKEHASHI Inc. Part 1: Scrum without Estimates Alternative 1: Small Items We use small items. ● Keep the Backlog items as small as possible. ● Finish each item in one or two days. ● Pick up five to ten items for one Sprint. This enables us to start Sprint without estimates.

Slide 31

Slide 31 text

You might be wondering… 
 “How can you plan?”

Slide 32

Slide 32 text

Part 2: Alternative 2: Slice Map

Slide 33

Slide 33 text

© KAKEHASHI Inc. Part 2: Slice Map Had These Thoughts with Product Backlog? As a user, I can search items by the name in the search page. As a user, I can search items by the price in the search page. As a user, I can check item details in the item page. As a user, I can add items to a cart in the item page. As a user, I can check items in the cart in the cart page. … As a user, I can search items by the category in the search page An example backlog for an EC service

Slide 34

Slide 34 text

© KAKEHASHI Inc. As a user, I can search items by the name in the search page. As a user, I can search items by the price in the search page. As a user, I can check item details in the item page. As a user, I can add items to a cart in the item page. As a user, I can check items in the cart in the cart page. … As a user, I can search items by the category in the search page Part 2: Slice Map Had These Thoughts with Product Backlog? When will the purchase feature be completed?

Slide 35

Slide 35 text

© KAKEHASHI Inc. As a user, I can search items by the name in the search page. As a user, I can search items by the price in the search page. As a user, I can check item details in the item page. As a user, I can add items to a cart in the item page. As a user, I can check items in the cart in the cart page. … As a user, I can search items by the category in the search page Part 2: Slice Map Had These Thoughts with Product Backlog? How are the items connected? When will the purchase feature be completed?

Slide 36

Slide 36 text

© KAKEHASHI Inc. As a user, I can search items by the name in the search page. As a user, I can search items by the price in the search page. As a user, I can check item details in the item page. As a user, I can add items to a cart in the item page. As a user, I can check items in the cart in the cart page. … As a user, I can search items by the category in the search page Part 2: Slice Map Had These Thoughts with Product Backlog? How are the items connected? When will the purchase feature be completed? Why are there so many oversights?

Slide 37

Slide 37 text

© KAKEHASHI Inc. As a user, I can search items by the name in the search page. As a user, I can search items by the price in the search page. As a user, I can check item details in the item page. As a user, I can add items to a cart in the item page. As a user, I can check items in the cart in the cart page. … As a user, I can search items by the category in the search page Part 2: Slice Map Issues with Backlog-based Planning ● Lack of overall view ● Unclear connections between items ● Hard to identify oversights (´ɾωɾʆ)

Slide 38

Slide 38 text

© KAKEHASHI Inc. Part 2: Slice Map Slice Map ● for better planning ● inspired by User Story Mapping.

Slide 39

Slide 39 text

© KAKEHASHI Inc. Part 2: Slice Map Slice Map Three steps to create a Slice Map: 1. Put items on the map 2. Sort the items 3. Draw lines Note: Collaboration and discussion are essential.

Slide 40

Slide 40 text

Step 1: Put Items on the Map

Slide 41

Slide 41 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 1: Put Items on the Map Lines up user stories The PM (Product Manager) lines up user stories telling user narratives.

Slide 42

Slide 42 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 1: Put Items on the Map Must-Have, Nice-to-Have, and Future Roughly divide items into three groups

Slide 43

Slide 43 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 1: Put Items on the Map Adding items to the Must-Have Group Add items from the developers’ perspective, any concerns, testing ideas, etc.

Slide 44

Slide 44 text

© KAKEHASHI Inc. Part 2: Slice Map Step 1: Put Items on the Map ● Reflect the collective understanding of the entire team ● Not only user stories but also necessary tasks

Slide 45

Slide 45 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 1: Put Items on the Map Importance of Nice-to-Have and Future Items ● Prevents concerns about missing features ● Influences system architecture and development

Slide 46

Slide 46 text

Step 2: Sort the Items in the must-have group

Slide 47

Slide 47 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Move the items up and down We discuss the order of the items and move them up and down accordingly.

Slide 48

Slide 48 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Group related items as a Slice Usually, a set of items delivers a single feature, so we group them.

Slide 49

Slide 49 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Prioritizing Core Features to enable early stakeholder feedback

Slide 50

Slide 50 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Prioritizing Technical Decisions that impact subsequent steps

Slide 51

Slide 51 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Splitting Items into Smaller Parts This allows us to rearrange the order flexibly and focus on the essential ones.

Slide 52

Slide 52 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Important Point in Step 2 to sort items so they can be in a single line up by priority.

Slide 53

Slide 53 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 2: Sort the Items Step 2: Sort the Items The entire team is aligned and aware of the priorities.

Slide 54

Slide 54 text

Step 3: Draw Lines

Slide 55

Slide 55 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 3: Draw Lines Milestone Lines help us understand the timeline to meet the release schedule.

Slide 56

Slide 56 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 3: Draw Lines Minimum Viable Product (MVP) line that determines the critical items for launch.

Slide 57

Slide 57 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 3: Draw Lines Drawing the MVP Line is a Tough Activity It should include much less than what we want to provide in the initial version.

Slide 58

Slide 58 text

Our MVP Line Definition "If we haven't completed up to this line, we'll postpone the launch.”

Slide 59

Slide 59 text

You might think… 
 “Shouldn't we work harder?”

Slide 60

Slide 60 text

© KAKEHASHI Inc. Part 2: Slice Map - Step 3: Draw Lines No, we didn't choose that approach ● Our starting point is the trust that everyone is already doing their best. ● Increasing speed wasn't an option for us. ● The variables we can adjust are the plan and the scope.

Slide 61

Slide 61 text

© KAKEHASHI Inc. Part 2: Slice Map Slice Map ● Lack of overall view ● → Shared overall view ● Unclear connections between items ● → Described as Slices ● Hard to identify oversights ● → All the items are on the map. We should keep updating the Slice Map!

Slide 62

Slide 62 text

© KAKEHASHI Inc. Part 2: Slice Map Slice Map → Backlog Pick items from the top area of the Slice Map and put them into the Backlog. Product Backlog is ● not for planning ● the result of the planning Slice Map is ● for clear focus on the Product Goal ● for shared understanding

Slide 63

Slide 63 text

Successful Launch and into the… 🎉

Slide 64

Slide 64 text

Part 3: Trunk-based Development

Slide 65

Slide 65 text

“Launch is not the goal. It is a beginning.” - my former manager

Slide 66

Slide 66 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Shift to Trunk-based Development Our team handles both development and operations.

Slide 67

Slide 67 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Shift to Trunk-based Development Our team handles both development and operations. ● Before launch: ● Deploy our applications to production anytime ● Quickly fix issues since there are no users

Slide 68

Slide 68 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Shift to Trunk-based Development Our team handles both development and operations. ● Before launch: ● Deploy our applications to production anytime ● Quickly fix issues since there are no users ● Post-launch with real users: ● Must deploy new features without disrupting their experience ● Want to add features quickly and verify many hypotheses

Slide 69

Slide 69 text

Therefore, we chose Trunk-based Development

Slide 70

Slide 70 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Trunk-based Development? A branching model primarily utilizing the main branch ● Enables quick and frequent deployments ● Smaller changes, less negative impact Image from https://trunkbaseddevelopment.com/ (Accessed on 2024-06-30)

Slide 71

Slide 71 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Trunk-based Development? Push commits directly to the main branch Use short-lived pull requests Image from https://trunkbaseddevelopment.com/ (Accessed on 2024-06-30)

Slide 72

Slide 72 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Trunk-based Development? https://trunkbaseddevelopment.com/ (Accessed on 2024-06-30) Use short-lived pull requests

Slide 73

Slide 73 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Delivery Steps

Slide 74

Slide 74 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Delivery Steps A user can see the item tag Modify item API to return tags Modify frontend to fetch tags Modify frontend to display the tags

Slide 75

Slide 75 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Delivery Steps Mob Programming

Slide 76

Slide 76 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Delivery Steps

Slide 77

Slide 77 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Delivery Steps

Slide 78

Slide 78 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Closer Look: Monorepo and CI/CD Pipeline

Slide 79

Slide 79 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Closer Look: Monorepo and CI/CD Pipeline

Slide 80

Slide 80 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Closer Look: Monorepo and CI/CD Pipeline

Slide 81

Slide 81 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Closer Look: Monorepo and CI/CD Pipeline

Slide 82

Slide 82 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed Deployment Steps

Slide 83

Slide 83 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed Deployment Steps

Slide 84

Slide 84 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed Deployment Steps

Slide 85

Slide 85 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed Deployment Steps

Slide 86

Slide 86 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed Deployment Steps

Slide 87

Slide 87 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed Deployment Steps Automated One click Deployment

Slide 88

Slide 88 text

You might be wondering… “How do you deploy a half-done function?”

Slide 89

Slide 89 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Handling Half-Done with Feature Flags

Slide 90

Slide 90 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Guidelines for Feature Flags Usage Feature flags are useful but have pitfalls. We follow team guidelines for using them.

Slide 91

Slide 91 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Guidelines for Feature Flags Usage Feature flags are useful but have pitfalls. We follow team guidelines for using them. 1. Minimize Usage ● Use feature flags only for temporarily hiding features during development. ● Avoid permanent feature differences for users.

Slide 92

Slide 92 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Guidelines for Feature Flags Usage Feature flags are useful but have pitfalls. We follow team guidelines for using them. 1. Minimize Usage ● Use feature flags only for temporarily hiding features during development. ● Avoid permanent feature differences for users. 2. Clean Up ● Remove flag-related code promptly after use.

Slide 93

Slide 93 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Guidelines for Feature Flags Usage Feature flags are useful but have pitfalls. We follow team guidelines for using them. 1. Minimize Usage ● Use feature flags only for temporarily hiding features during development. ● Avoid permanent feature differences for users. 2. Clean Up ● Remove flag-related code promptly after use. 3. Handle Unavailability ● Ensure apps handle missing flags due to network issues.

Slide 94

Slide 94 text

© KAKEHASHI Inc. Part 3: Trunk-based Development Our Trunk-based Development We deploy to production almost daily: ● In the past, we deployed to production 25 times a month. ● On our busiest day, we deployed 4 times in a single day.

Slide 95

Slide 95 text

Part 4: Extra Topics

Slide 96

Slide 96 text

© KAKEHASHI Inc. Part 4: Extra Topics Extra Topics 1. Confirming Progress with Visible Results 2. Daily Scrum as Daily Planning 3. Daily Refinement 4. Mob Programming 5. Pair-Centered Mob Programming

Slide 97

Slide 97 text

© KAKEHASHI Inc. Part 4: Extra Topics Confirming Progress with Visible Results ● Regular status checks with visible results ● Avoid saying "It's done" or reporting "80% progress" ● Show completed items with working deliverables ● Sprint reviews showcase functional items ● Examples: Web interface, VPC setup in AWS Management Console ● Ensures clear, visible progress ● Keeps everyone aligned

Slide 98

Slide 98 text

© KAKEHASHI Inc. Part 4: Extra Topics Daily Scrum as Daily Planning ● Our project moves quickly ● Daily Scrum = Daily Planning ● Discuss what we learned yesterday ● Assess if today's tasks are still relevant to Product Goal ● Focus on the Product Goal ● Adapt to new information ● Example: Pivot based on new hypothesis discovered by PM during a pharmacy visit ● Ensures work on the most valuable tasks

Slide 99

Slide 99 text

© KAKEHASHI Inc. Part 4: Extra Topics Daily Refinement ● 15-minute Daily Refinement after Daily Scrum ● Focus on future sprints and long-term product vision ● PM handles most preparation ● Technical input often needed ● Structured opportunity for PM to consult with the team ● Weekly longer sessions for in-depth discussions

Slide 100

Slide 100 text

© KAKEHASHI Inc. Part 4: Extra Topics Mob Programming ● Practice Mob Programming remotely ● Four developers in a Slack Huddle ● Focus on one feature at a time ● Benefits of Mob Programming and automated deployment ● PM or manager can experience the deployment process ● Guided through a Good First Issue ● Deployed to production within a few hours

Slide 101

Slide 101 text

© KAKEHASHI Inc. Part 4: Extra Topics Pair-Centered Mob Programming ● Focus on pair-centered Mob Programming ● Initially used for onboarding new members ● Realized need for more time on system improvements ● Current approach: ● New members handle feature development ● Original members focus on system improvements ● Morning discussions on new features ● Split into pairs for development and improvements ● Ensures continuous progress on both fronts

Slide 102

Slide 102 text

© KAKEHASHI Inc. Part 4: Extra Topics Extra Topics

Slide 103

Slide 103 text

Summary

Slide 104

Slide 104 text

© KAKEHASHI Inc. Our Development Approach Summary

Slide 105

Slide 105 text

Focusing on Product Goals to deliver customer value

Slide 106

Slide 106 text

© KAKEHASHI Inc. Our journey We trust everyone 
 to do their best 
 for the Product Goal. Summary

Slide 107

Slide 107 text

© KAKEHASHI Inc. 1. Scrum Guide 
 https://scrumguides.org/ 2. Cynefin Framework 
 https://thecynefin.co/about-us/about-cynefin-framework/ 3. LEARNING TO EXPERIMENT (Chris Lucian, RSGT 2019) 
 https://www.youtube.com/watch?v=iGNmyxzs1II 4. #NoEstimates (Allen Holub) 
 https://www.youtube.com/watch?v=QVBlnCTu9Ms 5. NoEstimates Scrum En (Ikuo Suyama) 
 https://speakerdeck.com/martin_lover/noestimates-scrum-en 6. User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton) 
 https://learning.oreilly.com/videos/user-story-mapping/9781663728661/ 7. Trunk-based Development 
 https://trunkbaseddevelopment.com/ References

Slide 108

Slide 108 text

No content