Tackling agile dilemmas: Tales from the front line

When you’re starting something new and don’t really know much about it, like constructing an Ikea shelving unit or building a complicated and expensive agile transformation, it’s tempting to give the problem to someone else. Someone who knows what they’re doing.

The same sort of thing applies to an agile transformation programme, and the experts we use to help us.

Arriving back in NZ from Europe, where I’d spent my last day panic shopping at Ikea, I looked with fear at several boxes freshly shipped from London. Unconstructed chairs, shelves, beds, coffee tables and a dining room table.

With little hesitation I called in the experts, who bought their tools and a can-do attitude and constructed it all in an afternoon. Benefits – I hate building kitset furniture, so managed to avoid something I hate doing. Cons – next time I need to build kitset furniture, I’ll be as unskilled as I always was, with a bad attitude towards kitset furniture, and will be highly motivated to outsource the problem again.

Don’t focus on being ‘nice’ – focus on building a culture safe to debate and challenge

Picture this in your own organisation: People are assembled from across the business and sitting around in squads for the first time, excited with a touch of fear, wondering what to do. In walks the coach, exuding experience and confidence, armed with lots of useful stories to share that will help the team learn.

The first retrospective

The team holds their first retrospective. A productive conversation, with good debate and a few actions. But there’s one problem. Someone from outside the team was there. A chapter lead who will be closely involved with the team, wanting to join as she had feedback to share.

“Sorry April, but you can’t come to these retrospectives” says the coach. “Why not?” says April, feeling deflated. “Because my job is to protect the team. Retrospectives are a safe place for the team only to share openly. Having outsiders here means the team won’t feel safe to talk openly

This small piece of expert advice has quite a ripple effect on a readily influenced and eager to learn group of team members. Let’s deconstruct this.

First, the precedent is set that the team is only safe when in their own company. Safety feels good, so we’ll build higher walls and deeper moats to keep the bad guys out. This is a devastatingly bad precedent. The next time one of the team wants to speak to an executive, they hesitate. Unsafe. That team sitting next to us that we’re relying on to complete their work, so we can get our work done? Unsafe.

The second precedent set is that the team needs protecting, by the coach. The coach is their protector. Who does the team need protecting from? Management. Bureaucracy. Hierarchy. That world outside that is lost to the dark ages of scientific management. The dark overlords of governance reports and performance metrics. Those ‘non-agile’ people. This precedent is even worse. The team becomes insular from the outside world they serve.

The team forms an ‘us versus them’ mentality, spurred on by the intoxicating sniff of a non-hierarchical, fully empowered world where nobody ever disagrees with them and they never get told what to do. Inside the team, team members are invincible and are pretty sure they’re right about most things. The behavioural patterns and symptoms of Irving Janis’s ‘Groupthink’ set in. The outside world doesn’t get them, and they don’t get the outside world.

Third, the team doesn’t learn and get better. They’re basing what they learn from retrospectives on a very limited data set – their own measures, views and opinions. We’ve all experienced a time where we’ve been struggling with a problem, stuck and unable to move it. And all it takes is a random conversation with a friend, talking through the problem, to gain another perspective. Of course! That’s it – I’ll do that. It’s the same with teams stuck in a performance rut. They need outside challenge, a different angle and diversity of thought, to break out of their existing mould to get in better shape. This is hard to do with the walls built high, the moats deep and the drawbridge up.

The first sprint review

Two weeks later, the team begins their first sprint review. The dozen or so business stakeholders anticipate something new. The Product Owner launches into insights from recent user experience workshops, highlighting the enthusiasm of participants about the promise of the upcoming product. 

“Wait” says the coach. “You’re only allowed to show completed work or working software at a sprint review”. The discussion about the design workshops was cut short and the review disbanded early – there was no working software to show. No completed work.

Make crossing boundaries into other teams a core part of your team’s DNA

A valuable opportunity is missed, early in the programme, to celebrate and show the user engagement and design work underway. Design work like this, that engages end users in building what they’ll eventually get, contributes massively to the end value of the work done. It’s good news for senior managers as their people feel engaged – less grumbles later. However – on the advice of the expert – only working software is allowed! Critical design practice of sharing imperfect work-in-progress to drive early iteration and improvement  is thrown out the window, defeated by a rigid application of the agile rulebook.

This team isn’t off to the best start. They’re learning from the experts that there are all these inflexible rules that come with agile. Gradually, but surely, the team becomes accustomed to following the expert rules from ‘that official agile framework’, or ‘that scrum master training I attended’.

When a team starts following the rules and shuts out outsiders – perhaps without realising it – something very sad happens. Personal judgement switches off. Individuals squash that urge to challenge and debate how things should be done. Problems go noticed but unspoken. Teams don’t learn how to figure out how to identify and solve problems themselves.

When toxicity creeps into the team, team members wait for someone to come up with an agile rule or a process for it, rather than raising it themselves to tackle with the team. When all of this happens, we observe teams that repeatedly miss delivery expectations and can’t make the interventions needed to correct the performance curve. It’s a demotivating cycle of non-performance that started with the early injection of a culture of rule-following, blocking outsiders and an over reliance on experts.

Next time they need to build a kitset shelving unit, they’ll still have to pay an expert. What a waste.

So – ditch the rules and do what’s right

Building an attitude and culture of personal judgement over rules, of challenge and debate over following the expert, is surprisingly straight forward but takes lots of frequent, deliberate effort. Maybe paradoxically, getting a team thinking for themselves requires strong leadership. Not of the lone charismatic champion leader variety, although that can help sometimes. We mean the sort of leadership everyone can bring to the team. The sort of leadership that role models, creates and nurtures an environment that is safe to ask simple, searching questions.

Asking ‘why are we not allowed outsiders at our retrospectives, if they have feedback to offer us’ is a good display of leadership. It’s role modelling to the team that rules can be questioned. That we’re intelligent people who think about things, asking ‘why’ before blindly doing what we’re told. If the response is ‘because that’s what we did at xxx company’ or ‘because I have a certification and it’s just how it is’, then with this little bit of role modelling about questioning things, the team can enter into a clear and crisp conversation on why these answers – whilst often useful – are not satisfactory.

This type of open questioning gets the team thinking for themselves. They decide to have a guest at every second retrospective, with the purpose of inviting outside challenge and observation into the team. The external perspectives brought into the team help to break the insular thinking and gives the team a richer array of data from which to learn from. Experiencing the success of what started as a simple question – ‘Why?’ – the team learns for themselves the power of asking simple, first-principles questions.

Apply new ways of working frameworks – like agile, design thinking, continuous delivery – as flexible guides only, not rules or rigid disciplines

Asking ‘what and who are you protecting us from’ is another display of leadership. It’s a great question. If the answer is ‘from the managers who will be imposing their bureaucracy on you – they’re top-down command and control and trust me you don’t want any of that’, then the team can consider how their proactive engagement with these managers might actually help the team get better at meeting their needs and serving their customers.

Through conversation, the team might understand better why management is issuing directives, recognising an unmet need in there somewhere. Surfacing what the real needs are, the team can then band together to deliver to these with greater clarity of purpose.  Rather than creating this artificial and unsustainable barrier erected by a ‘protector’, the team has leapt over this barrier to engage with the ‘outsiders’. With this open and curious attitude, the squad are building what they’re building with a more diverse range of perspectives, and organisation-wide change starts to happen. Boundaries are being broken. Trust is being built. All from questioning a rule and asking ‘Why?’

Balance is needed

Despite the alluring ‘ditch the rules’ line, it’s not quite like that. Especially starting out, teams need structure, guidelines and expert advice. It’s essential and often well worth the investment.  Current and more so in the future, people who bring true expertise to help organisations become more agile are worth their weight in gold. The trick is though, from the start, to make challenge, questioning and debate a central part of how work gets done in the team. Kind of the opposite of a team that is ‘nice’ to each other in meetings but stays silent when a problem really needs to be raised and addressed. This level of safety and comfort to challenge needs to be woven into the cultural DNA of every team – an acceptable and expected part of daily team behaviour.

Coaches and experts in the agile world have all dealt with the sorts of scenarios described above. The best coaches (figure 2) who really ‘get’ effective coaching know that their expertise has a time and a place, but the real value they bring to a team is in establishing a mindset and culture of raising problems openly and solving these problems as a team. And yes, sometimes questioning the rules and arguing with the expert!

All of the certificates in the world don’t replace a coach who can create this sort of self-sustaining, long-lasting way of thinking about and doing things as a team. Teams who can figure out for themselves how to do what’s right, rather than blindly following the rules, will have an enormously positive impact. Combining this with teams who welcome outsiders in, inviting external viewpoints and using a wide range of information to improve what the team does and how they do it, can make for a truly powerful organisation-wide force for good.

Takeaways

• Apply new ways of working frameworks – like agile, design thinking, continuous delivery – as flexible guides only, not rules or rigid disciplines.
• Instead, based how you work and build your mindset around what’s actually needed and what will deliver to the customer demand, and what will progress your organisational culture in the right direction.
• Know that ‘agile’ does not solve all problems – sometimes you have to go back to first principles to understand the true nature of the problem, and then work with leadership and teams to identify potential solutions.
• Challenge the rules and ask ‘why’ when given expert advice – understand why you’re doing what you’re doing and match your actions to your context.
• Make crossing boundaries into other teams a core part of your team’s DNA – this will help you get closer to your users, your leadership and ultimately help you serve your customers better.
• Actively invite outsiders and external perspectives into your team – use this information to challenge your team’s status quo.
• Don’t focus on being ‘nice’ – focus on building a culture safe to debate and challenge; diversity of thought and opinion in your teams is a good thing.
• Find coaches and experts who are really good at getting the most out of your team’s ability to solve their own problems, rather than handing out all the golden answers on a silver platter – this is way more effective for your organisation and for the people in it.

Peter Johnston is a strategy, business design and transformation specialist and writes about these topics based on his personal experiences in many organisations. Having run business consulting teams across Europe, the UK and Australasia, he established and led the IBM iX consulting practice in New Zealand, and over the years has worked with Heathrow Airport, British Film Institute, ANZ Bank, Air New Zealand, Vodafone and Watercare, among others. Peter applies behavioural science and design research to help enhance the customer and workforce experience, and to help make work more meaningful and rewarding.