Five Common Pitfalls When Organizations Neglect Agile Values

Agile software development means different things to different people. As it has erupted over the software landscape, agile’s core philosophy often has gone by the wayside as organizations hurry to implement cherry-picked practices in the name of pragmatism.

Toyota’s success with lean manufacturing happened only because the company painstakingly engulfed itself in the philosophy. Since the 1990s American car manufacturers have attempted to mimic these lean practices without embracing the philosophy, only to fail in their endeavors. In much the same way, I see software organizations attempting to implement agile practices piecemeal while ignoring the philosophical underpinnings that may actually suggest dramatically different practices, given an organization’s situational specifics.

When organizations neglect agile development values and principles, they fall prey to five common pitfalls. By avoiding them, companies can better realize the true benefits of agile: high productivity, great software quality, and happy customers.

1. Modifying stock agile frameworks before the organization has thoroughly absorbed an agile philosophy

Scrum and similar frameworks provide a “boxed” set of practices firmly rooted in agile philosophy, and they do not have redundant parts; everything is required for success. These frameworks are designed to be morphed based on organizational need, but not until the organization has a solid grasp of why every piece is in place. The most common mistakes organizations make when adopting agile is tampering with these frameworks before truly understanding the implications.

I’ve witnessed this particular antipattern happen at nearly all organizations adopting agile, but one situation sticks out like a sore thumb. A popular travel portal implementing Scrum and agile had a strong emphasis on user experience (UX) and established a silo of UX specialists. Rather than forming cross-functional teams, the company kept its UX silo in place and pipelined work from the silo to “implementation” teams. Not surprisingly, this structure perpetuated an “us versus them” mentality and severely hindered the completion of potentially shippable product increments each iteration. The organization abandoned its Scrum initiative some months later.

2. Scaling up before there is success

Agile emphasizes small teams working highly collaboratively. Large organizations are often in a hurry to scale agile because they don’t see value at a small scale. This is entirely practical, but what most organizations miss is that agile is a tremendous paradigm shift that takes time to sink in throughout an organization. Scaling too quickly often means the organization at large isn’t ready for the implications of agile and isn’t prepared to cope with the changes it brings. As a result, organizations scale up without a model for success.

One organization I worked with had trouble changing the engineering and product management culture due to a legacy engineering environment. The product had a legacy code base, and the team had many associated engineering challenges to sort out before they could operate in an agile manner. Steps were made toward addressing the underlying challenges for refactoring and environment upgrades. But at one point, management got impatient and forced the rollout of agile across the division before even a single team experienced success. The result was disastrous: Teams were being asked to conform to a fast-changing agile plan without an agile culture or even the possibility of implementing supporting agile engineering practices such as continuous integration and test-oriented development.

3. Reliance on cliché agile practices for success

Just because you stand up together every day and write stories on a card wall doesn’t mean you are doing enough to succeed. For instance, I personally see only topical value in user stories as a starting point for requirements analysis; I think most organizations need a lot more to succeed. Still, many organizations blindly latch on to popular practices without fully examining their situational needs and applying agile principles to innovate appropriate solutions.

I’ve experienced countless customer engagements where organizations espouse a Scrum practice, only to learn that it consists solely of daily stand-ups, teams that are not cross-functional, and a list of user stories. For instance, one organization asked me how to handle “defects” in Scrum. Puzzled, I dug a little deeper and discovered that they had a separate bug tracker full of defects but no one was working on them because defects were not user stories. I pointed out that the product backlog consists of everything needed to build a product, including defects. It took several sessions and training engagements before the “user story mania” subsided and this notion finally sunk in.

4. Failure to employ empirical forecasting

Agile approaches like Scrum control risk through frequent inspect-and-adapt points rather than relying exclusively on an extensive, upfront plan. Yet many organizations stick with “crystal-ball” predictive project management approaches, even though teams are conducting sprints and producing products incrementally. Organizations should instead translate product backlog items with relative estimates to an empirically derived prediction of schedule.

A company that produces hardware and software for transportation organizations had a well-formed Scrum practice, but they were not using empirical methods to forecast milestone completion, instead relying on their old waterfall-centric project management methods. When I asked what they were doing with their relative estimates, they realized their story point estimates were not being used for anything beyond sprint planning. I showed them how velocity and a simple tool like the release burn-up chart could be used to provide an empirical means for deriving duration and milestone forecasting. After a little coaching, the project management office started including empirically derived release forecasts with each release status meeting.

5. Neglecting distributed teams

Organizations composed of individuals or teams who are separated by many time zones are now the norm. Aside from the obvious cross-training on practices, organizations often forget that each geographical location has its own culture. The process of spreading the agile philosophy and achieving a real paradigm shift across distributed teams is something that must be considered for each geographical location, independent of successes achieved at any one site.

A major independent software vendor in the process of forming agile project teams for select customers fell into this trap. Over the course of several years, they did a phenomenal job of infusing agile culture into their US-based development center. However, their India-based teams were not included in this cultural shift. In fact, things were happening the same way in India, with a heavy focus on CMMI and ISO compliance standards. Needless to say, collaboration between the two centers was difficult, being that the two groups had vastly differing ideals and norms. Now, they are explicitly working to bring a uniform culture across geographies.

The Path to Enterprise Agility