Managing Agile team chaos with smaller sub teams

Agile practices work really well when you are dealing with smaller teams. Small teams are bound to be much more efficient and focused. It allows people to know each other well, while having fun at work. Simply put, it reduces the amount of bloat or waste, and it becomes quite evident when you see the team working.
Ideal Size

I prefer a team to be a max of 2-3 developer pairs. Any number more than this calls for a team to be split into smaller sub teams.

Team composition

Ideally based on features or themes. If you have 4 pairs of developers you are bound to be working on more than one theme or feature. A good Business Analyst or a Product Owner should be able to identify these themes in the functionality being developed. If you do not have 2 broad features, try to club the smaller features based on a pattern or a theme. Never split the team based on infrastructure (eg: UI team, Services team)

Align a BA and a QA to be focused on specific themes. If the features are functionally less complex, then a BA and a QA might be shared across these teams.


Split the meetings, making them shorter and more focused

The idea of reducing bloat also applies to the team meetings. Have separate standups among the smaller sub teams. When you have a max of 6-8 people in a standup, everyone will be attentive, interested and will remember what the first person said in the standup when it ends.

Split the Iteration Planning meetings also according to teams which are focused on tasking and estimating features they are developing. You can even have mini retrospectives with sub teams on a regular basis.


Split the card wall

The story card wall tends to clutter up with cards for 6 pairs of developers. Splitting the card wall into separate ones for each sub team helps in keeping the card wall cleaner and motivates the team to keep it up to date.


Handling dependencies across teams.

There will always be dependencies between sub teams. The teams might share some areas in the code base, builds, QA integration boxes etc... A PM or a lead of the whole team plays a vital role here. A PM will have to be part of both the standups regularly and ensure that dependency blockers are removed by teams communicating effectively. As long as the teams are sitting closely, once can always shout out if there is a show stopper !

The whole team can talk about technical dependencies and showstoppers in impromptu developer huddles/technical standups as and when required.


Managing people rotation between teams

People will get bored working on the same feature. Developers will be bored if they were working in a team just fixing bugs or small enhancements. similar is the case with BAs and QAs.Rotation is also important to allow team members to pair with members of the other sub team.

Any rotation between teams can be done at the beginning of an iteration. 1 person swapping in between two 2-pair teams would be ideal. A PM can also choose to limit the number of rotations based on constraints such as knowledge around a particular area of functionality etc...


Better feedback, pair rotation, and self organization

In a 8-10 people team sitting across a table, people can quickly learn about each others strengths and weaknesses. Knowing each other well automatically allows for a better feedback culture within the team. Pair rotation within 4-6 people allows people to pair with everyone in the sub team.

In a small team people have the tendency to self organize themselves. You will see people take on more responsibilities, sometimes a BA playing a PM hat and proactively planning stories for the next iteration. People will not wait for a retrospective to speak their mind about a certain issue, but shout across the table !


Stitching it all together

The Project Manager of the whole team plays a key role in keeping the sub teams focused and on track. For this purpose a PM can conduct an Iteration Close/Planning meeting with the whole team, showing team members where the team stands on velocity, and scope burn down, along with any team rotations for the next iteration. This could be followed by letting the whole team know the scope planned for next iteration.

Needless to say that team outings and other fun activities would involve the whole team !

Great teams will always be cherished

I have worked on over 10 projects in the last 6 and half years of my career. Sometimes when I look back at them, I cherish the projects which gave me an opportunity to work with a great team, much more than the one where we delivered 2 months ahead of schedule.

A team which worked on a Malpractice Insurance application (2004), and another one building a Leasing application (2006) clearly stand out of all the other teams. In fact one of the teams I work in currently is a close next, and that is probably the reason for this train of thought.

The team dynamics is so great in these teams which immediately allows for a lot of innovative thinking and high performance, since the team would have already got its basics right. It is very tempting to retain these teams as is, and do another assignment, but working in a big organization does not always give you this luxury.

It is difficult to put in words what makes a team great, but I will make an attempt in a later post.

(Note to self -> So strive to build a great team, it is probably what you will remember and cherish for years.)

One for the environment !

It all started when I was sticking a story card up on our story wall, and someone shouted "Dude, how many trees are cut because of our story wall !"

Today our team planted around 21 saplings near JP Nagar 7th phase with the help of TreesForFree The team outing was unique and immensely satisfying for everyone. In fact we decided that from now on we will plant one tree per story we deliver in a release ! (Sripad, who played a key role in organizing this outing, wanted to go to the extreme of 1 tree per story point !)

Apoorv has blogged more about the outing here.

I strongly urge all you agilists out there, who love your story wall so much, atleast plant one sapling, to heal the earth !

(It is hard work in the sun !)

The emotional wall

One of the key things a project manager has to do in a team is listen. Listen to people's aspirations, frustrations and expectations. Over a period of time a PM has a mental model of his team which could almost be like a matrix below

Avishek - Sad
Apoorv - Could not be Happier
Rohini - Just about ok

A lot of times a PM has to make decisions considering the above mental model, which is equivalent to keeping the teams emotional state in mind. A good PM will do well in making
these decisions, but then the mental model is still in the PM's mind and not really with the team.

And if the team strives towards self organizing itself, this poses a roadblock. We conducted a simple experiment to solve this wherein we created a wall of peoples names, and asked everyone to stick one Post-It sticky. The stickies were of 3 colors Red - Sad, Orange - Indifferent, Green - Happy.

Now , if a team member sticks an orange or a Red sticky,she also writes the reason for it on the sticky itself. (As long as the reason can be shared with the team). The idea was to update this wall whenever we felt like and see how long it lives.We just called it, the emotional wall !

Slowly I saw the team questioning each other on the color of their post-it. Karthik had a red sticky because he was working on bugs all the time. This made Kiran , who was working on a story to volunteer to fix bugs so that Karthik could be a bit more happier. There were lot of similar instances and it was fun to watch the team take interest in how their coworkers are feeling, and trying to solve the problems within themselves. Yet another experiment in self organizing.

Team racing challenge with our application

So it was a lazy Friday of a hectic week and I found myself dazed with all the meetings I had been through all this week. To pep up the spirits I coaxed my team members to take up a racing challenge where they will try to book a return train ticket in record time. The fastest one, gets a 1000/= gift voucher.

It was lucky that we did it in a meeting room around lunch time, since the excitement this created within the team was amazing. We had a stop watch going and people were cheering each other frantically. People had to go through at least 7 screens to actually buy a ticket from the web application. Some people got confused with a few screens which sure showed how usable the app was. A few others were trying to use the keyboard shortcuts in the app, some of which did not work that well.

In all among Devs, BAs and QAs .. it was a a Dev who made a booking in record time of 2 min 26 secs. Half n hour of good team fun !