It can sometimes feel like everyone’s “doing Agile” these days. Last year, for example, a Stack Overflow survey of 101,592 international software developers found 85.9 per cent of participants were using at least some Agile methods or processes. Data points like this, along with highly publicised examples of Agile’s adaptability, such as Amazon’s Scrum-less two-pizza teams, may lead many businesses to feel like everyone is transitioning to an Agile culture but them.
The reality, however, is most businesses aren’t Agile—far from it. Even out of those adopting Agile principles, few would say they’re dogmatically conforming. There’s a big difference between individual software development teams using Scrum and entire businesses operating daily using purely Agile principles. Any business disheartened by the perceived state of play needs to keep this in mind.
That said, high profile examples of Agile organisations are useful case studies for all businesses to draw inspiration from and emulate. Putting Agile principles in place is no longer theoretical, and other organisations have gained—and shared—ways to lessen difficulty. Particularly in IT, nothing drives change faster than real success stories to prove change is not insurmountable. By avoiding the common pitfalls and developing best practices from the outset, many businesses can make Agile a success—without being Amazon®.
Starting on the right foot
The now legendary Agile Manifesto, published in 2001, outlines the fundamental principles of Agile software development. For IT pros belonging to organisations not yet using Agile principles or processes, the manifesto can be a grim read. Software over documentation? Individuals and interactions over processes and tools? To those accustomed to traditional software development methods, meeting these requirements will seem a tall order.
To get started, IT pros should remember to focus on the business needs leading to Agile in the first place. Then again, IT should never focus on labour-intensive changes from technology or tools. In some ways, that’s the first test for Agile readiness—is your organisation willing adopt any change, however much it may improve software development—if it rejects the standard Waterfall model? Splitting workforces up into cross-functional teams working in independent, incremental ways is easier to say than do, or we wouldn’t re-gravitate to traditional linear approaches.
The main objection to the Waterfall Model is it’s too stagnated, siloed, and geared around a funnel prioritising IT operations ahead of end-user experience. In an Agile model, organisations are split into smaller teams focused on not only building, testing, and improving software in small “sprint” cycles, but actively tearing down intrenched processes. Most organisations start by enabling, at least some, teams to collaboratively work toward improving the end-user experience. And Agile often starts by fixing processes, systems, and user experiences that never really worked.
No mean feat
Full disclaimer: restructuring organisations in this way isn’t easy. Breaking a 100-strong team of developers into multiple small groups and having them each quickly and independently releasing specific features, might be the largest org change in a decade. Organisations are more likely to drive success by creating brand new parallel teams, led by experienced Agile technologists. Worst case, they shift work to these new teams over time, but often they build experience and good will for Agile to organically transform traditional teams. Increasingly, hiring managers are beginning to see job applicants rejecting positions in non-Agile environments. Agile is a delicious dish, once a team develops its palate.
Throughout this restructuring process, it’s particularly important to focus on individuals. The culture shift required for agile success won’t be brought about by new processes and tools alone. It requires everyone on the customer-facing side of development—product management, UX, development, and test—to change attitudes and motivations. Age-old habits are entrenched for plenty of reasons, and bias is hard to reset, even with compelling data.
Getting everyone so unreservedly on board is difficult, but essential to becoming a truly agile business. As I said, there’s a difference between individuals using Agile and businesses being agile. While a team might benefit from Agile collaboration, this is all lost when members are matrixed into tasks within different parts of the organisation continuing to rely on the traditional development model. This is one of the most common mistakes driving some teams to abandon Agile adoption.
So, how does this organisation-wide embrace of agile come about? A good place to start is with a series of focused team meetings. If ambitious IT pros and strategy leaders are planning to set their business on the agile path, then they already recognise the business value. The task, then, is to articulate these benefits to the entire organisation—faster releases, greater user focus, more independence—but in a language tailored for their challenges and expertise. Conversation, not proclamation, is an inviting way to get even the biggest Waterfall purists interested in experimenting with Agile.
The route to success
When it comes to Agile, bounded initial setbacks are normal and even encouraged. “Fail fast” is less painful when combined with limited scope, especially when it’s combined with modern test methodologies. It’s unrealistic to expect massive culture changes to be put into place without a hitch—that’s how human beings learn most effectively. The important thing is your team learns from mistakes together, which is also accelerated in a collaborative Agile environment.
It’s important to remember Agile is a journey, not a destination. The ongoing Agile process must be disciplined, persevering against the temptation to backslide. Pushing through the first few difficulties gives teams the experience to adapt Agile to fit their unique environments. Reduced friction then converts many sceptical, former waterfall-based development teams. A business knows it’s closing on its Agile transformation goals when it finds it can operate with fewer and fewer development cycle exceptions.
Perhaps that’s the most surprising outcome of adopting Agile, it’s even anti-waterfall in that its “delivery” has no calendar date. Instead, businesses realise they are more agile, with happier users and reduced delivery friction between dev. External teams are usually the first to notice Agile is paying dividends. With time, agile ways of working become the norm and efforts to maintain discipline become low. And that’s the KPI for Agile success in real environments. When you’re devoting more time and energy finally transforming your businesses rather than maintaining complex dev and release processes, you are Agile.
Patrick Hubbard, Head Geek, SolarWinds