What is the role of the lead developer in an agile team?

Question

In a non-agile development team a lead developer generally:

• Sets the standard (coding and otherwise)
• Researches new technologies for the team
• Sets the technical direction for the team
• Has the final say on matters
• Designs the architecture of a system

However an agile team works differently:

• An agile team will rely on emergent design, rather than up front
• An agile team designs together, rather than design being dictated by one person
• An agile team decides on their own technical direction, which is best to deliver a project

Where does this leave a lead developer in an agile team? Is it possible to have a lead developer in an agile team? Does a agile team demand different responsibilities from a lead?

Answer 1

Nothing in agile changes how the lead developer should function. They should be involving the rest of the team with system architecture decisions, and technical direction no matter what development model is being followed.

Handing out decisions by edict is a terrible way for any development team to run. Agile just makes getting buy in from the rest of the team a more explicit process, and a lead developer should have been doing that anyway.

Just because there isn't a set lead developer role in a scrum methodology doesn't mean the more experienced programmers opinions aren't the most respected. Agile is not letting everyone go wild on their own thing and then trying to stick it all together, there is still a unified vision and direction that needs to be set.

Answer 2

In an agile team everyone is supposed to put their egos aside.

If one member of an agile team has more experience than the others what will likely happen is that the experienced member will be involved in most code reviews and people will often defer to that person's experience when making team decisions.

So, a "lead" developer will continue "leading," but as a natural consequence of their experience and not as a mandated function of their title.

That's in an ideal world where people can put their egos aside. Good luck!

Answer 3

In addition to Ryathal's answer:

You talk about emergent design and team direction as though they flow from the team in perfect unison and harmony. Groups of people, groups of programmers especially have conflict. As the team lead, your job in an agile team is more of a referee or catalyst than in waterfall. When the team has conflict about what design to use for example, you'll make sure that people have equal say and stick to arguing over merits. And you end up being the arbiter to which proposed solution the team will go with when the path is not clear.

This is one of the most important responsibilities of the lead, but plenty of other things are needed to make a bunch of people into a team. You still need to set an example as far as good coding goes, and often enforce that (either directly or by creating a culture to do it). You need to facilitate communication between all of your team members, because once a day at standup isn't going to cut it.

The other important thing you've overlooked is meetings. It's impractical to bring the entire team to every meeting where the team needs to interact with business people, other technical teams, etc. As the team lead, you're the team's representative. You go to the meetings so that they can stay at their desks and get stuff done. You're the point of contact so that they're not interrupted by people stopping by directly. And you work to take information from the outside world (what other teams are working on, what the agile teams look like next sprint, what's the status of that open req, etc), boil it down for them and communicate it.

In short, you're the lubricant to make sure that they can run smoothly.

Answer 4

Your non-agile description doesn't invalidate your agile description.

An agile team will rely on emergent design, rather than up front.

Nothing about your definition of a lead developer says design must be had up front. He may set the direction, and he may still lay out an initial design. That design is definitely emergent.

An agile team designs together, rather than design being dictated by one person

Nothing about your definition of a lead developer says that he dictates design. Although he may have final say, only a poor lead would fully disregard the thoughts of his majority teammates. On the flip side, only a poor team would fully disregard the thoughts of the lead developer.

An agile team decides on their own technical direction, which is best to deliver a project

Again, this doesn't mean that the lead does not initially set this direction. The lead is part of this agile team. Even in a non-agile environment, only a poor lead would continue to march a team in said direction when it has becoming knowingly unfeasible, or when new information has been presented to invalidate this direction.

Answer 5

The question begs a few other questions. What do you think qualifies you to tell a team of fellow software engineers what to do? Is it your experience? Is it the funny little title your boss handed you? Is it your ego? Your tenure at the company? Is it your "panache?" Your "style?" Your "leadership skills?"

Agile teams don't hand out badges or hats to one another that say "Congratulations, you're our super genius -- you're the only one allowed to do super secret double genius work." Rather, the focus is THE WORK AT HAND. If you're indeed more experienced, then that experience should SHOW in how well your designs push the work forward toward completion. Your self-chosen assignments (cards) should reflect the areas you're most expert in. On the other hand, if some kid right out of college has a better idea, and it fits the context better than something some 40 year veteran comes up with, why on earth would we go with the poorer design? Our workplaces aren't therapy offices -- they're where we come to build great things.

That begs another question: who gets to decide what "better" means? The answer: the team of stakeholders. That means the developers, requirements people, testers, business people, etc. who are the builders and users of the thing in question. If you have a great idea, you better be able to demonstrate why it's better. If you can't do that, then there is no reason for the team to believe that your idea is better. Agile encourages meritocracy.

So, what happens to the "development team lead?" in agile? Nothing -- they just better live up to that name -- they better ACTUALLY be able to produce better software than the other people on the team. Otherwise, there's no reason to call them a "lead" -- it's just a little badge or funny hat, and it's meaningless. Lots of people find this threatening. They feel like they've been "working for" a badge or funny hat. Good developers don't work for funny hats. They work to build great software, and they plan to do it until they croak -- their goal is to get better at building software, every day. If that's not you, maybe you might want to look into project management. You'll probably be happier.

Answer 6

In my experience of Agile, the development team as a whole is handed less responsibility than your examples imply, leaving the lead developer and architect to co-ordinate top level design choices, but handing down lower level design to the agile team as a whole.

So, the lead developer remains responsible for system architecture and technology choices. This is very important: although agile encourages emergent design and refactoring this should be happening at the level of code objects. The system as a whole needs to have greater level of pre-design and rigidity else the project risks becoming an uncoordinated mess.

In our project the lead developer mandated the technology choices, and designed how system components would interact with one another. Agile planning meetings focussed on how to design those components within his higher-level mandates. As a pleasant aside, this keeps a scope cap on otherwise tiresome planning meetings.

He also functioned as the point of last resort. When individual programmers ran into problems that they were unable to fix, they would go to the lead and the final responsibility for getting things fixed was his.