The Agile Organisation: Are You Ready for Revolution?

Big promises are attractive. And they don’t get much bigger than those offered for organisations that can succeed in making themselves ‘Agile’.

Improved flow (including possible cost reductions), faster reaction to changing market conditions or competitors, happier customers, more engaged employees, reduced waste…

Agile is great! Let’s have more of it!

The theory is simple. Agile teams in software development have seen major improvements. Now imagine if these improvements could be amplified by extending the concepts behind Agile to the whole organisation.

Part of the attraction is that Agile has produced proven results – at least with individual teams. The various Agile methods are not really engineering ones, and so while code quality does often improve, this tends to be a by-product of other improvements in management.

According to the Version One State of Agile survey in 2013, benefits noticed and felt by teams using Agile methods included: an improved ability to manage priorities; increased productivity; improved project visibility, and faster time to market. An impressive 86% of respondents felt that team morale had improved.

With such figures, it’s unsurprising that organisations have asked themselves if they can adopt the new working methods. It’s become a hot topic – sometimes referred to as Agile at Scale, sometimes as an Agile Enterprise. The idea is to reap benefits around decision-making, speed of response and improved morale more widely.

Stumbling blocks

The most self-aware organisations have not only looked to the benefits, they have also considered the failings. The same survey reported that when Agile projects had failed, 33% of the failings were connected to broader cultural issues – either of pressure to follow waterfall or problems with communication and company philosophy. The big barriers to further Agile adoption – whether by other teams or more broadly in the organisation – were identified as: inability to influence or inspire change in the organisation’s culture; senior management, and workers.

It has led to an agile development department sandwiched between traditional processes in the rest of the organisation. Such blocks have led to an Agile development department sandwiched between traditional processes in the rest of the organisation. Dave West of Forrester coined the term "Water-Scrum-Fall". This type of top-down control, demanding up-front work and contractual estimates adds back in the extra time and expense that Agile hoped to remove.

Of course, this very awareness of existing issues with culture acts as a spur to improve. Organisations consider the potential benefits, observe existing stumbling blocks, and decide to start a transformation process to ‘make the enterprise Agile’.

When in doubt, just add process

Part of the popularity of Scrum is that to some it sounds like a recipe. Gather the ingredients, mix together, and – le voila! – every sprint a freshly baked cake will result.

Of course, those who really practice Scrum will tell you that it is more than a series of process steps. A 15-minute stand-up is an expression of Scrum’s pillars of transparency, inspection and adaptation. If you want to hold a regular meeting while lying down and occasionally the 15 minutes stretches into a major 2-hour planning session, then you will not be struck down by the wrath of the Scrum gods.

OK, so I’m teasing – but the fact is that people like process. Process can be followed. It can be laid out clearly and understood. And if it goes wrong, it can be blamed. The real truth is that what transparency, inspection and adaptation ask of us is hard. Few of us can are good at honestly and openly inspecting our work, our assumptions and our behaviour. We struggle to seek real feedback and then make genuine adaptations in the face of it. We only learn to do so over time, with practice and by being part of a culture and team, which supports and strives towards that aim.

Anyone who has been in an Agile team can tell you stories about people who follow the letter but not the spirit of Agile. While it’s true that positive behaviours can lead to a virtuous circle that eventually changes mindset, it’s equally true that a team can normally carry only one or two such people, before the effort breaks down.

If this is the case with a small team, imagine how much harder it is for a whole company, where the existing structure actively discourages transparency, inspection and adaptation. But rather than grasping the cultural nettle, organisations often wade into trying to create the structures that they hope will lead to good behaviours.

Picking the wrong structures

The Agile Manifesto tried to suggest underlying aims and messages about collaboration and communication, valuing individuals and interactions over processes and tools.

And yet, as soon as it comes to thinking about Agile at scale or for the enterprise, organisations plunge headfirst into processes and tools. Rather than trying to foster collaboration, the organisation creates specialist roles, meetings and events to mandate it. Rather than considering what transparency really means, the organisation creates a set cadence for releasing, approvals and the meetings which drive them.

And since this process is complicated and its introduction hard, an entire mini-industry has grown up specialising in ‘Agile at scale’. They offer frameworks, diagrams, processes and – of course – consulting.

Structures such as SAFe (Scaled Agile Framework) are perfectly well thought out as far as they go. But they do not deliver organisational change. They are essentially optimisation tools for water-scrum-fall. They enable the traditional elements of a business to coordinate more effectively with Agile development teams. This shaves some time off the decision-making and approvals process and regulates a few activities. It also pays heavily, however, by requiring formal coordination roles, from ‘Release train engineer’ and ‘System architect’ all the way up to ‘Portfolio Program Managers’ etc.

A rose by any other name would smell as sweet, and a Portfolio Program Manager smells as sweet or otherwise as any senior business stakeholder ever has. This is not an Agile organisation. It’s a traditional organisation that has become slightly more efficient at working with a few semi-Agile development teams.

And there’s nothing wrong with this. As Diana Larsen points out in her article “Agile Fluency” on the Agile Maturity Model, team and organisational culture is driven by the business need. She labels differing culture shifts from one star to four star, and insists that the investment levels, trade-offs and choices should be considered depending on what you want.

So do we really want an Agile Org?

It is worth returning to this point in some detail. The benefits described earlier sound a little glib. Faster. Better morale. Improved visibility. Fewer projects failing. Yes, yes. All sounds lovely.

And now organisations have to ask themselves if they really want these benefits, because achieving them is not simply a question of adding process and handing out new job titles. Even though such a ‘transformation’ is rarely cheap or painless, it does not deliver real change. Managers are still managers. A hierarchy still exists. Policies regarding pay, benefits, bonuses and appraisals continue. Ultimate control for budgets, strategy and the profit and loss remain with the same people. And all of these policies and structures work against true agility. They block autonomy; they inhibit creativity; they encourage short-term thinking and conflict; they increase waste and bureaucracy.

Changing all this is a much more radical proposition. A radical restructure can see job losses and changes. The organisation may gain, but some individuals will lose - often those at the higher levels of the hierarchy. For this reason, many organisations only choose this route when there is a burning, obvious need. Niels Pfaeling describes a Brazilian packaging company where waste seemed endemic. Poor performance was seriously threatening the company’s future and so the company felt a genuine urgency to make radical changes. "Change or die!" is a good strapline, but for most companies the moment for radical action is rarely signposted so clearly.

Occasionally change occurs because a powerful leader with a strong vision institutes it. In 1970, Jan Wallander became CEO at Handelsbanken. The bank had previously suffered from severe criticism in the press after various irregularities. Wallander had a vision for instilling principles and values in the bank’s DNA – he led a radical decentralisation programme, underpinned by profit-sharing among employees. Today Handelsbanken is unique in the financial sector for keeping power and decision-making at branch level, not central HQ.

What are the drivers?

On the left are the negative drivers – problems so severe that an organisation is prepared to take on almost any pain to change them. On the right are the positive drivers – the possibilities or end states that are so desirable, that a company is prepared to risk change and pain to achieve them.

The Radical Re-structure

Making an enterprise Agile requires a radical restructuring – one that grasps the cultural nettle and faces up to the problems inherent in a hierarchical organisation that is functionally divided.

For many, this feels extreme. But the radical pattern was inherent in Agile methods from the beginning. Scrum asks for a Product Owner who is responsible for the product’s profit and loss, for example. This offers the team high autonomy over decisions – should they chase a new opportunity; should they incur extra costs to launch early; is it time to cut all investment in an idea?

In reality, very few Scrum teams really work in this way. Product Owners are often relatively junior and the profit and loss remains firmly in the hands of others in the organisation, severely limiting the genuine decision-making autonomy of the team and often slowing them down. Another common compromise is made over cross-functionality. A team may claim to be fully cross-functional – but the definition of cross-functional only covers technical design, development and testing. Broader aspects of design, including the marketing and financial feasibility of the product are excluded, as are support functions, including hiring and accounting.

An Agile enterprise needs to rethink this model and look back to the original intention of autonomous teams interacting with customers to deliver value, faster.

A Network Structure

The model most commonly put forward is that of a network in which the enterprise restructures itself as a series of autonomous teams – sometimes referred to as business units or cells. Driven by customer or market requirements, each externally focused cell is responsible for its own profit and loss performance.

Such cells act as mini start-ups or businesses in their own right. They design, build and deliver products or services directly to customers. They make sales and market products, manage their accounts and resource needs. On occasions they may need specialist resources held within the organisation – legal, HR, PR or even capital investment. They can buy services in at cost from the relevant support cell or ask for extra investment and take on the additional cost just as a start-up might do with a bank loan. These services allow the organisation to make the kinds of economies of scale associated with having an internal legal expert or an accountant, for example, whose services might be required by several teams.

The cells require generalists. The kind of people Don Reinertsen described as ‘T-shaped’, individuals with one deep expertise and a breadth of general skills. It also means that cells are built around the talents of those you have – who may have to give up previously held positions of authority in order to become functioning team members. Others will become members of support teams offering services to the front-line cells.

The organisation now grows in reaction to demand. When a cell grows in response to increased demand, the decision is taken on whether to split it into two new cells. When a resource is called sufficient times from many different cells that the capacity is stretched, another specialist support might be added, or individual cells might consider bringing those skills within the team.

What else do you need?

An Agile Enterprise is supported by several practices that encourage and reinforce the structural changes. These are connected to how we treat and motivate people - especially as regards pay and bonuses. Pay related to targets and performance often creates unintended consequences as individuals manipulate the system for short term advantage. Strategies to counter this include giving everyone fixed salaries, with any additional rewards dependent upon market performance, or part ownership schemes around profit-sharing.

Agile enterprises need to be clear that they are focusing on rewarding interdependency, interactions and the systems, not individualism. Which is not to say that there can’t be pay differentials – depending on market rates, as well as the number of roles and responsibilities a person takes on. As Pflaeleg says: pay the person, not the position.

There are often further practices which support the cells’ full autonomy. Transparency is key – whether of how resources are allocated or where to look for help. Building and maintaining the networks between cells becomes an important task in itself – a part of a culture of openness and flexibility.

Maintaining a company’s culture is a shared responsibility. Different organisations have different methods and put emphasis on different aspects of this as part of their values. For Valve, ‘nothing is more important than recruitment’. For Spotify, great attention is paid to structures that encourage co-ordination and formalise some network paths. For Handelsbanken, decentralisation means being closer to the customer, and so the company works constantly to decrease central power, to move functions out to the regional units.

Conclusion

Becoming a truly Agile Organisation is a more revolutionary step than many companies are prepared for.

There is nothing wrong with not wanting to be an Agile Organisation – with trying to make a centralised system as efficient as possible; with attempting to align nested goals and objectives for projects and people, and taking steps towards increasing autonomy.

But this is not truly Agile, any more than a development team encased in Water-Scrum-Fall is. The hybrid path may feel safer and incremental change seem easier, but it will not offer the enormous leap in creativity, responsiveness and growth that an ‘Agile Enterprise’ promises.

For those convinced that the platform they’re standing on is sinking, or with their eyes fixed on land on the horizon, there is nothing for it but to take the plunge.

The Agile Organisation is one of the key ideas to be discussed at Spark the Change - a conference running in London 3-4th July helping to build better, happier businesses. For more information visit this website.

About the Author

Helen Walton is co-founder of Gamevy, a tech start-up bringing gameshows online and who recently launched their first game on Facebook – Blackjack Attack. As a company, they are employee-owned with no bosses and a democratic decision-making structure. She began her career working in marketing for Unilever before specialising in branding and copywriting for clients ranging from publishers to supermarkets. Helen has written 18 books for Value Flow Quality – the Agile Practitioner Course approved by the BCS. She has written numerous articles for different magazines and events, including InfoQ, but also on subjects as diverse as make-up in the Mail on Sunday and Henry Moore’s sculptures for Tate Britain. Helen is one of the organisers of the Spark the Change event which runs in London, 3-4 July. It aims to transform the whole business, not just a part – allowing us to build more successful businesses, become better leaders and create happy workplaces. Speakers include Tim Harford, Jurgen Appelo and Simon Baker, while companies involved include Unilever, change.org and PropellerNet.