Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Answering Matts last comment I would add that the lead developer should be the one that takes key architectural decissions that affect many components of the system. Also he is in the one that carry this responsability and should change his mind if things are going wrong. –  user2236631 Apr 25 at 7:25

6 Answers 6

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!

share|improve this answer
    
Nicely put. Short & sweet. +1 –  Kris Van Bael Apr 24 at 20:32

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.

share|improve this answer
    
Can you add some clarification to what you mean by, "Handing out decisions by edict is a terrible way for any development team to run"? I agree with the rest of your post but I only agree with the mentioned statement in certain ways but not others. For example, how would it be decided to use SOA over a database tier? Wouldn't that have been an edict or wouldn't someone have to have the final say? I ask because I am a team lead and ran into this very situation. I made a call not to use SOA based on business need. There just isn't enough time to allow all developers to discuss/argue every point. –  Brian Jun 27 at 16:41
    
@Brian making architecture decisions would be a story in a sprint, probably one earmarked for a specific member but otherwise the same as any other story. It should be subjected to peer review like any other story. The time argument is bullshit, if you happened to miss X or decided to try Z that everyone else on the team isn't familiar with you WILL spend more time developing as a result, even a full day of arguing about design would be insignificant comparatively. A simple meeting/review to say "I chose A because X,Y,Z." would likely take an hour and get just made it a collaborative effort. –  Ryathal Jun 30 at 17:27

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.

share|improve this answer
1  
This is especially important in meetings that are "Timeboxed", meaning the meeting, or specific discussion, will not last longer than X minutes. At the end of the time, someone makes the decision and keeps the process moving. This could be a Lead Developer for system architecture and related discussions. –  Chris Apr 23 at 20:17
    
Well put. A lead developer should also be geared to improve the experience and understanding of the team they are in, with the long term plan being to not just being a 'lead' but rather a member of a team of peers. –  ddtpoison777 Apr 24 at 6:13

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.

share|improve this answer

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.

share|improve this answer
    
+1 for "THE WORK AT HAND". I agree to focus on the best solution for what you have to deliver now. It's not about who comes up with the idea. –  Kwebble Apr 23 at 21:52

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.

share|improve this answer
    
This is similar to my experience, but I do indeed think that there are more "badges" and "hats" than necessary. There's almost no difference between how a good developer thinks about a design and what an architect thinks about a design. –  Joe Rounceville Apr 24 at 13:24

protected by gnat Apr 25 at 7:26

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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