Big Agile Teams

Ideas on dealing with larger teams in an agile way


Agile

As a team grows it becomes more difficult to apply some agile practices effectively. SCRUM meetings like standup and retrospectives become drawn out, the number of stories becomes hard to manage, and the communication within the team can easily break down.
Currently I have a team of 10 and I am experimenting with ways of tackling these issues. Hopefully this will turn into a loose series of posts surrounding my experiences with a larger team. I won't go into the why suffice to say it is a project rather than a product but we don't want to go waterfall.

Big team tactics

Most of these tactics focus on communication of what the team is working on but there are a few process items. Some of these tactics are taken from previous smaller teams and are by no means only for large teams. By the time you have 9+ people social bonding, communication, and working memory are all suffering so these need to be focused on.

Cells

The team is broken up into 2s. These 2 developers are responsible for keeping eachother abreast of their own progress. This is more than just an informal pairing. If possible they work in related areas. They are preferred for peer review and pair-programming. Most notably they are responsible for reporting progress for each other at the standup. See next point for details...

Developers are chickens too

A Pig and a Chicken are walking down the road.
The Chicken says: "Hey Pig, I was thinking we should open a restaurant!"
Pig replies: "Hm, maybe, what would we call it?"
The Chicken responds: "How about 'ham-n-eggs'?"
The Pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved."

Cell members alternate between being chickens and pigs. At a standup only the pigs report on progress but will do it for the fellow cell chicken. This keeps everyone informed but the number of active participants smaller. Not only that but the nominated pig needs to at least understand what the chicken did well enough to explain it. Hat-tip to the Feynman Technique ;)

Present the plan

Before implementing a complete story developers are encouraged to discuss how they will be implementing a given story before implementation is underway (or very far). This gives others a chance to weigh in on the implementation details and bubble up any hidden knowledge or pitfalls. I suggest a regular prompt for this, possibly straight after standup.

Technical demos

This is not a stakeholder demo. Plan regular (2 weeks seems good) demos where the developers can deep-dive on what they have been working on with the others in a bit more of a formal way. One or two slides, some live demos of code and functionality, and a Q&A afterward.

Dedicated learning time

It is easy for people to get lost in the group and fall behind and as a team lead it is difficult to spend time with everyone. Dedicating a regular afternoon to discussing new technologies or methodologies is good for moral as well as raising the skills of the team.

Socialize

Getting the team to bond is even more important when it is bigger. Lunching together, non-work activities, or even retrospectives can help bring together. A focus on sharing feelings at points in the retrospective can help others understand how others they are not close to in the team are feeling.

Conclusion

I hope some of these suggestions are helpful and if you have any of your own please let me know in the comments below. These are all a work in progress and I will hopefully report back in a later post.




blog comments powered by Disqus