We will describe our experience of scaling scrum from one single team to seven teams during 2010 and 2011. To do that, we will talk about the new meetings we added to our scrum framework to improve team communication and synchronize the parallel sprints that we run to develop the most important online payment system in Brazil. We will address the steps that we did and the focus on values instead of rules that is the basis of our agile environment. This work is a continuation of our first paper about this topic (Moving back to scrum and scaling to scrum of scrums in less than one year)) presented at SPLASH 2011 conference. Now we plan to emphasize our “mega scrum framework”, that allows us to add more teams to the same product more easily. Our first work was focused on our experience of implementing scrum in a team that had already tried it and failed and in less than year scaled it to four teams. At this moment, we can say that we have learned how to handle multiple teams in parallel in the same product. Nowadays, we have a framework and for us it is quite simple to start a new team (but it was not easy in the beginning). The focus of the first paper was on values like transparency and commitment and a vision that we could have more than two teams working in different backlogs but everyone belonging to one big team. In this propose to agile 2012, we will emphasize the mechanism of framework that we created to scale scrum: “the mega framework”. It is important to say that the development team and the business team agreed that the product backlog had a lot of different areas and the existent team was not sufficient to deliver as the market expected (There are historical reasons for that and we will detail them in the paper). So we started our strategy of adding and hiring people to existent teams before creating new ones. As new people learned the values and how we work, we started a new team. With more than three teams we learned that it would be important for everyone to know the sprint backlog of the other teams and to know the course of the parallel sprint. So we created two meetings: mega planning and mega daily. The first one happens just after the plannings and the second one in the middle of the sprint. At this point we created our “mega framework” with the challenges of continuing being agile. In the beginning (with two or three teams) it was possible to have meetings with everyone, but nowadays, there are so many people – the meetings were not productive and there is no room for everybody. So we learned and adapted them to meet our needs. We will detail that in the paper. One important lesson that we learned was the necessity of improving the communication of the team and between product owners and scrummasters. So we created some rules to do that, improving our development process. Another important lesson that we learned was that scrummasters and product owners must be synchronized but that was not only their responsibility – the team must know what the other teams are developing. We can detail that and we believe that point is one of the biggest challenges to scale scrum. Another relevant point to share is that we improved the productivity of the team. We observed that the velocity of the teams increases when they have a focus – with two or three teams, there were many different subjects to handle. Another metric is that the revenue of the business increases in a ratio that is bigger than the team expansion – so the team is delivering value to the clients can be observed in this scenario. So, we think that story is very useful to the agile community because we have learned a lot (and continue to learn) and now we have a framework that makes easy to add new teams. We also believe that everyone can adapt that to start a process of scaling agile in their teams. Of course we have more details of each point and we plan to discuss them in the paper.
http://submit2012.agilealliance.org/files/session_pdfs/scaling-scrum-mega-framework.pdf
