Maximizing Productivity across the Globe – proposal for Agile 2008

2008-02-28T12:42:00Z

Doing Agile across distributed locations around the globe makes it harder, but not impossible. It puts strain on the Agile principles, we have to work hard to make sure that the focus remains on delivering value to the customer. It is very easy for the complexity of the situation to stop us dead in our tracks. There are a number of essential elements that need to be right to ensure this doesn’t happen; these include working practices, tools, effective teamwork, a shared vision and effective ways of communicating. Each of these is an essential piece of the jigsaw that needs to be considered if you are going to have distributed teams and be successful.

Agile 2008 will be in Toronto at the beginning of August, I have submitted a proposal mainly to share two case studies on distributed agile teams that I have been involved with over the last couple of years. However the final part will draw together experiences from these projects with other multi-site projects that myself and colleagues have been involved with.

What have we learnt from these experiences?

· Challenges facing distributed teams

· Key patterns for delivering with distributed teams

· Anti-patterns – what doesn’t work with distributed teams

· How to facilitate successful iteration planning, reviews and retrospectives

· How to create an environment where distributed teams can collaborate effectively

· Tools and development environments

To see the proposal go to http://submissions.agile2008.org/node/4455, to give feedback you will need to create an account if you don’t have one already. Your support would gratefully be received.

Tasks assigned at the planning meeting

2008-01-20T16:06:00Z

I have recently observed Sprint Planning meetings where tasks are either being selected or assigned to individuals within the team at the start of the Sprint. Apparently this is not an isolated event, but aren’t Scrum teams supposed to be self managing, aren’t team members supposed to pick up whatever task will most help the team on its journey towards a goal. Why does this happen to agile teams?

Control

This allows the team to have individual burn downs for each member, as a manager you can see if somebody is struggling and take corrective actions early to make sure the team achieve the goal of the current sprint. Scrum has thus improved the information at the fingertips of the manager, so that they can base their decisions on actual progress rather than the position we should be in according to the plan. This puts management in a position where they feel they are in control of the project once more. If the Scrum Master is used to feeling in control of projects then this can be very tempting.

Specialist Roles

The team is new to agile, the team members may all have a particular specialist area, you may have one front end developer, one web services developer, one database developer, one tester, etc. It may just seem common sense to assign all the database tasks to the database developer, and when he is 100% utilized on that sprint then great, you know not to accept in any more items that will require his time.

The Result

Because all tasks are allocated to individuals, it is in that person’s interest to get all of their work completed so they look ok, rather than working as a team towards a common goal. There may still be some collaboration, but that will always take second place to burning down the individual’s tasks, especially if those tasks have been assigned by the ScrumMaster. As a result they are not a team; they are just a group of individuals working on a set of tasks, very similar to more traditional plan based approach.

The second thing that happens is that people don’t grow new skills. In an agile team, members should pick up whichever tasks will benefit the team most at that point, this may mean that they do tasks which are not in their comfort zones, this is good because they are learning new skills and the team is growing because of that. As the individuals share their skills, the team becomes cross-functional, and ultimately more productive.

A final point, if the team is truly collaborating towards a shared goal and a new team member is introduced, then it is in the team’s interests to help that person. I have witnessed new graduates quickly become productive team members as part of an agile team, whereas in traditional approaches nobody can spend as much time with the newbie as they should because they have their own tasks to complete. I think if tasks are already assigned it will be more difficult to integrate new people into the team.

Conclusions

I understand why people assign all the tasks at the sprint planning meeting, especially if team members have particular specialties. For new teams it is sensible to take account of the limitations imposed by people’s skill sets; however we must be careful we don’t stifle a team’s chance of growing. I believe to grow an agile team you have to let go a little bit, maybe even sacrifice some initial productivity while the team learns new skills in order to eventually have a hyper productive team.

Mark Summer's Blog

Maximizing Productivity across the Globe – proposal for Agile 2008

Tasks assigned at the planning meeting