Ever wonder why there’s the saying “hindsight is 20/20”- it’s because psychologists have proven our bias towards thinking outcomes must have turned out the way they did and we are convinced we knew it all along .
So what’s the problem?
Because of this bias we may not be learning from our fumbles and that’s a shame. See here:
The hindsight bias is our tendency towards thinking that things must have turned out the way they actually have. The hindsight bias can be a problem when it stops us learning from our mistakes. If the entrepreneurs knew how biased their estimates of success were, would they have done things differently? … how will they learn to consider alternatives? – Jeremy Dean, @PsyBlog
What’s the solution?
Honestly look at our judgements and provide/think of alternative ways things could have turned out. I think Daily Scrums and Retrospectives help Agile teams see how differently things could done if teams were not wrapped up in hindsight BLINDness.
What do you think? Is hindsight always 20/20 as the saying goes?
Do you think hindsight bias is always unproductive and negative? How do Agile teams guard against bias? Is it just “per unusual” in creating product and we who design and create just have to get on with it?
Great blog post from Knowledge BLOG: “What’s wrong with the project approach to software development?” It got me thinking and comparing project management vs. Agile practices.
Projects are work defined as activities and tasks. There’s a start and an identified end.
OK – but factor in complexity, time to do it, size of the team and available (estimated) budget and the wheels come off.
- Project stalls or overruns.
- Agile methods fix this (Strategy Meeting).
ProjMgt Best Practice
Do not begin a project until all goals are well defined and agreed upon. Seriously, who has a crystal ball to share? Let’s break this thing up.
- Success measures, length of time for “agreed upon?” – further out, the less agreement.
- Agile methods fix this (Release Planning, Iteration Planning, Iteration Review).
In a recent straw poll, 40% of product professionals selected “Managing scope /requirements change” as the most important topic for their career. Seems serious…
- Agile methods fix this (Iteration Review, Daily Stand-up, Continuous Adaptive Planning).
Managing Expectations Both Sides of the Aisle
Clear communication between development teams and the business suits (I’m a suit), big #FAIL!
- Mention: Culture clash between “stakeholders’ involvement” and “productive collaboration to build product.”
- Agile methods fix this (Product Owner, Scrum Team).
Continuity, Lessons Learned
Projects are temporary in nature. Teams who work projects are assigned and then reassigned as the projects live/die.
- What about continuity, flow, innovation? I think missing. You lose what you’ve learned.
- Agile methods fix this (Scrum Team, Retrospective Meeting).
Knock It Out
“Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?” – pg_rule, Knowledge BLOG, January 11, 2011.
I think it’s about covered – using any Agile method provides the foundation for collaboration between product visionaries (sometimes suits), development teams and stakeholders to build products that customers want and buy.