5 ms·

I’ve bought the Critical Chain by E. Goldratt two weeks ago and I’ve been enjoying the anticipation of reading it. The Goal was a real eye opener and I hope tha

I’ve bought the Critical Chain by E. Goldratt two weeks ago and I’ve been enjoying the anticipation of reading it. The Goal was a real eye opener and I hope that the Critical Chain will bring me new insights on project management specifically (the Goal is a great introduction to lean methods but it is heavily geared towards manufacturing processes).

Jtsummers 8y ago
I really liked The Goal (though the family side story was a bit strained at times, the experience with his kid and scouts in a "model" environment was useful though). While it is geared towards manufacturing, I think pairing its concepts along with Mary Poppendieck's writings on Lean in software development is very helpful. A lot of her writing (especially the more introductory books) put in the effort to translate Lean Manufacturing ot Lean Software. For instance, we don't have "inventory" in the physical sense. There's very little cost in the retaining of un-shipped code. But there is cost in that we don't get value from it. And our understanding of it goes stale over time (for the individual who wrote it and the organization who "owns" it, especially if the creator leaves or moves to other projects). Pairing her work with writings from traditional Lean and Theory of Constraint sources (focused in manufacturing) is an excellent way to take those theories and apply them to our field.
- laurentl 8y ago
  Thanks for the pointer to Mary Poppendieck, I hadn’t heard of her. Which book of hers would you suggest I pick up first ?
  - Jtsummers 8y ago
    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.

Jtsummers 8y ago

I really liked The Goal (though the family side story was a bit strained at times, the experience with his kid and scouts in a "model" environment was useful though). While it is geared towards manufacturing, I think pairing its concepts along with Mary Poppendieck's writings on Lean in software development is very helpful. A lot of her writing (especially the more introductory books) put in the effort to translate Lean Manufacturing ot Lean Software. For instance, we don't have "inventory" in the physical sense. There's very little cost in the retaining of un-shipped code. But there is cost in that we don't get value from it. And our understanding of it goes stale over time (for the individual who wrote it and the organization who "owns" it, especially if the creator leaves or moves to other projects). Pairing her work with writings from traditional Lean and Theory of Constraint sources (focused in manufacturing) is an excellent way to take those theories and apply them to our field.

laurentl 8y ago
Thanks for the pointer to Mary Poppendieck, I hadn’t heard of her. Which book of hers would you suggest I pick up first ?
- Jtsummers 8y ago
  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.