3 ms·

A perfect plan on paper theoretically guarantees a seamless process during the execution phase until you practically hit a brick wall, that's what I was trying

A perfect plan on paper theoretically guarantees a seamless process during the execution phase until you practically hit a brick wall, that's what I was trying to say. "Hire me and I'll tell you" is certainly a good point for figuring out what's enough, but what about others who want to find it out on their own?

Jtsummers 2y ago
http://www.poppendieck.com/reference.htm http://www.poppendieck.com/reference.htm - a lot of good books, don't bother reading them all. It's listed in reverse chronological order, I'd read some of the older ones first. I'd add Deming to the list, Out of the Crisis is a tragicomic read because you'll realize that we haven't learned anything as an industry since he wrote it (published in 1982). OK, so I have a lot to write on this topic but I'm going to distill it to just a few points. 1. Don't create longterm plans, period. If you do, they should be no more detailed than a sketch past the 3-12 month mark (where in that period depends on your context). And it should never be treated as a commitment, because there are too many unknowns. Even if you fall for the idiocy of BDUF for a large effort, your design will almost certainly be wrong unless you've done the work before (in which case why are you designing anything, you have a design already; no, wait, why are you building anything you have a working system). 2. If you don't know how to judge whether a plan is good or not, then create the opportunities for yourself to learn. Either read about successful and failed projects, or go participate in many projects, or go observe them. If you're in a corporate environment you should have the ability to do all three of those. 3. If you have one big project you need or really want to do, and don't have the time to broaden your experience across many other projects, then be smart. The only smart way to run a large, complex, longterm, novel (to you or industry) project is iteratively. Iterations create learning opportunities because they offer you a feedback loop. Learn from each iteration and revise your planning practices and plans as you go along. 12 month iterations mean slow feedback, so use smaller iteration cycles (1-3 months, maybe 6). You don't have to deliver a deployable product each iteration, you need to deliver something that can be learned from though. Even prototypes to solicit feedback from customers or a proof-of-concept that can determine the next steps (possibly even ruling out the approach taken in the POC) are fine. 4. Avoid large batch sizes. Don't turn in a complete rewrite of a system after 24 months of work and hope it works. Find a way to incrementally deploy or deliver the changes. One of the worst projects I worked on required 3 successive generations of the system to be running at the same time because each generation was a big-batch, BDUF project. By the time they were finished they didn't deliver features that had been added to the older systems. Oops (not oops, it was obvious it was going to happen to anyone who thought about it). Delivering smaller batches or transforming the existing system is the most reliable way to succeed on a large effort. 5. Learn the difference between "big step" and "little step" work and how to judge when each is appropriate. This can be approximated with iteration lengths. If you have a lot of unknowns, you want shorter iterations in general. This gives you more feedback earlier to guide the next steps. When you reach a point where you know the next steps, you can increase your iteration sizes and scopes. Accept the risk, though, that goes along with that. A 12-month iteration that fails means you have to potentially rollback 12 months of work. A 1-month iteration that fails, you lose 1 month of work. When is frustrating, the other is catastrophic and potentially destroying your business. In case it's not obvious, the common theme is iterate, learn, and adapt. You have to iterate to reliably succeed in novel large scale systems development. Complete plans spanning large periods of time become binding obligations because if you spend $1-10 million creating a plan, you or your paying customers will want (sunk cost fallacy coming into play) to see the plan through even when it becomes obvious it's doomed. So don't set yourself up for failure, set yourself up for success. Tight feedback loops, shorter iterations (but not too short, your judgement from experience), and adaptation to changing circumstances and the feedback from each iteration.

Jtsummers 2y ago

http://www.poppendieck.com/reference.htm http://www.poppendieck.com/reference.htm - a lot of good books, don't bother reading them all. It's listed in reverse chronological order, I'd read some of the older ones first. I'd add Deming to the list, Out of the Crisis is a tragicomic read because you'll realize that we haven't learned anything as an industry since he wrote it (published in 1982). OK, so I have a lot to write on this topic but I'm going to distill it to just a few points. 1. Don't create longterm plans, period. If you do, they should be no more detailed than a sketch past the 3-12 month mark (where in that period depends on your context). And it should never be treated as a commitment, because there are too many unknowns. Even if you fall for the idiocy of BDUF for a large effort, your design will almost certainly be wrong unless you've done the work before (in which case why are you designing anything, you have a design already; no, wait, why are you building anything you have a working system). 2. If you don't know how to judge whether a plan is good or not, then create the opportunities for yourself to learn. Either read about successful and failed projects, or go participate in many projects, or go observe them. If you're in a corporate environment you should have the ability to do all three of those. 3. If you have one big project you need or really want to do, and don't have the time to broaden your experience across many other projects, then be smart. The only smart way to run a large, complex, longterm, novel (to you or industry) project is iteratively. Iterations create learning opportunities because they offer you a feedback loop. Learn from each iteration and revise your planning practices and plans as you go along. 12 month iterations mean slow feedback, so use smaller iteration cycles (1-3 months, maybe 6). You don't have to deliver a deployable product each iteration, you need to deliver something that can be learned from though. Even prototypes to solicit feedback from customers or a proof-of-concept that can determine the next steps (possibly even ruling out the approach taken in the POC) are fine. 4. Avoid large batch sizes. Don't turn in a complete rewrite of a system after 24 months of work and hope it works. Find a way to incrementally deploy or deliver the changes. One of the worst projects I worked on required 3 successive generations of the system to be running at the same time because each generation was a big-batch, BDUF project. By the time they were finished they didn't deliver features that had been added to the older systems. Oops (not oops, it was obvious it was going to happen to anyone who thought about it). Delivering smaller batches or transforming the existing system is the most reliable way to succeed on a large effort. 5. Learn the difference between "big step" and "little step" work and how to judge when each is appropriate. This can be approximated with iteration lengths. If you have a lot of unknowns, you want shorter iterations in general. This gives you more feedback earlier to guide the next steps. When you reach a point where you know the next steps, you can increase your iteration sizes and scopes. Accept the risk, though, that goes along with that. A 12-month iteration that fails means you have to potentially rollback 12 months of work. A 1-month iteration that fails, you lose 1 month of work. When is frustrating, the other is catastrophic and potentially destroying your business. In case it's not obvious, the common theme is iterate, learn, and adapt. You have to iterate to reliably succeed in novel large scale systems development. Complete plans spanning large periods of time become binding obligations because if you spend $1-10 million creating a plan, you or your paying customers will want (sunk cost fallacy coming into play) to see the plan through even when it becomes obvious it's doomed. So don't set yourself up for failure, set yourself up for success. Tight feedback loops, shorter iterations (but not too short, your judgement from experience), and adaptation to changing circumstances and the feedback from each iteration.