By Roan Bester

One of the fundamental principles of the Agile methodology is a sense of togetherness in business, regardless of role, so why do some organisations still struggle to come to grips with the Agile mindset?

It’s not uncommon to hear it said that software developers ‘think differently’ to other disciplines, but then it’s not that hard to find common ground either. As a developer, I’ve had my fair share of frustrations encountering this disconnect, so let’s explore some of the reasons why I think it’s so, and also how Agile may provide the fix.

As developers, we’re trained to think in an Agile way from the start. The nature of our work is to think about both the big picture and sweat the details. We need to understand the business needs before we can translate them into software.

To do our work effectively we need to be in touch with developments on the forefront of technology, and, therefore, learn to learn really quickly. This isn’t always easy, which partly explains why developers sometimes have that perplexed look on their faces – they’re still digesting the morning’s “new knowledge” while working on the afternoon’s project. Don’t mistake that look for absence, because that knowledge is already being used to impart value on the work of the day. Thinking fast and ‘out-the-box’ is akin to living on the edge, albeit in the relative safety of an office environment. We learn quickly, but that also fuels our passion for well-written code, new toys and cool UI.

Of course, that drive to learn and adapt on-the-fly comes at a cost: structure, meetings, lots of Excel spreadsheets or thick requirements docs are not really our thing. The developer's Agile is to adapt often, learn and deliver quickly and embrace the chaos.

From a developer’s perspective, on the opposite side of the room, with a degree in financial planning, banking or an MBA, sits the executive trained in an industry and practices that have been refined and stabilised over decades. Efficiency, creating order from chaos, and the planning and tooling that goes with it is a staple. Executives learn to play by the rules, and while the rules may change from time to time, management is a fairly stable, predictable practice.

Executives, we developers assume, thrive on order; they hold meetings, create plans, host roadshows, create documentation explaining everything, and spend time tweaking financial plans and business strategies. They use software every day, but in a linear way, and if something breaks, the focus is given to the issue until it’s fixed.

As developers struggle with order, so executives may struggle with chaos; shooting from the hip, with minimal planning, and ignoring the details until the very end of the process is not a typical management practice. Similarly, time-frames for outcomes are typically different for developers versus management teams. Delivery of a “go to market” product requires a different timeframe to “good enough proto-type to elicit feedback”.

At this point, you might be thinking it’s a bridge too far between the two worlds, but in reality, we’ve shown countless times that getting to grips with the Agile mindset is really just a matter of tweaking the frame of reference for both camps. Perhaps even more importantly, it is about eliminating the “Us” and “Them” and becoming a team that leverages the strengths of the diversity in the team.

Agile favours individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. It’s about collaboration and teamwork, trust, accountability and a ‘fail fast-learn fast-deliver fast’ mentality. Fortunately, Agile itself has the tools both camps can use to cross the divide. SCRUM, for example, helps developers create order out of the chaos that is software development. It also helps executives to plan and understand (by virtue of visual elements like the board, burn-down and demos) where they're at in the project and get a better grip on what they'll get. Another Agile framework, SAFe, gives upper management easier access to the workings of Agile in the business as a whole.

Of course, no tool or framework makes any difference if there is not trust within the team, or if accountability isn't given where it should be and collaboration is still a once-a-quarter meeting. What’s really needed in any forward-thinking Agile organisation is bold leadership. Find me a leader today that doesn’t subscribe to these virtues and we are likely looking at someone still stuck in the past. It’s not about saying to your developers or executives: “do what they do and get on with it.” It’s about demonstrating how the common goal is to transform and succeed, as a team.

Each discipline (technical and management), with its own strengths and limitations, is a vital resource for the other. Executives frame the business need in pragmatic deliverables, and developers serve the business need with rapid-fire solutions. Get the balance right and you’re well on the way to success through Agile practices with which everyone can come to grips.