Lean Software Development

What Hacker News says

1. matt_sMar 2023
   Anything focusing on Lean Software Development and/or Agile. As much hate those words bring up in people that have had bad experiences and bad management of those processes, the alternatives of waterfall are much worse for software. There are exceptions like if you’re building software for a nuclear reactor or high risk projects you’ll want very stringent requirements processes.

   The core concepts behind agile/lean are really geared towards minimizing churn on stuff that doesn’t matter (unimportant features) and having a short feedback loop so you can find issues faster. Nothing is perfect and you will still have unused features and bugs, that’s the nature of it. One of the books I read had research backed findings based on analysis of projects, I think it was Agile Project Management with Scrum. Rework and other books by the Basecamp founders are good. It’s good to read up on a few different ways people have successfully done things to get perspective that not everything is “one size fits all.” Don’t take any methodology or process as prescriptive, they all have trade offs.

   Show morethread
2. jdlshoreNov 2022
   I’ve found hardware-oriented businesses to be woefully behind the times when it comes to software engineering processes. This article is no exception. Although I agree with his overall framing, once you get to the details, James is describing a document-oriented approach that was in vogue about 25 years ago, and has long since been superseded.

   What replaced it? Agile. Wait, don’t throw rotten vegetables—I’m not talking about the overwrought excuse for micromanagement people call “Agile” nowadays, but the truly innovative thinking that was happening in the late 90s and early 2000s. Stuff like the Poppendiecks’ Lean Software Development (based on their experience at 3M) and Cockburn’s Agile Software Development (based on research he originally conducted at IBM). And of course Beck’s Extreme Programming, based in part on his work with Ward Cunningham at Tektronix.

   These processes and thinking started with the reality that it’s impossible, given a large, complex system, to correctly specify everything in advance. They recognized that documents are a particularly poor communication medium—one that’s time-consuming to create and consume, and very difficult to do in a way that isn’t misunderstood.

   Instead, they focused on people as more important than process, and adaptation as more important than prediction. Traditional SDLCs fell by the wayside, and for good reason: they didn’t work well. Their document-heavy approach resulted in poor visibility for management and software that met the spec but not customer needs.

   I talk about this more in my book. The first chapter talks about how and why Agile supplanted traditional processes. It’s free online (along with a lot of other material) here: https://www.jamesshore.com/v2/books/aoad2/what_is_agile

   Show morethread
3. jdlshoreJul 2022
   At the risk of self promotion, my book (The Art of Agile Development) attempts to balance explaining the underlying theory with providing pragmatic "how to" guidance. A lot of the theory is set up in the first chapter, which is online here:

   https://www.jamesshore.com/v2/books/aoad2/what_is_agile

   The rest of the theory is spread throughout the book, in "key ideas" sidebars (which you can find in the index) and the "Experiments and Alternatives" sections at the end of each practice.

   I'm not aware of any books that are purely about the underlying theory, but these books swing the pendulum more towards the theory side of things:

   Lean Software Development (Mary and Tom Poppendieck) - if you only read one, this is the one to read

   The Principles of Product Development Flow (Tom Reinertsen)

   Agile Software Development, 2nd. ed. (Alistair Cockburn)

   Extreme Programming Explained, 2nd ed. (Kent Beck)

   The Lean Startup (Eric Ries)

   Show morethread
4. allenuAug 2021
   You may want to read the book Lean Software Development: An Agile Toolkit, it describes waste in the same manner and offers principles to help reduce it.
   thread
5. allenuMay 2021
   Another way to look at emphasizing latency/feedback is to "increase learning". There's a great book, Lean Software Development: An Agile Toolkit, that covers this.

   The idea is that there are so many unknowns within a project, that organizations should aim to move quickly enough to uncover them sooner. A lot of these unknowns lead to constraints that have profound effects on designs, so if you delay learning them, you are more likely to have to re-do designs deeper in the process, when it is more costly. The sooner you discover them, the more likely you will have the flexibility to account for them in the design.

   Show morethread
6. RandomSortOct 2018
   In Continuous Delivery and DevOps:

   Lean software Development - Mary & Tom Poppendieck

   The DevOps Handbook - Gene Kim, Jez Humble, Patrick Debois

   Accelerate - Nicole Forsgren, Jez Humble, Gene Kim

   Continuous Integration - Paul M. Duvall, Andrew Glover, Steve Matyas

   Continuous Delivery - Jez Humble, David Farley

   Show morethread