Differences

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

Link to this comparison view

Both sides previous revision Previous revision
agile_scrum_xp_and_lean [2019/04/20 14:17]
mgunderloy
agile_scrum_xp_and_lean [2019/05/20 07:57] (current)
mgunderloy
Line 3: Line 3:
   * [[https://​www.amazon.com/​Accelerate-Software-Performing-Technology-Organizations/​dp/​1942788339|Accelerate:​ The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations]]:​ This book tries to take a rigorous, data-driven approach to teasing out the impact of DevOps practices on organizational productivity. The authors come to conclusions like "lean product development causes less burnout"​ and offer their survey-based research as evidence for their conclusions. I desperately *want* to believe this book, because their conclusions accord with my own prejudices: that lean, agile, and transformational practices contribute to organizational improvement. Unfortunately,​ I just can't quite close that gap. One of the telling points for me comes in Chapter 15, where the authors say "We did not collect data from professionals and organizations who were not familiar with things like configuration management, infrastructure-as-code,​ and continuous integration. By not collecting data on this group, we miss a cohort that are likely performing even worse than our low performers."​ I don't see any evidence for that assumption, or any reason to believe that their self-selected snowball sample is representative enough to tell us anything about the actual impact of various practices on software development. Nonetheless,​ I'm happy to see this book, because it pushes things in the direction that I'd like to see them go. Whatever my own concerns about methodology,​ you may be sure I'll be citing this in my attempts to get my own upper management to move to more "​agile"​ ways of working, simply because I find them more pleasant. (Reviewed by Mike Gunderloy)   * [[https://​www.amazon.com/​Accelerate-Software-Performing-Technology-Organizations/​dp/​1942788339|Accelerate:​ The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations]]:​ This book tries to take a rigorous, data-driven approach to teasing out the impact of DevOps practices on organizational productivity. The authors come to conclusions like "lean product development causes less burnout"​ and offer their survey-based research as evidence for their conclusions. I desperately *want* to believe this book, because their conclusions accord with my own prejudices: that lean, agile, and transformational practices contribute to organizational improvement. Unfortunately,​ I just can't quite close that gap. One of the telling points for me comes in Chapter 15, where the authors say "We did not collect data from professionals and organizations who were not familiar with things like configuration management, infrastructure-as-code,​ and continuous integration. By not collecting data on this group, we miss a cohort that are likely performing even worse than our low performers."​ I don't see any evidence for that assumption, or any reason to believe that their self-selected snowball sample is representative enough to tell us anything about the actual impact of various practices on software development. Nonetheless,​ I'm happy to see this book, because it pushes things in the direction that I'd like to see them go. Whatever my own concerns about methodology,​ you may be sure I'll be citing this in my attempts to get my own upper management to move to more "​agile"​ ways of working, simply because I find them more pleasant. (Reviewed by Mike Gunderloy)
   * [[https://​www.amazon.com/​Agile-Retrospectives-Making-Teams-Great/​dp/​0977616649|Agile Retrospectives]]:​ This one has been on my shelf for a decade, but I just pulled it off and read it again since I'm finally part of a team that is serious about retrospectives. Even though I'm not the agile coach for the team, I found a lot to think about here - there are many, many retrospective techniques that can be used, and I'll be interested to see us try some of them. This was also the first time in a long time I've thought about release or project retros, instead of just sprint retros. (Reviewed by Mike Gunderloy)   * [[https://​www.amazon.com/​Agile-Retrospectives-Making-Teams-Great/​dp/​0977616649|Agile Retrospectives]]:​ This one has been on my shelf for a decade, but I just pulled it off and read it again since I'm finally part of a team that is serious about retrospectives. Even though I'm not the agile coach for the team, I found a lot to think about here - there are many, many retrospective techniques that can be used, and I'll be interested to see us try some of them. This was also the first time in a long time I've thought about release or project retros, instead of just sprint retros. (Reviewed by Mike Gunderloy)
 +  * [[https://​pragprog.com/​book/​jragm/​create-your-successful-agile-project|Create Your Successful Agile Project]]
   * [[https://​www.amazon.com/​Extreme-Programming-Explained-Embrace-Change/​dp/​0201616416|Extreme Programming Explained]]   * [[https://​www.amazon.com/​Extreme-Programming-Explained-Embrace-Change/​dp/​0201616416|Extreme Programming Explained]]
   * [[https://​www.amazon.com/​FIRE-Inexpensive-Restrained-Elegant-Innovation-ebook/​dp/​B00FJ3A6FC|FIRE:​ How Fast, Inexpensive,​ Restrained, and Elegant Methods Ignite Innovation]]:​ An argument that better work comes out of projects that are deliberately "fast, inexpensive,​ restrained, and elegant"​. The author comes out of the engineering & military communities,​ where he's certainly had lots of opportunity to observe projects that miss all of those targets, soak up money, and deliver nothing of value. But the principles apply in software development as well. Constraining things can have a wonderful focusing effect. (Reviewed by Mike Gunderloy)   * [[https://​www.amazon.com/​FIRE-Inexpensive-Restrained-Elegant-Innovation-ebook/​dp/​B00FJ3A6FC|FIRE:​ How Fast, Inexpensive,​ Restrained, and Elegant Methods Ignite Innovation]]:​ An argument that better work comes out of projects that are deliberately "fast, inexpensive,​ restrained, and elegant"​. The author comes out of the engineering & military communities,​ where he's certainly had lots of opportunity to observe projects that miss all of those targets, soak up money, and deliver nothing of value. But the principles apply in software development as well. Constraining things can have a wonderful focusing effect. (Reviewed by Mike Gunderloy)
  • agile_scrum_xp_and_lean.txt
  • Last modified: 2019/05/20 07:57
  • by mgunderloy