This week featured the latest gathering of Scrum prapractitioners in Bangalore. This free event drew a solid 50 participants for the second straight time, and featured some really smart technology workers. The group was about 50% developers, 25% testers, and 25% managers. I did get to do my standard presentation on Agile Contracts, but the broader theme for the day was “Scaling Scrum”. This was of great interest to me, since RippleRock is helping a large dotcom implement Scrum across two strategic pilot programs using 4 teams on 2 continents. Needless to say, I took copious notes below

Scaling Scrum

First off was Vibhu Srinivasa from Solutions IQ. People laughed out loud as he facilitated a team dynamics game. But what people came to hear were his points about using Agile techniques on really large projects:

• Understand Why You’re Scaling – The point is not merely to have an official standard for managing work. The point is to create alignment across larger projects, to make sure people are on the same page about delivering on a business objective.
• Understand What Scale Means – To help bring alignment to our own large group Vibhu offered this definition of large-scale agile projects: “A group of teams working together on a common product or project or portfolio”.
• Well groomed backlog is required to scale Scrum. For a single team of 7 people, a poorly formed backlog will only impact that team. On a larger project of a dozen teams working on the same poor backlog of project work, then you’ve just scaled the associated pain and errors.
• There are several ways to nest Scrum teams. In general you can have nested backlogs of increasing degrees of detail, but there needs to be a clear, singular owner of each product backlog.
• Charter a Product Owner team, responsible to keep the backlog groomed and prioritized. In larger organizations, the Product Owner role can quickly get to be too much work for one person. Have relevant stakeholders meet as required, above and beyond any other meetings with the Scrum team.
• Align the sprint schedules. Namely, it helps if everyone is working to the same deadline.
• Use the Scrum-of-Scrums only to coordinate dependencies. The overhead associated with the Scrum-of-Scrums is best utilized less as a status meeting, and more of an impediment removal meeting.
• Relentless Automation – Just scaling scrum management is not enough. You need continuous integration, low-cost regression testing, and  ”touch free” deployment.
• Rotate ScrumMasters – Spreads skill and awareness of Scrum and alleviates anxieties about career path.
• Ambassador Pattern – Fly people to their distributed counterparts for key meetings or even for an entire sprint . This help preserve team dynamic,  when individuals return to their home base.

Globally Distributed Agile Teams

Then, Rini van Solingen. the CTO of iSense Prowareness, joined the group over skype. He started off with describing the “30 meters principle”: When teams are distributed more than 30 meters apart, the communication frequency drops to near zero. So, it doesn’t matter if your 3 time zones away or 3 miles away, the real limit is 30 meters.

This is a bit of an obsession for Rini, who is working a research project at TUDelft called “Creating the virtual 30 meters”. In this research, he has found some best practices:

1. If a single roof is possible, do it! Don’t distribute if it’s not absolutely necessary.
2. First, deploy Scrum locally and effectively before working distributed.
3. Assign Scrum roles explicitly. The Product Owner and proxy roles becomes even more critical.
4. One team in one rhythm. Staff your regional teams with people from all other locations. This is the “ambassador pattern” described above.
5. Meet. Teams are not built by themselves. You need to actively establish relationships by traveling to each other’s sites.
6. Impediment removal and retrospectives are even more crucial. In fact, meet collectively for retrospectives (see previous item).
7. Work at the customer location at least between 10-20% of the time.
8. Personal mindset is crucial: “what did *I* do wrong? what can *I* do different? how can *I* help?”.
9. Don’t focus on tools: discussion and interaction are more important.
10. However, communication and awareness don’t happen automatically. Here, tools can help, but only if implemented with the right purpose in mind.
11. Fail fast: improve empirically. Both success and failures are sources for learning.

Open Conversations

The day wrapped up with an open space session. A number of topics were suggested, but the top two were two key topics:

• Estimation: In this conversation, there was a lot of discussion about the expectations around estimates. Managers expect your estimates to be internally consistent, when in reality they aren’t. They also expect your actuals to match those estimates exactly, but in reality they were really just estimates. One suggestion was to begin using the word “forecast” instead of “estimate”. Doing so may emphasize the fact that the numbers are rigorous, but not iron clad.
• Careers. Here, there was concern about the impact Agile roles and responsibilities have on your career. For example, if a developer takes the risk of helping lower-paid testers learn code-based automation, will that make him less needed? If a BA takes the risk of not writing all the details for all the requirements up front, how will her skill be judged? If we take the risk to move in the professional direction of Agile skills, is there a job market for those skills? The answers are not easy. If you work for bad managers, then they may punish you for doing the right thing. But then again, they’re probably already doing that. And really, the your career should not be based on a choice between Agile jobs or non-Agile jobs. Your career should be based on what makes you and your team most successful.

It was an eventful day. iSense does a really good job of organizing this. I look forward to the next one at the end of September.

{ 2 comments }