4

I have worked in an organization where we implemented Scrum, but we dropped the roles "junior" and "senior." Senior developers still regarded themselves as seniors (with all the attitude that comes with that).

I work as a Scrum Master now in a different organization, and I am thinking of implementing the same policy. But this organization has juniors, seniors, QA, and development managers. I am thinking of dropping all the titles and make everyone a developer, and having a lead developer on each team.

Is this a workable approach?

Improve this question
1
  • Your question was lightly edited for grammar, and to prevent closure as a survey or opinion poll. Please feel free to continue editing if you want to improve the question further.
    – Todd A. Jacobs ♦
    Mar 6 '16 at 18:58
6

A Scrum development team is self-organising and avoids the traditional hierarchical roles such as lead developer.

The idea is for team members to lead by setting an example and by gaining the respect of the other members of the team. For example, in the case where you have a very experienced develeper on the team they may often take technical leadership with the full cooperation of the team due to the respect the team has for them.

The danger with having a lead developer role is that it can disempower other members of the team. Say, for example, that 3 developers on the team want to use approach X, but that the lead deverloper wants to use approach Y. The lead developer's role lets them override the opinion of the other team members. Whereas in a Scrum team they would argue the case for approach Y with a good chance of winning the argument due to the respect the other team members have for them.

The benefit of this approach is that all team members feel like they have a buy-in to the decision making process. This helps all of the team to pull in the same direction and to work with enthusiasm for the chosen technical approach.

Improve this answer
3
  • Very good point.
    – dqm
    Mar 6 '16 at 22:39
  • I think you did a good job of explaining why Scrum doesn't have hierarchies within the development team. My answer focuses more on the framework requirements, and I think does so quite well, but you did a very nice job of addressing the underlying values.
    – Todd A. Jacobs ♦
    Mar 7 '16 at 6:21
  • "The danger with having a lead developer role is that it can disempower other members of the team." This depends on the methodology you're using. For instance, DSDM includes an explicit Team Leader role: agilebusiness.org/page/…
    – nick012000
    May 25 at 6:43
2

I think Barnaby hit this pretty solidly on the nail.

You can have grades of experience in your company, and in fact may not be able to get away from it given how HR often stratifies job titles. However, what you need to make clear to everyone is that it is the team that is measured on the collective success or failure of the team. There are no rockstars in the team, just teachers and students which can be interchangeable depending on the skill (Bob is an awesome C++ coder and teaches Sally. Sally is a goddess at Java Script and teaches Bob).

If you are a rock star coder, and your team is struggling to perform, you don't get a new team. Instead you get asked, "what are you doing to help the team get better?" I'll take a team of average coders who are really good together over a couple of individualistic rockstar coders pretty much any day.

There is a newer HR assessment model that really supports this. Instead of an individual being reviewed on their personal success, the model is split 50/50 between team and individual development. The first 50% of your review is based on the success of the team. If the team score is 100%, you get 50 points. If the team scored a 50%, you get 25 points.

The second half is based solely on individual development based on goals set by the employee and manager. Did you learn that new language you signed up for? Then you get a high development score.

The key is the individual isn't measured for work done, the team is.

Improve this answer
3
  • I like this. I upvoted, but think it would be stronger if you said they were measured on their collective success or failure, as that speaks to heart of the flattening of roles within Scrum. Just my $0.02.
    – Todd A. Jacobs ♦
    Mar 7 '16 at 6:17
  • 1
    Good point, edited. Also added a comment on a progressive HR system that works well to support this.
    – Joel Bancroft-Connors
    Mar 7 '16 at 6:33
  • 1
    " I'll take a team of average coders who are really good together over a couple of individualistic rockstar coders pretty much any day." - I think the mileage of this attitude may vary. If you're developing a relatively straight forward web site for a client then a responsive team who work well together and communicate excellently are key. However, if you're trying to solve a really difficult computer science problem then your average coders may well simply be unable to solve it.. With some problems, average devs can be pretty much useless no matter how well they work together.
    – Benj
    Jul 6 '17 at 8:40
1

TL;DR

Scrum only has three roles. Using other titles or roles within the team (including "lead dev") is very much a Scrum anti-pattern.

Scrum Has Exactly Three Roles

While you can have people of various skill levels and specializations on Scrum team, the Scrum framework only has three roles within the team:

  1. Product Owner
  2. Scrum Master
  3. Development Team Member

That's it. You can't call it Scrum if you have roles like "Junior Assistant Flunky in Charge of Bending Paperclips" within your Scrum Team. It might be a useful skill that adds value to your project, but it's not a legitimate role within Scrum.

Improve this answer
5
  • I hear you and I will correct you: 3. is Development team (without the member). Now as far as the "lead" goes, this is someone in the company that knows the stuff inside out and could be the go-to person to get answers and make suggestions.
    – dqm
    Mar 6 '16 at 17:49
  • 2
    @dqm Correct all you like. You can't have a Development Team without team members, so I'll stick by my assertion that Development Team Member is a valid individual role within Scrum. As for your other assertion, it doesn't matter how experienced this person is; there is still no role within the Development Team other than "Development Team Member." However, you're certainly free to do other things; you just can't legitimately call it Scrum.
    – Todd A. Jacobs ♦
    Mar 6 '16 at 18:53
  • Yes, fair enough, point of Agile at the end of the day is to actually be Agile and adjust to fit your needs. I doubt there's someone out there who's going to spank us if we call it Scrum but have a lead dev!
    – dqm
    Mar 6 '16 at 20:29
  • @dqm why do you need to define the title "lead dev"? How is that helping the team perform better. In a proper Scrum Team, every team member should be able to be to go-to person to get answers and make suggestions.
    – Sebastian
    May 27 '19 at 7:49
  • @dqm Your comment above is incorrect. The Scrum Guide say, "Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person [and] although implementing only parts of Scrum is possible, the result is not Scrum." You will not be spanked, as spankings aren't an agile technique, but you are clearly being told what you're doing isn't Scrum by the authors of Scrum. See also: scrumguides.org/scrum-guide.html#team-dev and scrumguides.org/scrum-guide.html#endnote.
    – Todd A. Jacobs ♦
    May 27 '19 at 15:04
0

Definitely, the most important thing to work for is actual teamwork among the various developers. It's inevitable that some are more senior than others – often on very different skills. The #1 thing to make sure of is that the people who are very good at one particular thing don't simply "go off by themselves and do it." You need to make sure that they first explain to others what they're going to do (and why), and then show the others what they've done. Everyone is thus involved, everyone gets a chance to learn, and, inevitably, someone notices something that the more-experienced person accidentally overlooked.

The notion of "plan the work, work the plan" is there for a reason. But many teams who call themselves "teams" don't actually follow it.

A year or so ago, I became involved with a "team" that was really just "lone wolves, in a pack." Their former "manager" was content to merely be a supervisor, asking them once a week what each of them was doing and ending the meeting by telling them to keep doing it. Everyone was spending their day busily working on whatever it was that "they" did, as though everybody else in the room wasn't even there. It was a bit of a culture-shock for them at first – but they all came to admit that "actual" project management greatly reduced the intense personal pressure that all of them had learned to live under.

Improve this answer
-1

I think that Scrum is a fantastic framework for software projects. With that said though, only having those three roles leaves a gaping hole in the team. Whether or not you remove the developers' titles, it doesn't change the fact that there are indeed junior level, intermediate, and senior level developers on the team.

I have seen it so many times where the Product Owner (PO) writes all of the user stories. And of course that PO, though they may have been at one time in the past, is not a technical person. The stories written by a PO are not technical like the tech specs used to be in the Waterfall framework. But if you think back to the days of Waterfall, who wrote the tech specs? The senior developers did. The FA (functional analyst) wrote the business requirements, and the senior developers took those requirements and created tech specs for the developers to follow.

Fast forward to today, that tech spec is missing. If you don't have senior developers "leading" the developers you end up with a lot of tech debt. I have seen it. I would suggest a little tweak...

Make sure that each development team has one senior developer, and the rest are intermediate and junior. The PO writes the epics and the high-level stories, but the senior developer writes the lower-level stories that get assigned to the developers.

And under no circumstances should a PO be making technical decisions; those should be made by the senior developer, or they should at least be giving the final approval on technical decisions. I've seen so many times where the PO makes technical decisions, and promises are made based on them, before the development team even sees the requirements.

Improve this answer
1
  • 1
    I didn't downvote, but I can offer two guesses for why this was downvoted. i) Top-down assignment is generally frowned on in agile workflows. ii) This answer assumes that "No junior/senior designations" = "No technical specs", without providing any reasoning or justification for that assumption.
    – Sarov
    May 17 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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