Recently there was some major shuffling of the development teams at Point2 which resulted in me leading a team of seven developers. Of those seven only two were on my previous team. Even though all of the teams were developing software using Scrum, each of them had specific processes and practices. One of my challenges as the Team Lead was finding a way to effectively bring all of these people together who were used to their team running a certain way.
The easiest thing I could have done was to just decide how things were going to run and inform the team. This would have also been the worst thing I could have done. Teams are supposed to self-organize and they are going to have an easier time doing this if they are working in a way that they feel comfortable.
So what did we do to expedite the fusion of the team members into a new group?
- Get the team into a room to hammer out ideas regarding how iterations were going to run such as Sprint length, required meetings, etc.
- Encourage all team members to talk about why certain things worked well on their previous team. We want to make sure that the best processes and practices are being discussed. It’s easy for people to be less opinionated in a new group.
- Manage the expectations of the team and the customer/business. The team and business people were likely used to work getting done at a certain pace. Getting a new team to mesh is difficult and takes time. Make sure everybody understands this to prevent the team from getting frustrated, and the business from wondering why things have slowed down.
- Even though we do hold Retrospectives and Root Cause Analyses at the end of every Sprint, it is in the early stages of the new team that these are critical. These are the times where problems with the processes and practices will most likely be raised and discussed.
- As a Team Lead or ScrumMaster you have probably seen what works well and what does not. Find that balance in guiding your team in the decision making process without pushing them down a path for purely personal reasons. There may be times that they want to try something that you have seen fail previously. Under certain circumstances it may be best to let them try it. If it works, great! But if it does not it can also act as a good learning experience.
The new team has been together for about three weeks and has been running quite well. Our Sprints have been a little bit unpredictable and sporatic as we are working on a mash-up of stories from previous teams. Despite that our velocity was still most impressive for a new team.
I think the majority of the success has to do with the Agile maturity amongst our developers, but I also think that the team working in a way that they have fashioned is also playing a factor. It may seem like an obvious statement to say your team should decide how things are run, but it is also easy to get stuck in one’s ways, and just do what you’re used to.
At Point2 Technologies, we develop software following Agile principles. We are always interested in discovering, learning, and sharing new and better ways to embrace agile development practices. That is why we would like attend and possibly present at the upcoming Agile 2009 conference.
We have prepared a few presentation proposals which we have submitted to the conference’s official website:
*Please note that you do need to create an account or login to be able to view the links.
By: Jesse Webb