Scrum teams are cross functional. Every person on the team has skills and experience that they contribute, turning the requirements into the best possible increment possible for them. One never knows when an insight, a memory, a skill rarely used will come into play. That is the beauty of Scrum teams, the growing synergy of the unanticipated.
Many have trouble setting aside the labels that have confined their participation. Labels such as “business analyst” in no way limit someone from knowing the endless loops are bad. People previously known as “quality assurance” often can see that architecture will be untestable, hence not viable.
I was in a bar last week (don’t ask why) and saw someone similarly constrained.
An office building was going up across the street. It was nearly complete, and had beautiful brickwork throughout.
During its construction,, the construction workers stopped by the bar after work. They would share stories, discuss the odds for the Red Sox, and try to relieve some of their aches. One of the most vocal was a bricklayer, a duck from Nova Scotia. Apparently, his flock had left him behind six years previously. He had to find gainful employment, so he turned to an opening in brick laying and masonry field, starting as an apprentice and working his way up.
Today, though, the duck was pouring them down. He was despondent that the project was over, he was out of work, and winter was approaching. He turned to bartender, moaning of what was to come of him.
The bartender, knowing that there was a circus in town, told the duck to go to the circus and offer his services.
The duck rejoined, “Why would a circus want to hire a brick laying duck?”
Ken Schwaber's Blog: Telling It Like It Is 
Cross functionality is a fine thing, but easier in principle than practice. True, the “business analyst” label doesn’t limit someone from knowing that endless loops are bad, but someone probably trained as a business analyst is probably in a poor position to rewrite code to eliminate an endless loop.
Much of the time I hear about scrum teams being cross functional — I hear it from OUTSIDE of scrum teams (coaches, trainers, experts). The view from inside teams tends to be … a wee bit different.
Cross-functionality means everyone contributes according to their skills and capabilities. Nobody should say, “I don’t do that work. I’m a business analyst or coder”
Ken
Please ignore that first “probably” I’m sure that in this hypothetical example they were, in fact, trained as a business analyst 🙂
The opposite of the cross functional team (or T shaped skills) is of course specialization (http://www.scrumalliance.org/community/articles/2011/january/specialization-and-generalization-in-teams). I’ve been in those frustrating situations much to often, feeling I could be making a contribution to move the project forward but being blocked by a ‘Title’ or job description boundary.
Convincing others to break the ‘it’s just the way it is’ or ‘it is what is is’ mindset is difficult. Secretly they believe they could make the difference but political and social impediments are the blocker.
Not hurting people and being respectful is important, however one still needs to be open to new ways and not be blocked by culture. Become an iconoclast from within as Ricardo Semler might say and be a respectful change agent. But in some (and a small some) environments it’s best to move on :-;
And on a personal anecdote – don’t move someone on for purely having a different view (like this one). This is emotional short term reaction. One must ask if this is actually the best move for the organisation. It speaks of very low emotional intelligence and people in charge need to be better at this in general.
I think Nick and UberScrumster make valid points. And, having said that, I also think there’s big difference between a dominant role and a pigeon hole.
I used to work in a pretty stove-piped organization with a graphic designer who really want to get into web development. So, almost every project I worked on I dragged him with me. I did the more complex tasks of doing database queries or creating PHP templates. He did more of the front-end and style sheet work, and who better than the guy who designed the thing in the first place? This freed me up to worry about refactoring and writing code well instead of, “Make it purple. Change the font face.” requests from “the designer.” And, he did start getting into more complex concepts in code. But, if we had stuck with the boundaries as defined – that would not (could not) have happened.
Each person in your story stuck more or less to his specialty and interest – though maybe not so much to his official job title. I think this proves that there still is a place for specialties/disciplines/whatever we want to call them. We are NOT all of us, good all-around-ers – and sometimes are just not passionate enough about some of other stuff to it justice. Agile/scum should never get to the point that people are forced out of their areas of interest to do things they don’t care about just so they can be cross-functional; the point should only be to not restrict them and to not create walls/silos.
I know this is an old post but I liked the terms ‘dominant role’ vs ‘pigeon hole’!
There are two roles being challenged in Ken’s story:
– The duck, who does not accept that his role as an talking avian bricklayer has potential applications beyond the construction industry
– The bartender, whose role as an advisor clearly does not impress the duck
The first challenge is potentially the easiest to deal with, in so far as it represents a class of problem that is well understood. The duck needs to do a customer segment pivot, in Lean Startup terms.
The second challenge is the thornier of the two, because advice (although sound) is coming from someone whose role provides no concomitant level of assurance. A barman is there to dispense beer, not career advice. Many Scrum Masters experience the “barman’s dilemma”, where the coaching they give about organizational transformation is dismissed on the grounds that they are team-level managers and thus unqualified to comment.
Pingback: Quick Agile News from Digital Saber Solutions - Digital Saber Solutions
Is it notable that the text is “Cross-functional teams have all competencies needed to accomplish the work…” verses “Cross-functional individuals having all competencies needed to accomplish the work make up teams…”? I believe it is.
I think when it comes to this part of Scrum teams people really like to try driving home the point that a Development Team is comprised of people all sharing the title “Developer” with “no sub-teams … regardless of particular domains that need to be addressed…” While that in and of itself is not a problem, often the message is twisted to all people on the team having all necessary skills. I don’t believe the intent of this singular title is that all people on the team must be able to do all work that the team gets. My thoughts are supported by the text “Individual Development Team members may have specialized skills and areas of focus…” The final part of that section is what really should be focused on: “… accountability belongs to the Development Team as a whole.”
The team is cross-functional. The title “Developer” could just as easily have been defined as “Team Member.” In fact, that may be worth looking into. Just as a rugby team is filled with individuals that have different talents but succeeds or fails together so to the Development Team is filled with individuals with different talents that succeeds or fails together. Just as every “Rugby Player” on a team is not doing the work of a Left Wing not every “Developer” is going to do the work of, well, a developer.
Cross-functional synergy doesn’t mean every person on the team is going to write code, clarify requirements, and build UIs. It does mean that everyone on the team will work together. They will all use their best skills to the best effect possible in pursuit of the definition of done. (I learned this as “aces in their places” what feels like a lifetime ago.)
I pay a visit everyday some websites and blogs to read articles, except this weblog offers quality based articles.
Pingback: Cross-Functional: Teams vs Individuals | Our Agile Journey
wonderfull article .i appreciate your writing.looking forward for more on this
visit- http://www.scrumstudy.com
Pingback: Agility without Labels | Onlive Engineering Corner
Pingback: 11 tips on hiring great Scrum Masters | Jerónimo Palacios
Pingback: Should the development team ever write test cases or review them in depth? | DL-UAT