Eight Reasons Going Agile Might Slow You Down

For the first four decades of its existence, National Public Radio (NPR) developed new programs in a process that hinged on long production times, splashy launches and multi-million-dollar budgets. It could take years – and a substantial investment -- to realize that a new offering was a programmatic failure.

That all changed when NPR brought agile software development approaches into the network, embracing the philosophy that products should be released early and iterated often. It began adapting existing shows or broadcasting them live, focusing on pilot runs rather than permanent offerings. It began tapping into its passionate fan base for feedback on each program, making it something of a permanent public beta.

Within a few years, those agile practices were on firm footing in the organization, with programming costs down 66 percent as a result. When Landor released its first Global Agile Brand Study in late 2015, NPR ranked No. 5 most agile company in the United States, ahead of tech giants Google, Apple and Microsoft.

NPR is among the growing number of non-tech teams and organizations that have found that borrowing from agile methods can help increase collaboration, reduce time-to-market, better satisfy customers and enable teams to respond to constantly changing market conditions. It can help large organizations pivot as quickly as the newest startup.

Implementing agile methods is hard, particularly when it involves a non-tech company with a long history of command-and-control leadership and third-party tech integrations – they rarely have the skillsets in place to deliver large projects incrementally. As a result, these non-tech organizations often find themselves falling victim to one of eight common mistakes:

1.  Not anticipating a major cultural impact

The adoption of agile methods, even for just an IT department within a larger, non-tech organization, requires a cultural shift and infrastructure changes across the entire organization. There’s an inherent tension between the agile philosophy, which involves frequent code pushes and releases, and that of the traditional organization, whose executives prefer to minimize updates to the technologies running their businesses in order to keep the code base stable. Departments need to communicate and prepare both their own teams and the business itself for the cultural transition.

2.  Not including the business early enough in the process

Ideally, an IT division will include business leadership from start to finish during deployment and implementation of agile strategies. The earlier developers identify what is driving value for the organization, the better agile works.

3.  Stripping product owners of their power

Product owners must be dedicated, have decision rights and possess in-depth knowledge of the issues and feature requirements. They need to understand the technology and business needs and share a product vision. The best ones are an integrated part of the agile team and are able to define and prioritize their needs and relay information effectively to both sides.

4.  Not using retrospectives to change future behavior

A key part of agile is the retrospective, or lessons-learned meeting. It allows stakeholders to constantly refine the process and product. Many organizational cultures, however, fail to create a safe space for people to discuss working relationships and admit mistakes. Without regularly scheduled retrospectives that facilitate continuous improvement, these mainstays of the agile process can turn into blame-fests with that fail to deliver actionable results.

5.  Being WAGILE

Organizations frequently go through the motions of applying agile without actually changing what they’re doing, or they slip from agile back into the waterfall methods to which they are more accustomed.

6.  Focusing (and deciding) on agile tools at the beginning of a project

One of the agile approach’s main strengths is its ability to change midcourse, and that includes the agile tools themselves. The waterfall model of mapping out a project and selecting the tools in advance doesn’t fit. Teams should pick the option that best fits their needs, knowing that those needs likely won’t be obvious until they’ve started working together.

7.  Micromanagement by the scrum master

The key to a scrum master success’ lies in his or her ability to mentor and motivate a team to work well together and deliver high-quality results. The scrum master is there to facilitate and keep the team accountable – he or she is not a manager. An agile project requires a high level of trust in the delivery team.

8.  Assuming that agile is a magic bullet

Becoming agile does not change the complexity, budget and resource constraints, or team skills required by a project. Unrealistic expectations will doom its implementation.

Bringing an agile mindset to a non-tech industry is tough, but it doesn’t have to be an insurmountable challenge. Awareness of these eight common mistakes can help any organization realize faster, cheaper, higher quality development and establish a continuous learning environment fueled by the core principles of agility.