Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Our Scrum without Estimates, and into the Trunk...

Our Scrum without Estimates, and into the Trunk-based Development

Presentation Materials for DevOpsDays Taipei 2024
https://devopsdays.tw/2024/session-page/3059

KAKEHASHI

July 11, 2024
Tweet

More Decks by KAKEHASHI

Other Decks in Technology

Transcript

  1. © KAKEHASHI Inc. Our Scrum without Estimates, and into the

    Trunk-based Development 2024-07-11 @ DevOpsDays Taipei 2024 SHIIBA Mitz
  2. © 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
  3. © 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
  4. © 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
  5. © KAKEHASHI Inc. Part 1: Scrum without Estimates Our Product

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

    A web service for patients and pharmacists. • Uncertainties in requirements: • Built on several hypotheses.
  7. © 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.
  8. © 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.
  9. © KAKEHASHI Inc. Part 1: Scrum without Estimates Software Development

    Image from https://thecynefin.co/about-us/about-cynefin-framework/ (Accessed on 2024-07-01)
  10. © 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)
  11. © 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.
  12. © KAKEHASHI Inc. Part 1: Scrum without Estimates Our Dedication

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

    the Product Goal. We tend to look at the gaps between estimates and actual progress.
  14. © 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.
  15. No Estimates Enables us to focus on the Product Goal,

    Ensuring that we deliver maximum value to our users.
  16. © KAKEHASHI Inc. Part 1: Scrum without Estimates Alternative to

    Estimates Instead of estimates, we perform two specific activities.
  17. © 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.
  18. © 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
  19. © 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?
  20. © 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?
  21. © 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?
  22. © 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 (´ɾωɾʆ)
  23. © KAKEHASHI Inc. Part 2: Slice Map Slice Map •

    for better planning • inspired by User Story Mapping.
  24. © 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.
  25. © 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.
  26. © 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
  27. © 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.
  28. © 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
  29. © 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
  30. © 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.
  31. © 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.
  32. © KAKEHASHI Inc. Part 2: Slice Map - Step 2:

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

    Sort the Items Prioritizing Technical Decisions that impact subsequent steps
  34. © 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.
  35. © 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.
  36. © 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.
  37. © KAKEHASHI Inc. Part 2: Slice Map - Step 3:

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

    Draw Lines Minimum Viable Product (MVP) line that determines the critical items for launch.
  39. © 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.
  40. Our MVP Line Definition "If we haven't completed up to

    this line, we'll postpone the launch.”
  41. © 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.
  42. © 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!
  43. © 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
  44. © KAKEHASHI Inc. Part 3: Trunk-based Development Our Shift to

    Trunk-based Development Our team handles both development and operations.
  45. © 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
  46. © 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
  47. © 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)
  48. © 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)
  49. © 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
  50. © KAKEHASHI Inc. Part 3: Trunk-based Development Deep Dive: Detailed

    Deployment Steps Automated One click Deployment
  51. © 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.
  52. © 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.
  53. © 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.
  54. © 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.
  55. © 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.
  56. © 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
  57. © 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
  58. © 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
  59. © 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
  60. © 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
  61. © 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
  62. © KAKEHASHI Inc. Our journey We trust everyone 
 to

    do their best 
 for the Product Goal. Summary
  63. © 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