When we think culture, we often think about nationality and/or regional cultures. Culture is often a dinner discussion with my wife and friends; it’s great to reflect upon how our upbringing, surroundings, and maybe even our genetics drive our work habits, how we work with others, and how we see and work with authority. Culture is a difficult thing to work with because it’s ingrained in us.

Last month VersionOne released the 7th Annual State of Agile Survey. Within the survey, it is obvious that culture is the leading challenge to all aspects of agile adoptions and transformations. There were two questions within the survey that really highlighted the cultural challenges (note: I plucked out the key responses that impact culture – be sure to check out the full survey):

Concerns About Adoption

  • Lack of Upfront Planning – 34%
  • Loss of Management Control – 31%
  • Management Opposition – 27%
  • Dev Team Opposed to Change – 18%

Specific Organizational Failures Behind Agile Failures

  • Failure to integrate people – 34%
  • Failure to teach team-based culture – 28%

Prior to the survey being released, I already started making a list of those human behaviors and or cultural behaviors that I’ve seen impact the ability of an organization to build good software, let alone those behaviors that negatively impact an organization’s agile initiatives. Here’s my list:

  • Fear of Losing Control. This is primarily an individual fear; however, it can also be ingrained in the organization. I’ve heard, “If I don’t put these controls on how the team works and if I’m not making decisions, when they screw up — I’m the one that is going to hang.” Of course, the idea of control being lost ultimately becomes a myth because we generally see everyone’s engagement raise up a notch or two. Thus, more people are involved in making the decisions at the proper levels — hence, scaling the organization.
  • Gate Keeper Culture. Often a subset or product of ‘Fear of Losing Control,’ this is the manager or director who acts as the liaison between his or her direct reports and the rest of the organization. I’ve seen and even lived in environments where all communications have to go up and down the ladder… or where, in order to talk to someone on the “protected” team, you have to walk past the Gatekeeper and they then take the message or grant permission as long as they are part of the discussion.
  • Measurement of Success is Based upon “On Budget and On Time.” Many organizations, especially IT organizations, live in the world where they try only to be concerned with what they can control — and that is generally, “we deliver what was signed off and will do it based on a budget and set schedule.” Well, we fail to recognize that we should be measured based on the success of the product, either in the marketplace or the usage internally. The funny part is when we time box and quit focusing on the when and who, and instead focus on the what, everyone is happier including the development teams.
  • Fear of “What’s My Role?” This is the protectionist behavior where managers and/or team members don’t see a fit for themselves, or don’t find a fit for themselves, as an agile transformation takes place. These team members or managers generally start creating barriers to deflect blame while at the same time climb to the rooftops to shout out about the failures of the team and process. Meanwhile others are looking at the right thing (e.g., product moving out successfully).
  • Victim Mentality. Have you ever heard, “It has always been that way and it’ll never change?” Well, this is the typical response for the person who either doesn’t want to deal with change or they’ve been told “NO” so much, they just give up. Personally I used to be one of these people; then I learned quickly: if you don’t ask, you don’t get. And, if it is something that could have really positive results, isn’t it worth the risk?
  • Superhero Culture. Now don’t get me wrong; I appreciate hard work and stepping up your game to make sure we succeed as a team. But constantly over committing and being let to over-commit is not a good thing. I’ve also seen that individual who loves to be on a pedestal, thus when we start working more as a team — they’ll often be the person making back room deals to do more work or take on the clandestine project which our ScrumMaster isn’t supposed to know about. Again, hard work is great but we have to respect the concepts of sustainable pace, transparency, and “The Team.” Remember we regularly deliver value.
  • Us/Them Culture. This one is obvious, but it takes on a few forms including department silos, role-based silos, and Ivory Tower silos. Department silos exist when we have complex solutions that require the integration of products from multiple departments and a bad (or no) rapport between the teams. Role-based silos will generally exist in early agile adoptions where the value of diversification and cross-functional teams have not yet been visible. And Ivory Tower silos are typically, “I’m a Director” or “I’m the Product Manager and you just do what I say.” This never results in teamwork unless the team is conspiring together to take down the Tower. If people talk about the managers in the organization as “The Suits,” then you might have some Ivory Tower silos and are possibly going in the opposite direction.

What challenges, either culturally or behavioral, have you’ve experienced? I’m interested to hear about those that not only impacted your agile implementation, but those that impacted delivery of good product.

Join the Discussion

    • Mike DePaoli

      Hi Matt,

      Great post.
      I think that Dan Pink’s work in Drive is very apropos to this topic. Fear of loss of control suggests a mindset that believes that humans beings are lazy and unfocused in their natural state. This is what Pink calls “Motivation 2.0”.

      Companies and their leadership and management would do well to being moving their thinking and eventually their culture to be more aligned with Motivation 3.0 thinking. This is much more in keeping with the mindset that is necessary for success with lean-agile execution, especially at scale.

      Also, a great tool to assess where your team is at in working as a team and also teams working together as part of a larger team is the “We vs. Them Test”. Listen when people describe their work and their relationships. Pay attention to when the terms switch from ‘we’ to ‘them’. This will give you a better understanding of the degree to which team-based thinking has permeated your teams, organization and even with teams formed in partnerships with vendors.



    • Scott Duncan

      This comment isn’t aimed at you Matt, but I am constantly amazed at agile-related conferences (e.g., Agile 20nn’s around the world, Scrum Gatherings around the world, Lean conferences with heavy agile influences) because speakers can sound like they “discovered” organizational change (along with its associated issues) as an important concern. I wonder where people have been for 30 or more years. There have been gobs of material written on this subject and the speakers do often sound like they are either oblivious to it or think it is some recent important discovery since the Agile Manifesto.

    • Matt Badgley

      Hey @Scott, I cannot agree with you more. It would seem that we would have nailed this by now, but being out there with organizations — it’s obvious that one of the most challenging problems with adopting agile is culture. I think that what is not understood well is whether or not it’s the culture of the organization or the meaning of culture actually being one person that is resistance.

      A good book I’ve been reading lately is Repeatability: Building Enduring Business for a World of Constant Change by Chris Zook and James Allen. The writers cite a lot of research and they’ve found that if folks embrace the foundation of the organizations culture, they can institute changes to their approaches and practices successfully.

      In any case, you are right — there are “gobs” of information out there. Let’s hope folks start listening and using that information.

    8 + 1 =