High Performance Agile Teams Have Problems

December 31, 2007

problem.jpg

Yeah, you heard me right. High performance Agile teams have a lot of problems. These clowns discover new problems every day. Every time they resolve one (which they do very aggressively), another rears its ugly head. And, believe it or not, they love every minute of it.

What’s wrong with these people? Where does this irritating habit come from? Perhaps a traumatic head injury? Is it some sort of deep seated neurosis that compels these folks to revel in the problems they discover? Surrounded by all these problems, you’d think these teams would be populated with those negative types who just can’t see the glass as anything other than half empty.

Not so.

A team that is constantly raising and resolving problems (or impediments) is likely to be highly effective. Not only are they continuously improving their process (Kaizen), they are also removing those things that slow them down. They are also continuously learning. They are uncompromising in their perfectionism – looking for even the smallest ways to improve their performance as a team.

So, if you are looking for the best performing team in an organization, perhaps you should be looking for the team that is finding and resolving the most problems!

Advertisements

What does it mean to be a “Cross-Functional” team

December 22, 2007

As a coach, I’ve encountered a great deal of confusion when talking to teams about building a cross-functional team. Often, as soon as I mention the notion, the reaction is negative. People often seem to think of cross functional behavior as every person on the team being able to do every job on the team. The impression that they get is that they are being told specialization is bad, and generalization is good. I believe this is often exactly what some Agile advocates are thinking when they talk about cross functional teams, but I want to paint a different picture.

I mean, generalization overall is a good thing. But we still need specialists. We are looking for the right mix of people with the right skills – not one person with all the skills. Everyone can’t and won’t be equally good at everything.


Tom’s Catalog of User Story Smells

December 20, 2007

Here are a few smells I’ve encountered while working with user stories with different customers:

  1. One word stories
  2. Technical stories
  3. Stories missing goal
  4. Stories missing user role
  5. Stories specifying architecture
  6. Customer doesn’t understand stories
  7. Boring stories
  8. Too many stories

For each story there is a symptom and a related discussion of the problem:

One word stories

Symptom: Stories are just single words jotted on a card with no description or explanation associated with them.

Discussion: Although stories are “Intended to be a placeholder for a conversation” it is possible to stretch that notion too far. It’s easy to see how a product owner might think that they have a mutual understanding of the issue with the team – so much so, that they neglect to describe the story sufficiently. However, it’s critical that the story provide some simple context, some simple statement of action. A disciplined team sticks to the format: As a <user> I want to <do something> so that <I can accomplish goal>.

Single word stories can also be an indication that the team is writing the stories for the product owner.

Technical stories

Symptom: The story is written in completely technical terms that have no meaning for the customer or the business domain.

Discussion: This is probably the most common problem with user stories. Technical stories that refer to layers of architecture, or specific technologies are completely opaque to the customer. The customer finds it hard to understand the value of the activities if they are not written in business terms. If you go to a review meeting, ask the customer/PO to accept the story and they say, “I don’t know what that means.” Then you have a technical story.

Technical stories are also an indication of another smell: Customer won’t write and prioritize stories. As a result, the team ends up writing stories that make sense to them – technical stories.

Stories missing goal

Symptom: Stories contain user role and feature, but there is no explanation of why the user would want it.

Discussion: Incomplete stories of this type are quite common. The goal is what can provide context for the rest of the story. Often the goal is an expression of the value the feature has to the user. Often an inexperience product owner will neglect to put the goal in a user story.

Stories missing user role

Symptom: Story contains a description of the desired feature without a reference to the user role.

Discussion: Without knowing who the customer is, it makes it very difficult to understand the value a feature may have – furthermore, it’s almost impossible to assess the fitness of the feature to the user.

Stories specifying architecture

Symptom: The story contains references to architectural design or components.

Discussion: This is simply another version of a technical story. This comes up most often when there is a dedicated architecture team.

Customer doesn’t understand stories

Symptom: Customer/PO doesn’t recognize or understand stories

Discussion: It’s likely they didn’t participate in writing the stories.

Boring stories

Symptom: Stories sound stilted and without passion.

Discussion: This could just be that the stories aren’t well written and need to be refactored a bit. Another problem may be that the goal is not particularly compelling. Is this story prioritized correctly?

Too many stories

Symptom: The total number of stories in the product backlog has grown to literally 200, 300, 400 stories or more.

Discussion: This is waste. The team will very likely never get to those stories. When the backlog gets this large it’s time to prune it down to a more reasonable size.


What’s a Waterfall?

December 12, 2007

As an Agile coach and a trainer I often compare Agile methods to “Waterfall”. Waterfall is a bad thing. We all do it. When we are assessing a team, sometimes I hear people say in a desultory tone, “They’re just doing mini-waterfalls.” Typically when I think of waterfall processes I think of a project that is organized as follows:

Analysis ->Design->Implementation->Test->Release

Or something close to this (you may use different terms). Basically, we do this, then this, then this… and repeat. Typically this method is criticized as creating too much specialization, not enough collaboration, too many hand-offs, and so on. So far, none of this should be  a surprise to anybody. I can slap this sort of project together in MS Project in my sleep.

Now, let’s take a look at our Scrum task board. Here we see something similar to the following:

ToDo, Test Complete, In Progress, In review, Done

Interesting. In a typical case, can we do any of these steps out of order? No.  Can we skip steps? No. Hmmm…let me show you those terms one more time:

ToDo->Test Complete->In Progress->In review->Done

Oh, now that’s kind of interesting. It seems that the Agile process that we are using to track our tasks looks remarkably similar to the Waterfall process. But that can’t be right! Let’s put them side by side and see if we can find a difference:

AGILE:                 ToDo->Test Complete->In Progress->In review->Done

WATERFALL:    Analysis ->Design->Implementation->Test->Release

Oh nuts! Now I’ve really done it. Perhaps its a matter of scale. Perhaps its a matter of the order of magnitude difference in the activities. Or…perhaps using the “Waterfall process” is a straw man that we shouldn’t really be using when we talk about the benefits of Agile. Perhaps the greatest difference between how things are done on an Agile project, and whatever folks have done in the past is not in the order that the tasks are completed in. You can rename the tasks, reorder them all you want. But you still end up with the same thing. Call it something different, “a mini Waterfall.” If it makes you feel better, great. But my argument is that this is not the key difference between Agile and other methods. The difference lies someplace else, not in the ordering of the tasks – because, if we just compare the ordering of the tasks, guess what? Agile and Waterfall look the same.

Maybe I’ll sleep on this tonight and look back on this tomorrow and regret it. After all, I’m a good little ‘Agilista’ and I don’t want somebody to stamp my meal card “No desert”.  Perhaps I’ll go back on my medication tomorrow and realize that this was all a hallucination. But somehow I doubt it. If we are looking to explain to others how doing an Agile project is different than others, perhaps we should avoid this comparison and focus on other differences.


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.


Type 3 Scrum – OK, now I get it (finally!)

December 11, 2007

It took me a while, but I think I’ve finally grokked the difference between type 1, type 2, and type 3 scrum. These different types or gradations of Scrum were suggested by Jeff Sutherland, one of the originators of Scrum. Briefly, the three types can be rather simply described as follows:

Type 1 – Fixed gates: Standard, out of the book Scrum. Plan your sprint, run your sprint, review your sprint – rinse and repeat.

Type 2 – Overlapping gates: Plan your sprint, run your sprint with ongoing planning sessions (for upcoming sprints), start next sprint as first sprint winds down, review last sprint – rinse and repeat

Type 3 – Mini gates: Plan a feature as needed & start sprint (features can start anytime), when sprint is complete – review it.

The way I see it, with type 1 Scrum, you are starting off with the training wheels on the bike. Things are pretty strictly regimented. We want to get the team used to a time box (they need to learn how to scope their work effectively). We want to get the team used to frequent planning and frequent reviews (put the rudiments of a quality driven, inspect and adapt system in place). And finally, get them used to working with smaller batch sizes.

As a team graduates to type 2 Scrum, they have mastered the fundamentals of type 1 Scrum. Now they can begin to improve on the process. Planning becomes much more of an ongoing activity that never stops. We remove the hard start/stop constraint between sprints. We want to establish a comfortable rhythm where the team begins to blur the lines between the current sprint and the next. We keep the sprint planning and review though – we want that culture of continuous improvement to remain. We probably have a trend of the batch sizes for each sprint starting to get smaller.

Finally, As a team gets comfortable with type 2, they have reached a point of really significant maturity. Now is the time when we can look at the team and say, “What if we reduce the batch size to one?” One sprint has one story. We overlap as many sprints as necessary. Basically we are creating a state of continuous flow where there are always multiple sprints in progress. In addition we have driven the batch size down small enough that the inspect and adapt cycle is now almost continuous. Sweet!

Based on my own experience I know that a team would have a very hard time skipping from type 1 to type 3. It’s an evolution. I also think that it is remarkably similar to other systems like Kanban – after a while I guess they all start to look the same in some respects.


Hanging My Test Driven Christmas Lights – A Retrospective

December 7, 2007

OK, so by now, many have read my first missive regarding my annual sado-masochistic ritual of decorating the house for Christmas. I’ve just finished the whole embarrassing production once again. Time for a little retrospective:

So let’s start by reviewing our objective…

Goal: To win the Elf Award for the best Christmas lights in my subdivision so that I can revel in the glory and adulation of my neighbors and idle passers-by.

What Went Well:

  • More lights than last year
  • Key display items repaired (“Frosty is back!”)
  • Ten Fingers, Ten Toes, Skull still intact, No broken bones
  • No visits to the ER
  • Fewer unexpected blowouts – improved quality
  • Still married

What Could Change:

  • Casualties: 3 fingernails & one stapled thumb
  • Work more closely with the product owner
  • Get approval for changes to the lighting scheme BEFORE implementing

All in all, this year’s lighting experience has been much better than last year’s. There are a few things that might explain this success beyond what I talked about last year. This time I did the work in much smaller chunks instead of trying to do everything in one day. This made the physical exertion seem much less.

I should have gotten approval from the product owner for smaller increments of the work. I had a few scares where my wife came outside, looked at the fruit of my labors, and said, “You’re NOT going to hang icicle lights on the tree are you?”

Of course not, Honey…

Of course the real approval for this release will come from the judging committee when they hand out the Elf Award. Maybe I should bake some cookies for the committee? Should I greet them at the door wearing a tie? Should I write an acceptance speech? Stay tuned.