Delivering projects (both business process and technology focused) for the bulk of my career, I have found these themes to ring true as barriers to agile transformation within the enterprise:
Resource Management
While resources are cross-functional often wearing many hats, they are often part of a matrix organization and deployed to simultaneous projects at once. This creates conflicting priorities, lack of visibility, and the inability to fully participate in the day to day needs of any one project team. The Agile solution - dedicate resources to a single team. Allow resources to fully participate in the daily team interactions, forge relationships, and share accountability for the overall project goal. Dedicated participation will speed the overall delivery and ease communication barriers. Freeing the resources to move onto the next priority rather than working on several at once.
Physical Location
Large corporations (even the not-so-large) have always been fond of cubicles. Building physical walls between people for privacy. What suffers is team communication. So meetings become the main way for talking with each other. Instead, break down the walls and allow the team members instant communication anytime it's needed. Co-located team members is also a huge issue. The business often lives in one building and the technical in another. Again, creating physical barriers to communication and collaboration. Keep project teams together and break down the physical wall for the duration of the project.
Requirements
Requirements are a huge stumbling block in large enterprises. Not only the requirements themselves but the politics surrounding them. Politics such as - who had input? who signed off? when were they signed-off? are they in scope? when is a change request required? The traditional assumption around requirements is that the business knows exactly what it wants and that it won't change for the duration. Any changes are considered risks to project delivery. The agile mindset says - keep requirements light, keep them just-in-time, allow them to evolve with the needs of the business. This works because the cross-functional team is in constant communication. As requirements evolve real-time business decisions can be made based on the current state of the product. Together, the team takes input from a product owner to help craft ultimately how the product meets the goal. The product owner isn't expected to give detailed how-to requirements. Only to know what the business needs and, through a series of product demos, collaborate with the team to make the product just right. Traditionally the enterprise has encouraged a long very detailed upfront requirements gathering phase in which everything is written in documentation prior to building. This produces nice documentation that can quickly become outdated as business needs change (and business needs ALWAYS change). The project starts swirling around creating change requests before one line of code has even been developed. Stop the madness, document what's necessary to give the team a running start, evolve the documented requirements as the product evolves, not vice-versa.
Compliance Requirements
Agile promotes just enough process to get the job done. Sometimes in larger enterprises the "just-enough" becomes too heavy weight and prescriptive in the name of compliance. This is a huge misfortune and one of the largest barriers to starting and being successful at Agile. The key to compliance is a keen understanding of what controls need to be in place and what the purpose of the control is. The enterprise must provide the tools, resources, and guidance necessary for teams to be successful in meeting the controls NOT provide a detailed how-to for doing something. Education and shared accountability with actionable recourse are keys to compliance.
What are your experiences and barriers encountered when bringing Agile principles to your projects?
