Top Ten Ways to Destroy Agile Teams

December 11, 2007

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.

  1. Break apart the team when the current project is complete
  2. Keep the individual/team compensation plan a secret
  3. Don’t openly share financial data with the team
  4. Lay people off on a periodic basis
  5. Refuse to aggressively invest in employee training
  6. Keep the team ignorant of corporate goals and plans
  7. Do not allow any “slack” time
  8. Always cave in to the demands of the customer, regardless of the impact to the team
  9. Allow the customer to “cherry pick” the team members they want
  10. 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:

  1. Moving individuals to different assignments is easier than moving whole teams.
  2. Teams get ‘stale’
  3. 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.

Periodic Layoffs

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.

Anti-Patterns: When Scrum Becomes Ordinary

November 15, 2007

Scrum was named for the formation of a Rugby team that is contesting possession of the ball during a Rugby match. It is characterized by a unified front formed by the entire team. Teammates are literally locked together arm in arm, shoulder to shoulder. Everyone on the team is intensely focused on the same objective: get the ball. When there are two teams lined up against each other like this, you can tell that it is a herculean effort. It is a contest of strength, of will, of iron resolve. It’s tremendously exciting to watch. There is nothing ordinary about it.

Scrum shares many of these attributes with the sport of Rugby. The team is focused on the same goal. It is a unified effort that is driven by the strength, will, and iron resolve of a team. Think back to those first few times you worked with a Scrum team. Were you energized? Did you believe in the promise of agile development? Did you really want to see it work? It’s normal for a team to be very enthusiastic at the beginning of a project. If your team isn’t enthusiastic at the beginning of the project, you probably have a problem on your hands.

Regardless, teams march forward, sprint after sprint, chasing the ball. After doing it for a while, it’s easy for complacency to set in. You do the planning, the daily scrum, the review and retrospective, rinse, wash, and repeat. Simple. Somewhere along the line, the team gets into a rhythm and everyone knows what to expect next. The customer is seeing increments of product value, the team is delivering, and everybody is happy. This is when a Scrum team is most vulnerable to its greatest enemy: The Ordinary.

The Ordinary is very seductive. It whispers warmly in the ears of your teammates, “Why change now? Why mess with a good thing?” The Ordinary croons some of my favorite tunes, “If it ain’t broke, don’t fix it.” And “Good enough.” The seeds of The Ordinary seek to take root everywhere: in your goals, in your user stories, in your code, in your impediments. When things get “ordinary” on an agile project, it’s really the beginning of the end.

What do I mean by ordinary? Let’s go to the dictionary (Mirriam-Webster):

Main Entry: 2ordinary
Function: adjective
Etymology: Middle English ordinarie, from Latin ordinarius, from ordin-, ordo order
1 : of a kind to be expected in the normal order of events : ROUTINE, USUAL <an ordinary day>
2 : having or constituting immediate or original jurisdiction; also : belonging to such jurisdiction
3 a : of common quality, rank, or ability <an ordinary teenager> b : deficient in quality : POOR, INFERIOR <ordinary wine>
synonym see COMMON

I’m talking about definitions 1 and 3. Some people might argue that an agile team becoming ordinary is a desirable thing – not me. Ordinary is the archenemy of inspect and adapt. A team that settles for the routine, the usual, is not looking for ways to improve themselves. They’ve become set in their ways and stopped looking for new ways to improve. I’ve seen it happen over and over again. The teams start out gung-ho and launch themselves up the agile learning curve with great gusto, only to stall out midway to their goal. I’ve seen it so much that I think of it as an agile anti-pattern. I’m sure I’m not the only one to notice this – in fact I’m willing to bet that someone else has coined a term to describe it (but I won’t let that slow me down).

What are some of the symptoms of the ordinary in a scrum team? Here are the top 4 places I look for the ordinary on an agile team (in order of importance):

1. Impediments – Missing or failing to resolve them

2. Failing to Act on Retrospective Action Items

3. Meaningless or Missing Sprint Goals

4. Boring Stories

Whenever I go to a standup meeting and one by one everyone says, “No impediments” I know the team has succumbed to The Ordinary. They’ve lost the will to keep seeking improvements. Impediments often seem like deceptively bad things. Impediments slow you down, right? No! Impediments are opportunities to speed up your team! Impediments are a gift, a chance to make things a little better. They are tiny things with subtle impact. They are EVERYWHERE! We live in a veritable soup of impediments every day. That’s part of the problem – we have gotten so used to them that they have become ubiquitous. We fail to recognize them because we have gotten so used to accommodating them. Finding impediments can be hard because we have conditioned ourselves to ignore them. It’s easy to come to the daily stand-up and report, “No impediments.” And get on with the rest of your day. After all, if it was a serious problem it would be staring you in the face, right? No! I would propose that you think of your stand-ups differently. Think of the 15 minute standup as your one golden opportunity to do one small thing to help out your team. Count on it – this is a chance to make big difference to your team. You have just a few brief seconds to identify what you did yesterday, what you’re going to do today, and identify an impediment. An impediment is a gift that you bring to your team every day. Everyone should strive to find one every day – and the scrum master should be striving to eliminate them by the end of the day. Conversely, failing to identify an impediment every day is letting your team down when they need you.

One area that I have failed my team as a scrum master is with the Retrospective. Here is what I mean, part of the Retrospective is to identify the things we would do differently in the next sprint. It’s another one of those golden opportunities for change. However, it is deceptively easy to walk away from the retrospective and forget about those things. It’s almost like we treat it as a purgative experience. We flush out all the bad ju-ju, wave a magic wand, and move on to the next sprint. We sit around and share what went well, we anguish over what didn’t go well, we feel each other’s pain…and everybody goes home. We come back the next day all refreshed, and we continue to work as normal. What’s up with that? When nothing changes, The Ordinary has won again.

Meaningless or missing Sprint Goals are another sign of the Ordinary. When sprint goals are missing, it says to me, this team isn’t willing to take the time to come up with a real reason for accomplishing this sprint. It tells me that they are content to trudge onward without a goal. One story after the other, one foot after the other, marching forward without a goal. That just sounds like drudgery to me. In rugby terms, the objective goes from “Score a goal and win the game” to “get another 5 yards”. The reason, the passion, the objective for why you are doing what you are doing is completely lost. This isn’t a team pushing the envelope – this is a team that forgot to lick the stamp!

I’ve already written about “Passionate User Stories” before. Who wants to work on boring stuff? If you can’t bring any passion to your work, who is going to sign up for those stories? Are you really going to get the team to work hard on something that bores them to death? I don’t think so. The teams that win consistently are the teams that put an equal amount of passion and zeal into everything that they do. Nothing is too ordinary to be elevated and made worth truly doing. When I read boring stories that lack passion, I know that The Ordinary has set up house with that team.

So how do you defeat The Ordinary? You don’t settle for the status quo. You keep pushing yourself and your teammates to bring greatness to your team. Set audacious goals. If you aren’t trying to become the best agile team in your company, then your goals are too low. If you don’t want to be the absolute best, then scrum probably won’t be much more effective than any other methodology. In fact, you have to do more than want it – you have to demand it. You have to expect it of your team. You have to seek out the The Ordinary and root it out where ever it hides. You must hunt it down, identify it, and exterminate it relentlessly.

So what is your job? Your mission is to perform The Extraordinary and settle for nothing less.