There are many obstacles to enterprise agile adoption. Some are intrinsic to the agile philosophy and difficult to handle. Others are self-induced by the agile community. Here’s an obstacle we can handle.
One of the key attributes of agile software development is teamwork. We build small teams, keep them together, and have everyone share the workload. Whether the underlying approach is Scrum, Kanban, XP or Lean, tightly knit teams always apply. It sounds good in principle, but it runs counter to the way most big companies operate.
Companies usually define roles like project manager, software architect, database administrator, quality engineer, network engineer, and many others. It’s all about specialization. Senior people in these roles are often assigned to multiple projects. Their roles on any project are limited in function and duration.
Is the concept of specialized roles contrary to goals of agile development?
Let’s hope not. For agile development to succeed in large enterprises, the techniques need to adapt to the existing personnel structures. There’s nothing inherently anti-agile about building small core teams and having specialists help out as needed.
For example, a project manager can help organize multiple Scrum teams working on a single large system. The project manager isn’t a member of any one Scrum team, yet she coordinates activities that span teams.
A software architect can perform a similar function at the technical level. Multiple teams cannot go off and build isolated components or systems and expect them to interoperate well at the end. Someone must oversee the architecture and guide interoperability.
You get the idea. A similar argument can be made for database administrators, software quality engineers, and network engineers. Highly specialized skills are needed to build large, complex, multisystems.
The convergence of agile software development and enterprise software development can only occur once we embrace specialization and use it to build enterprise-scale solutions. Are you ready?