Berkun reading group discussion
MakingThingsHappen
>
Chapter 2: Discussion and Questions
date
newest »
newest »
message 1:
by
Scott
(last edited Mar 09, 2015 11:32AM)
(new)
Mar 09, 2015 11:32AM
Mod
reply
|
flag
Thought #1 (p. 24): When I started this chapter, my immediate reaction was, "Schedules? zzzzz...can we start on a more boring topic?" Aaaand perhaps I'd just identified my biggest source of project problems: not focusing on the schedule enough! Actually I *have* given a lot of thought to schedules, specifically deadlines, in the past. And my conclusion has been: "run away from committing to them whenever possible." Ha, of course, that's not always possible because the business has to coordinate deliverables with other parts of itself, but I do think PMs and teams should push back when there's not enough info to deliver an accurate estimate - or at least be super clear about the low confidence levels in any estimates provided. The chapter did a great job of covering this.
I think the single best take-away from the chapter in this vein is Figure 3-2 on p. 32. Showing this to project sponsors is the easiest way to demonstrate how low confidence in the schedule should be early on.
Thought #2: One of my favorite personal sayings is "technology won't solve people problems." Like most maxims its a broad, sweeping generalization, of course (yes, tech has solved, or at least improved, many "human problems" but not ones that involve complex human dynamics). However the essential point is one carried over from Chapter 1: people over tools/methodologies. And thanks to DeMarco's quote (p. 27) and Scott's recommendation in the Chap 1 discussion, I now have a new book (Peopleware) on my reading list. Looking forward to it.
Thought #3: Rule of Thirds (p. 27) - Going off lesson #2 from Ch. 1's history lessons (the simpler your view of what you do, the more power and focus you will have), it is so helpful to think of any project as (simply) three phases, even if they are a repeated cycle during the project's lifespan:
1. Design
2. Implementation
3. Testing
Thought #4: "Projects are zero sum game" (p.28). I almost wish this would've been covered in its own section (not chap) because, for me, this is the essential power of schedules.
Thought #5: Ask the questions on p. 37 (common oversights) for the next schedule you see.
Loved a chapter that I thought I was going to dread. Nice work, Scott!
Mod
"If everyone can agree that the schedule is a set of probabilities, the problem isn't in the schedule itself - it's in how the schedule is used"
This was often the primary mistake I'd see teams make - they took schedules as a kind of gospel and never questioned them enough - the schedule is supposed to help the project, it's not a sacred cow.
The title of this chapter "The truth about Schedules" made me cringe. It's so hard trying to get accurate timelines or estimates from anyone. I still try to avoid conversations about schedules and work break down structures. The key takeaways for me in this chapter were the following:1. There is no magic formula or science for creating perfect schedules. Good enough schedule is OK
2. The schedule is a set of probabilities. By thinking of the schedule as a set of probabilities, I'm able to change my perspective and attitude. The example of completing task 1 is 80% and completing task 2 is 80% resulting in a probability of 64% resonated with me. It's a concrete example that's now stuck in my head.
3. The questions you should ask to catch schedule problems early on are excellent. My favorite question was "Did team leaders add more feature requests than they helped eliminate?"
4. The snowball effect list (Figure 2-4) is a great way of communicating what went wrong and highlights that the schedule is a set of probabilities. I plan to use that in my retrospectives
5. Figure 2-3 on the range of estimation errors is excellent. It's a great way of showing that estimates become reasonable at the implementation stage.
Mod
After reading Making Things Happen, I was primed to fall in love with the online scheduling tool Liquid Planner (liquidplanner.com). It uses ranged estimation on every task in the schedule! Thus, you can share a schedule that says we have a 50% chance of making this date, but only a 10% chance of meeting this early date.The danger in scheduling is when we spend more time on the schedule than we do on the work. Don't over-invest in the schedule, especially in a high uncertainty project.
Scott wrote: "That kind of thinking of trying to use real data from real work to drive predictions is exactly what's missing from all the old school, PMI, big-project, type estimation thinking that's still popular in the software and general project world. "I agree Scott. The beauty of agile (SCRUM) is that it provides a framework for you to try experiments from what you have learned from the previous iteration or sprint. My favorite estimation tool is the burn down chart. They reveal the strategy being used, show the progress made against predictions, and open the door to discussions about how best to proceed, including the difficult discussions about whether to cut scope or extend the schedule. The goal of a burn-down chart is to act as an early-warning system, warning the team that there are unidentified blockers or hidden process problems where actual delivery is being skewed away from the original estimate beyond what might be considered reasonable deviation. Like any other tool, I've seen this abused by many teams new to SCRUM.
Mod
I think this chapter holds up very well and like the stated 3 purposes for schedules:1) make commitments about when things will be done
2) force people to see each individual piece as being part of a whole
3) track progress and break the work into manageable chunks
From experience I have also noticed that it can be a big red flag when a leader is obsessed over the process. I've yet to see those types of leaders deliver good results unfortunately.
Ravi wrote: " Given what you know about Agile/Scrum did this chapter hold up well for you? "Yes, Scott the core ideas held up well. One of the things that you do well is to highlight individuals and interactions over process and tools. Also, responding to change over following a plan.
I'm posting the bullet about estimates being probabilities at work.
And I posted too fast. I enjoyed the whole chapter. It held up well too! I actually like that this was the second chapter. Schedules are one of the first things blamed when things go wrong. It's always good to remember all the things that can go wrong and how to help them go right.
I want to start out by saying how much I enjoy and appreciate the simplified terminology and writing style of this book, it takes a lot of PM topics and actually makes it interesting and digestible to read, and I feel like people that aren’t project managers can easily grasp the basic concepts. Well done!There are a lot of good takeaways in this chapter. Always looking for ways to improve estimates, I really like the tip about including a baseline confidence level of the estimates, and of course to be “optimistic in vision and skeptical in the schedule.”
This book, so far at least, seems to be written for software development teams, but I’m curious about how to apply some of these techniques to an agency model. For example, I completely agree with the concept that schedule estimation grows in accuracy over time, but do you have any tips on how to sell that to a client? In my experience, schedules are one of the first things the client wants to see, even before discussing all of the requirements. I’d love to sell them on the idea that we can provide a rough estimate now, and refine it as we get to design and integration phases, but it often seems that we get locked into the original estimate that we’ve pitched, and hard deadlines or set budgets don’t give us much room to adjust throughout the projects. Do you have any recommendations for how to kick off a project and set expectations that we'll want a chance to refine estimates?
Stumbled on an article that relates to chapter 2 - https://medium.com/backchannel/estima...- discusses validity of #noestimates 'movement' and references some great case studies.
Although I have had this described "yak-shaving" feeling with some estimation tasks I still agree that estimating/scheduling done (somewhat) right yields useful information beyond deadlines.
Mod
The three functions of scheduling are spot on. However, one pitfall or misuse of schedules, is lack of schedule transparency, especially across departments or even organizations. When a schedule is set externally, it's often treated as divine and constant, which may lead to compromised feature scope or quality as teams scramble to meet deadlines. This is perfectly acceptable if schedules have good justification, but not so much if they're set arbitrarily (someone in some back office decided on some due date so as to not conflict with a vacation). If the reason(s) for a schedule are properly conveyed along with the schedule itself, it may give implementation teams a better sense of priority and wiggle room to question and push back on schedules.
I am coming back late to the party but just wanted to say: 1) this is still a great chapter and I liked how estimation anxiety is addressed :) I have to request tons of estimates to people as part of my job and I want them to know that I feel their pain. Also "the real schedule risks are the things not written down"
2) I did not know of the expression "shaving the yak" and I am going to use it every time I can :)
