4squareviews

In the last three posts I described the three elements of the culture of agile as described in the fourth chapter of the Agile Practice Guide.   These are

• self-organization
• 100% dedication (i.e., team members’ time not split between other projects)
• co-location (having access to a common workspace)

When I was the Director of the Executive Council at PMI Chicagoland, we talked about the creation of an agile culture and what threatened it within the organization.   One of the executives said, “well, you can create an agile culture on a team, but when you try to re-create that culture in the organization at large, watch out for the corporate antibodies that start to attack!”

What he was saying that the culture of the organization at large may be traditional, and creating a sub-culture within an agile team is all well and good, but the larger culture of the organizational may see this as a threat–in the analogy to the body’s immune system, the agile culture may be seen as a “foreign” or outside entity that the body needs to protect against.

In asking this executive what the main element of organizational culture is that perceives agile as a threat, he replied “organizational silos.”  I remembered that when this discussion came up on p. 47 of the Guide on “Overcoming Organizational Silos.”

How do you create an agile culture?   According to the Guide, “by building a foundational trust and a safe work environment to ensure that all team members have an equal voice and can be heard and considered.”   One of the names of this kind of organizational structure is a “heterarchy” where everybody is at the same level of power.   This is opposed to a “hierarchy” where certain members have more power than others, and this is often what you generally have in an organization that is divided into different silos or specialties.   On a traditional project that has a balanced matrix structure for example, you have the team members on a project who report on the one hand with regards to their project work to a project manager.   Their main work in the organization, however, comes from a particular department where they have a functional manager overseeing their everyday work for the company.   This often creates a tension within the team member of dual loyalties both to the project and to the larger operations of the company.

In agile, this is avoided by having the various functional managers who give team members to the agile project allow their members to join the project and dedicate all of their time to it for the duration of the project.   The loyalty now is not to a project manager, as in a traditional project, but to each other, the members of the cross-functional team.

Once the project is done, the organization at large can see how leveraging its people can optimize the project or product being built.   However, there is another advantage to the organization that is trying to adopt agile culture and that is to learn from the synergy of the team on that project and use it to try to dissolve the impediments that the organization puts out for cross-functional agile teams.

That is the way in which agile culture can affect the culture of the organization as large–not in the sense of destroying that overall culture, because that attitude is what causes the “corporate antibodies” to reject agile culture.   Rather, it should be seen in the light that agile culture “transcends and includes” the culture of the organization at large.  Yes, there are hierarchies that are unavoidable in many companies, but having the “heterarchies” of agile teams loose in the company may cause the silos to have greater communication with each other, and more empathy for what each of them needs.

In this way, agile culture can truly be transformative of the corporate culture as a whole, rather than being seen as a threat.

This was the last post on Chapter 4 on Creating an Agile Environment.  The next post will start with chapter 5: Delivering in an Agile Environment.  The first post will be on what a project charter, an essential document in traditional project management, looks like in an agile environment.

Filed under: Uncategorized |