When no one is looking, I would really like to sneak one extra line into the Agile Manifesto:
We prefer Attitude over Aptitude
That is, while there is value in aptitude, we value the right attitude more.
Don’t get me wrong: aptitude is certainly important, but if I had to choose between a proficient developer with a super attitude and a genius developer with a surly attitude, I would choose the former over the latter.
Rock Stars
There is a movement in IT recruiting circles to try to locate “rock-star” developers. I’ve always had an issue with this juxtaposition because it sends a confused message to the market. Let’s think about this for a minute: What are the qualities that are synonymous with rock stars? I’m sure you’ll agree that rock stars are typically perceived as charismatic, creative, and individualistic—good traits, right? Flipping the coin now, let’s look at some of the less laudable, stereotypical characteristics—think temperamental, attention-seeking, and arrogant, with a healthy dose of my-way-or- the-highway attitude thrown in. Does this sound like the type of person who would play nicely in a tight Scrum team? I think not.
Studio Musicians
Now, let’s look at studio musicians. These musicians are happy to live out of the limelight and instead support the lead singer in producing a great album. As long-time music industry veteran Bobby Owsinski writes in The Studio Musician’s Handbook (2009):
[jbox color=”gray”]
Studio musicians are expected to be creative, be extremely versatile, and have a formidable skill set… The fact that you are working very closely with other players, engineers, producers, artists, label and agency people (and who knows who else) usually means that the easier you are to work with, the more likely you’ll get asked back.
There’s a way to do things in the studio, and it differs from playing live. A studio musician’s protocol exists, and you’ll be expected to abide by it. Suffice it to say that if you like being the center of attention, then studio work may not be for you.[/jbox]
My conclusion: I’d much rather have a team of studio musicians than a team of rock stars.
Scrum Values
How should you go about selecting a team of studio musicians to ensure that your scrum doesn’t collapse under the weight of immense ego and constant bickering? The best place to start is with Scrum’s core values, which should be embraced by all team members, forming the basis of their professional personality. These values are shown in Figure 1.
Figure 1 – Scrum’s core values should be embraced by all team members.
In addition to these values, I am always seeking the following attitudinal attributes in my Scrum team members: energy, empathy, curiosity, and friendliness. Let’s explore what I mean in more detail.

Energy
I’ve worked with some really smart developers who were easygoing and friendly enough. Sounds like our type of candidate, right? Well, these same developers had special powers akin to those of the soul-sucking Dementors from Harry Potter. Using their zombie-like interactions, these developers were somehow able to sap all positive energy from a room, especially during the daily scrums, where the aim is to set an energetic tone for the entire day. So, if any low-energy team members are dragging the rest of the group down, see if there is anything bothering them that you can help with.
Empathy
Working in a close team requires patience and understanding. Each team member is reliant on others to help achieve the collective goals, and the reality is that we are all prone to having off days. A flat tire, a late babysitter, difficult personal circumstances, or simply feeling unwell — any number of things can throw us off stride. When these situations inevitably arise, teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield.
Curiosity
Development teams are cross-functional. As you’ll read in Shortcut 6, these teams are ideally made up of members possessing “T-shaped” skills who have the ability to work adequately outside of their specialty when the need arises to help avoid bottlenecks. This requires team members to be willing and eager to extend their skill sets, taking every opportunity to learn more about the functions that they are not necessarily expert at.
Friendliness
I remember working with a somewhat antisocial yet highly intelligent developer who I felt needed a talking to after a particularly critical attack on a new product owner. Our conversation went something like this:
Me: “Irrespective of what you thought of his ideas, there are ways and means of communicating without resorting to verbal nuclear bombardment.”
Him: “Well, I’m not being paid to make friends—I’m here to do a job.”
Me: “Well, yes and no, pal. You’re correct in that you are here to do a job; however, you are also being paid to work in a highly collaborative team environment. The more friendly you are, the more effective you will be.”
Him: (Silence)
When selecting a team member, I’m not just looking for someone who is polite; I try to identify someone who is genuinely friendly. It is much easier to rally to a friend’s aid than to a stranger’s (or even worse, someone you dislike), and it goes without saying that working with friends is much more fun (and that can only be a good thing). As Jurgen Appelo, author of Management 3.0 (2011), writes,
[jbox=”gray”]“It doesn’t mean you have to be close friends with everyone. That’s not even possible. But simply knowing a little more about their life, their families, their home, and their hobbies (and them knowing some more about yours) would be a great start.”[/jbox]
Respect
Respect is one of the core Scrum values mentioned earlier. I feel it is important to explain my interpretation of respect in more detail, because unlike the other Scrum values, its application can sometimes be ambiguous.
Let’s face it: people (even very smart ones) occasionally come up with some less-than-stellar ideas. Perhaps they misinterpreted some fundamental input, or maybe they just got excited and blurted out what was on their mind without filtering it first. Unfortunately, I’ve worked in several environments where a brainstorming session ended up feeling like a cagey Olympic judo match, the participants cautiously waiting for each other to slip up so that they could throw their “opponent” across the room with a heavy dose of criticism.
Hostility is the last thing you want in a creative zone. Instead, a constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion. As Dale Carnegie (1981) writes, “Show respect for the other person’s opinions. Never say, ‘you’re wrong.’” When people hear “you’re wrong” too many times, their ideas (including the good ones) are likely to dry up pretty quickly (see Figure 2). There are far better ways of disagreeing without being disrespectful.
Figure 2 – The effort you’re willing to contribute goes down the more times you hear “You’re wrong!”
Time to Make Music
I believe that Scrum’s success is premised on the fact that you have a team with the same positive, collective attitude. A group of brilliant yet egotistical individuals will never work as well as a group of solid yet collaborative teammates.
Remember that Scrum is about the team, not the individuals. That doesn’t mean individuals aren’t recognized as unique and integral; however, it does mean that their personal goals should be superseded by those of the team. Owsinski (2009) writes
Everyone is there to play their part as perfectly as possible. When the red light is off, the personalities are as diverse as you would see anywhere, but when it’s time to make music, everyone’s focus is 100% locked on the music.
Give me studio musicians over rock stars any day of the week, thank you very much!
If you liked this article, you can:
Subscribe to this RSS feed!
Find out more about forming Scrum teams by taking one of our CSM training courses.
Warm greetings Ilan,
With your article here, the nail has been hit right on the heads regarding how a Scrum team should operate.
This same debate has been ringing in the halls of my organization recently as our last 3 hires have been of the ‘rockstar’ kind and we have had a lot of the ‘rockstar’ attitudes. It has been important to be making note that the 3 hires were all for the one position. Each one has not lasted long.
I am begging my management levels to stop advertising for such people types as we are getting many headaches with them. Between them, they either turned up late, only wanted to talk about how awesome their own code was, spoke over the top of their more established team members (often with nil context) and made big demands and complaints shortly after they started (why don’t we have a gaming system like a Playstation or Xbox, why can’t I wear shorts to work and such things).
All the while, the rest of us studio musicians work together and keep getting the work done and completed. I think I will forward this article to my high-ups and hopefully our fourth recruit will be of the right caliber.
Thanks for your article.
(PS – sorry if my English is not super duper – my code is so much better than my English writing 🙂
Hi Sanjay – thanks for sharing your experiences and I sure hope that you are able to get some success. Let me know how you go.
I have to agree. I’ve worked with prima donnas – mostly on Waterfall-based projects – before and it was a right pain dealing with them and their egos, if only because in their minds, they’re right, especially when they’re not!
The issue is far more universal than with picking Scrum teams, although I’d reckon with Scrum it’s more crucial as you’re wanting whole team ownership and collaboration. Rock Stars tend to dominate the thinking and crowd introverts – often a good source of wisdom – out.
Yep, give me Session Musicians any day!
Hi John – yep you’re right – this isn’t a Scrum issue but is much broader however as you point out, the issue is certainly exacerbated within Scrum’s self-organizing teams.
Great website. Love the resources.
I guess I am a rock star dementor developer. I do set demands for my working environment, e.g management try to set me up with a 17 inch monitor. I scream loudly. A 27″ monitor is the equivalent cost of me working two hours for them. You try to control the way I dress? Why do you care? I deliver top quality, does it matter to you how I dress? You want me to come in early for what? Two hours of me waking up and then go to lunch?
You try to get me to commit to fulfilling “user stories” who is just a sentence. “We want a video archive feature” in a fixed amount of time.
Then I will get difficult and you know, not say yes, ask questions and ask for behavior and specifications. But then again, I am the difficult one.
I do scream loudly when the CI screen is broken. “Oooppps looks like someone broke the build!” when it has been down 4 hours.
I do say names out loud when I come across horrendous code that I now must work with. I do invite people over to explain to them in a friendly manner how to refactor the code not to make me scream.
I guess I don’t really respect the management and my co-workers. They have all died inside a long time ago.
I agree with the points in your post about what makes up a great team. I am just afraid that bad-managers who read this will get more arguments to shield themselves from their own incompetence. Oh my god, John is such a rock-star dementor. No wonder we never get any work done…
[…] have the personality to be the ideal Scrum team member. Ilan Goldstein wrote an excellent article in which he makes the distinction between ‘rock stars’ and ‘studio […]
[…] you hire a studio musician. Don’t hire a rock star. But when hiring a new team member, focus on the attitude instead of aptitude. Some contractors […]
[…] ein ideales Mitglied eines Scrum Teams zu sein. Ilan Goldstein hat einen exzellenten Artikel geschrieben, in welchem er zwischen „Rock Stars“ und „Studio Musicians“ […]
[…] have the personality to be the ideal Scrum Team Member. Ilan Goldstein wrote an excellent article in which he makes the distinction between ‘rock stars’ and ‘studio […]
[…] you hire a studio musician. Don’t hire a rock star. But when hiring a new team member, focus on the attitude instead of aptitude. Some contractors […]
[…] you hire a studio musician. Don’t hire a rock star. But when hiring a new team member, focus on the attitude instead of aptitude. Some contractors […]