Differences

This shows you the differences between two versions of the page.

--- how_do_small_incremental_changes_result_in_big_improvements [2019/07/20 13:03] – Reworked text based on feedback hpsamios
+++ how_do_small_incremental_changes_result_in_big_improvements [2019/08/06 07:49] (current) – Delete duplicate page hpsamios
@@ Line 1: / Line 1: @@
-====== How Do Small Incremental Changes Result in Big Improvements? ======
-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.
-This approach is usually contrasted with the more traditional approach to improvement where every now and again you get everyone in a room and figure out the next improvement in the business process under consideration.
-The question becomes “can we rely on these incremental improvements to produce dramatic changes in our ability to deliver value?”
-The short answer is “yes”, and the short reason is “the effect of compounding improvements.” Let’s look at how this works.
-If we assume baseline Team performance is 1 unit of throughput as they form and, as a result of a retrospective we have a 1% increase in throughput as a result of the improvement discovered. This means the throughput of the Team is now 1.01 (1 x 1% or 1 x 1.01). Doesn't sound like much, does it? But wait. Another retrospective results in another 1% throughput increase. So now the Team's throughput is 1.02 (1.01 x 1%) as this improvement builds on the previous gain.  If we imagine this happening after each and every retrospective, then after a year they will be 29% more throughput each and every iteration (1.01 ^ 26 weeks). 1% is a very low bar for improvements especially for Teams new to Agile, but it all adds up. If they do improvements weekly the number is 67% (1.01 ^ 52 weeks).
-A couple of notes:
-  - The rate of change is increasing. If it were linear, we should only get 58% (29 x 2) increase, not 67%, as we change from 26 improvements to 52. This is the effect of compounding improvements - improvements build on each other.
-  - This compounding effect is a great argument to do more and more "improvement" work. In particular, if you have a new idea them maybe there is no need to wait for the next Retrospective to implement it.
-  - This assumes that every improvement identified actually produces that 1% improvement. Since the people that are doing the work are identifying the improvements, my expectation is that the majority of changes should result in improvements. But even if everything the Team tried was a failure the risk is pretty low. You’d end up with a throughput for that Team of 0.77 (1.01 ^ -26 weeks). And this assumes the Team never goes back to fix their problems.
-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 turns out to be less of a concern than most would expect. 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 like 8.35 people.
-The conditions for making these improvements possible is built in many Agile practices:
-  * There is someone operating in the role of a coach (the Scrum Master)
-  * There is capacity to focus on improvements (at a minimum, the retrospective)
-As said, a 1% improvement out of a Retrospective is not a high bar. In fact you could argue that newly formed Teams should have significant improvement percentages. Simple tools such as Value Stream Mapping, improvements in collaboration and communication, reduction in impediments required to deliver value and so one are usually easy to find and offer large improvements. All it requires is the discipline to act on findings.
-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 where 261 is the typical number of working days in a year)! 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.
-Now I realize this is all throughput / capacity / utilization type thinking, not exactly Agile where we expect people to focus on value delivered. The assumption we are making is that the Teams are doing the right work based on business priorities. There are two potential improvements our customers could see - the right thing faster (prioritized value delivery), and more of it as well (improved ability to deliver).
-====== Want to Know More? ======
-  * [[what_does_a_scrum_master_do_all_day|What Does a Scrum Master Do All Day?]]
-  * [[https://jamesclear.com/marginal-gains|British Cycling approach to improving through “marginal gains”]]
-{{tag>FAQ incremental capacity retrospective}}