The Pitfalls of Agile When Organization Fail To Understand Real Agility

I often see big organization decide to adopt Agile without the right mindset, and they fall into a common trap of mediocrity, which at best they do Iterative Waterfall and call it Agile. Of course, when you talk to them they tell you that they are really proud of their new development process and claim that they have created their own Agile Framework. After all, the have stood up Scrum teams with Scrum Masters, Product Owners and have sticky notes on the wall, they sprinting and loaded their product backlogs into an online tool … the whole enchilada. So, they are Agile, right? Wrong!

Agile software development means different things to different organizations. As it has exploded over the software development lifecycle, Agile principal and discipline often have pushed aside as organizations rushed into implementing pick and choose practices in the name of practicality.

When organizations disregard agile development values and principles, they fall into some common pitfalls. By staying true to Agile’s core philosophy, companies can better realize the true benefits of agile: high productivity, great software quality, and happy customers.

Altering standard Agile framework before the organization has thoroughly grasped an Agile mindset

Scrum, Kanban, XP, Lean and similar frameworks provide a specific guideline and set of practices tightly embedded in Agile methodology. These frameworks are designed to be flexible (to some degree) based on organizational environment, culture, and need, but not until the organization has a solid grasp of why these practices are in place. The most common mistakes organizations make when adopting agile is tinkering with these frameworks before truly understanding the implications.

One common antipattern happening at nearly most organizations adopting agile is omitting to form cross-functional teams and continue with silo and domain-centric teams or team members. This structure perpetuates an “us versus them” mentality and promotes mini waterfall approach, which usually starts with shorter release cycles and eventually falls back to the traditional way of developing and releasing product, due to the fact that it is almost impossible to complete potentially shippable product increments each iteration.

Big bang approach and scaling up before there is momentum

Agile is best to shine when small teams working highly collaboratively. Large organizations are often in a hurry to go all-in and scale up 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 and it takes some 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.

Dependence on Agile – Scrum ceremonies for success

Just because you do your daily stand-ups, write user stories and put them on your backlog, and conduct your Scrum meetings 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.

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 software for supply chain management 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 the driving duration and milestone forecasting. After a little coaching, the project management office started including empirically derived release forecasts with each release status meeting.

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, the 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

Agility is a tremendous paradigm shift in our thinking and behavior. It cannot be rushed or pushed on an organization. It cannot be effective if the underlying philosophy is largely an afterthought. Pragmatism is an intelligent pathway, but it often precludes the consideration of lofty ideals—something essential in enterprise agile transformations.