Scaling agile

Attended by a small group from various backgrounds but everybody was practicing agile AND had experienced scaling up (not much CI in this session).

Distributed Agile

Several participants described described the issues when running a distributed team across several time zones. These were mostly practical issues and we discussed pragmatic solutions that had been tried.

One had a team with members in Vietnam and Reading. They managed to find a time of days where both teams were working (or at least awake!) but ran into problems as one team was finishing day X of the sprint whilst the other was just starting. They had had confusion around reporting progress on tasks and filling in the burndown. Several others in the group reported similar issues when the timezone difference was significant (usually transatlantic or to India). The consensus seemed to be that these were teething issues and that once an approach had been agreed the problem went away.

When dealing with a distributed team everybody agreed that everybody had to use the same medium for communication. Where one part of the team was sitting in close proximity with a number of others working remotely they had tried having a task board which some of the group could see and others used a webcam to watch. This did not work well as it always put somebody at disadvantage and lead to that person or persons not participating fully. Everyone (I think - my notes a vague!) agreed that if one part of the team was remote then everybody had to use headsets and an electronic task board. Communication channels had to be homogenous.

We discussed the practical issues of scheduling a demo when the team and various stakeholders are distributed around the planet. Everybody seemed to use Webex or some other desktop sharing style application. One member described their procedure where the scrum master would schedule a 15 minute preparation period before the demo where they would ring people up and get them connected. This sounded like a big investment but from my own experience is a great idea as it avoids a fifteen minute delay eating into the start of the demo.

Scaling up

We talked about scaling up agile teams. Success was reported by a group member who had commissioned a distributed team in eastern europe. He had flown out and run a mini-sprint with the remote team so they could experience all phases of the lifecycle, the artefacts produced and the vocabulary used. This sounded like an excellent approach to me.

Another group member used rotation where an experienced member of a team would be sent to work overseas for a significant period in order to seed a new team with the culture of the initial group in the UK. This had proved effective when creating new teams in Boston and the seeding period had been three months.

We talked about experiences one group member had had with larger agile teams. In one instance the large team had been a group of committed and experienced agilsts. They had sustained a team of fifteen people effectively. Everyone was collocated and the team took responsibility for organising themselves in such a way that the agile processes (e.g. planning, standups) did not become unwieldy.

In the second instance where the team was a mix of contractors, consultants and permies at client site a different approach was required (see report and slides. Here the team had to be split to keep it effective and the architecture of the application refactored so that it better reflected the teams. One of the group pointed out that this is an interesting twist on Conway's law.