There are a few disruptive corporate behaviors that have been bothering me for a while. Forgive me for a moment while I get them off my chest. If you have witnessed these disfunctions, I’d be curious to get your perspective on them. Here are my top 10 ways to destroy an Agile team.
Break apart the team when the current project is complete
Keep the individual/team compensation plan a secret
Don’t openly share financial data with the team
Lay people off on a periodic basis
Refuse to aggressively invest in employee training
Keep the team ignorant of corporate goals and plans
Do not allow any “slack” time
Always cave in to the demands of the customer, regardless of the impact to the team
Allow the customer to “cherry pick” the team members they want
Ignore the skill set of team members when building a team (“Hey, aren’t we all cross functional?”)
Hey, I feel better already! Some of these things may seem pretty obvious. Others may may be more difficult to understand unless you happen to be wandering around in my skull (a dangerous neighborhood for sure…).
Breaking apart the team
Boy, for some reason this is a controversial topic for executives and resource managers. To me, it just seems obvious – if it ain’t broke, don’t fix it! Yet for some reason many managers feel compelled to reorganize teams on a regular basis. They cite reasons such as:
Moving individuals to different assignments is easier than moving whole teams.
Teams get ‘stale’
The company can’t afford to keep all the good people on one team
The way I see it, a team is greater than the sum of its parts. Based on my own experience, getting a good team that gels well and performs well is very rare. So when someone from management claims that it is ‘easier’ to move individuals than teams, I feel like they don’t really appreciate what goes into making a good team. People simply aren’t fungible resources. That notion is one of the fundamental mis-understandings in the development world. You can’t replace Joe with Bob and get the same work. Sorry – it almost never happens that way.
Alternatively I’ve heard the claim made that a team is getting ‘stale’. Team members are too comfortable with each other, and they aren’t pushing each other to excel. Therefore we need to break apart the team and try another combination. Possibly, but I doubt this for two reasons: First, I’ve yet to meet a team where being ‘too comfortable’ was a bad thing, and second, making this a decision outside of the team is basically making a command and control decision without the participation of the team. It’s up to the team to improve themselves and it is up to the product owners to hold them accountable.
Finally, the notion that all of the talented engineers can’t be on one team is a great example of a team that becomes a victim of it’s own success. First they become a high performing team, then they are well respected within the organization, then people start to say, “hey, we need some of that talent over here!” Again, based on my experience, it is very difficult to build a truly high performing team. Once you have one, the worst possible thing you can do is break it up. Instead, use the team as a model for other teams. Find out what it is about the way that teams works that makes them so successful and then emulate it.
So, despite what may seem to be rational objections to keeping teams together, I think there are few things that are more important to a team. Any organization that finds itself reorganizing the teams over and over again is very likely going to find it extremely difficult to succeed at Agile. They are more likely to find themselves reinventing the wheel over and over again. Forming, Storming, Norming, Forming Storming, Norming, Forming, Storming…ad nauseum.
Keeping the Individual/Team Compensation Plan a Secret
The fundamental problem with this is that compensation is never really a secret to anyone on the team. Everyone finds out sooner or later, whether it’s over a beer one night, or in a back room bitch fest. If we can accept that, then we have to realize that openess and transparency are a much more”Agile” solution to the problem. If everyone knows that they are fairly compensated, then they don’t care as much how much someone else gets paid. If they are not fairly compensated (or perceive it) then they are going to be unhappy. I would rather have that unhappiness out in the open. I want to have those difficult conversations within the team. If the team is going to be expected to be self-organizing, then they ought to be given the ability to control their own expenses – and this includes their own salaries. Let the team work it out – not the managers. I know it’s a wacky thought, but I think it might create more dedicated investment in the success of a company by the team if they were to manage their own salaries (within a budget).
Don’t openly share financial data with the team
Now to me, any company that isn’t willing to open their books to their own employees probably doesn’t trust them. That mistrust doesn’t go unnoticed. If the company wants the team to feel like “were all in this together” then they should share this information. I’ve only worked for one company that didn’t share financial data with their employees, and I hated it. Frankly, I want to know if the company is going down the tubes, or conversely if it is doing extremely well. I think my rule of thumb now is not to work for companies that aren’t willing to show you how they are doing financially on request.
Ugh! This is a no brainer. Any company that shows a regular pattern of layoffs is never going to be able to create a decent environment for Agile teams to grow in. Layoffs create an environment of fear and distrust. I understand that layoffs are a fact of life in today’s economy, but I don’t understand how companies can do it repeatedly – that just screams “bad management” to me.
Refuse to Aggressively Invest in Employee Training
To my way of thinking a highly educated workforce is an Agile workforce. Having the discipline and drive to engage in continuous improvement has to be something that is motivated at a personal level. Anyone who is constantly seeking to improve their own knowledge is very likely to be the kind of person who can best motivate continuous improvement. Unfortunately, more often then not, I see training given only lip service by executives and resource managers. It’s very rare that a company shows a serious commitment to it.
Keep the team ignorant of Corporate Goals and Plans
I know. It sounds so silly. What kind of company wouldn’t share their goals and objectives with their teams? Well, it turns out that a surprising number of organizations are like this. They stumble along and wonder why it is that their teams never really get very productive. It’s because the teams don’t understand where the company is going. You end up with 5 different teams going in 5 different directions. The ensuing chaos is fun to watch, but doesn’t help anybody.
Do not allow any ‘slack’ time
OK, I admit it. I’m a big fan of DeMarco’s book. If you are looking for innovation and evolutionary improvement, then you need to allow things to mutate a bit. You need to allow a little bit of randomness to creep into the process. Individuals who have hands on the keyboard all day long are not going to have any time to innovate. Frankly, their not going to have enough time to learn or do much else either. Focusing on development work as exclusively the activity of coding is ultimately counter productive. There is a whole host of different activities that go into creating great sofware – exploration, experimentation, pacing around the room, working with colleagues on the white board, playing with the desk toys – these are all legitimate activities that are not just necessary, but required to develop good software. Human beings don’t function well at 100% – give them a little slack, say 25% and you will probably get a much better result.
Always Cave in to the Demands of the Customer Regardless of the Impact to the Team
Part of me thinks this is petty, but it happens often enough that I can’t ignore it. Let’s face it, some customers can be a real challenge to deal with. Often times the Scrum Master/Coach spends as much time defending the team from interference from the customer as anything else. It’s a tremendous drain, but it’s what you have to do with some folks in order for the team to be successful. However, you can destroy this when an executive gets involved who is more interested in the money than how his team is treated. I’ve had execs walk in and cave into customer demands – usually fickle demands to satisfy their egos. Afterwards, the Scrum Master is left to go tell the team, “Sorry guys, you have to just suck it up and work 100 hours.”
Allow the customer to “Cherry Pick” the Team Members that they want
This is totally disruptive to an Agile team. I’ve had product owners who just felt like messing with the team. I’ve had customers worth millions of dollars to the business who decide they must evaluate individual contribution on the team. It is one of the worst forms of micromanagement that you have to deal with. My answer is a flat, “No.” You want a team, you take the one you get and hold them accountable to deliver. There are few things more disruptive and destructive than someone outside the team choosing the composition of the team.
Ignoring Skill Sets of Team Members when Forming a Team
There are some people, who feel that everyone on a team should be equally good at everyone’s job. This is a misunderstanding of the meaning of a cross functional team. Don’t get me wrong, cross functional people are nice to have, but nobody, and I mean NOBODY is equally good at everything. Don’t ignore people’s strengths when forming an Agile team. Don’t rob yourself of the best talent because you are looking for a “jack of all trades”. There is a reason that it is called a “Cross Functional Team” and not “Cross Functional Individuals“. Think about it. I say this because I have been on projects where I had lots of talented developers who loved Agile, but none of them had the skillset that we most desperately needed. Computer technology is unforgivingly specific. When you need expertise in a certain technology, you really can’t fake it. Well, actually you can, but it’s damn slow.