Agile Intelligence: Scrum of Scrums

With the rising popularity, the Agile methodology started getting applied in almost everywhere. The project sponsors and some other stakeholders in many organizations were bought into it pretty quickly; not much due to the fascinating stuff Agile brought in, but the scars left by the traditionally approached and failed projects. Very soon, the large projects started with agility have been caught with an unprecedented reality: the overhead of communication.

So far, Agile methods fostered communication in all direction, and in small projects with small number of team members, that worked quite well. As the size grew, the numeric formula of 2ⁿ-1 started taking toll that was due. By and large, the project management practitioners take the project communication very seriously. Each project plan comes with a communication plan, be it a software development project or a stadium development project. The project managers take a meticulous measurement of the communication cost in terms of hours and infrastructure (long distance and international calls) spent. Accordingly, the project team structure and the communication plan have been devised for traditionally approached projects. For the projects following Agile methodology, the communication channels active would be 2ⁿ-1, where ‘n’ being the number of team members, stakeholders included. This means, a 4 member team would create 15 communication channels, and a 12 member team would create 4095 number of channels. As you know, the team size can grow even larger for large scale implementation work, and this theory of Scrum may wreck a havoc, to put it mildly.

The proponents of Agile methodology were quick to respond. Instead of trying to pester with the same technique, they quickly brought in the age-old method of communication clustering; this time under the guise of Scrum of Scrums. In a nutshell, Scrum would be held within the small workgroup or team formed on the basis of the geographic location and modules they work on. The Scrum Master of each Scrum would then assemble in another meeting to discuss the same topic, albeit with a different phrase. Instead of asking how the individual has been doing, the questions would focus more towards how the team has been doing. Accordingly, a set of 5 questions have been formulated –
1. What did your team do during this period?
2. What will your team do in the coming period?
3. What are the obstacles on your team’s way to completion?
4. What are the tasks that your team will put forward for other team(s) in the coming period?

As you can see here, the fourth question comes with a lot of relevance. This question now addresses the collaboration need among the teams. One team finishes a certain work (say, development of a module/screen) and hands over to another team (say, for integration) is a common phenomenon in a project, and the fourth question is set to address that. With the answers provided by each Scrum Master on this question, the other Scrum Masters would get to know the tasks they are going to get assigned in the coming period.

Another important shift was on the change in frequency. Scrum takes place everyday, and hence the questions are about yesterday and today. Scrum of Scrums are not meant to be an everyday affair, so it talks about the last period (i.e. the days between last scrum and the present scrum), and the coming period (i.e. the days between the present scrum and next scrum). That brings an important question: what would be an ideal frequency? The answer to this varies widely. The early proponents of Agile still believe a daily frequency should be the ideal dose. The practitioners who are transitioning into Agile from traditional approach thinks it should be much less; they are grouped into twice weekly and once weekly frequencies. Once weekly frequency practically imitates the traditional project progress review meetings, while the twice weekly frequency provides more substantive discussions among the Scrum Masters, not necessarily all those would be relevant.

I would recommend the readers to visit the same Scrum Alliance website to read more about the latest happenings in this area, while I would like to proceed on stories.

Agile Intelligence: Scrum

When I look into the roads through which the Agile framework has been evolving, it points back to a multiple source of managing software development. Like a project manager on any other mission, the peers in the field of software development also realized the importance of instituting a process. Thus there is Scurm, the process to address the complexity of software development by implementing inspection, adaptation, and visibility requirements in a simple set of rituals. It implements a simple iterative process skeleton which hangs on its own practices. At its core, lies a daily ritual of all-hands meeting to allow everybody to open up their hearts and deep (dark) secrets of their coder life.

Referring back to the classical way of managing projects, and the best practices recommended by the apex PM bodies; such a ritual fits within the project communication management. While the project communication management outlines a comprehensive set of methods and standards to address the communication requirements across the hierarchies, Scrum is largely focused for the people to whom the said project is the primary responsibility.

Being simple in approach, it makes the communication in a peer-to-peer format. Each Scrum starts with a Scrum-master who is tasked to ask 3 questions to everybody:
1. What did you do yesterday?
2. What will you do today?
3. What are the obstacles on your way to completion?

Each member of the project team is to answer these questions, in its most brevity possible, and the Scrum ends there. The collection of the responses form the progress made so far, the anticipated progress to be made in the next one day, the risks/issues in action.

The responses for the third question are particularly very interesting. This is the time the team members (read coders) are asked to open up. More they bring out their problems in hand, more transparent the project becomes. While Scrum does not offer the scope of problem solving right there, it facilitates the agreement of helping each other for problem solving. As example, when a developer is having a particular problem, another developer in the same room may have already overcome with an innovative solution. Scrum facilitates to have an agreement of getting this problem resolved on the same day. Similarly, when two (or more) developers are having the same problem at the same time, Scrum facilitates to have an agreement of joint attempt of resolving the problem instead of trying it from different silos.

The trick here is the culture of opening up. Programmers, by nature, take enormous amount of pride of accomplishing a complex programming problem. When they hit a problem, quite naturally, they try to own that and try to solve that by themselves. Not all programmers are comfortable enough to state a problem with the expectation that somebody will bail them out. Although, the Scrum master is tasked to ask a set of questions, this is the area where he/she needs to overcome the mere role of facilitator, and take a deeper interest in helping to get the problem uncovered. Similarly, there are team members who would describe their problem(s) with such details that it may appear to be very high on severity and complexity. The Scrum master also needs to ensure that such problems are discussed with their due priorities.

While writing this post, I came across two very good documents on Scrum. Both impressed me with their clarity and brevity in describing this practice and it fits well into your busy project life:

• Agile Meetings by Linda Rising (http://members.cox.net/rising1/Articles/STQE.pdf)
• What is Scrum by Ken Schwaber (http://www.scrumalliance.org/system/resource/file/275/whatIsScrum.pdf)