Scrum for specialists teams

Question

Scrum is best for teams with generalists members, that is teams where 2 people at least can do the same tasks. My main concern is to find good solutions to adapt scrum (what to keep, what to remove, what to improve) for teams made of specialists?

Suppose you have a team of 5 developers (not real, just for the example):

1. One mathematician with strong skills in C;
2. One DB developer;
3. One Web Developer;
4. One UX/GUI developer;
5. One software architect;

Here, all are specialists and no one can replace someone else (I don't care about the risks of building such a team, I want to focus on scrum). So, in a scrum context, here are my thoughts:

1. Useless spring plannings: indeed, when the mathematician says that a specific task is worth 2 points, nobody can vote against him;
2. Useless team velocity metric: as everybody can allocate any number of points to his own tasks, computing velocity makes not sense;
3. Replace daily scrum meetings with weekly (longer) scrum meetings: as each member of the team is working on his own tasks, daily scrum meetings should be really important to keep a "team spirit". However, daily scrum meetings are supposed to last around 15 minutes. This is clearly not sufficient to understand what the others are doing and will do. Moreover, the mathematician will most of the time answer the same things: "I am still doing %&Lo( + ?$$+&)"... Weekly meetings would give more time. To keep the same meetings time between "initial" scrum meetings and "weekly" scrum meetings, each weekly scrum meeting should last (5 days a week, with 4 weeks sprints, with sprint meetings lasting 4 hours and daily meetings lasting 15 minutes): (4*60 + 20*15)/ 4 => 2h-2h30 which seems reasonable.

Or is scrum still usable? Maybe another agile technique should be used?

Answer 1

Scrum is not a silver bullet. Not every project has to use Scrum in order to succeed. The situation you are describing however sounds like a great fit for Lean / Kanban. You may wish to check it out.

Kanban basically asks you to do only a few things, none of which are at odds with the kind of team you are describing:

• Visualize the flow of value, i.e. the Kanban board. The Scrum board is a specific application of a Kanban board; It is possible to adapt it to allow for specialization.
• Limit the Work In Progress (WIP), so that the amount of work assigned to the team is just enough to keep the work constantly flowing - i.e. no "blockage" on either the start of the stream (design) or the end (deployment).

You might want to check out some references about Kanban:

• One day in Kanban Land
• Priming Kanban (free EBook)

Answer 2

You are focusing a bit too much on the mechanics of scrum/agile without looking at what agile is supposed to deliver. You say that if the maths guy estimates 2 points no one can say he's wrong. This isn't the goal. The goal is to agree an achievable set of objectives for the upcoming sprint. As the expert on that task he will know best how long it will take.

"So what if he lies or just gets it wrong?" you say. In my experience people under estimate more because they fear they will be shot for giving an accurate guess. Others under estimate then add a safety margin which balances everything out and the odd lazy person will over estimate so they don't have to rush. Of the three the first will be picked up on the velocity tracking, the second while sounding wrong, is working and the third is something you have to deal with outside of scrum.

The daily meeting still provides benefits. There are dependencies between team members even if they are each specialists. The UI guy may be waiting on the server guy to fix a notification bug. The server guy may be waiting on the maths guy to figure out why a calculation is wrong. It also isn't just about how their work affects you. If a team member is constantly being delayed because of "Reason X" but they haven't taken time to mitigate future "Reason X" occurrences, that can be challenged.

Answer 3

If you have specialist with qualifications like the ones you described, your assumption that each one is working on his own task, with seldom need to communicate to the others, is IMHO wrong. In fact, to realize a new feature (a "user story"), you often will have to

• change your database
• add or change the GUI or the Web interface
• combine this with the correct business logic (where, perhaps, you "mathematician" comes in)
• make sure that all those changes work well together

So I guess they will have to communicate much more as in a team of generalist, where everyone could work on a different application / user story, making all the necessary changes to all application layers by himself. Thus, all the team activities from Scrum you listed above make a lot of sense for such a team.

Answer 4

Scrum is certainly still appropriate for your situation, but so could other frameworks.

To deliver new features you are likely to need all or many of these skills. In order for the team to make decisions that impact one another and work together they'll need to communicate. The longer the time between Scrum meetings, the longer a negative plan can stray the team. By meeting daily, the team can address these situations quickly and come up with a new plan.

I would like to address some specific topics you bring up as well:

Cross Functional Teams A team would be considered cross-functional if it has all of the skills needed to deliver on a sprint goal and/or product backlog item. This does not mean that there are 2 people for every job.

Sizing It's important to remember that we are sizing a business problem or need, not a solution or part of a solution. For instance, Integrate social media/Twitter into our e-commerce site is a problem which requires UX, UI Design, Programming, Database, and knowledge of the Twitter API. A team should be sizing that as a unit since they are, as a team, going to be delivering this functionality. This size is not going to be 100% accurate, but we do find that, in aggregate, forecasts based on relative sizing are more accurate. This means that some will be high, some will be low and taken together the calculated forecast is more accurate than estimated duration.

Useless spring plannings Sprint planning is a time to collaborate as a Scrum Team (Development Team + Product Owner + Scrum Master) in determine what should be produced and coming up with a plan for how to begin. Some teams will break these Product Backlog Items chosen into tasks while others will come up with their own way to progress, like tests that must pass (think XP).

This is a two way collaboration. Assigning the team a set of PBI's and saying "go" is a dictator's role. The team is negotiating with the Product Owner to maximize the time in the sprint.

Useless Team Velocity Metric With teams sizing problems and needs of the business that cut through the architecture/system and past experience telling us how many of those the team have been delivered in a consistent time box (sprint), we can now provide a team forecast for the remainder of the backlog.

Again, no two sprints will be the same and the smaller the sample set of Product Backlog items you use, the less spread out the error in estimates will be. Think of it like the stock market; it has always gone up, but that doesn't mean we don't have down years. At the aggregate you can make money, but on any given month, quarter, year you will guess wrong.

Replace daily scrum meetings with weekly (longer) scrum meetings The Daily Scrum is there to provide the team with a 24hr feedback cycle and opportunity to plan for the next 24 hours. Nothing more, nothing less. The "Three Questions" are meant to help facilitate that effort.

If you don't have any feedback for 5 days, I believe your tasks are not fine grained enough. This is simply my opinion, but it is based on my experience as a coach and team member. Teams should be talking, planning, and integrating their efforts FAR more often.

Conclusion Scrum is meant to facilitate learning and balancing that learning with delivery (where real learning happens). Experiment with your processes and tools over time and use Scrum to inspect the impact. Try moving from daily to weekly Scrums and see if it helps or hurts the teams ability to deliver the right functionality. That may work for you.