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?

  • If someone still cares about this topic, I think this material from PMI worth a try (Disciplined Agile - Large Agile Teams) & I also wrote an article about my personal experience in a similar situation, Commented Oct 4, 2020 at 6:23

3 Answers 3


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.
  • By component teams, would mobile fall in as a component or would mobile be a feature team?
    – jmort253
    Commented May 26, 2015 at 15:22
  • We felt that having the dev manager be the scrum master may force the team to continue to see that person as a manager, but in scrum since teams are self-organizing, it seems that could be disastrous. Some of the examples in this article identify how managers need to step back: scrumalliance.org/community/articles/2009/december/…
    – jmort253
    Commented May 26, 2015 at 16:59
  • Mobile, being externally focused, can be considered a feature team. Commented May 26, 2015 at 17:01
  • I loosely disagree. (Strong opinions weakly held.) Do you have any reading material on that which I might find helpful? It's actually a bit of a debate internally. Thank you! :)
    – jmort253
    Commented May 26, 2015 at 18:16
  • 1
    If your mobile team can perform all of the tasks necessary to complete an end-customer valuable feature, then it can be considered a feature team. Commented May 26, 2015 at 19:12

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.

  • The "two teams of 10" was just a ballpark figure. Surely, it may make sense to use smaller teams to reduce communication paths. We'll discuss internally...
    – jmort253
    Commented May 31, 2015 at 8:11

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.

  • Product owners? We were thinking there would be a single product owner since it is a single product, but with two separate scrum teams who both happen to be working on the same product.
    – jmort253
    Commented May 26, 2015 at 15:19
  • Having a single product owner for both teams will limit your scale-ability in the future. If you foresee the need to have more than the 20 people in the future, I would highly suggest looking to SAFe. If not, monitor the efficiency of the PO to answer the amount of questions and ambiguity the teams have in understanding the work. I have seen a single PO be over-worked when attempting to do this for two teams. Perhaps your PO is a rock star, but it's worth protecting against burn-out of this critical team member. Commented May 26, 2015 at 20:30
  • He already does this job for the team now and has been doing so for over 5 years. If moving to scrum were to suddenly overwork or overwhelm him, then I have major concerns about scrum as a solution. It should make everyone's job easier not harder, right?
    – jmort253
    Commented May 27, 2015 at 6:29
  • Having a single product owner should be fine. Being a product owner is not supposed to be a full time job. Commented May 31, 2015 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.