Don’t Let Functional Silos Kill Your Agile Implementation

The fastest way to destroy an Agile implementation is to let functional silos get in the way. Unfortunately, it happens all the time. And it happens because many companies underestimate the organizational implications of a successful Agile implementation. Most technology companies are still organized into discrete, functional chimneys: Marketing, Engineering, Quality, Manufacturing, etc. In such organizations, functional allegiance tends to trump customer/product allegiance. Deferring to functional needs rather than customer needs runs counter to Agile principles. In functional organizations, team members tend to become entangled in conflicts that arise from resource misalignments, inconsistent project priorities and office politics. These are major obstacles to the team’s ability to execute to a predictable schedule. And when functional organizations do not support the transition to Agile, your implementation is defeated before it begins.

Putting the needs of functions above the requirements of product teams reduces Agile’s effectiveness but many companies do not understand or simply ignore this fact. Leaders must optimize their organization and develop a culture that supports the transition from more traditional development processes to an Agile approach.

Moving from Functional to Product Allegiance

Unfortunately, the move toward Agile requires cultural and organizational change – both of which can be difficult. Agile requires a culture of collaboration up and down the organization and the functional chieftains tend to resist what they see as a loss of influence. Managing this change requires breaking the momentum of what your were doing yesterday in order to behave differently today.

A first step is to clearly define the organziation and culture as they are today and then define what the culture needs to become. Do not expect perfection from the start. First a child learns to crawl, and then walk, and then run. Your organization will follow a similar trajectory. Start small and build capabilities as you go.The next step is to clarify the roles and responsibilities in a new environment that will support rather than hinder your Agile implementation. Once these new roles have been implemented, and the teams understand the basics of the Agile methodologies, then manage the change by measuring behavior. Measurable changes in behavior are an early indicator that the organization has embraced the new process.

Measuring Behavior

Here’s an example to help you begin to identify the cultural drivers that support Agile implementation.One key behavioral change in implementing Agile methodologies is the use of User Stories, which replace the well known Marketing Requirements Document. The purpose of User Stories is to clarify how your customer wants to use your product. The value of the User Story is that is drives a cross-functional conversation regarding features and usability that leads to designs that delight customers.

In this case, a good predictive metric would be the number of User Stories created. Track this metric weekly for each project over a short period of time. The behavioral change you want to see is that your groups are creating User Stories as opposed to continuing to use a Marketing Requirements Document. If you find in the first few weeks that the number of User Stories created is zero, or near zero, then that’s a crystal clear indicator that the team is not transitioning to the agreed upon Agile methodology.

Chances are that if the team is still using a Marketing Requirements Document instead of User Stories, there continues to be greater functional allegiance than customer allegiance. It also indicates that the Agile culture has not started to take hold. If you see that User Stories have started to supplant the old MRDs then your organization is learning to crawl. Now you can begin, slowly, to walk – and then perhaps to run!