Name: Leading lean software development
ISBN: 9780321620705

What Hacker News says

wpietriOct 2015

One really interesting historical example (or, perhaps, counter-example) was the Empire State Building. At least in Mary Poppendieck's telling, it was completed on time, under budget, and with no plan in advance, at least not as we understand plans today:

https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...

And there's a better telling of it in her excellent book:

http://www.amazon.com/Leading-Lean-Software-Development-Resu...

This makes a ton of sense to me; the American culture around plans is thoroughly fucked.

In software, otherwise reasonable people expect me to give them numbers at the drop of a hat. When will this be done? What will it cost? What will our revenues be for the next 5 years? When I tell them I have no data for numbers like that, they will ask again, as if they thought I hadn't quite heard the question.

When I make it clear that although I'm glad to do real estimates I won't just make up numbers, they get mad. They need numbers! [No, they don't. They want them, often for political reasons.] Other people have given them numbers! [I am not other people.] This is how everybody does it! [Thanks, I've seen the stats on how well that works.] I should just give some ballpark numbers! Nobody will take them seriously! [Except they always, always, always turn into real numbers.] It makes me crazy.

For years, I kept thinking that if I just explained it well, people would come around. But I've come to believe that the root problem here is a managerialist culture, where power matters more than expertise or professional responsibility. Managers want numbers, so managers get numbers. They don't actually help, but managers get to feel in control. If it all happens to work, they're brilliant managers. And if it doesn't, the blame falls upon the people who gave them the numbers, or the people who failed to execute according to the always-impossible plan.

Now I just look for people and work cultures that are focused on actual results and are comfortable with bottom-up power structures.

thread

viraptorJul 2015

"Leading Lean Software Development: Results Are not the Point" is pretty good, I think. You definitely shouldn't use it as the only book, but it's worth reading.

thread

viraptorAug 2010

Fiction:

- Someone already mentioned Neil Gaiman's "American Gods", but it's so good, I'll mention it again :) Very well constructed and has its specific atmosphere...

- Anything by Iain Banks - "Walking on glass", "Wasp factory", "A song of stone" are definitely not light reading, but worth spending some time on them. His science-fiction is much simpler, but... didn't get me as excited as "Walking on glass".

Non-fiction:

- "Leading Lean Software Development - Results are not the point" (http://www.amazon.com/Leading-Lean-Software-Development-Resu...) is the best team / organisation / project leading book I've seen. I hate most of books like that with passion, but this one is different. I can't wait for the next story they introduce in every chapter. It touches many topics useful for anyone working with even one other person and you can read it like a good adventure book - it's got clear examples, interesting quotes and in-depth but not boring analysis.

thread

JtsummersDec 2018

I think the first one I read was Lean Software Development then I went through Leading Lean Software Development and Implementing Lean Software Development.

It's been a while, but as I recall the latter two can be treated something like workbooks. How to go from "traditional" project management towards lean/agile. The former introduces many Lean concepts but within the software development world. So that's where I got the idea (maybe I'd seen it before I read that book?) about treating developed, but not integrated, code as "inventory". It has a cost because we have to eventually integrate it but it'll become "stale" over time as its interfaces or other features become further from the main branch.

If you have a Safari Books Online account they're probably in there. I found them to be fairly easy reads, perhaps spending 2-3 weeks on each. Applying it at work, of course, has taken a lot longer.

thread

wpietriMay 2016

I was disappointed that planning methods didn't come into it. US business and civil culture has shifted heavily to very plan-oriented approaches. But there are other ways to do things.

As Mary Poppendieck explains, the Empire State Building was built on schedule and under budget in 18 months. When they started work on the bottom floors, they hadn't even finished designing the top floors. But that was fine, because they were working in a flow-oriented approach:

https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...

(It's also covered in one of her books, and I think it's "Leading Lean Software Development".)

As we know with software, big up-front design approaches can get unnecessarily long, confusing, and expensive. (See, for example, the healthcare.gov fiasco.) But we also know that approaches that optimize for cost- and time-effectiveness can work much better. (See, for example, Lean Startup methods or the healthcare.gov rescue.) We haven't really learned the lesson in software yet, so I can't blame people for not rediscovering it in other spaces yet. But I hope one day they will!

thread

wpietriSep 2013

I did not say that the Internet was not designed. But I'm glad to say that now. Specifically, it was not designed in the sense that megaprojects requiring planning and estimation are designed. My point there is that people just assume that big achievements require big plans, but that is demonstrably false.

I do agree, as a long-time reader of RFCs, that some of the protocols were designed, sort of. But if you read more deeply, you'll see that they were just as much evolved. And, that they were never imposed through a central control structure. It's no accident that the foundational documents of the Internet are all Requests For Comment. An instructional contrast is the OSI protocol suite, a top-down alternative to the Internet. Now dead, of course.

I agree that some projects can be estimated. I'm saying a lot of them shouldn't be, because there are more effective ways to get results.

You can read more about that, and about the 3M example, in Mary Poppendieck's books. I think the specific one I have in mind Leading Lean Software Development.

thread