How to organize a software development team so 20 people are on two scrum teams?

Question

We have a software development team, working on an independent product, made up of 20 people of varying roles, located in India. One of our goals is to treat this product team as a separate entity, separate from the rest of the company, and utilizing scrum as a development methodology:

• design
• development
• testing
• content writing
• support
• possibly mobile

Traditionally, we've followed an internal model of development that loosely follows some agile practices and some waterfall practices. After reading Jeff Sutherland's book, How to do Twice the Work in Half the Time, we've started looking into ways to introduce scrum to this team.

The team currently has a manager who mostly does customer outreach and planning. We think he is a candidate to be a product owner as much of what he does today is to put feature requests on the to do list for implementation, based on customer feedback.

The team also has a development manager, and we realize transitioning this role is one of our challenges. Self-organization may be a problem if the team cannot view this person as another team member.

From what we've read, we've concluded we would possibly need to break the team of 20 into two teams of 10. To counter the management problem, we considered rotating the role of scrum masters to different people on the teams every 6 months or so.

We also think each team should contain all of the people to complete a feature independently, so each team should have its own testers, content writers, etc.

We have considered trying scrum with just one group to start and leaving the other to their own devices, but we're not sure what the best way to start is that will help us be most successful. What adjustments to this plan should we make or what should we do different to implement scrum in a way that will be successful for our team and demographics?

Answer 1

Your Scrum transition plan looks good

Here are my suggestions:

1. Get some training: Any team transitioning to Scrum will struggle with getting stories ready, estimating, release roadmap and so on. So, send some of your key people for training. And ask them to come back and train the rest of the team.
2. Create feature teams: Not component teams (such as a back-end team and a front-end team).
3. Plan to keep the teams stable: Teams take time to gel together and become productive.
4. Making the customer outreach Manager the Product Owner is a good plan: He/she can be the PO for both teams.
5. You need a strong Scrum Master: For a team transitioning to Scrum you need a strong Scrum Master to establish the process. One possibility you can consider is making the development manager the Scrum Master for both teams. He/she may be good with removing impediments.
6. Use planning poker for estimation: You may find it a bit slow. But it gives better estimations and team commitment. Also, it gets the team in self-organizing mode.
7. Hardening week: In my experience teams transitioning to Scrum struggle to get a 'potentially shippable increment' ready by the end of the iteration if they are doing manual testing. Try to introduce automation where possible. In the interim, one way to mitigate this is to have a 'Hardening week' every second or third iteration. The entire team focuses on testing, fixing bugs and getting the release ready.

Answer 2

Having 10 people on a scrum team is a stretch. The recommended size is on the order of 4-7. Remember that scrum is about communication, and communication scales as the square of the team size. On a team of size 10 the communication costs will be very high, with some people over talking, others tuning out, and others being ignored.

I would suggest breaking the 20 developers into 3-5 teams, based on how close their work is. If you must have two teams of 10 (where did that requirement come from?) then I would suggest using a very modified scrum process, reducing the number of daily stand-ups, and having sub teams plan their own work together.

Answer 3

When I was challenged with a similar issue, I found that I could implement pieces of SAFe (scaled agile framework) that suited my program to solve most of them. This helped enable me to have all the critical pieces of management to foster team development and collaboration. (the "big picture" seems confusing at first, but click through the Program and Team Layers, and I'm sure you will find some good insights. http://scaledagileframework.com/ )

Breaking up the team into several smaller teams is a great start. Be sure you setup the means for them to collaborate just as if they were delivering a common asset. Certain meetings and touchpoints that are required (Grooming, Demos, Daily Standups, Scrum of Scrums, etc), most of this is par for the course regarding SCRUM. What SAFe does is scale this to help collaboration across many SCRUM teams. SAFe's framework identifies a Program layer that drives feature identification and program vision (the product owner candidate you spoke of can lead this effort). This Program layer role is labeled as a Product Manager, and works closely with Product Owners on the Scrum teams, thus providing governance over the features being developed. Having the two be separate allows the Program Layer to concentrate on the future and provide current guidance to in-flight work through the Product Owners.

Looking to involve your customers in the internal demos you have will also support transparency and encourage the fast feedback you praise. Since SCRUM and SAFe promote completion of working pieces of software each Sprint, Demo-ing this helps display to each team what has been done and you get instant feedback from your customers.

Regarding the development manager, I found that having this person be an arbiter for technological decisions the teams can't agree upon and helping the Product Manager at the Program Level define features was a great benefit. There is also a concept of a System level team that integrates the individual team's work and provides a program level demo at the end of each Program Increment. This may be a place for that person to still be looked up to, and participate highly in development of the product.

Rotating your Scrum Master can be tricky, as you force people to perform the role. I would suggest one of two things:

1. Do this on a volunteer basis and ensure this person gets the required training to be a SM.
2. Have the teams determine who is best suited to be the SM by organizing themselves over the course of the first sprint or so.

The second option is the best as you will find natural leaders and Scrum Masters who have the ability to "wrangle" the team.