The role of a team lead in agile environment

I think pure waterfall model is impractical. It is as impractical as the pendulum in pure physics where the thread is of no weight and no friction exists. And that is what you can never have in the lab.

We, the software developers know there is always ‘friction’ and nothing is ‘massless’. The ever changing nature of the human mind and limitation to perceive what it needs results in modification in the requirement. That why we are agile, we don’t just fall.

Now, trust and sense of responsibility are at the base of agile methodologies among some other. Here, every member in a team is expected to be self driven and self motivated. They are given task and set free to accomplish that at their own choice. Formal managing, let alone macro managing, hardly gets its place. Then what would the team-lead do ? Should s/he dive into developing? or is there indeed any need of a team leader?

Actually, there is an unavoidable need of the team-lead-role. And s/he should never dive into developing unless it is that required. Rather, he(please add an ’s’ before ‘h’, I’m lazy.) role is to keep all his mets connected as well observe aspect of their work.

Team-Lead role is almost similar to the role of the wicket keeper in cricket; cheering up the players and catch all the balls behind. A team lead should also look for the quality and security of the code component. As well, he will also ensure development path is not deviated from the path. As we are talking about agile methodologies, change may come, but that change should be verified by the team lead.

Besides, the team lead should accumulate the knowledge learned by each of the team members. He is to somehow implement the notion of adaptive software development(ASD proposed by Jim Highsmith) i.e. focus on collaboration and learning. He is to arrange an meeting to share the knowledge of the team mets. It can be in lunch time, can be after lunch hour or whenever seems appropriate. Remember, there is no need to prepare presentation as it often time consuming and deviates the concentration from the development. Main idea is to use any wheel if developed already by a team.

One point must be concerned about at this regard is to maintain the motivation and positive team spirit. Say two techniques are developed by two of the team members for similar type of problem. Both the developers are smart and techniques are smart too. Now, to server in future which method is to be used? The team lead should carefully analyze(don’t take too much time, if not resolved drop it till a right time) the two techniques with participation of them and expectedly he should sort out the right one and has to convince both of them positively.

Always keep in concern to maintain the team spirit and motivation.

When captain want to score

It is a post in reply to SQABD Yahoo group.

Really a nice statement, there is no ‘I’ in TEAM.

In addition to it, I would like to say, “…though it is consisted of
some I’s”. And everyone, really need to be concerned about all the I’s.

Why I am saying this, is for another truth that you said about team
sport. Yes, surely someone gets more credit. Say in foot ball, may be
the scorers are highlighted. But if the scorers want to play alone it
is not appreciated and can be risky; as we all know it will also
hamper the team effort.

Additionally, think about the case when the captain is always planning
how to score himself and forgets to plan how to defend his back, or
how to employ all the players for winning the match, in software
development context, meet the deadline and keep the project and make
the customer happy

Though, in some organizations and in some teams, it is experienced
that some members irrespective of his/her role often forget their
play.Sometimes they fail to understand the difference between
confidence and (superiority)complex. It is rather detrimental when it
happens to the captains.

Specially the captains who came up to the managerial level by his/her
development talents, which is undoubtedly appreciable. But
occasionally, they are found to give more concentration on
development(not design) rather on managing. As a consequence,
developers kept idle. There are even some situations where developers
were kept idle for 5+ hours for a 2 decision of the skipper(and it was
solved in 10min after that), why ? cause s/he was coding in quiet
mode! And it was not use to happen occasionally, rather it was a
everyday practice! Developers working late nights often had to wait
for hours together for a decision.

Moreover,another problem of captains who were a Ronaldo(I’m his
fan!)once is frequently found in their initial planning and designing
the system. They tends to concentrate(and confined in the box) more on
development details. I had another experience, where the manager was
very talented and designed an system architecture(it was really a
nice, I admit) and made the developers write more than 60 classes! But
the problem was s/he did not know which technology/api will be used.
When the api is got along with the apidoc, all those piles of codes
are kept aside for the dust to fall on and with a hope to use in
future. Developers again started writing code when they come to know
what to do after sitting idle for hours. And again, the captain uses
his/her full talent to develop some roadblocks (definitely those were
very important) but without an integration plan and guess what… even
without a revision control system. So the developers started writing
the drama, which was scattered and scary…..

So I think, though the word TEAM has no ‘I’ in it but it has an ‘M’ at
the lead. S/he must ensure and be concerned that there comes no ‘I’ in
TEAM.

Have a nice day !