How going agile helped us doubledown and avoid the planning fallacy & groupthink
Imagine its 1990, West and East Germany are doing the unthinkable: reunification is good and well on its way. To bring the city together, there is talk of a single, unified airport for both Berlins. Sixteen years later, building begins and a prospective opening date for fall 2011 is set.
Then its postponed for June 2012.
But four weeks before opening, major safety structures are discovered to be faulty. Then the opening is postponed for summer 2013, then early 2014. By 2014, its projected that the opening will be in 2017. As the original budget surpassed by €5 billion and companies file bankruptcy due to the delays, weeks pass and the Berliners and Germans alike become habituated to the never-ending public works blunder known as the BER airport.
By 2018, we’ve come to believe this airport will never open and likely will involve demolishing the never-used terminal (there are rumours that there are no light-switches, that the roof is 2x too heavy for the structure and that the planner was just a student — some of this is likely untrue but fun for those of us annoyed by this failure in near perfect “German Engineering”).
This digression sounds like some fun tidbits for your next cocktail party. But it highlights a very real problem: projects almost never go as planned.
And Berlin is not alone: just google “planning delay” from your own city and you are likely to find a similar example.
This highlights the very unsurprising conclusion that despite extensive experience with project planning, things often don’t go as planned.
Projects start off with a group of highly talented and optimistic people but budgets run over inevitably and timelines are extended.
For the Employee Experience team (within HR) that I was part of inside a European tech company, a recent example was the launch a large program to onboard new hires. Originally planned to be finished the first phase in two months, after month five and we were still ironing out the final details — don’t ask about the budget either.
That got me to thinking: Is it possible to prevent these delays from happening in the future?
Over the last nine months, my experience integrating an agile project management flow in the HR departments of two different organisations has convinced me that the answer to getting more things done on budget and in time is by re-imagining operational functions like HR in an agile light.
More recently, it dawned on me that many of the tenets of agile are validated by decades of scientific research coming out of the field of cognitive psychology and behavioural economics.
Quick wins were a plenty
The reason the agile method has been so readily adopted in development teams is the flexibility and adaptability to changing needs it offers. Because the agile method is not linear, it boasts quicker completion times as products are released earlier (in a less finalized form called an MVP) to allow for earlier testing and iteration more often.
As an HR team, the system brought our team a number of quick wins:
- Greater responsibility and ownership as tasks are visible to all in a team (writing down tasks in a public space triggers greater commitment to completion)
- Because the tasks that are pulled into the Kanban board are chosen by the project lead, prioritization is centralized for the team therefore ensuring that the team moves in one direction collectively, instead of fractured need-to-do-this-now side projects
- It encourages greater collaboration in the team because in theory anyone can pick up a task to help bring the project along
What’s key however, is that the agile method allows us to become more predictive of project completion. How can this be?
The connection between group cognition and Transport for London
Before I was introduced to agile, I was first introduced to a formerly-government run department out of the UK called the Behavioural Insights Team (BIT), otherwise known as the “Nudge Unit.”
It was created by David Cameron’s former government to investigate how science could better inform public policy. They have been so successful at integrating science into public policy, that similar nudge units have popped up all around the world. Recently, the BIT was contracted to investigate project management of London’s transport authority and how time and costs could be better managed and estimated.
The BIT’s in-depth analysis of London’s transport authority found that project management teams suffered from a variety of cognitive biases, that are exacerbated in group settings (they found evidence of four biases but I will cover just two):
- Planning Fallacy
- Groupthink
This is interesting because conventional knowledge suggest that benefit of teamwork is greater creativity and hence alternative ideas.
This case highlights the finite power of the brain even when many minds are brought together (Note: collective work is not always ineffective). Undergraduate psychology courses teach that on an individual level, humans rely on heuristics (mental shortcuts) to overcome our finite resources and these shortcuts result in cognitive biases.
For those managing projects both big and small, understanding how cognitive and decision making is influenced by these mental shortcuts provides a better understanding of what can go wrong when estimating time, budget and success of a potential project.
Before reading ahead about how behavioural science and agile overlap, I recommend trying this 1 minute puzzle problem to test your own fallibility to bias.
Being optimistic isn’t bad. Is it?
In the examples above about the BER airport disaster, we can see (in hindsight and as external viewers) that project managers seem to be unreasonably optimistic if delays are now what citizens come to expect as part of regular city works projects.
That introduces us to the first bias in the list. The Planning Fallacy describes this exact phenomenon whereby people tend to overestimate their likelihood of success.
Daniel Kahneman, a nobel prize winner in economics, described in his 2012 book Thinking Fast and Slow, how this bias introduces unrealistic forecasting hinging on best-case scenarios.
Why does this happen?
It’s a matter of perspective-taking. When planning a new project, there is a strong tendency to take an “inside” perspective to our abilities: to focus on what makes up a project (internally) rather than looking at the external factors that will influence the delivery of the project tasks.
“People rarely take into account their own past experiences with similar tasks, instead focussing on the future expected outcomes…[they] anchor future outcomes on plans and available scenarios of success, rather than past results which leads to overly optimistic predictions” (BIT, 2017).
This more often than not leads to a failure to consider and identify the “unknown unknowns.”
a. The remedy for being (overly) optimistic: Feedback
As you likely guessed, taking an outside view is recommended to overcome this oversight. This involves the referencing of past similar completed projects to form a baseline for completion times and budget. A word of caution here: this may seem super obvious, but as research finds, people often ignore this information entirely when planning. In the case of the BER airport, by 2016 it was apparent that the originally planned capacity for the new airport was 6 million short of the current capacity of Berlin’s two existing airports.
This leads us to the first recommendation that is mirrored in agile project management: “Well-designed feedback” as the BIT puts it.
It’s as simple as ensuring that failures are openly discussed and dissected, frequently.
Agile implementation: The Agile Manifesto lists twelve principles. One of these is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Feedback is therefore an integral aspect of an agile team. Regular standup meetings happen weekly or more frequently and allow teammates to share progress and and to follow up on potential roadblocks.
In the same light, “retrospectives” are bigger review sessions, like a built in “breather” for the team.
b. The remedy for being (overly) optimistic: Keeping score
Unsurprisingly, data is another way to avoid making the planning fallacy. By keeping score on past performance, costs and timing, better estimates for future projects can be gleaned. Keeping score not only informs a team consciously of their realistic performance. The way feedback is provided can also also activate unconscious biases in a positive way: The Behavioural Economics Team of Australia found that providing feedback to doctors on how they compared to other doctors on the rate of antibiotics they prescribed led to a 12.3% reduction in overall prescriptions.
Agile implementation: Luckily, data collection is a built-in feature of agile management tools like Jira and Asana. Both allow a team to track the rate is of task/issue completion in one sprint or week, depending on the format of your project.
c. The remedy for being (overly) optimistic: Pre- and post-mortems
The BIT report mentioned above recommends something called a “pre-mortem” developed by the researcher Gary Klein. The concept is very similar to the retrospective but a pre-mortem is held during the onset of project planning.
A pre-mortem involves bringing all stakeholders in to imagine that the project has failed. Stakeholders are asked to consider and ideate reasons why the project has failed. Afterwards the different stories are shared and used to help inform others about the problems they may not have considered (thereby considering the “outside factors”).
Pre-mortems are so effective that they “can improve a person’s ability to correctly identify reasons for future outcomes by 30 percent” — this also can help overcome group think — what we will cover next.
Agile implementation: During the planning phase of a sprint/project, the way projects are broken down into small parts helps the planner consider details in a more refined way. While not standard practice in agile management as far as I have found, Atlassian nonetheless provides a useful guide to holding pre-mortems here (in some instances its called a “Futurespective”). Such a session can easily be integrated into the early stages of planning.
d. The remedy for being (overly) optimistic: breaking a project down
The BIT also quoted more recent research into something called the Segmentation Effect as justification for setting aside time at the onset of a project to think about the individual tasks in involved. Research from Forsyth and Burt (2008) found that when people were asked to estimate the time needed to complete a large task vs. the task broken down into smaller tasks, they estimated less time for the single large tasks then they did for the sum of its component tasks.
Agile implementation: Itemizing actions and tasks is a key aspect of the agile method, particularly in the sprint method. The planning phase of an agile team can take many forms but usually the team members will all sit together and estimate and vote on the size of component tasks. This makes it easier for the project manager to plan a sprint based on estimates from those who are actually doing the work and based on the historical tasks completion rates.
Groupthink
The second bias to consider comes from a psychologist by the name of Irving Janis. He coined the term “Groupthink” in the 1970s after studying military and governmental failures like Pearl Harbor or the Bay of Pigs.
Groupthink refers to the peculiarity when a team’s output is less than the sum of its parts. Group dynamics and the influence of a few can disable the normal process of discussion, questioning and finally agreement in a way where conformity towards one view prevails instead of a full appraisal of all options.
What ends up happening is that groups cover common knowledge: what they all know instead of questioning what people do not know.
a. Avoiding groupthink: Playing devil’s advocate
As we have learned, taking an outside view is harder than it seems. Therefore, an easy way to do this is not to do it at all.
Instead, assign someone in the team to role play as the Devil’s Advocate.
The Devil’s Advocate was recommended by the BIT for London’s transportation group to integrate into early team discussions and planning sessions. It’s as simple as asking one person in the project team (or someone from outside) to role play as a competitor trying to find faults with the planning and to challenge any decisions.
The practice is backed by research: people do not underestimate others’ time to complete a task, rather only overestimate their own abilities.
Agile implementation: If you work with company-wide dashboards, many teams can observe different boards. By integrating project completion into a dashboard, this invites fresh eyes and constructive feedback. However a devil’s advocate is not standard practice. To add it, simply assign someone during the planning phase of meetings or design sprints who is in charge of finding flaws in plans and question escalation of commitment.
b. Avoiding groupthink: Being mindful of group dynamics
Another way to prevent groupthink is through minor changes to the way a group discusses ideas.
Irving Janis recommended that leaders speak last. Even flat hierarchies can display problems of following the leader.
Alternatively, try to bring the outside in. Like the Devil’s Advocate, the BIT recommends bringing in people who are not invested in the project as a sober second thought during planning.
Agile implementation: One of the twelve agile principles is to take a hands-off approach to management: “Give them [team members] the environment and support they need, and trust them to get the job done.” Furthermore the collaboration of business people and developers (since the agile manifesto was originally intended for software developers) hints also at the value of bringing the outside in.
c. Avoiding groupthink: Pre-commitment and second chances
The problem with groupthink starts with the group. Therefore one way to overcome this is to bypass the group altogether, or at least in the beginning.
The BIT recommends asking team members to consider the task or project before the first meeting in a maneuver called “pre-commitment.” Therefore people consider the issues and potential solutions on their own before they can be influenced by the group.
In the same line, after the initial planning meeting is held, offer a second chance: at a subsequent planning session, begin the session by allowing all team members to voice any reservations that they may have developed over the period from discussion to the second meeting.
Agile implementation: In terms of groupthink, the agile method encourages frequent team collaboration thereby making it susceptible to the biases of group dynamics. However, when planning a tasks, agile encourages individual brainstorming before ideas are shared in the group: The JIRA backlog function acts as a low-commitment store for ideas that can be finalised later (therefore a build-in second chance feature). Furthermore, because issues are not automatically assigned to employees, it gives the chance for each member to individually consider the best way to achieve it on their own time.
Summary
Project management is susceptible to cognitive biases because cognition is bound by limited time and mental resources. This bounded cognition also applies to collective power of groups. This means that planning for a project often is overly optimistic in timespan and allotted budget.
A recent report out of the UK’s behavioural Insights Team (BIT) on more accurate project management corroborates the formative behavioural science research from the 1970s on the Planning Fallacy conducted by Kahneman and Tversky and the work of Irving Janis on Groupthink. This BIT report proposes validated recommendations for project managers to overcome cognitive biases in project planning and delivery.
This is one of many recent reports and examples of applied behavioural science in governmental agencies, policy, banking institutions and consultancies. The way smaller teams can use these insights can seem less clear to those without an advanced degree in psychology or economics.
However, if you are planning to go agile or are already, you are likely already taking advantage of the benefits of behavioural science. The agile method is (indirectly) backed by multiple peer-reviewed and validated theories from the study of cognitive biases such as the Planning Fallacy or Groupthink on decision making:
1. Well-designed feedback: Meet with the team often and make it deliberate. Share the good and bad of a project’s tasks and progress.
2. Keep score: Integrate data-based tracking of task completions to use for future project planning.
3. Pre- and post-mortems: At the project onset ask the team to imagine themselves in the future and that the project has failed. Ideate on how and why this happened. At the project wrap up, review what actually happened and what was and was not expected but happened. Keep note and use for future planning.
4. Break down project to-dos into tasks that take between 30 min to 3
days: Extra effort and time spent planning how project sub-tasks can be broken down into itemized issues that take more than 30 min to complete but no longer than 3 days helps better estimate time required.
5. Assign a Devil’s Advocate: Offset groupthink by asking someone to play the contrarian. This is most effective when the person actually holds these views or their counterarguments are believable.
6. Be mindful of group dynamics: Make a habit of leaders speaking last and try to bring in people with no investment in a project to question decisions and prevent groupthink.
7. Pre-commit but offer a second-chance: Before the details of the how and when are decided, allow team members to consider the project on their own time. Later allow for open discussion in a group. It’s even better if ideation can be done anonymously. In the same line, after the initial meeting provide a follow up where people can voice and second guesses.
So did an agile approach really help us overcome many cognitive biases that hinder on-time and on-budget project management? Well I hope I made it clear that overcome is a bit optimistic.
But, knowledge is half the power and with that any team can be better informed on what might go wrong and how we can avoid this through careful planning and feedback.
P.s. Links to non-electronic sources cited above:
Duhigg, C. (2016). Smarter Faster Better: The Secrets of Being Productive in Life and Business. New York: Random House.
Kahneman, D. (2011). Thinking Fast and Slow. New York: Farrar, Straus and Giroux
Janis, I. (1972). Victims of Groupthink. New York: Houghton Mifflin.
