Tag archive

VersionOne

Behaviors and Culture Can Impair Creating Good Product

in Agile/Agile Engineering/Product Management/Project Management/Teams by

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 engrained in us.

A few weeks ago, 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:

  • Controlled manFear of Losing Control. This is primarily an individual fear; however, it can also be engrained 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, resulting in more people being 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 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 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.
  • “What’s My Role” Fear. 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 start creating barriers to deflect blame while at the same time climbing to the roof-tops to shout out about the failures of the team and process. If others are looking at the right thing (e.g. product moving out successfully
  • Victim Mentality. Have you ever heard, “it’s 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?
  • photodune-3820842-young-superhero-sSuper Hero 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 overcommit constantly 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 that our Scrum Master 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 been visible yet. And Ivory Tower silos are those “I’m a Director” or “I’m the Product Manager” and you just do what I say — this never results in team work, 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 possibly going in the opposite direction.

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

Pondering the Agile “Don’t Know” Methodology

in Agile Engineering by

DontKnowMethodIf you haven’t already heard the buzz, the VersionOne State of Agile Survey 2011 is now out and it is packed full with some great information.   The survey is a helpful resource to quantify what people are doing and the value they have realized or have not realized through their particular agile implementation.  As part of teach agile and speaking to the delivery methods used, I often reference the pie chart that shows the Agile Methodology Used and I updated my training materials with these latest results.  One thing really jumped out at me and made me go, “huh?”  That was that 8% of the respondents answered “Don’t Know” to the question of “What agile methodology do you use?”  That is roughly 500 of the over 6,000 respondents.  And like any good agile metric, seeing this only made me ask questions and hypothesize as to why that many folks answered “Don’t Know”.

The first though I had is training.  Yes coming from a guy that does coaching, that is the first thing I thought of.  But not for the reasons you may think.  If you think about it, the amount of teams applying agile climbing the blade of the hockey stick and as someone who has seen the benefits in product outcomes and overall organizational morale – this is great!  But, the challenge is with adopting agile it does require training the team members so that they, the TEAM, can make the transition successful and help adapt, adjust, and evolve the methods used to fit their development environment.  In Agile, the TEAM owns the process and the TEAM are empowered to make it successful.  This is much different than traditional project management where you can focus training on just those folks in leadership positions and the project managers.  The team just needs to know where to report time, and know how to write up their status reports.  So, if the team has not been trained on what agile is and the surround methods and processes, then I can understand when you ask them “Do you do agile?”, “Yes”, “What agile method do you use?”, “I don’t know.”

The second reason I can think of why folks answered “Don’t Know” is that they are leveraging multiple concepts from the various methodologies – including agile and traditional project management.  The survey did allow folks to answer “Hybrid” (9% of respondents answered), but in my discussions with teams lately – the application of Agile principles is the beginning focus with the adopting and adapting processes is much more flexible.  Teams are starting with one method and morphing to another, and in some cases leveraging a little bit from everything.  This approach can be good and bad, depending on the maturity of the team and the ability to continuously improve.

Besides the answer of “ignorant blissfulness,” the only other thought I had for the “Don’t know” response are those that work at organizations that have heard about this Agile thing and decided that they will become Agile.  So they leveraged Find and Replace to put the word Agile in place of whatever methodology they were using before.
So, what are your thoughts?  If you participated in the State of Agile Survey this year, why did you answer “Don’t Know”?

Go to Top