When Agile software development practices are introduced into an organization, they often spread faster than they can be controlled.
Without a clearly defined standard to guide your implementation, numerous Agile management approaches can emerge simultaneously—sometimes in direct conflict with one another. That’s not necessarily a bad thing, but traditional, top-down management structures typically experience some growing pains as they transition to the more egalitarian Agile approach. As an executive, how do you embrace Agile yet mitigate risks in scaling technology, people and processes?
This blog series attempts to answer that question and offer a road map to scale Agile adoption for enterprises embarking on that journey. I’ll present common roadblocks you are likely to encounter along the way.
These impediments, which will be the topics for this blog series, can be classified in four main categories: people; processes; technology; and teams, management, and culture.
Let’s explore the first topic.
Which enterprises will successfully adopt agile?
What types of projects are most suitable for applying Agile practices?
It’s even more important to consider the organizational setting where the work gets done. Any project can succeed in Agile; what dictates if it takes off or stalls out are the organizational and cultural constraints of the enterprise.
Lean Software Developer Tom Poppendieck sums this idea up: “The constraints on when Agile approaches can be used are primarily organizational and cultural, not project types. Some organizations and some contexts are incompatible with Agile/Lean thinking. When these organizations eventually come up against a strong competitive threat, they will fail to meet it unless they change their values and mindsets. Lean/Agile is, at its foundation, the fourth industrial paradigm, the first being Craft Production, Factory Production with machine tooling, Automation, and Taylorism. These come along every hundred years or so and take a few decades to work through. Each paradigm includes the preceding one and makes it dramatically more productive.”*
There is no need to sell Agile except to organizations that want to survive long term. If they don’t see the threat/opportunity, they cannot succeed with Agile or Lean nor can they sustain economic viability in the long run.
The best indication that it will be able to make the transition is a willingness to listen and change accordingly. Many organizations insist that they listen to their employees and foster an Agile culture, but that claim is frequently disproved when Agile values conflict with organizational values. Such a culture clash reveals just how deeply embedded traditional waterfall-ish mentalities are. Frequently, enterprises are unwilling to break from habit, even when short range difficulties will yield long- term improvements.
Consider an organization with a lot of up-front analysis and design. How does its employees respond when asked to write User Stories? Do they insist that Use Cases are better than User Stories? Or do they ask to be shown how to write User Stories? The employees who are open to the new paradigm will transition to Agile faster and with better results. Other issues, though, are more tightly woven into the fabric of the organization. Consider an organization that traditionally provides individual offices for its developers. How does management respond to the suggestion of common team rooms? Do they justify the status quo or are they willing to experiment with alternatives? In short, for organizations willing to listen and change, there are no issues that cannot be resolved; it is only a matter of time and effort.
That is not to say that change is not disruptive. On the contrary, change of this order sends shockwaves throughout the entire enterprise. When an organization first introduces Agile practices to a team, the team’s difficulties are limited to the immediate adoption of the practices and how they alter their familiar working methods. But after the team acclimates to these new practices, the challenges shift to a larger, team-wide scope. This is how concerns over Agile tend to develop: by shifting from local, individual problems to over-arching, organizational ones. As Agile practices spread throughout an enterprise, the scope and nature of the problems mirrors that growth. Although these issues cannot be anticipated in any absolute sense, it is possible to classify them as groups and highlight some of the most typical challenges organizations encounter, which can be divided into the following four categories: people; processes; technology; and teams, management, and cultur e.
Next week I will share some thoughts on how to overcome impediments due to overly specialized skill sets, lack of ownership, refusal to work with the team, and mixed signals from management.
The post Removing Barriers To Scaling Agile Adoption: An Introduction appeared first on blogs.collab.net.