Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Does this FizzGood? Improve velocity, predictability & agility by asking a simple question

2,720 views

Published on

LeanKit's founding team had a strong Lean-Agile background from previous careers. So, in the early days of the company, we just instinctively did things in a Lean way with as few formal processes as any startup. But, like any growing company, we eventually did have to start clearly defining how we do things. And like anyone, we were tempted to become more bureaucratic - with lots of scheduling, coordination, meetings and estimates.

Instead, we developed our FSGD (Frequent Small Good Decoupled) approach. This LeanKit way of working has provided our teams with a simple yardstick for making effective decisions without a lot of cross team scheduling and coordination. It has simplified abstract Agile concepts into something everyone easily understands and cheerfully applies on a daily basis.

FSGD isn't a replacement for Kanban, Scrum, XP, etc. We strongly believe in and spend lots of time teaching our teams about the Kanban Method as well as standard Lean and Agile principles, tools, and techniques. But FSGD distills what we think are the key decision making elements of those methods into something everyone can remember.

We apply this model to all of our teams: design, development, testing, operations, sales, marketing, finance, HR. Indeed, we believe that applying it as broadly as possible makes it work most effectively.

Indeed, that's part of why the model doesn't reference software directly at all. It's meant to be generally applicable. One sub-concept included in the slides TLDR (Tested, Logged, Documented, Reviewed) is more specific to the technology context.

We have seen significant improvements in our delivery speed across multiple teams since rolling out the FSGD approach. We want to help other people gain the same benefits.

Bio:

Jon Terry is co-Chief Executive Officer of LeanKit. Before LeanKit, Jon held a number of senior IT positions with hospital-giant HCA and its logistics subsidiary, HealthTrust Purchasing Group. He was among those responsible for launching HCA’s adoption of Lean/Agile methods.

Jon earned his Global Executive MBA from Georgetown University and ESADE Business School in Barcelona, Spain, and his Masters Certificate in Project Management from George Washington University. He is a Project Management Professional, a Certified Scrum Master, a Kanban Coaching Professional, is certified in the Lean Construction Institute’s Last Planner Method, and trained in the SAFe Lean Systems Engineering method.

Published in: Leadership & Management

Does this FizzGood? Improve velocity, predictability & agility by asking a simple question

  1. 1. Some Background on Fizz Good • LeanKit in the beginning … • As we grew … • Growing pains …
  2. 2. Hurray! Never Again LeanKit for Construction and Connections and Mobile and Marketing and SSO and ….
  3. 3. We love Lean, Kanban, Agile, DevOps AND
  4. 4. FSGD ( Fizz Good ) Frequent Small Good Decoupled
  5. 5. Frequent Small Good Decoupled Annually Quarterly Sporadic
  6. 6. Release Frequently for … (IMPROVE IT LATER IF NECESSARY.) Changing business realities
  7. 7. "We are getting away from 2 years, 3 years, 4 years, 5 years, to design, build, test and then deliver a product. We live in a world of high levels of agility; being able to build, measure, learn; being able to get on a faster cadence and a faster loop where we can deliver value more frequently."
  8. 8. … and we don’t just mean to the customer
  9. 9. because math (not the Agile Manifesto)
  10. 10. 0% 100% Utilization 0 Infinity Cycle Time A fully busy system == zero productivity All credit and praise rightfully belongs to to Don Reinertsen
  11. 11. WIP Limit 1 2 5 10 20 Infinite Average Cycle Time 1.0 1.5 2.8 4.6 7.2 10 Time in Queue 0 0.5 1.8 3.6 6.2 9 Utilization Percent 47 63 79 85 89 90 Slack Time 53 37 21 15 11 10 Blocking Percent 47 30 13 5 1 0 All credit and praise rightfully belongs to Don Reinertsen A little bit of reduction goes a long way
  12. 12. All credit and praise rightfully belongs to Don Reinertsen WIP Limit 1 2 5 10 20 Infinite Average Cycle Time 1.0 1.5 2.8 4.6 7.2 10 Time in Queue 0 0.5 1.8 3.6 6.2 9 Utilization Percent 47 63 79 85 89 90 Slack Time 53 37 21 15 11 10 Blocking Percent 47 30 13 5 1 0 Let’s assume the starting point is 90% utilization, 10 day cycle time & no WIP limits
  13. 13. WIP Limit 1 2 5 10 20 Infinite Average Cycle Time 1.0 1.5 2.8 4.6 7.2 10 Time in Queue 0 0.5 1.8 3.6 6.2 9 Utilization Percent 47 63 79 85 89 90 Slack Time 53 37 21 15 11 10 Blocking Percent 47 30 13 5 1 0 All credit and praise rightfully belongs to Don Reinertsen A WIP limit of twice current average makes us 28% faster in return for 1% slack
  14. 14. WIP Limit 1 2 5 10 20 Infinite Average Cycle Time 1.0 1.5 2.8 4.6 7.2 10 Time in Queue 0 0.5 1.8 3.6 6.2 9 Utilization Percent 47 63 79 85 89 90 Slack Time 53 37 21 15 11 10 Blocking Percent 47 30 13 5 1 0 All credit and praise rightfully belongs to Don Reinertsen A WIP limit equal to current average makes us 54% faster in return for 5% slack
  15. 15. 0% 100% Utilization 0 Infinity Cycle Time Higher variability = even less utilization All credit and praise rightfully belongs to to Don Reinertsen
  16. 16. It’s tough to limit WIP with variable batch sizes
  17. 17. Frequent Small Good Decoupled Big
  18. 18. Some things are just naturally big?
  19. 19. Some things are just notoriously big
  20. 20. Why? Why? Why? Why? Why? Five Why's Root Cause Analysis
  21. 21. 5 Why example: notoriously big things Why does it have to be so big? It does lots of things and has lots of components Why does it do so many things? Because they are interrelated. Why can't they be broken into several releases? Because it is costly to deploy each of them Why is that? Because we do not have an automated testing and release process
  22. 22. Round Robin Scheduling • Breaking work into smaller slices • Just-in-time decision making
  23. 23. Round Robin Scheduling
  24. 24. Round Robin Scheduling
  25. 25. Round Robin Scheduling
  26. 26. Round Robin Scheduling
  27. 27. Round Robin Scheduling • Smaller batch size allows flexible reprioritization without context switching
  28. 28. Round Robin Scheduling
  29. 29. Round Robin Scheduling
  30. 30. Round Robin Scheduling • What next? • Project B? • Bugs? • Maybe Project C? • Your choice!
  31. 31. Round Robin Scheduling
  32. 32. Round Robin Scheduling
  33. 33. Round Robin Scheduling • Oh no. Project B Part 2 is taking too long. • Too big! • Too fat!
  34. 34. Stop Digging
  35. 35. Round Fat Robin Scheduling • Move it aside • Choose next priority
  36. 36. Fat Robin Scheduling • Small & Decoupled allow us to complete, and gain value from, other portions of the project
  37. 37. Fat Robin Scheduling
  38. 38. Fat Robin Scheduling
  39. 39. Fat Robin Scheduling
  40. 40. Fat Robin Scheduling
  41. 41. Fat Robin Scheduling
  42. 42. Fat Robin Scheduling • Back to that fat robin • Break him up into smaller pieces
  43. 43. Fat Robin Scheduling • Flow as usual
  44. 44. Fat Robin Scheduling
  45. 45. Fat Robin Scheduling
  46. 46. Fat Robin Scheduling • What about critical issues?
  47. 47. Fat Robin Scheduling • Stop the line • Tools down on other work • Do not simply add more work to the team
  48. 48. Fat Robin Scheduling • Critical issue resolved, back to usual flow
  49. 49. Fat Robin Scheduling
  50. 50. Fat Robin Scheduling
  51. 51. Fat Robin Scheduling
  52. 52. Fat Robin Scheduling
  53. 53. Fat Robin Scheduling
  54. 54. Fat Robin Scheduling
  55. 55. Fat Robin Scheduling
  56. 56. Fat Robin Scheduling
  57. 57. Fat Robin Scheduling
  58. 58. Fat Robin Scheduling
  59. 59. Frequent Small Good Decoupled Garbage
  60. 60. Tested Logged Documented Reviewed @ifandelse github. com/ifandelse
  61. 61. Frequent Small Good Decoupled Garbage Gold-plated
  62. 62. Frequent Small Good Decoupled Damaging
  63. 63. Frequent Small Garbage Decoupled
  64. 64. Frequent Small Good Damaging Frequent Small Good Decoupled Frequent Small Garbage Decoupled
  65. 65. PRIMUM NON NOCERE
  66. 66. PRIMUM NON NOCERE First, do no harm
  67. 67. Frequent Small Good Decoupled beneficence non-maleficence bioethics (i.e. non damaging, do no harm)
  68. 68. Frequent Small Good Decoupled Coordinated Damaging
  69. 69. DecoupledCoordinated
  70. 70. Coordinated
  71. 71. "These services need to be able to change independently of each other, and be deployed by themselves without requiring consumers to change. ... Without decoupling, everything breaks down for us."
  72. 72. Example: Custom Icons
  73. 73. Example: Custom Icons
  74. 74. Example: Custom Icons New field in the database, prepopulated … SHIP IT!
  75. 75. Example: Custom Icons Use that to relabel UI in browser … SHIP IT!
  76. 76. Example: Custom Icons Use that to relabel UI in mobile … SHIP IT
  77. 77. Example: Custom Icons Add edit field to browser board edit UI … SHIP IT!
  78. 78. Example: Custom Icons All the pieces are in place. It just works.
  79. 79. Example: Custom Icons ANNOUNCE IT (prewritten … whenever)
  80. 80. Marketing Team Browser Team Mobile Team API Team Sales Team Releasing a New Feature
  81. 81. Frequent Small Good Decoupled Frequent Small Good Decoupled Frequent Small Good Decoupled Frequent Small Good Decoupled Frequent Small Good Decoupled
  82. 82. Results
  83. 83. LeanKit Mobile Team Releases
  84. 84. LeanKit Mobile Team Releases Bet a
  85. 85. LeanKit Mobile Team Releases
  86. 86. WSM Radio Home of Grand Old Opry Regular Listeners Brentwood, TN’s Blaw-Knox Tower • Extremely large target audience for the era • Required tallest US radio tower when built in 1932 • Height put it under severe pivoting strain • Normal design would have meant massive frame • Instead, lean design was lighter & cheaper • Lightweight modular design was faster to install • Smaller cross section requires less maintenance • Narrow base pivots easily, needs minimal insulation
  87. 87. Marketability Sustainability Frequency Feature Delivery WFSGD The Spirit of LeanKit Repeat Customers Product Management Technical Excellence Decoupled Small Good
  88. 88. View our FSGD (Fizz Good) content and download this presentation: leankit.com/FSGD 2014 by LEANKIT – Daniel Norton, Jon Terry and Chris Hefley FSGD (Fizz Good) – A LeanKit Way of Working FSGD (Fizz Good) is made available under the Creative Commons Attribution-ShareAlike 4.0 International License: http://creativecommons.org/licenses/by-sa/4.0/

×