Tuesday, 25 March 2014

Moving to Scrum of Scrums

It's about 10 months now that I have been working with a project team on a 1year and half long project. My role started as Project Manager, moved to Scrum Master and now I'm Coach/Agile guide.
As new to Agile, my team was pretty insecure 10 months ago on how will they get a handle of this huge project, AND do that in a new way, Agile, as part of the transformation the company is going through.
At the beginning, I started this project with 6 people.
2 months after there were 25 people involved (either core or external)
3 months after there were 45 people involved (either core or external)
5 months after we had a good understanding of the core team and externals.
There were about 30 people on the Core team and maybe another 30 as externals/SMEs/as-needed.

You can probably all jump and tell me how I should have started splitting this team right away into smaller teams. Yes, yes. I know.

I will tell you the 2 reasons I had  to continue with 1 big team for a little longer:
1- These teams did not know a lot about each-other's areas. Consider this a project like an app with multiple components, but all presented through 1 interface. It is something like what Spotify uses when they talk about their squads. But in this case these components were not talking in a "controlled" way to each other. Everyone knew well their component and a little bit about how their component connected with 1 or 2 other components. Looking at the big picture, nobody knew how all the pieces connected together and what was the ripple effect of a small change we would make on one component.By working together as 1 team, they got to learn a lot about each-other's areas, about the other components and understand better the effect of their changes. If you put this on the System thinking, we moved from a system where everything was complex, to a system where some components became complicated and some are still complex.

2. As new to agile, they all needed help with thinking, planning, reporting, understanding the meaning behind certain scrum ceremonies, etc. Doing most of the scrum ceremonies together, all of them got to hear from me the same message, at the same. Of course, I had to put more attention, time and coaching on the teams that were bigger and had to work on the bigger component. Nevertheless, after 7 -8 months working like this, they all got to a comfort place with what Scrum meant, how to run the ceremonies, what the Product Owner role was, what did I mean when I asked them "What do you really mean when you say - We are Agile?", etc. As part of this process, some people grew up naturally into some areas they didn't know they had the skills and strength to shine. For example, one of the Business Analyst showed a lot of skills that are required from a Scrum Master. Because we had multiple Product Owners, we had to pick one of them as Product Champion. He showed some really good leadership skills on handling not only his team (where he was playing the Product Owner role) but also coaching the other Product Owners of the other components. The Dev lead, grew as a technical coach for the developers we had to hire and for the new team of automation testers we started for the first time. The Project Manager went to a Scrum Master training and came back with a lot of energy to share.

So as per the pure spirit of the Agile development, this 1 project team grew empirically on knowledge about the product they are creating together AND on the process they are using while working together.

It was time to split them into smaller Scrum Teams.
I thought this would really easy, but I was wrong. Although the idea was taken as "Sounds great!" when I first presented to them during a Retrospective session, they were still hesitant to action on it. Project Manager was one of the members that put the foot on the break the hardest. She was feeling like she was loosing control of the project. How could she manage now these teams? How could she trust now these new Scrum Masters to do the job right? I know this because I found myself answering more than once questions like:  What will happen to X person that needs to go into all the other standups? How will we handle dependencies between these teams? How will we know when there are problems?
 So it took about 1 month and half to make this change official but we are now a project made out of  9 scrum teams with sizes from 3 to 14 people.

I need to break them again!!! 14 people is a big team and 3 people is a very small team. Yes, yes I know!

As a change agent, I have to pace changes I bring. It was a big deal to get here. I want them to focus now on getting better results within these smaller teams. I expect a better focus to their work, smaller iteration length on at least one of the teams and, a better focus and clear understanding on the dependencies between teams during the Scrum of Scrums sprint planning. Once I verify this hypothesis, we will decide what to do next.
The good thing is that now I have 9 Scrum Masters in training.  Pretty soon I will see a group of Scrum Masters discussing and solving issues between each-other, rather than look on my direction.


  1. Scrum is the most commonly used agile process for projects specifically more prominent for software development. As a product development framework scrum is applicable for any type of projects but you need to train your project managers in Agile Project Management .

  2. To stop making avoidable mistakes in project management one can also try attending good PMP classes conducted by any of the PMI registered REP's for gainig expertise best processes of project management. Any good PMP prep course will provide students with lots of actionable insights in project management along with preparing them for PMP certification.

  3. Looks like this post is attracting some interest on the Scrum certifications. That was not my goal. Although the trainings offered by different organizations are helpful, Scrum certification is taking Agile away from the original goal or connecting Business with IT. Certifications are used as "the way" to run Agile. In my opinion Agile is something you sense, measure and act as required. No formula, no rubber stamped solutions