Agile, Scrum, XP, and Lean Books

  • 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)
  • 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)
  • 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)
  • The Lean Startup: I ran across this one on my shelf, having completely forgotten I'd picked up a copy and never read it. So I went ahead and did so. I can go along with crediting this book with doing a lot to promote “lean” thinking in the context of software startups, which makes it an important current in agile thought. But I couldn't help noticing how many of the companies he cites in this 2011 book have failed to make an actual splash. That's a common failing of business books, of course - but it does make having faith in conclusions a bit harder. On the plus side, the notion of knowing what you're optimizing and experimenting fast is a good and useful one. On the minus side, I suspect we would all have been better off if “pivot” as a concept had never been introduced to startup-land. It's not Ries' fault, but that's ended up as shorthand for “we haven't spent all your money yet, let's try the next stupid idea.” (Reviewed by Mike Gunderloy)
  • Making Work Visible: Subtitled “Exposing Time Theft to Optimize Work & Flow,” this is the handbook of kanban practice that you didn't know you needed. Degrandis does a great job of showing why kanban is a practical technique, not just a different set of ceremonies, by motivating it around the need to find (and eliminate) the things that waste time at work. It goes through a lot of different ways to tweak a kanban process for specific purposes, and it's likely that any struggling team will find some immediate relief here. (Reviewed by Mike Gunderloy)
  • The Openspace Agility Handbook: A little bird (at a previous job) clued me in that this one was getting read in our C-suite. Naturally I had to grab a copy for myself. It's a quick read, and one that proposes a structured course for launching an agile transformation (though much of the structure is concerned with opening up space to avoid existing structures). A few observations: 1) The authors (and developer of OpenSpace Agility) have a bad case of Too Many Proper Nouns With Capital Letters Syndrome. The editor in me wants to make them rewrite to conform to standard rules of English. 2) It was worth the work to get past the T.M.P.N.W.C.L.S issues and engage with the actual material. The path the authors propose for launching a successful agile transformation is at least plausible. 3) Even with this structure, it's all going to come down to people & commitment. It seems pretty clear that the C-suite could launch an empty OpenSpace Agility exercise, collect the results, pat themselves on the back, and go on with business as usual. It would be pretty easy to only extend invitations to participate to “safe” employees, i.e., those who will not rock the boat. 4) I suspect the choice of Facilitator is going to be absolutely critical. I think it will need to be someone with respect across the organization and either (a) sufficient political capital to make upper management listen or (b) sufficient IDGAF to ignore upper management. 5) There are some novel ideas here, including inviting even those who are opposed to an agile transformation, and casting the whole process as a game. I don't know if they'll work, but when existing ideas aren't working it seems to me that any new idea is worth trying. 6) Like most agile books directed at a context wider than software development, this one tries to navigate between a “one size fits all” prescription and a “do whatever you want” description. The touchstone here is whether practices conform to the Agile Manifesto. I'm not convinced this works but I don't have a better idea. 7) “Emergent leadership” appears to me to be an idea ripe for abuse by people who are determined to get ahead at the expense of others because they are more outgoing, vocal, or simply loud. I don't see any attention here to encouraging safe space for diverse voices, or to approaches other than the “marketplace of ideas,” and that concerns me. 8) There's an assumption here that you bring in an outside coach to help. That smells like a good idea to me, and any organization that's not willing to spend the money on an outside coach may not really be serious about transformation. 9) If the company is really serious about pursuing this path: (a) there will be quick movement and a sense of urgency about starting the process (b) the overall Sponsor will be at the very top level of the company, not a few levels down because “it's their job” © all parts of the company will be involved, not just engineering (d) travel and other costs will be covered for employees no matter where in the world they live. There are, I think, a lot of paths to agile. This one certainly looks plausible, and its structure may make it less scary to upper management than a complete “trust us and turn us loose” approach. I'd be happy to see my employers go down this road. And, if the rumor about them reading this book is true and nothing happens in 30-60 days, I'll be drawing some negative conclusions from that as well. (Reviewed by Mike Gunderloy)
  • Organize for Complexity: Pflaeging presents his core ideas in this graphic-heavy book (suitable for both right-brained and left-brained readers): that “management” is a problem rather than a solution, that leadership is distinct from management, and that there is a difference between “alpha” (managed) and “beta” (led) organizations. Lots of connections here with things like agile, though mostly implied rather than spelled out. Radical decentralization of decision-making is one of his key themes, and he argues that this can lead to enormous competitive benefits. Best part: there is some prescriptive material on how to think about changing an existing organization into a beta form. Worst part: I think some of his history is a bit glib and misses the complexities of how we got current management structures, though it makes for a good story. (Reviewed by Mike Gunderloy)
  • Project Myopia: Mostly a polemic about trying to mix traditional project management with agile software development. For people stuck in a project mindset, it might be an eye-opener. Briefly, the fixed scope fixed end attitude of traditional projects doesn't mesh well with the notion of delivering highest value first. Kelly brings a lot of arguments to bear on this, just in case your boss is reluctant to understand or you're a little slow yourself. (Reviewed by Mike Gunderloy)
  • Scrum 101: A quick read about the basics of Scrum (100'ish pages most half blank). It's set up as a set of questions and answers, walking from the basics of the Agile Manifesto through the ceremonies and artifacts of Scrum. I have the same problems with it that I do with most Scrum books, which is that some people seem to mistake form for function, but as a reference it isn't bad. (Reviewed by Mike Gunderloy)
  • Scrum - A Pocket Guide: Good and fairly short (100 pages) overview of scrum. One way they made it “pocket” though was by reducing the type to something like 7 point so it's eyestrain city for us older folks. Things I found interesting; 1. Presenting scrum as a game, with rules and tactics 2. The de-emphasis on “do it this one way” in favor of “here's the principle, there are many practices” 3. The growing movement towards “scrum and … ” as it gets into ever-larger and more diverse organizations. Things that annoyed me: 1. Tiny print 2. The self-congratulatory tone 3. The lack of editing by a native English speaker All in all, it'll be on my shelf, close at hand, as long as I'm in an organization using scrum. (Reviewed by Mike Gunderloy)
  • Scrum Mastery: This one has me thinking, which is an excellent recommendation. The author applies experience as a scrum master to identifying behaviors that move scrum masters from “good” to “great.” When I look around my own company, I don't see a lot of these great behaviors - but I think that's due to lack or organizational support. So then the question is: what can the organization in general, and I in particular, do to help remedy that? (Reviewed by Mike Gunderloy)
  • User Story Mapping: If you think user stories are just “As a I want to _ in order to _” Mad Libs, then you've got a lot to learn here. Patton has a broad overview of stories as conversations, and he spends 250+ pages getting that overview to the reader. Covers everything from writing good stories, to the different sizes and uses of stories, to a variety of ways to hold workshops for different purposes, all revolving around the continuous conversation between all stakeholders. This one was an eye-opener; our company is agile, but there's a heck of a lot more we could be doing here. (Reviewed by Mike Gunderloy)
  • agile_scrum_xp_and_lean.txt
  • Last modified: 2019/05/20 07:57
  • by mgunderloy