As part of my continuing review of practices that undermine the value of scrum I’d like to focus on two areas that I see teams struggle with. Let’s start with a couple of definitions from Wikipedia.
Team: A team is a group of people who have a certain task to complete. In order to meet their target, the members of the group must cooperate with each other.
Successful team: A group of people tend to meet their target without facing any sort of barrier.
Unsuccessful team: A group of people who have a very difficult time when attempting to complete a certain task. The members of the team think only of themselves and create an uncomfortable environment for other members of the team.
You hope that your scrum team can be called a successful team but how successful they can be depends on how well they cooperate and integrate themselves. This is why co-location is such a valuable team attribute. It’s much harder to cooperate and integrate through distance, time zone, and cultural differences.
When learning scrum some team members bring baggage with them from the Waterfall process. One piece of baggage is the idea of a specialist who can do only one type of work. On a typical scrum team of 7 +/- 2 people if you have more than 1 specialist within the group you’re in danger of scrumbut. Sometimes true specialists are necessary as in the case of a shared resource that has some level of knowledge that can’t be transferred to others easily. In most cases I’ve been able to debunk the myth of more specialists are a good thing. Let’s be clear, we’re all specialist in one way or another. I happen to be a great C++ coder but only okay at writing Stored Procs. It’s just not a good idea on a small team to have a bunch of people who can only do one thing. It creates a very dependent, serialized development process flow. Fortunately this issue is really more of a mindset than a true liability. On my teams I encourage each member of the team to be a specialist in an area that they might be particularly adept at but I also encourage them to learn what the people next to them are doing.
Some at this point might question the logic in asking someone to do something that someone else on the team can do better. Consider this, what do you do when your one and only specialist decides to take a vacation, have a baby, or worse yet ends up under a bus. The more cross functional the team can be the more they understand the bigger picture of what they are doing. This will make integration smoother, more testable code, and allow your team to increase its velocity over time as you end up with more people who can do the same work. An added benefit is that your story estimating should also improve the estimate accuracy since more people understand what’s involved by doing the actual work.
One last area to mention here; the baggage of “that’s not my job”. Going back to the Wikipedia definition of unsuccessful team you’ll see how this person clearly aligns with that way of thinking. It’s everyone’s job on the team to ensure the success of the sprint. It means wearing different hats, doing work that may not have been initially assigned to you, even if you consider that work to be less difficult than what you normally do. In one particular case I’ve heard the argument that developers were selected to be developers because they have an aptitude to write code not test it. I’d assert that way of thinking means that we are in danger of failing as a team; we’ve serialized the effort it takes to develop our product within a given sprint. We must be able to do whatever work is in front of us, regardless of what your role on the team is; if we want a highly functioning team, get over it.
If you see this type of behavior on your team, you may be in the Scrumbut zone.
No comments:
Post a Comment