- People , once outside their competence, cannot judge how wrong they are ( and usually think they are right – the illusion of knowledge).
- People observing groups work, consider groups that change direction (pivot) to solve a challenge as worse performing than groups that set a clear scope and plan and stick to it (when tasks are controlled to have the same outcome and performance regardless of approach).
- If, given a multiple choice exam, you pick an answer and then have doubts and think another answer may be right – you have a better chance of being right if you change your answer rather than stick with the first answer.
- People have a strong desire to maintain consistency once committed to a direction and behavior.
These are outcomes from investigations into the psychology of behavior of individuals and groups (from work by David Dunning and Justin Kruger and others). Note the text is my paraphrasing.
When I read these insights from psychology – they opened up a lot of questions in my mind about how we work with Innovation and supporting processes like Agile and Lean startup (MVP/Build-measure-learn).
I have always been asked to think about Agile and Lean startup as models how to work with high risk projects or explore new business models ( i.e. processes for accelerating success in innovation).
They are sold as ways to create small , self-motivated teams, who can move fast and ensure the outcome is quickly adapted and changed so we get close to the real customer value as we develop the offering.
When I started to look at the psychology of behavior, this opened up some other thoughts.
Lets look at the insights above:
“People , once outside their competence, cannot judge how wrong they are (the illusion of knowledge)” .
When we start activities with high uncertainty and risk – pretty much the definition of innovation related activities – we (the team) will be operating outside our competence by definition.
From the insight, it also means we will have no idea how wrong we are – but will tend to believe we are better than we are – “Your baby is ugly” is true – and you will not know how ugly it really is.
This means, for Agile and Lean startup processes – the real aim of the process must be to ensure that the team finds out where they have no competence and do something to challenge their knowledge and competence , and then build it up competence to meet the challenge.
The psychology implies something that is obvious, but not something that we often focus on when starting up Agile / Lean startup – we have to build up our competence. Slightly different to finding the customer pain / gain, fill out the business canvas and so on.
How many of you have run innovation processes or agile projects where a team is selected because they are a “talent” team of new high fliers. Or been led down the path that what we need is “new blood” with “new mindset” to bring in innovation.
I have had the privilege of running innovation events and processes with all sorts of mix of teams. There seem to be very little common elements that drive the successful teams, but these two observations seem to hold true consistently (both are needed):
- Teams that have at least some members with strong relevant competencies in the domain in question do better (eg. compared to pure talent teams with high general competences)
- Teams that are highly reflective to outside inputs, responsive to make changes and effective in using others, do better (ie are effective at building new competences).
The psychology statement suggests that if an agile / lean startup team do not show they can respond to inputs and develop competences , then we should change people within the team. Also teams that have no basis in the problem (have no strong start point in relevant domain competences) are going to struggle and take a lot longer to get going – usually longer than a large organisation has patience for – and should change their team composition.
We forget , perhaps, a bad team is still a bad team, also in Agile or other innovation processes. Team competences, together with a learning mindset, are a critical part of this. The process does not solve this – only (hopefully) makes it more obvious earlier.
Having said that – we can also see why the process structure of Agile and Lean startup variants are powerful, from the psychology point of view.
Both demand that the team work in short cycles where they do something, test it works and demo it – then change their next actions based on observations and learning. This inherently forces teams to quickly test their ideas work and then ask external stakeholders to verify it.
External verification and fact based testing on what you have done is about the only way a team will know “how wrong they are” and if they are on track to “get it right” – and so move from the illusion of knowledge to knowledge – provided they change based on learning.
Essentially, we are , in these processes, building in a countermeasure to a human behavior for the “illusion of knowledge” that works against innovation. This, in turn, suggests why these processes have such a positive impact when applied effectively.
As an aside – we often use the word “customer” to define the group that we need to test / demo with. I think this often leads to confusion and unnecessary debates (“we can’t get the real end customer this time, but Bob will be an OK proxy”). Instead we should use the idea of the most competent “external verifier” we can access, relevant for the question or assumption being explored.
“People observing groups work, consider groups that change direction (pivot) to solve the challenge, as worse performing than groups that set a clear scope and plan and stick to it”
This one, I think, really suggests why a more formulaic process like Agile works in larger organisations as a framework and why Lean startup has great ideas that can be used to replace more rigid process elements of Agile – and not the other way round.
Stakeholders – or the people who pay for projects – really do not like a process that says we can pivot and change as we go and cannot articulate clearly where we will end.
We need to be able to change directions and pivot to overcome the bias of “how wrong we are” and yet our paymasters see this as bad performance – instead asking for things like business plans and clear targets within specific time lines.
Lean Startup thinking is the most articulate and clear on need to pivot and learn and how to manage exploration and high uncertainty – addressing the individual and team bias mentioned above – but does not provide any real crutch of reassurance for stakeholders to invest in the process and feel some element of control in their investment. This is problematic, as its always difficult to change peoples mindsets, and if we don’t provide some kind of structure that helps , then its often down to just persuasion, training and case examples of success – slow processes that are difficult to scale.
Agile , however, manages to convey a sense of direction and provides a structure that paymasters can use to help guide their behavior and helps stakeholders feel like the team is driving in a consistent direction with a plan and purpose. It then, through frequent interaction with stakeholders (eg via demos) – allows them to express concerns and be brought along a journey of the team changing directions in a manageable way (from the stakeholders point of view).
Agile says we have a project vision (clear high level direction) and through its elements like release planning, sprint structure and backlog thinking, allows teams to roughly predict ahead how long things will take without knowing exactly what will happen. If we consider the psychology insight above that observers don’t like teams that change direction, then this is a much more reassuring framework ,psychologically, for stakeholders than one that says we will pivot and change, like lean startup. This suggests that combining the Agile elements that support stakeholders with lean startup elements that are very direct in the change and learn loops could be a strong combination from a psychological viewpoint, to these different key groups.
“If, given a multiple choice exam, you pick an answer and then have doubts and think another answer may be right – you have a better chance of being right if you change your answer rather than stick with the first answer. However, in general, individuals have a strong desire to maintain consistency once committed to a direction and behavior.”
I’ll put the last two statements together. For me, this suggests, as an individual, you have a better chance if you pivot than if you don’t – but our instinct is to stay on the course we have chosen. (Its not quite the conclusion of the psychology trials – but close enough.)
Basically, at the root, we have a mindset that likes to have consistency (and stay within our comfort zone of competence). However, to really deal with innovation and uncertainty, we have to pivot and change based on external inputs and learn as we go.
This means we must train ourselves to manage our bias as individuals not to pivot and change. In this way the principles of both Agile and lean startup are again effective at providing a value set and structure that provides a countermeasure to this bias at an individual level. In particular – both strongly push the bias for fast action and learn rather than planning and analysis.
In summary these statements mean , at the heart of innovation, we have a dilemma of human behavior – we are asked to behave in ways, at the stakeholder, team and individual level, that are not our preference and we are exposed to unconscious biases that work against innovation, like thinking we have it right when we don’t.
Agile and lean startup (and the many derivatives and variants that follow a similar structure) are process frameworks that mitigate the worst elements of human behavior from a psychology point of view and as such are a strong support to innovation – indicating , perhaps, why they can be very effective.
In particular we see there are three key groups of people, who are key in innovation from a behavior viewpoint, that should be addressed by whatever process we decide to use, to help correct for natural bias against innovation. These are:
- The individual person, their competence and motivation to engage and learn
- The group or team, their motivation to exploit each others competence, engage with each other and external, share goals and jointly learn
- The stakeholders or ‘ paymasters’ and their motivation to succeed through the teams results ( typically to earn money / get a return on investment of some kind)
This means that we should be able to merge and modify elements of innovation models & processes freely, provided we retain the key elements that support the preferred behaviors we want in the three groups to support innovation.
An experiment to focus on behavior rather than any specific “process” formula – we did try such an exercise on a technology innovation project.
We kept the structure of time-boxed sprints and demos – for the stakeholders to be able to follow and feel they can effectively express their opinions and be heard. This addressed the stakeholder need for some consistent structure and address their behavior bias against test and pivot. It also provided the team and individuals with some sense of consistency and overall direction – also a key behavior need that was requested by individuals in the team.
Then we focused on using the rapid assumption / testing loops from lean startup “build – measure -learn”, where teams must ,fact-based, verify top uncertainties rapidly with external inputs and objective testing. We also challenged the team to define multiple possible “design directions” to explore in parallel. This ensured a structure to test how much we don’t know quickly, encouraged the team to exploit each others competence and reach outside for external verification as a foundation in all activities. This addressed the “illusion of knowledge” bias outside the teams competence zone and avoided the trap of following one direction too long (avoid the team and individual preference for consistency of direction). Instead driving quick learning loops. It also reassured stakeholders that progress was being made.
Finally we worked with the team for a day, to practice rapid testing loops, getting verification from external sources and then adapting the next tests based on leanings. This training – where people experienced directly and personally, within a training environment – the benefit of rapid learning loops and following multiple options, closing them down quickly – was seen as the best way to address the individual behavior biases. Feedback reflected this – after getting first learning from very rapid tests – it opened eyes how much can be gained quickly. This re-enforced in the individuals that this approach worked, giving confidence to continue in the same way.
In this way, by thinking about the basic behaviors we wanted to support, rather than any specific process, we merged ideas from several sources to get a simple process that was up and running in a few days.
Interestingly – we could not impose co-location or dedication into this project. We instead put some simple , effective virtual tools in place with a time each day the team had to be online working on the tasks.
We also dropped a number of other elements, that are considered key in different processes, but are complex to embed and train (eg strict role definition and splits like Product Owner & scrum master).
So far – it seems to work well – suggesting if we focus specifically on supporting underlying behaviors that drive innovation in the three groupings of people that are key for a project – we can go a long way with simple process structures.
(the views here are my own personal views)