The biggest drawback of Agile development is most people don’t understand what it means to be Agile. As a result, they make unsupported assumptions, e.g. there is no need to plan in Agile projects, about what it means for both development teams and the business.
Many companies “want” to be Agile, but don’t invest in the effort to actually educate management or employees about how the principles apply and what methodologies will work best within their culture and organization.
All too often, Agile is adopted as ‘silver bullet’ solution…or worse, ignoring the impacts on other business concerns.
Most of the Agile problems have come from teams who have decided to design their own solutions without taking the time to understand what they are changing.
Another common problem, leading from a lack of formal training or understanding is that the very flexibility of Agile leading to teams engaging in bad behaviors, and “blaming” poor results on Agile itself, rather than the choices made by the team. This tends to result from teams reading the Agile Manifesto and focusing solely on the “items on the left” to the exclusion of the “items on the right.”
Not every corporate culture is “ready” for the changes Agile requires — which are not only to the development teams. The kind of flexibility, uncertainty, and regular interval-driven reviews that make Agile approaches successful require significant amounts of change throughout the entire organization:
All of these things require culture changes within the organization.
The lack of predictability inherent in Agile approaches, which are a function of the acceptance of uncertainty and the focus on doing only what work is necessary to move to the next phase. When we accept uncertainty in our efforts and value responding to change over following a plan, we sacrifice the kind of predictability and security of traditional methodologies. This can be difficult to accept; it complicates budgeting, marketing plans, sales comp plans, and even investor pitches.
When running projects with Agile, we ask teams to be as fully capable of delivering quality results as possible within their team.
Scrum, for theorizes every Scrum team should be fully cross-functional and able to deliver any end-to-end solution thrown at them. While this sounds very attractive in principle, it’s exceptionally difficult in practice.
Some Scrum teams have a knack for these things; some even have a knack for both things. All too often teams adopt Agile practices and they start to run into major issues figuring out how to work in the design and testing needed to deliver successful products.
In recent years, there have been many attempts at building scalable Agile system architectures, such as SaFE, LeSS, DaD and Nexus. These concepts have been driven primarily by the difficulty of effectively scaling the work teams do into larger and larger organizations.
When the ideal size of a scrum team is most often positioned at between 5 and 9 people and your development team consists of 500 developers, how do you manage the interrelationships between those small teams while still maintaining a cohesive approach? Most Agile methodologies were designed for small, nimble,young organizations to adopt and adapt, but only in recent years have there been real efforts to identify and establish scalable Agile practices large organizations can apply.