ScrumBut – Part 2: I’m a specialist and that’s not my job

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.

Avoiding ScrumBut: Why can’t test go in the next sprint

There are many possible failings that can occur when transitioning between Waterfall SDLC and Agile. You can skip daily stand ups, let a single sprint iteration go for months, don’t use a daily burn down, let the scrum master assign work, have talking chickens, or skip sprint planning. Any one or more of these makes your process begin to smell (Mike Cohn: http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf). One particular agile principle that I see questioned often is why does all of the testing have to be done in this sprint; why can’t we do dev one sprint and do testing the next. It’s not very efficient for dev to write code and test it at the same time.

These are all trappings of ScrumBut; looks like scrum, feels like scrum, but definitely doesn’t smell like scrum; in fact it smells very bad indeed. One of the key principles of scrum that shouldn’t be discarded is creating complete work within an iteration. If your organization has a history of constantly changing priorities, half finished work, and low team morale I would strongly urge you to focus on the principle of finishing your work during a sprint.

As software development professionals we should count on changing priorities, it’s the nature of business to reflect and adjust to meet the constantly changing needs of the marketplace and to effectively compete in today’s global market. Half finished work is work that has high potential to be thrown away because it can’t offer immediate value. Team morale suffers when hard work isn’t recognized by shipping to customers. In general this is something that we want to avoid whenever possible.

Going back to the question of why can’t we do dev in this sprint and test in the next; what happens when the CEO (or other senior manager) decides that you should immediately begin work on the “next” thing that will make an impact on the market. Testing a half finished product feature probably doesn’t qualify as a high priority and risks being tossed.

Teams that find themselves in this situation are kidding themselves if they think they can predict the future. As a Scrum Master I often find it difficult enough to ensure discipline to the current sprint without asking that we hold an additional sprint to finish what we started. When agile is proposed to management it’s pitched as being complete within a single sprint (narrow feature scope, complete work). If we remove this benefit from management we should expect them to question other areas the team finds beneficial (self organizing, trust, committed).

Let’s be disciplined to completing the work, don’t drag along technical debt and deliver high quality products to market faster. Yes, it’s a little more coordination effort on the part of the team but it’s also something that needs to be done to deliver on the value of agile.