how_do_small_changes_lead_to_big_improvements
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
how_do_small_changes_lead_to_big_improvements [2019/08/05 12:59] – created hpsamios | how_do_small_changes_lead_to_big_improvements [2025/02/21 07:25] (current) – [Want to Know More?] Added "improvement" link hans | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== How Do Small Changes Lead to Big Improvements? | ====== How Do Small Changes Lead to Big Improvements? | ||
- | ``` | + | > “Improving daily work is more important than doing daily work” - Gene Kim, The Phoenix Project |
- | “Improving daily work is more important than doing daily work” - Gene Kim, The Phoenix Project | + | |
- | ``` | + | |
One thing that Agile encourages is a more iterative and incremental approach to delivering value. This thinking also applies to how we do the work. Agile expects that you will identify improvements in an incremental way, continuously and relentlessly improving the ability of your Team to deliver value. The expectation is that these incremental improvements build on each other. Since they are small changes, there is potentially a lot less risk in trying something out. | One thing that Agile encourages is a more iterative and incremental approach to delivering value. This thinking also applies to how we do the work. Agile expects that you will identify improvements in an incremental way, continuously and relentlessly improving the ability of your Team to deliver value. The expectation is that these incremental improvements build on each other. Since they are small changes, there is potentially a lot less risk in trying something out. | ||
Line 22: | Line 20: | ||
One interesting side effect of this is the natural concern when people start an Agile transformation that they “lose capacity” as a result of identifying dedicated Scrum Master (SM) and Product Owner (PO) roles. Because of the compounding improvements this is not a concern. Lets say we have typical Team of 7 people, one of which is SM, another is PO. With this improvement model, after a year with 2 week iterations, the Team is functioning at the level of 6.45 people (5 x 1.29 as a %). The 1 week iterations would produce a Team operating 8.35 people. | One interesting side effect of this is the natural concern when people start an Agile transformation that they “lose capacity” as a result of identifying dedicated Scrum Master (SM) and Product Owner (PO) roles. Because of the compounding improvements this is not a concern. Lets say we have typical Team of 7 people, one of which is SM, another is PO. With this improvement model, after a year with 2 week iterations, the Team is functioning at the level of 6.45 people (5 x 1.29 as a %). The 1 week iterations would produce a Team operating 8.35 people. | ||
- | I realize that 6.45 is still less than the 7 people we started with but the reality is that 1% improvement every couple of weeks is a very low hurdle. Most Teams are able to identify far larger improvements. Newly formed Teams can expect to see significant improvement percentages. Simple tools such as Value Stream Mapping, improvements in collaboration and communication, | + | I realize that 6.45 is still less than the 7 people we started with but the reality is that 1% improvement every couple of weeks is a very low hurdle. Most Teams are able to identify far larger improvements. Newly formed Teams can expect to see significant improvement percentages. Simple tools such as Value Stream Mapping, improvements in collaboration and communication, |
- | A condition for making these improvements possible is built in Agile: | + | {{ :2x_improvement_after_16_iterations.png?600 |}} |
- | + | ||
- | * There is someone operating in the role of a coach (the SM) | + | |
- | * There is capacity to focus on improvements (at a minimum, the retrospective). | + | |
Perhaps the Team can end up somewhere in the realm of 1% improvement per (work) day over a year. The improvement for this team is 1342% (1.01 ^ 261 days)! This is not a typo. That is a 13X improvement in throughput, or a Team operating like it is a 67 people. Fanciful? Probably. But kind of interesting. My personal experience showed a Team with 9X improvement after the first year. | Perhaps the Team can end up somewhere in the realm of 1% improvement per (work) day over a year. The improvement for this team is 1342% (1.01 ^ 261 days)! This is not a typo. That is a 13X improvement in throughput, or a Team operating like it is a 67 people. Fanciful? Probably. But kind of interesting. My personal experience showed a Team with 9X improvement after the first year. | ||
This is all throughput / capacity / utilization type thinking - not exactly Agile where we expect people to focus on (the flow of) value delivered. The assumption we are making is that the Teams are doing the right work based on business priorities. There are thus two potential improvements our customers could see - the right thing faster as a result of good prioritization, | This is all throughput / capacity / utilization type thinking - not exactly Agile where we expect people to focus on (the flow of) value delivered. The assumption we are making is that the Teams are doing the right work based on business priorities. There are thus two potential improvements our customers could see - the right thing faster as a result of good prioritization, | ||
+ | |||
+ | Note: A condition for making these improvements possible is built in Agile: | ||
+ | |||
+ | * There is someone operating in the role of a coach (the SM) | ||
+ | * There is capacity to focus on improvements (at a minimum, the [[how_do_we_run_our_first_sprint_retrospective|retrospective ceremony]]). | ||
+ | |||
+ | ====== Want to Know More? ====== | ||
+ | |||
+ | * [[how_do_we_get_away_from_business_as_usual_thinking_on_teams|How Do We Get Away from “Business as Usual” Thinking On Teams?]] for ideas on improvement. | ||
+ | * [[what_can_we_do_to_improve_our_retrospectives|What Can We Do To Improve Our Retrospectives? | ||
+ | * [[how_do_we_run_our_first_sprint_retrospective|How do we run our first retrospective ceremony]]) | ||
+ | * [[what_does_a_scrum_master_do_all_day|What Does a Scrum Master Do All Day?]] | ||
+ | * [[https:// | ||
+ | |||
{{tag> | {{tag> |
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_do_small_changes_lead_to_big_improvements.1565035195.txt.gz · Last modified: 2020/06/02 14:32 (external edit)