3 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

In addition to Ryathal's answerRyathal'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.

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.

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.

2 Ryathal's answer += http://programmers.stackexchange.com/a/236729/31260
source | link

In addition to Rythal's answerRyathal'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.

In addition to Rythal'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.

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.

1
source | link

In addition to Rythal'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.