Dr. Julia Oberhofer
Between 2011 and 2018 I conducted research in various companies that were integrating design thinking into their process landscape.
I realized that several conflicts seemed to appear again and again – in large and in small companies. This happened in a company that develops software as well as in a company that builds machine components.
Design thinking is an interesting example of an agile approach. Teams are agile because they run a process of exploring user needs and building prototypes for new solutions in small iterations.
The concept of design thinking allows teams to act and respond to many signals – from customers, but also from within the team and corporate stakeholders. Ideas are being expressed in rudimentary sketches in order to quickly receive feedback and go from there.
This way, teams learn fast by making decisions and immediately experiencing their effects; a quality found in various agile approaches – and often coined experience-based learning.
My dissertation mainly focused on team members’ and project managers’ individual experiences. But the research data also revealed a procedural perspective on what happens when companies incorporate an agile team approach such as design thinking into a process landscape that is less agile and somewhat/largely linear in design: conflicts arise. And these conflicts have a major impact on project managers.
Project managers are close enough to teams to feel the heat of agile teamwork – they see the daily uncertainties and excitement when teams are on the lookout for hidden insights about their customers. But project managers also receive direct responses from upper management that expects results on time and in budget. Not only that, but upper management also expects details on a project’s progress and its direct impact on strategic goals.
As it turns out, agile teamwork in general – and design thinking in particular – does not reveal itself as an easy-to-handle-approach. And project managers are often the first ones inside a company that truly understand the implications of agile teamwork in otherwise non-agile organizations.
Design thinking is typically embedded as a teamwork approach for open-ended projects.
That way teams begin with an open-ended project briefing that marks a topic of interest for the company, for example:
“re-design the way we support our customers during their taxation process.”
The project briefing captures market research, as well as existing solutions, but it does not imply the outcome of the project.
Teams begin by exploring user needs. They typically meet customers and users of existing solutions for interviews and observations in which a process takes place, for example the process of taxation.
Based on their observations teams try to make sense of what is happening that they see as wrong or imperfect. They then imagine new and better solutions, typically in the form of low-fidelity prototypes. This way, they can quickly show their ideas to customers and receive further feedback on their needs. If customers and users seem to be happy about these new ideas, the team can wrap up their findings in a now validated solution – that is still a prototypical version of a solution.
The agile quality in design thinking reveals itself in what is called “Feedback Loop 1” (FL1) , as shown in the illustration above.
Every prototype is designed to be tested and evaluated by potential customers and users. Much of the feedback typically implies that a team has not yet found a satisfying concept of a new solution. Therefore the team is forced to go back to exploring the underlying needs and design a better solution next time.
A lot of team discussions arise: Do we just have to change our idea, or did we completely misunderstand the underlying problem? Is our customer happy enough with our newest prototype or should we even try to come up with a better version – and what would that look like? A team faces quite a complex decision-making process when entering Feedback Loop 1.
In some cases, teams enter a Feedback Loop 2 (FL2), which is even more challenging. Here, they discuss whether the actual project topic is still valid when looking at their customers’ feedback. For example a team may realize that the existing taxation process is not covered perfectly but well enough so that any new effort to come up with a new solution would be hard to justify
However, these loops turn out to be even more challenging from a procedural standpoint. As it turns out, we cannot know how long it will take for a team to be able to move from one loop to another — sometimes a single interview can reveal everything a team needs to know.
In a project on speech recognition, a team member realized after only one interview with a blind person, what the biggest usability flaw in the existing solution seemed to be. In other projects, teams would talk to more than 30 different customers and stakeholders and would still not be able to prioritize their ideas.
Every project manager that would try to set milestones along the project – simply to measure progress – felt strongly irritated by the fact that it seems hardly plannable when their teams would arrive at results that would justify another loop.
This is what I coined the milestone dilemma. It is a dilemma because the conflict could not be avoided by simply working harder or smarter. In many cases, it was simply not plannable if and when results would create enough certainty for a team to move on.
Another major challenge arose when teams arrived at project deadlines but their project results were still ambiguous. Teams would then ask themselves various questions: why don’t we have the “right” or good-enough solution yet? What does good enough actually mean in a set up that is open-ended by design? What if we just need one more loop – just a bit more time?
For project managers these discussions in the latter half of the project felt uncomfortable. There were often good reasons to believe that another loop would increase the overall results but there was no certainty to that. Also, it was not clear whether time has already been wasted since the team may never find a good-enough solution.
At that time, neither project managers nor team members could pinpoint a result that would justify when the project should naturally come to an end. The exit was never defined from a content-perspective but was planned based on the scope of the initial project briefing. At that point, the project briefing may already have become obsolete due to various loops but the final date was still valid.
Project managers sometimes tried to persuade upper management to buy more time and resources for their team so that more loops could happen. Unfortunately, their standpoint was uncomfortable as they could not promise to deliver “good enough” results within just a few more days or weeks. In most cases a lot of open questions remained and project managers would have to stop projects for the sake of scheduled development projects.
That means design thinking teams were expected to deliver a validated concept for a solution on time so that a product owner and agile development teams could translate the solution into a product backlog and iteratively develop product increments for the market.
Furthermore, some agile development teams would begin with a concept for a new solution and would find out that results from the design thinking process are rather imperfect and need to be re-negotiated during the development process – this intent is represented by “Feedback Loop 3” (FL3) in the above illustration.
In most cases where these discussions appeared, teams would have not been able to clarify open questions with the former design thinking team. These teams were not accessible because they were already engaged in other projects.
Again, project managers would have to either fight for their teams or for the corporate strategic vision.
This is the situation I coined the strategy dilemma. If they fought for their teams’ novel outcomes, they indirectly questioned previous decisions being made by strategic management, for example how strategic problems have been prioritized and options for projects have been defined (see illustration below).
In none of the companies I observed were project managers in a good position to discuss highly interesting yet strategically irrelevant project outcomes with upper managers. These results would often indicate the previously made strategic decisions may be less valid than expected.
As project managers pointed out, a truly agile company would allow for a “Feedback Loop 4” (FL4) in which operational outcomes from innovation projects would constantly inform the overall strategic process. However none of the companies has established a formalized feedback loop of that kind. The overall process and the handover from strategy to innovation remains a one-way-street. In consequence, the agile team experience suffered – in most cases internally in team discussions and invisible for strategic management.
Project managers were the first to realize the effects of a rather non-agile process landscape on the actual agile teamwork.
They faced situations that turned out to be dilemmas as no decision could have solved the conflict for all sides.
Dilemmas like these show that the mere idea of agility touches topics outside the actual agile teamwork. Organizational interdependencies can have a direct influence on what is happening at the operational level of agile teamwork. However, it is mainly project managers who seem to realize the situations, as they are in between all chairs.
Project managers are therefore the ones we need to primarily involve in discussions about designing agile companies in the future.