Today we live in a fast-paced world where technology is changing the goal posts on an almost daily basis. Old-style enterprises are rapidly finding themselves challenged by technology-led disruptors, à la Kickstarter, Airbnb, Uber or Xero. These challengers have the benefit of being young and not weighed down by legacy infrastructure, processes and mind-sets. Like a Hamilton Jet they can navigate unexplored waters and respond quickly to market fluctuations and opportunities. They disrupt the incumbents, innovate fast, and can stay ahead as industries adapt. Meanwhile, traditional businesses have spent the past 30-plus years setting their processes in stone and honing their efficiency. Changing direction is done at the speed of a laden cruise ship and sees them left in the wake of the disruptors, unable to respond quickly and ill-equipped to embrace innovation.

Many IT departments used to be like these old organisations (some IT departments still are, but that is a tale for another day). Large and lengthy IT projects developed a reputation for being risky and prone to frequent and spectacular failure. The traditional Waterfall approach to IT projects hinged on preparing a detailed business case then executing it to the letter before testing and deploying it. This could take years, by which time needs had changed and the end users were dissatisfied by the result.

Is agile mainstream?
In the 90s a group of radical software developers and interested parties met to discuss better ways of developing software that would result in fewer project failures. What ensued was the Agile Manifesto which cemented the core tenets of developing software while avoiding project failure. Its core values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Essentially it meant lots of small projects that allowed developers to fail small but often and to fix issues as they arose. These ideas were reiterated in the landmark Chaos Report released (way back in 1995) by The Standish Group. It concluded that smaller project time frames, with delivery of software components early and often, would increase IT project success.

Since then, the now-annual report’s central thesis has continued to say that smaller projects are essentially better and, a decade later, the message is gradually getting through.

Today there are many flavours of agile development, from Extreme Programming to Scrum, Sprint, Lean and Kanban, and it is no longer considered fringe. Since agile frameworks are designed to be flexible, pinning down a specific definition deflects from the more important issue of finding the most efficient way to deliver IT projects. What truly differentiates an agile project, however, is its bite-sized projects and constant review of working code. Agile’s mini-projects, or development cycles, are usually referred to as ‘sprints’. Each sprint involves planning, design, development, testing and deployment activities and delivers functioning code to the customer for review and signoff throughout the duration of the project. Many well-known companies from Suncorp to Telstra, NAB, Jade Software and Xero now swear by its effectiveness.

Craig Beveridge, COO and general manager of Jade Software in Australia, a full-service provider of business software and technology, is responsible for solution delivery and capability using agile methodologies and works closely with big, complex clients on challenging software projects around the globe. He says that working in an agile manner allows organisations to test their ideas in the market very quickly with no surprises at the end of the project. From concept to pilot they could have something up and running within six to nine months.

“That’s really, really quick when you consider you have done your market research and your testing along the way and by the time you get to the end you are actually up and running and you’ve got customers using your product.” It sounds like common sense, but many large organisations are yet to embrace an agile workstyle.

Can large organisations be agile?
The inherent flexibility that has made agile frameworks so successful can also be their undoing when it comes applying them to enterprise environments which thrive on clear structures and processes. Adam Boas, advisor to the Agile Australia conference and delivery lead at Australia’s REA Group, which uses agile development frameworks extensively, says that new adopters are typically looking for some clear instruction on what to do and instead get advice on how to approach things and some useful tools.

“It’s been a bit of a disappointment for some companies that have attempted to adopt agile frameworks and agile thinking because most mature agile frameworks refuse to tell you what to do,” he says. Indeed, they encourage you to pick and choose the tools that are most useful to you and most mature agile companies use a mixture of techniques cherry picked from the various agile frameworks.

Not only do larger organisations struggle with the flexibility of agile frameworks, they can also find it difficult to deal with the lack of hard deadlines and a responsive project management approach. Boas says that the introduction of Scrum, which draws heavily on PRINCE2 project management principles, helped to put some structure around agile in terms that traditional businesses are more comfortable with. In particular it helped to dispel the perception that agile frameworks lack accountability.

Scrum has been a very popular agile process within enterprises, but Boas says the more mature organisations often move past that and adopt the principles of Lean, which have more of a focus on just-in-time feature delivery. Even so, he finds it frustrating that many companies start to see a better outcome using PRINCE and Scrum and then don’t take it further.

“There’s a common failure mode where they cease to question whether they can get more, so they often get frozen in that early phase of agile adoption and confuse that with having completed the journey.”

Flexible organisations
The core concepts of agility are not only relevant for IT projects but are transferable across any type of work and any line of business. Although big business has spent the last three decades solidifying its processes with a focus on efficiency, the rise of digital business models is driving a change revolution. Gartner analyst Michael Warrilow said at a recent Gartner Predicts 2015 briefing, that by 2017, 70 percent of successful digital business models will rely on deliberately unstable processes designed to shift as customer needs shift. This will require an agile and responsive workforce that is empowered to make decisions and is held accountable for those decisions.

Beveridge, who uses agile frameworks throughout Jade, says, “I think it’s quite easy to implement agile teams in verticals within an organisation. The greater challenge is to get an agile project which is cross-disciplinary, especially once you start bringing in partners or externals. In my view it’s that organisation agility that needs to step up next.”

And it is a challenge. You can have very good pockets of agility within a business but the more fingers you get in the pie the more difficult it becomes to remain agile. “I believe the key to a successful agile organisation is to focus on the overall process or project that you are trying to deliver and introduce agility at the executive level all the way down. Then you look at how you apply those agile principles to all those processes regardless of how big or small they are,” he says.

Xero is another organisation that has brought agility into its entire organisation, not just its product development teams. Jolene Enoka, who heads up Xero’s online marketing, spoke at the AgileNZ 2014 conference about how the marketing team has taken on the principles of agile. Eighteen months ago Xero had one centralised global marketing team of 20 based in Wellington. It was frequently a bottleneck to progress and at one point had 300 projects in its work cue. “We knew we needed to change so we took a few cues from what was going on in the product development side of the business,” says Enoka, who admits that agile was completely foreign to her at the time but now feels like common sense.

They chose to introduce what they call the ‘pod system’ (similar to a Scrum team) which already operated in the product development side of the business. Each pod is cross-functional, co-located and autonomous, made up of all the skill sets that are needed for a marketing project. Xero established eight pods around the world and de-centralised the newly named ‘global marketing services team’ in Wellington into another six pods. Focus was one of the key outcomes from the change as staff suddenly had a sense of purpose and knew what they needed to work on, which was both empowering and sped up the pace of delivery.

Enoka says that the real risk with de-centralising the team was that there would be an alignment issue and the different pods would start to pull in different directions, but a common purpose, regular communication both within the pod and back to the wider marketing team and trust that the pods could operate autonomously and effectively were the answer.

As for specific agile philosophies that have found their way into marketing, Enoka says that the team has stopped looking for a silver bullet or big bang solution, working on a succession of small improvements and projects that incrementally contribute towards overall success. Iteration and frequent testing in a live setting to gauge customer priorities have become the new mindset.

This idea of breaking big problems into small problems is core to agile operations, says Boas. So are transparency, accountability and stakeholder trust – every day team members are called on to report on the progress of the tasks they are responsible for (and everyone is responsible for something). The Kanban storyboard is a good tool that helps teams and companies to visualise throughout REA. The HR department, for example has a storyboard for hiring people, so you can see what is going on in the team at a glance.

Innovation teams
If you want to inject agility into an organisation without changing everyone, Beveridge suggests using specific innovation teams.

“These teams implicitly have the authority or permission to take an idea and research and test it quickly. If the idea works it can then move it into a more mature execution within the main business,” he says.

These sorts of innovation programmes are naturally well-supported by the executive committee and, if their projects are set in the context of the long-term business strategy they can also be a good way of introducing innovation to the wider organisation. A ‘mid-point’ team made up of people from the main business can sit between the innovation team and the business-as-usual teams to make the link between the forward thinking and the company’s day-to-day operations.

Beveridge adds that “an evolution rather than a revolution type approach” to system development is a more effective means of changing the backend of the business in today’s budgetary environment.

He says another really important aspect of using agile project frameworks is that they help organisations to build a proper and successful capability model to help them face and even take advantage of the disruption that digital technologies bring to industries.

Over the horizon
Beveridge has one word of warning however. He says that you don’t want to lose what he calls “the vision over the horizon”.

“Agile projects are by nature focused on what the next outcome is, so you don’t want to lose your long-range planning and strategy,” he says. One way to manage this is to ensure that the people working on the project don’t only understand the tactical needs of the day but also how they fit into the two to three year strategy for the company.

• For innovation projects where the outcome is to identify new products, services or processes that may disrupt the market or build a competitive advantage, our teams draw heavily on the tenets of design thinking and often use design studio methodology to quickly establish a very solid design that gets a huge amount of input at the beginning of the project. We’ve literally iterated dozens of variants in a couple of days using this method. One of the major benefits of these agile design approaches is that they allow you to take the business stakeholders on a journey very quickly that allows them to test all their ideas and distill them down to those that matter most – this insight might not come out until much later in a waterfall project.
• To develop digital solutions that allow businesses to inform, engage and transact with consumers we use Scrum most often. It lets a team start delivering software almost immediately and it allows us to respond instantly to market and user testing. Scrum can help you get the very best value-for-money in terms of features and functionality, in a fixed time frame.
• Before development begins we make heavy use of all sorts of rapid prototypes to validate scope and requirements and this can range from paper sketches to clickable wire-frames or even throw-away applications.
• To manage an ongoing programme of work and the associated work-flow we will use Kanban boards which allow us to quickly identify bottlenecks in work and ‘swarm’ to get things moving again.

…