I have been recently promoted to manage a division in software development department of my company.
Till then I was used to managing one team at a once, not exceeding 10 people in size.
Now I find myself with 8 teams to manage having each a size ranging from 4 to 7 people.

In my previous role I was comfortable with adopting the SCRUM agile framework and quite used to play the role of the scrum master and to participate actively to the product owner role.
Some of the new teams were already trying to follow the agile practices, some were still working with rather a traditional waterfall approach. So naturally I found myself driving the teams to adopt the SCRUM framework. I made sure to share with them my return on experience and to point out the pitfalls and the small details that can make a difference.

Fortunately for me the resistance to change was less than expected.
All the teams were eager to try the new framework and to improve their agile practices.
This is when things start to get a bit more complicated.

Among the teams that had tried agile methods, some had tried the SCRUM framework before but ended up by letting it go. Some accommodated the framework with what they thought it would suit them better and thus were practicing a modified custom version.

This reminded me of the caveat entitled Do not change scrum in The Enterprise and Scrum (by Ken Schwaber)

Having observed that, it was clear to me that I had to bring the teams to the required level of understanding of the methodology and to help them in the adoption and ramp up phase.

Doing that was not a problem for me, on the contrary I enjoy playing the role of the scrum master in an agile development team. The problem was rather a capacity one, will I have enough time to do it right.

You might say, sure it won’t take that long to train a group of people to an agile methodology.
I can’t disagree with that, after all I had my scrum master certification after a two days training.
But what I also know, is that it took me nearly two years of practice to be able to take full advantage of the framework. So when I say doing it right, I mean working closely with each team trying to share with them what I learnt and helping them reaching the tipping point to becoming agile.

The couple of teams I had selected to start with showed high appreciation of the help they received and I could instantly see the difference and the positive impact on their day to day job.

But till now I haven’t managed to keep a regular pace to assist closely all the teams in this adoption process and this doesn’t make me feel satisfied. With all the responsibilities I have to assume I never get the time needed to accompany the teams in all of their agile ceremonies.
Since a couple of days I’ve been asking myself, assuming I had nothing else to do, is it possible to do such a close follow up? That’s when I decide to do the math.

For one team, per iteration of two weeks, I will need to allocate:
- 3 hours for the demo/sprint planning
- 2 hours to retrospect
- 2 hours to participate to the backlog grooming
- 10 x 15 minutes of daily stand up

This leads us to 9 hours and 30 minutes per team every two weeks, multiplying this by 8 leads us to a total of 76 hours. So at the end doing the close follow up with all teams will require me to allocate 38 hours per week for this activity alone; a full time job!

Although this seem to fit in my working hours habit I doubt I will go that way.
Why? Because the expectations from my new role go beyond that, I have other duties to fulfill that are part of the role and that are time consuming too, nearly half of my time.

So what next? Well no doubt, I’ll need to make a choice, follow the most important things and delegate the rest.
First action is to ask a team member to play the role of the scrum master for a given iteration. All team members will play this role in a round robin fashion.
Second action is to skip attending the daily standups, this will let me gain back 10 hours per week, and I believe the teams will be able to conduct them efficiently on their own with the help of the assigned scrum master.

Next step will be to opt out from the retrospectives once the team is used to conducting them. Of course I will provide my notes to a team member and ask him to represent me. This will let me on the long term get back 8 hours.

So in total I will need to allocate 20 hours per week to perform the remaining activities which seem reasonable. I believe this close follow up will yield to a better results, I’ll be trying this and learning from the experience.

Interested in the outcome? Stay tuned.

photo credits:
calculator (license), Perpetual Scrum Google Glasses (license), scrum diagram (license)