3

I have this issue for a while now: "rockstars" (e.g. a contractor or freelancer, who's very good technically) tend to be quite independent and reject any form of process. Many of them don't have the patience to learn about the process, as they focus on building things and are driven by tangible results.

But on the other hand, many of them don't work well in a team, as they feel restrained by the team, rules, even Agile frameworks (not even mentioning Scrum, because Scrum seems to be the devil for these guys).

My question is: how do you use Agile to make sure you keep these guys in the company? They are mostly very talented individuals, but how can you use the tools Agile offers to help them have their freedom but also work with others?

*I do realise this is more of a people / group dynamics question but I find that many issue come from creating an Agile team, rather than using the right practices with people that have no issue with using Agile.

Improve this question
6
  • 2
    to be fair, SCRUM is a way of completely controlling the work that is going to get done and usually that means not allowing any exploration or creative thought on the part of the team members which is fine for emergencies or short-term projects but results in limited career growth.
    – user27307
    Commented Apr 5, 2017 at 18:21
  • @RudolfOlah do you mind detailing how Scrum is restrictive? I am asking because the way I see and use Scrum is: it's a tool, I can use it in a very rigid way (e.g. Huddled must answer the 3 questions), or just adapt it. I'll continue with the huddle example: the team said it's useless, so we did a simple exercise to decide what should be discussed in the huddle to make it useful. The idea was: it's your team, it's a tool, the objective is to look into progress towards reaching our goal. How do you want to do it? How often do you want it? And same thinking worked with other tools.
    – Andreea
    Commented Apr 5, 2017 at 21:49
  • Scrum is a framework, a container for other techniques, methodologies, and practices. Rudolf: There is a lot of opportunity for exploration and creativeness, and the Development Team is empowered to determine their forecast. It sounds as if a poor experience with false Scrum has you misinformed. Andreea: Directly answering the three questions is a common misconception resulting in a rigid implementation, but that technique is certainly not required and is often discouraged. One can work with an agile mindset to create their own processes, but do not call it Scrum if it violates the framework.
    – Alan Larimer
    Commented Apr 5, 2017 at 23:46
  • Multiple poor experiences @AlanLarimerPSM and always imposed from above and rigidly followed and completely ignore project management techniques. I'm saying you can run a project using SCRUM and have it succeed, exactly by limiting scope and allowing for rapid change. But you can't expect SCRUM to work for all projects and you can't use SCRUM sprints to run a marathon. So I will agree it isn't real SCRUM. Andreea that sounds like you're taking the good team-building collaborative approach!
    – user27307
    Commented Apr 6, 2017 at 2:37
  • I agree that Scrum doesn't fit all projects and all people. That's why, if I can't work with Scrum and creates only tension instead of a collaborative work environment I move on to using parts of Scrum with other frameworks. It's not pure Scrum, indeed but again, Agile is about people over processes. As long as I address the concerns that Scrum tools are used for, it works out fine. If not, iterate.
    – Andreea
    Commented Apr 6, 2017 at 2:41

6 Answers 6

Reset to default
7

Here is the thing - the rockstar is rarely a good programmer.

Most programmers which are great technically understand the need of teamwork. It is a core part of the job, something you need to understand if you want to have any semblance of true skill on the field. More often than not you'll find yourself working alongside other people, sharing results, teaching and learning with them.

More advanced coding skills come with the need to make your code manageable by other people. Unit tests, dependency injection, correct use of patterns - good code is easy to understand and easy to change as needed, easy to teach someone else to work on.

This isn't the code that Rockstars use. A Rockstar programmer is, more often than not, a average or below average developer with a few obscure tricks under his sleeve and good sales skills. He appears to be more skilled, but he uses his charisma and his aggressiveness towards the team to keep himself above the others. He can't play with the rest of the team - if he does that, his lack of skills will show up pretty quickly.

I've worked with a lot of rockstars in the past. While they could deliver working code most of the time, most of them lacked basic understanding of what exactly they are doing. They failed to grasp some concepts that were needed for deep understanding of what they should and shouldn't do. But they did look awesome, with arcane codes that worked for some miraculous reason and bold, incisive speeches that made everyone look at them with a bit of wonder.

But eh, they were just winging it. Really, any dev that goes around saying "I'm the best, you guys suck, I'm the holy jewel of the team!" probably is just winging it and has no real sense of what he is doing.

This is a variant of the Dunning-Kruger Effect that is really prevalent on IT.

Improve this answer
11
  • 2
    I wish I could upvote multiple times. A "rockstar" programmer just isn't. If he were really that good, he would be able to work in a team. Being a good programmer includes writing code that can be used by others.
    – nvoigt
    Commented Apr 7, 2017 at 12:06
  • 2
    I don't want to downvote this yet (I'd like to give you a chance to revise), but "rockstar" and "ninja" are not at all the same thing as cowboy coding. It can also be used as shorthand for subject-matter expertise, or the 10x programmer effectiveness that some people have observed compared to the "average" programmer. The OP is really talking about loners, not coding superstars. As a result, I think your answer addresses the Y in an X/Y problem.
    – Todd A. Jacobs ♦
    Commented Apr 7, 2017 at 13:49
  • @CodeGnome My understanding reading the OP questions is what I know by Rockstar Programmer - someone whose ego is far bigger than his skills that fail to work with others. I'm aware that other definitions may exist, but that's the one I'm going by!
    – T. Sar
    Commented Apr 8, 2017 at 0:18
  • I think this theory falls into its own trap as it were. the rockstar by definition produces valuable products. Complaining about abstracts like grasping concepts making a 'good programmer' is just academic eliteism
    – Ewan
    Commented Apr 9, 2017 at 14:32
  • ie would you complain 'flappy bird' didnt follow OOP when you were making god knows what in ad revenue per day
    – Ewan
    Commented Apr 9, 2017 at 14:33
6

  1. Find someone else. In agile it's all about team performance, not individual performance. Adding an individual to the team who doesn't fit in can really affect the rest of the team. If you can choose between a technical rockstar and a teamplayer (with just enough technical skills to do the job right), it's an easy choice to make.

  2. Be very explicit about expectations. As you said, they are strongly focused on building things and tangible results, neglecting other goals. If for instance knowledge transfer is important, try to make it as SMART as possible ('your job is to make sure that within 4 weeks Sally and Isaac are able to do technical task x on their own').

  3. Work with the whole team on team roles and team dynamics. Just any team building exercise with a focus on diversity will do. Team role tests (Belbin) or tests about personality/behavioral preferences (discovery insights) can give insight in each team member's different strengths. The key part here is that there are more ways to be valuable than just delivering lines of code.

  4. Be aware that high performance can be high maintenance. They have plenty of job offers to choose from, know their market value and are not easily satisfied. If you want to build a good working relationship, then you need to talk with the rockstars about their own personal goals and motivations, and give them an opportunity to work on these. An example is setting aside a bit of time to work on long-term innovations, or exploring new technologies.

Improve this answer
5

Summary

They are mostly very talented individuals, but how can you use the tools Agile offers to help them have their freedom but also work with others?

You are conflating things which are not orthogonal. Agile frameworks are based on teamwork and collaboration, so you need to consciously select for that in your team composition even more rigorously than you select for skill.

Analysis and Recommendations

There are mediocre teams that use agile frameworks like Scrum to great effect because the team-based approach enables average programmers to collectively function at a reasonable (and consistent) level of performance. There are also high-functioning teams full of collaborative ninjas who work together to turn out stellar work.

In the middle, you have teams with a few high performers, and some middle-of-the-road folks. As long as everyone works together, the high performers can pair or mentor others in the team to improve overall performance and skills transfer, while the remainder of the team works hard to ensure that they are contributing to the overall effort without becoming "help vampires" or creating drag on the team.

Agile frameworks will not make inadequate developers "rockstars," nor will lone wolves (rockstars or not) improve the overall performance of the team. The team succeeds or fails as a unit; that means that skills definitely matter, but teamwork, communication, and the ability to collaborate effectively matter more.

When you build your team, you need to make sure that you are selecting for the right mix of skills and cultural fit that make an agile team successful. That means filling your team with cross-functional (or at least "T-shaped") team members who are on board with the agile framework and its processes, and who are willing to continuously improve their team collaboration skills.

Anyone who can't work within the framework or collaborate with the team should be placed in a role outside the team that will not impact the team's ability to deliver the project. That precludes treating them as advisors, subject-matter experts, or otherwise creating a project dependency on those people. They may or may not have a place within your company, but lone wolves have no place on an agile project.

Improve this answer
1

There are a few approaches you can use:

  1. form a clean-up crew that cleans things up after the rockstar performer gets them done
  2. clearly define the limits that the rockstar performer will operate within
  3. let the rockstar performer create prototypes
  4. emergency handler

Based on your quotes:

...they focus on building things and are driven by tangible results

This means they will do work that is visible and has a result.

...on the other hand, many of them don't work well in a team, as they feel restrained by the team, rules

That means there may be technical debt or documentation that needs to happen.

Clean up crew

What you can do, which is a little unfair to the junior members of the team, is to get the junior members of the team to clean up after the "rockstar". They turn the tangible result into a well-engineered result that can be maintained by others.

Clearly defined limits, split the work

You can also split the work into modules and boundaries that have clearly defined limits. The rockstar performer can play in their sandbox without messing up the sandbox of others and they can move as fast as they want. If they get the module done quickly, then they have free time that they can use for other projects or to become more collaborative or to train themselves. These are all good outcomes.

Prototypes and sales demos

The rockstar wants to create new things and deliver a visible result. That's perfect for sales demos and prototyping where the initial result is passable and can get the sale or prove that a certain approach will work.

Most prototypes and sales demos can be developed solo or by one developer in collaboration with sales/marketing/designers/managers.

Emergency Handler

Because they want to do things quickly with tangible results, they can be excellent bug hunters and emergency handlers. The process for both of those situations is simple and perfect for the rockstar.

If your project has an emergency and needs lots of work done, let the rockstar performer at it. If there's lots of high priority bugs, they will want to show off how good they are at fixing them. If there's a real emergency with some of the modules, the rockstar will re-create them but they will work to some degree (though they will be loaded with technical debt).

Improve this answer
1

Inability to work in a team (including following the agreed-to processes) is a problem in itself, and it is independent of knowledge, creativity, or productivity.

Knowledge, creativity, and productivity are not personal handicaps. Having a team with a disparity in those traits is a management problem, not a problem with any particular individual.

If management cannot assemble a team of individuals with alike productivity (lack of budget?) it must find a way to work the disparities out.

Choosing to only hire among the average, to avoid the disparities, seems silly.

Analogies can be made to the recruiting that happens in good sports teams. The budget is never enough to have an all-star team, so coaches learn to manage teams in which less than 20% of the team members are of outstanding performance.

In short, the problem is probably not with the individual, but with the coaching.

Improve this answer
1

So. Lets get this out of the way. With a freelancer and to a lesser extent with a contractor you should not be managing how they work. Otherwise they will be an employee and you will have to pay tax. Set the task an let​ them get on with it. (I understand that in practice the task might be, complete backlog item X and check it into the company source control)

Now to the meat of the question.

Scrum and agile methodologies are in some ways designed to turn developers into task completing machines. The PO specifics the tasks and the dev team knocks them out to minimum spec as quickly as possible.

If min spec isn't good enough the PO adds another task with more specs.

Now a 'rockstar' programmer is used to taking a vague business idea and making something. They write the spec, do the work, change the spec as they go, add stuff they think is good, skip stuff they think will take too long etc.

Now you need agile (or some process) because the rockstar approach doesnt scale. But 9 times out of 10 you will lose the rockstar. Becoming a cog in a dev machine will be a massive step down in responsibility. Moving up to management is a move away from the coding they love.

You can invent software architect style roles but really a small startup is the best fit for them and you are no longer a small start up.

Improve this answer
3
  • 2
    +1 for freelancers are not employees. It is not reasonable to expect them to integrate into a (permanent) team when they are just there for a project. And it is not reasonable to expect a freelancer, who chose to work independently, likely in order to be their own boss, to be willingly managed like an employee.
    – amon
    Commented Apr 9, 2017 at 23:27
  • Hold on, as a freelancer for a very long time, I know that we get paid a significant amount of money to do the work we do. We don't pick and choose what part of the task we want to do, we go to a company to get told what to do, and get paid very well to do it. If I turn up to a company and they say "Stand up with us, then pick a task and match our Definition of Done", I don't pout and say "Nonononono, I only take vague ideas and then implement them the way I see fit". I've never heard of the concept of "treat that dev differently because they're not an employee". Strange distinction IMO.
    – dKen
    Commented Apr 12, 2017 at 5:12
  • how do you avoid IR35 in that case?
    – Ewan
    Commented Apr 12, 2017 at 5:14

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.