Tuesday, January 8, 2013

Care and Feeding of a Team

Lately, I have been working with a group of people that are involved in a high stress low feedback project. This got me to thinking - how can Agile help you treat your people well, so that the organization fully benefits from healthy happy team members? Is this even a goal in the organization?



This seems like an unusual question, but lately I have noticed that there are several questionable practices given the technology practices I see in the regional market. These include:

  1. Hiring on Technical Stack knowledge - and only looking for a PERFECT MATCH
  2. Looking for "hungry people" that are willing to do whatever it takes to get the job done
  3. Looking only for Alpha personalities
  4. Promoting tech people to non-tech roles - and getting rid on them when they fail
  5. If a person develops a problem, they are isolated and looked down upon
  6. Nothing is more important than releasing that product/project/goal
These in and of themselves are not negative practices, indeed, individually they are all taken as strong positives. But there is a flip (and dark) side to this coin. And it manifests itself clearly, like all things, with pressure and time. Almost just like a marriage!!

Let's take a look at how these can really mess things up - and then see what we can do in an Agile umbrella to avoid these issues.

Many great people have blogged about the shortcomings of a technical stack hiring approach. The issue I have seen under the covers here is that there is a perceived cost savings by "hiring experts" in basically short-cutting having to grow or train a resource internally. Indeed, many organizations see the "load" of having to train someone at any level as an extremely distasteful exercise. It is as if hiring a person who fits but is not ready to provide "value" is such a loss that we will not chance the risk. Corollaries to this issue to consider are - what happens when I don't have expertise in one technical stack? What happens when I am no longer a perfect match? And if training is a risk, when I want to go to a conference or get a certification, or just improve my skill set, how will my request be taken? We all know that it is common sense that a well trained work force produces better quality products. This is true in traditional work spaces, how much more true must it be in Knowledge Work?

Likewise, "Hunger" or "assertiveness" belies a hidden agenda for people with poor personal boundaries, to the benefit of the organization. I am a personal victim of this, and have seen it used in many different industries to "maximize value" from your resources. I have seen this impact women in a large amount of cases, but it also impacts people who want to make a name for themselves. The thought is "you have to do what we need to if you are truly committed". The unspoken follow up is "if you are NOT committed, why are you here"? This is extremely common in organizations that favor (and set up) a "hero" facilitated approach, where there is always one winner and a loser. The winner/hero gets all the credit and cannot be questioned, everyone else is there to support him/her. The problem with this is self evident, and leads to large amounts of turnover. All alphas usually indicate this type of organization as well.

Promoting a tech expert to a "leadership role" because you need the "brightest and best" to lead the organization is a HUGE misstep of Developer Led organizations. The dysfunction is clearest at the largest, Redmond based companies, and the ex-employees have lots to say about it. When leadership cannot tell the difference between Technical Expertise and Non Technical work, the underlying reason is a misunderstanding of the value paradigm of a leadership/management role. For a tech person, this can be so much of a challenge, and have so much of an emotional impact, they may actually leave technology altogether. Again, this is common in other practices, but technology is a particularly strong adherent of this issue.

This also is closely related to the "problem team member" issue. Because when you show weakness, in some organizations, "there is something wrong with you". This is plain and simple a symptom of an organization that values the work product more than the people who do the work. Sadly, this is the baseline for most American corporations, and it takes a LOT to convince people that this is an issue. This is why most people on extremely toxic projects keep on going and build the frustration up inside. This is a primary reason developers burn out, and it happens in silence and with no one trying to help. As a ScrumMaster, I get to pick up the pieces for this - as an intrusive crazy guy I get to implement tools to prevent this - to the displeasure of most organizations. Because if I am right, it is a shortcoming of leadership... And there can only be ONE winner...

Lastly, the almost tech only "sanctity of the release"... I see more people burn out with that "last push" only to have the "last push" process repeated again and again and again. And as a Coach, even when you propose possible different ways to do things in order to have better results, you get a quizzical look, and sometimes the response "but we simply do not have this issue here". In fact, I have worked with a few teams where the cost of success was the loss of a long time team member, or indeed, a whole team. Somehow, at the end of the day this loss is not analyzed, but rather justified. Usually along the lines of "well, it shows he wasn't committed" or "we are better of without all those guys, they were trouble anyways". Although organizationally this makes us feel better, it prevents us from learning about ourselves, and thus we lose an opportunity to inspect and adapt.

So - where is Agile in all this? Where can a committed coach go to help an organization understand that these are negative issues that result in a capital cost that is too high to bear? Well, I have some bad news and good news. The bad news is that we have an all encompassing meme to use on all these individual issues. We all know that  we need to "work towards a sustainable pace". This is bad news because the definition of sustainable can easily change from organization to organization depending on several factors the coach cannot control, and sometimes even see. Much of the work I have done has included a large amount of in flight discovery - so I do not know the culture or value system until I am a few sprints into the project. Usually, by then it may be too late to effectively affect change. So what is the good news?

Well, the good news is that as a Coach, you get to observe, identify analyze and propose solutions to these issues. You get to convince the organization that these can lead to holes in the value of the team members, and hopefully research a little and get the information from peers that have presented similar suggestions given the opportunities. The good news is - you are not alone, but it may seem that way. Get engaged, ask people in the community, read materials on the proper care of people - and say something about it. The risk you are able to take depend on your personality and organizational structure. And if you need help - well, give us coaches a call. We can help, and the two of us, well maybe we can get something started!

1 comment:

  1. I have to agree with you on these points. Those who don't know about how to structure an agile team tend to fall back on what they do know.

    Technical stacked teams, "hungry" team members, etc are all traits of a command-and-control management approach. This is the primary reason management needs agile coaches.

    Don't get me wrong: the teams need coaching too. But without the management to support the agile approach, at crunch time the teams fall back to what they know management values.

    And although the management professes a love for agile, they are looking strictly at what they perceive as speed of delivery. It's okay to burn out the team as long as the product gets out quickly. "We can always find more hungry people who are willing to put in the effort" is not a good approach. That type of thinking values short-term (fleeting) results at the expense of long-term viability of the product. Very sad...

    ReplyDelete