Im thinking it would help me if I took one day a week to put my “project manager” hat on and divy up tasks for the coming week into story points, and then kept the hat off the rest of the week to keep time based goals out of my way.
Does anyone with some experience scheduling their own time using tips in the talk have any suggestions?
It's a great reference for project management, but not very math heavy.
More math-oriented I'd say:
- "How to Measure Anything," although not specific to project management
- "The Principles of Product Development Flow." Think of "product" in this context as anything you want made that is unique (not made made repetitively in a factory). E.g., software. There's some queueing theory in there. And although the math isn't always presented, you will get more out of it if you can figure out or understand the math behind the principles
This is extremely powerful in non-trivial scenarios where you have a properly resourced & cost loaded schedule with logical constraints.
Avery was the lead engineer for Google Fiber's home wifi devices, building, managing, and monitoring the whole fleet in customers' homes. ... Before that, he started startups including one that deployed Lotus Domino in 10 minutes, and one that did unspeakable things to Microsoft Access databases.
Microsoft Access, Lotus Domino, and consumer Wifi (mass-deployed!)? Shoot me, please, three times.
On the other hand, they are a great way to learn the challenges of project scheduling and management. (In fairness, Lotus I mostly know by reputation, but the other two are enough.)
And some additional comments on the evolution of wireless networks in my talk from Battlemesh last year:
One part that made the problem more tractable was that we both ran the network and made the devices. This almost never happens. It means we could optimize the devices for quality and supportability instead of making the usual consumer device tradeoffs (is it pretty enough? cheap enough? glitzy enough?).
So the argument to over-estimate or sand bag, and fold in better solutions with the boy scout principle seems to me the best way to make a brown field site green again.
I’ve had one experience of this which totally worked. Time to implement features went from weeks to hours. I’m currently trying to apply the same method again with mixed results
During the conversion phase from relative sizes to absolute sizes (which should be based on historical measurements, not aspirations), you can choose to add a bit of extra time so that people can work carefully and fix things rather than feel rushed. That's often a very good idea.
What is interesting to me is that nobody puts these people actively at the top of the projects. It's more like they grow to these positions naturally. But now that they are there, you can't really apply the logic from the presentation to convince them. Insted you might even give them the impression that they don't apply enough pressure yet because you are criticising their job.