11

Where I'm currently working, I'm the only BizTalk/Integration developer. Other developers are specialized in hand-held devices, others in Silverlight, and other in electronic devices. I don't know what they know, and they don't know what I know. How would SCRUM work in this type of environment. Obviously, it would be good to cross-train and share knowledge, but I don't particularly want to be a hand-held developer.

Isn't one of the theories of scrum is that all team members should be able to do each others work. We don't have 7 (plus or minus 2) people of each specialty.

Improve this question
2
  • 2
    So what is the concern? Are you going to work together on a team to create something or are you the 'manager' of such a team? Or how can SCRUM be applied in such a heterogeneous team? Not clear what the problem is...
    – PhD
    Commented Jun 16, 2012 at 3:39
  • Trying to determine if Scrum should even be considered in such an environment. Is there an acid test of when Scrum does or does not fit?
    – NealWalters
    Commented Jun 19, 2012 at 13:35

2 Answers 2

Reset to default
9

A scrum team can very well be composed of more-or-less specialized members. This is the situation of almost every team and this can be a good thing IMO, as long as the team can self-organize itself to take advantage of its specialized members.

Please read these two articles for more information:

Balancing specialization

The need for balancing specialization occurs when a team takes shared responsibility of all the work in a Sprint. As a result, team members need to learn a little bit of each other's specialization. This does not mean that all team members must be generalists, but that members move away from the other extreme -- being a specialist in exactly one area. Team members will learn multiple-specializations but probably not all of them.

Improve this answer
4
  • 1
    HI Mattj, I added one of the main ideas from the first link to your answer. In general, links are great as a supplement to the answer, but it's always a good idea to include some of the main ideas in the body of the answer. If the links ever break, an answer with a summary still has value. If my edits lost the main idea of your answer or if I chose the wrong summary, please feel free to edit further to clarify. :) Thanks and welcome to PMSE!
    – jmort253
    Commented Jun 16, 2012 at 21:16
  • The main idea I take from this answer is that Neal won't have to suddenly become an expert on the other platforms, but may occasionally need to learn some of the other skillsets to tackle the occasional small story. In most cases, he would most likely take stories that are specific to his skillset since people do better at what they specialize in.
    – jmort253
    Commented Jun 16, 2012 at 21:20
  • @jmort253 thank you for your edits and tips.
    – Matthias Jouan
    Commented Jun 17, 2012 at 8:45
  • 1
    Excellent links, thanks! In my case, I'm a contractor, and they brought me to do "blue" as the article uses colors an example. So I think management will make sure there is some blue work in each Sprint. But they aren't officially doing Scrum, and I wanted to make sure that it wasn't crazy to suggest it when we basically do have blue-programmers and red-programmers.
    – NealWalters
    Commented Jun 19, 2012 at 13:43
3

I don't think this has anything to do with Scrum or any other management methodology/process. Yes, scrum suggests having a 'vertical skillset' but that's a guideline and not a rule. It does make things easy if everyone can do everything with varying levels of expertise.

In your specific case I guess you need to take extra care for knowledge sharing and put in extra time for knowledge transfer. So even if everyone can't do everyone's work at least they can understand it in some detail so as to be helpful in debugging, system design etc.

You could still use Scrum with the daily stand-ups, burn-down charts, sprints etc. However, you must decide, as a team "how" to do the work. If they are experts as you claim then let them do their job but spend more time on 'interfacing' - both human and code (latter more important from implementation POV). Have special meeting times about 1-2 times a week where each specialist holds a 2 hour session talking about their area and 'educating' everybody. Allocate time for this and adjust the schedule estimates accordingly. I'm sure everyone will know something about everybody else's code but not enough to make changes. But it's upto the team how to get rid of information silos - that's the only reason Scrum suggests everyone be able to do everything to prevent superstars or SPOFs (single points of failure).

I guess you need to discuss this with your team to figure out how best to address this 'risk' IMHO.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.