In this blog series, Heidi Araya, an agile Transformation Leader and creator of the Four Facets of agility, unpacks the roadblockers inherent with agile transition and explains how our Four Facets of agility help organisations to reframe their thinking. She’s already deep-dived into the first two facets – complexity thinking, and people and leadership. Here, she explores the third essential aspect to successful transformation: technical and cultural practices.
At first glance, technical and cultural practices might feel like two disparate ideas awkwardly bumping up alongside each other. What does technology have to do with workplace culture? The answer is everything. Of course delivering valuable software requires good engineering, but that can’t exist in isolation – it depends on cultural practices that allow it to thrive.
Meanwhile, culture can’t exist without people. So you might have thought this would fall under the facet of people and leadership, explored in my previous blog. But while that aspect covers the evolution of an agile mindset, this is about making a cultural sea change through technology adoption and team behaviour – people can’t embrace agile if their actions are stifled by the organisation itself.
The cultural conundrum
Some good examples of this are Test-Driven Development (TDD), where coding, testing, and design are tightly interwoven; pair programming, where two programrs share a single workstation; and writing user stories. These are all technical practices, but for them to succeed, a cultural shift is required. If speed is prioritized over quality, why would a programr spend time on TDD? If they’re rewarded for finishing tickets individually, why bother pairing up with someone else? And if people aren’t at the centre of the coding conversation, why write a user story in the first place?
Some of agile’s most fundamental technical practices run contrary to the way many people have worked for years and might feel counterintuitive. Take Extreme Programming (XP) with its core list of interconnected practices, including collective code ownership, regular refactoring, and pair programming. XP sees software development as a team sport relying on face-to-face discussion and constant feedback. It challenges the siloed thinking of traditional development, recognising that if the whole team works in collaboration on something, it will be done faster and better than if it’s left to a lone wolf.
Radical thinking and ignorant leadership
Makes sense, right? But not to everyone. Some leaders find this thinking radical. In fact, a VP once told me that if they allowed a tester to pair upfront with a developer (something called pair testing), the developer would find a way to sneakily code around the tester on purpose. In fact, in that same company, we discovered that pair-tested stories had a much lower defect rate than those that were not pair-tested.
We can blame ignorance to an extent. Sometimes leadership just doesn’t know that teams should be doing these practices. But where they do recognise the benefits, more often than not, they assume programrs ‘learn on the job’. I have rarely seen that to be true, especially in environments where there’s immense pressure to deliver. If organisations don’t view software development holistically and aid staff to understand these new practices and why they are helpful to increasing quality and speed of delivery, their people will fall back on the familiar and fail to realise their true potential.
Go team!
Many technical practices relate specifically to teamwork. At Adaptavist, we incorporate ‘team science’ into our thinking. Espoused by the likes of Richard Hackman, Patrick Lencioni, and Amy Edmondson, and organisations like Google, this centres on the idea that a great team will always outperform a group of random people working on the same project without a team approach. Surprisingly, this is brand-new information to some organisations, who choose project-based teams and priority-focused reorganisations to dictate how people work together.
But naming it doesn’t make it so: it’s not enough to gather a group, call them a team, and leave them to figure it out on their own. People need to learn how to operate in an emerging ecosystem built on complex situations and multiple interactions. Beyond this, they need to understand the factors that make their teams effective: clarity of mission and purpose, boundaries, conflict management, and diversity of thought.
Without team science in play, there are no guarantees people will allow diverse thinking to flourish, handle conflict appropriately, or even be able to make healthy decisions. Our appreciation for organisational culture and scientific approach to team strategy and implementation help our clients determine how effectively existing teams work together, and whether the conditions are in place to help them succeed.
Time to change your mindset?
Getting to grips with new technical practices and cultural change can be tricky. But it’s vital to incorporate this thinking if your agile transformation has any hope of succeeding. And you don’t have to go it alone. Adaptavist’s experts are here to help. Sign up to learn more about agile transformation today.
About the author
Heidi partners with leaders and companies to help solve agile, organisation design and strategy execution challenges. A specialist in digital transformation with over 20 years experience, Heidi is no stranger to leading agile transformations in a wide range of global and distributed companies. Always bringing a pragmatic approach to her work, she collaborates with businesses to create more responsive, effective, and resilient teams with engaged employees. Her passion? Helping organisations harness the creativity and innovation of their people.
