If you Google business innovation, there’s a solid chance the world ‘agile’ will be in the top results. Whether referring generally to working quickly and with flexibility or using the Agile methodology for software development, it’s a catchphrase common to modern business.
The Agile methodology, at its core, is the ability to create and respond to change in order to succeed in an uncertain environment. According to Nick Van Weerdenburg, CEO of Toronto development firm Rangle, Agile software development is achieved through quick releases, user testing, and constant iteration in order to get market-ready products out faster.
However, a willingness to utilize Agile methodology is only half of the equation. In order to truly succeed in an Agile working environment, a business has to reorient its entire operation around Agile principles, and that requires a fundamental mindset shift.
Building an Agile mindset
Van Weerdenburg said that to build an Agile mindset, the first step is to build a culture of execution. This means building and shipping small pieces of your project constantly – pushing to be as fast as possible and to break down projects into their smallest fundamental pieces. This allows the team to see and test more elements of the product, meaning they will not only be able to quickly throw out a bad feature but also won’t waste a ton of time developing it in the first place. Building that culture within an organization is all about changing how you think.
“Get to Agile processes and continuously try to be uncomfortable in the foundational stuff.”
“If you want to get high velocity, high-performance teams, then it’s building the continuous improvement model and mindset,” he said. “Unless you make a mindset shift, you are not going to be as far along as you could be. You could also end up in a situation where the Agile process is more damaging than promising.”
Agile traditionally applies to software development, but Van Weerdenburg argued that the principles must also extend to the entire organization in order to be successful. If just the development team moves to Agile but the rest of the company doesn’t follow suit, the support functions of the organization end up becoming bottlenecks.
Van Weerdenburg referenced one example of launching software in the insurance industry.
“You need regulatory sign-off every time you do a release, and sign-offs are optimized for capacity – i.e., they have a person doing this much work per month and will give you an approval in three weeks even though the software was ready that morning,” he explained. “So apply design thinking and look at overall, end-to-end processes, re-engineering it so legal knows that when they have a request from the Agile software team, they have to approve it and let it go out.”
But legal and compliance teams often have a lot of work and can’t drop everything for a new request. “So software sends a preliminary report to compliance notifying them when the request will come in and what it’s about. Then compliance has it in their system and knows what to look for. Compliance didn’t have to reinvent itself, but it is Agile in that way.”
When Waterfall works
Even devotees of the Agile framework recognize that there are some occasions when an organization requires a traditional waterfall approach with upfront planning. This applies to situations where rapid iteration and a ‘fail fast’ mentality are not possible, such as products that require testing on humans.
In these cases, Van Weerdenburg noted that Agile may not apply to the product itself, but that doesn’t mean an organization should throw the methodology out the window. Instead, Agile comes into play in other areas, because Agile is all about providing value to stakeholders.
“Lean and Agile is about orienting how we work and generating value for key stakeholders,” said Van Weerdenburg. “From an organizational perspective, even if a group isn’t Agile, they have to support the Agile processes of other departments.”
Deploying Agile across the whole organization
Supporting Agile processes is a unique undertaking, even with the right mindset. Once an entire company is on board with becoming Agile and reorienting itself as needed, the next step is to think system level instead of job or department level.
Thinking on a system level allows for shared context, a crucial pillar for non-technical roles in an organization if they want Agile processes to be successful.
“When you optimize, you often think things like, ‘the developers don’t need to be in the design meetings’,” Van Weerdenburg said. “The design team creates designs and hands them over to development. But you underestimate the amount of information loss here – the ability for developers to ask questions.”
“You want blockers removed, and you do that by having everyone on the same page with shared context. When you have this, you see massive increases in speed.”
“You want blockers removed, and you do that by having everyone on the same page with shared context. When you have this, you see massive increases in speed.”
Once companies start removing the little hurdles like handoffs and lack of shared context, Van Weerdenburg said they’ll begin to understand what an effective team looks like within the organization. The next step is supporting that continuous improvement mindset so the company can improve the system, bit by bit, as it learns and grows.
Then, ultimately, you’ll find that you’re “doing” Agile, which Van Weerdenburg said is the only way to truly learn the methodology.
“Agile needs to be learned experientially,” he said. “Get to Agile processes and continuously try to be uncomfortable in the foundational stuff, and then you will go places you have never imagined.”
Photo via Unsplash.
