User Tools

Site Tools


Recommended Videos

Systems Thinking

Second Generation Lean Product Development Flow by Don Reinertsen.

As usual a very “dense” pitch with a lot of information. If you want to understand impacts of things like queuing theory, lean, and why variability should be preserved for new product development (hint: Black Scholes option pricing model) then this is the video for you. See My notes for more information.

Estimating and Planning

10 Reasons Estimation and Planning Fails and What to Do About It by Troy Magennis.

Great pitch. Love the basics here. Main message is “a lot of bad things happen in projects which increase utilization into the 'non-linear' (when lead-time graphed over utilization - above 80% utilization leads to exponential lead time) zone and so make estimating useless and forecasting difficult.”

Key learnings include:

  • If you are in the non-linear region of utilization for your project (i.e. greater than 80% utilization) then estimation will always fail.
  • Sometimes you need just enough information to decide what not to do, and perhaps toss a coin for remaining options (if they really are close enough).
  • If we only have a high utilization system and we cannot change this, then estimating using points etc doesn't make sense. For high utilization systems we need to track system level impediments to the flow.
  • Top 10 list (portfolio level): (BTW why this project won't finish on time is because of last project - and no amount of estimating is going to help)
    • Don't start on time. Eg delay in previous project
    • No team (no one to do the work).
    • Partial team. Eg on prior project. Half strength team → over utilization
    • Partial body substitution. Similar to above.
    • Missing skills sets. Variation on a theme. Are we producing useful stuff. Look busy but don't know whether we are making progress. See “capability matrix” based on level of capability - novice and learner (but will to learn), do / maintain and so able to modify (and make small additions), teacher / creator (able to do work and show others). Help actively develop your T-shaped people.
    • Over-stated parallel effectiveness. Adding teams / people to make it faster does not scale linearly. Limited by whatever serial processes you have in place. Variation on Amdahl's but applied to people. Spend 8x the effort but only 3x additional capability. Need to invest in independents and tools (eg continuous deployment)
    • Dependency and friction. Tracing through how work was actually done. How many levels of dependency. 1.5X the Sprint length is the fastest you could move through the system (as sometimes it doesn't get delivered in the Sprint expected.) Need to understand the dependencies you have. Every dependency you can remove from your delivery stream doodles your chances of delivering on time. This could mean, for example, having merged larger teams to reduce the number of dependencies.
    • Carried over defects and debt.
    • Ship stoppers. There are always these. If you ask the question “if I double the team would this help”. Often answer is “no”. Tried to find these out early eg by surveys every week “would you ship this tomorrow …”
    • Splitting. Rate the we finish items and the rate that we arrive are never the same, because we split. We need to take into account that we are splitting items as we do work.
  • Use these “assumptions” to understand whether the project is on track. Don't really need status reports if these assumptions are not met.

Individuals and Teams

Dan Pink's TED Talk by Dan Pink.

Or if you want the more fun presentation then use Drive: The Surprising Truth About Motivation. Helps you understand how we motivate knowledge workers:

  • Mastery
  • Autonomy
  • Purpose

And the use of money / bonuses etc - to take the issue of money “off the table.”

/home/hpsamios/ · Last modified: 2020/06/02 14:22 (external edit)