Learn Software Development

Do Scrum of Scrums meetings add value to the project – Part 1

ashish — Tue, 07 Feb 2012 19:53:10 +0000

One of the most confusing meetings for new entrants to Scrum is the Scrum of Scrums meeting. For a lot of people, there is no clear understanding about why this meeting is held, who are the participants, frequency, agenda, etc. I have been through a couple of trainings and those did not really cover the Scrum of Scrums. In the past, we have had some team members of complex Scrum teams (where the project was split into several Scrum teams for convenience) coming to us (a group of experienced Scrum Masters), asking for more experience in what this meeting was about. Some of them were researching about what to do when they had large teams working together, and needed some guidance in this regard. This post (and many others) are more in terms of explaining what the Scrum of Scrums is, and how it can be optimized.
So what is the Scrum of Scrums ? Well, as in many of such terms and processes, you will find some amount of variety in the answers you get, but there is consensus about the fact that it is a process geared towards ensuring that multiple scrum teams interact with each other. Consider a big project with many features; these are broken down into multiple Scrum teams. However, it is required that these teams interact with each other, since it would be pretty accurate to expect that features could interact with each other. For example, a login module would not work until another team has made the connectivity with the Database work, and yet another team has made the security protocols for the login process.
Because of all these interactions and dependencies, the teams need to interact to resolve and coordinate the integration of these dependencies. In our experience, we have had the Scrum Master and Product Owner from the Scrum teams attend the Scrum of Scrums (the frequency of this meeting in turn needs to be defined by the members of this meeting; we have had cases where the number of dependencies meant that teams meet for this meeting every day, in another case where the User Stories were fairly independent, and the Scrum of Scrums would be setup for once a week and would finish quickly); we haven’t had something like a Scrum Master concept for the Scrum of Scrums meeting. But, we did ask for a person from the Product Management organization with enough authority to act as a Product Owner for this Scrum of Scrums; one of the primary roles of this PO was to reconcile different priorities among the various Scrum teams to ensure that feature dependency schedules were properly synchronized, even if that meant that some individual Product Backlogs had to be redone to incorporate changes in priority (in one significant case, one Scrum team ended up with a task on the next Sprint that was at a very low priority because other teams depended on that task for a lot of architecture support).

More on the Scrum of Scrums in the next post ..

Succeeding with Agile: Software Development Using Scrum	Agile Estimating and Planning	Agile Testing: A Practical Guide for Testers and Agile Teams

Not pushing the team too hard – a fine balance that can be easy to miss – Part 5 ..

ashish — Wed, 01 Feb 2012 11:22:03 +0000

In this series of posts (previous post about compensation disparities), I have been talking about the problems that caused our team, which had improved its productivity levels to become one of the most productive teams, to start raising objections to being pushed for the work that they were doing. So far, during the analysis that we had done once we started getting pushback from the team, we had listed compensation policy change, general fatigue, and some other reasons that caused these problems. In this post, I will talk about some additional problems that we started facing as we faced the same team getting older.
One of the advantages of not having too much attrition is that you get people who are experienced with the application / software project. So, these people have much more experience with the code, are able to get things done faster, are quickly able to figure out potential problems, and so on. Equally, once they see a problem, whether found by the QE team or customers, many of the problems will be some that they would have found earlier; and in some cases, we found that people were easily able to figure out the specific defect number that had been deferred earlier, or otherwise resolved. Newer people take a lot more time to do this.
In our case, we had the same team, with fewer changes due to the low number lost due to attrition, and as a result, over a period of time, we found that the team was getting much more experienced with the product. Hence, there was an improvement in productivity directly because of their increased experience. Yet, since we had started with a younger team, as they got more experienced, many of them lost their single status and got into relationships, and many of them started families.
One normally does not account for changes such as these since the personal life of employees, and their work-life balance was something that needs to be kept in balance. However, part of the factors that went into increasing the productivity of this team was about them putting in extra hours, and this was also backed up by awarding people who put in more time (and also those who had managed to make major changes in their productivity). But guess what ? As their involvement with families grew, the amount of time that people could spend on the job decreased, and also they had more distractions. The birth of kids, health problems, etc would normally take up a higher importance in their time, and this showed up in the productivity of the team stabilized, or a small decrease.
And the most surprising item was that people were willing to accept that they would no longer be rated as the most valuable member of the team, if that meant that they had to take a compromise between putting in extra time and be able to spend time on the personal front. And this in turn contributed to the pushback we were getting from the team members in term of productivity.

Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness	How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results	Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity

Not pushing the team too hard – a fine balance that can be easy to miss – Part 4 ..

ashish — Sun, 29 Jan 2012 19:53:22 +0000

This is a series of posts (Previous post about a hard pushing manager) that I am writing about the morale issues we faced in a team that increased its productivity levels over a period of months, making it one of the most productive teams in the company. However, the issue was about whether we reached a point where the team members starting protesting against the policies being followed, and we started facing morale issues. At this point, we had a series of meetings and discussions about what was going wrong, and these are some of the discussions we were having.
In this post, we talk about compensation issues and what these can do to morale, especially in a team which was being setup for high productivity. Over a period of time, the company decided to setup a system to encourage high performers. Initially, the company had a system where a bonus was paid out to all members of the organization when the organization reached a certain performance level. However, over a period of time, the organization got into a mode to focus on the high performers in the organization and ensure that they got into reward mode. Previously, the company used to ensure that people who were high performing got their rewards through an accelerated growth during the annual appraisal cycle.
But, in a twist, there was a lot of push in the higher management towards putting more focus on the high performers in the company. This was based on a study and research which showed that the whole industry was getting in a mode whereby the high performers wanted to be differentiated from the others who were not as good as them; and the company also wanted to ensure that attrition levels were contained within the high performers. So as a result, a lot of the policies were geared towards benefiting the high performers in the organization.
Further, these 2 trends started converging on each other – the team was geared towards higher productivity and at the same time, there was a trend to divide the team into multiple groups for the benefits of giving awards. The policy was to use a Bell curve to divide the team into multiple groups, with the higher rated members of the team getting a greater share of the benefits than earlier. The Bell curve ensured that division of the team resulted in lower ranked members of the team getting lower amounts of benefits than earlier. This was difficult to explain to these team members, especially since they could see a productivity increase and were unable to understand why they were getting rated lower; and even worse, were getting a lower share of the benefits than earlier. The biggest problem was that now the stock grant was given to a lesser percentage of the team than before, and hence people could suddenly see that they were not getting stock as they used to be given earlier.
This resulted in a major morale issue, and you could see that people who were not placed in the higher ranking group were dissatisfied with the policy of the company, not about their ranking, but the fact that the company had suddenly decided to make a major difference between the high ranking members and the ones who were not so high ranked.

Continued in the next post ..

Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness	How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results	Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity

Not pushing the team too hard – a fine balance that can be easy to miss – Part 3 ..

ashish — Mon, 23 Jan 2012 19:14:41 +0000

This is a series of posts that I am writing about the dynamics of a team, and how it came to be that we started getting push back from the team about pushing them too hard, which lead to a series of introspective discussions (Pushing the team too hard) about whether we had gone too far, and what should be the next steps. In the previous post, I started writing about how the team was being pushed to be more aggressive, and this in turn was causing additional risk to projects that the team was taking up.
In this post, I will be talking about the problems that an aggressive manager was inadvertently causing to the team. Morale of the people involved is a big deal for teams that are supposed to be highly productive, and the organization needs to continue doing efforts that would make sure nothing is happening that would reduce the morale of team members. However, this can get problematic when you have a manager who can put a lot of pressure on team members to the extent that this would reduce morale and make them feel down and out.
As part of the efforts to improve the productivity of the team and make it a top performing team, the organization brought in a new manager who was reputed to turn around teams. The manager was a high energy person, and you could see that fairly fast into his introduction into the role. He would monitor implementation of projects, directly moving among the team members and had a good idea about team members who were effectively shirking work. This tactic worked pretty effectively, since it also encouraged the various team managers to monitor the performance of their team to a greater extent and ensure that anybody shirking or not working as much as required was spoken to and provided feedback.
However, there is a fine transition between being aggressive and starting to cause frustration in the team members. When people believe that they are working at a good pace and feel proud of what they have accomplished, they seek to hear good words; but when you have a person who can be aggressive, it can turn out pretty good in terms of driving the team (but this happens when the team members believe that the overall manager is actually a great driver and visionary and then neglect or ignore his hard driving efforts). However, if the team members start to feel that the manager is actually not appreciative of their work when they have put in some great effort, it can be very bad for morale.
In our case, this is what was starting to happen. The manager would push people to get work done fast, and for some time, those team members who liked doing great work were very impressed. However, when they could see that the manager was all about push, and more push, and it was hard to actually hear some words of praise from the manager, there started a wave of people expressing issues or feeling hurt after the interaction with the boss. What made it worse was that the team members would share their own stories, and this made the issue of morale even more difficult; and of course, since the team was performing at a high level, the manager was seen as a success story.
However, after this much analysis, and after the HR Department also got involved, the management prepared an exit path for the manager and decided to bring in another manager who was passionate, but who had also got a reputation for appreciating good work.

Continued in the next part …

Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness	How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results	Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity

Not pushing the team too hard – a fine balance that can be easy to miss – Part 2 ..

ashish — Tue, 17 Jan 2012 15:34:14 +0000

The previous post (Pushing the team, maybe too hard) detailed some of the problems that a team that was under-performing started experiencing when it decided that it would not longer under-perform and started to move up the performance chain, but in the end, the focus on productivity started taking a toll on the team members. There were a number of factors that were not considered when it started becoming a bit more clear that the team was getting fatigued.
One of the biggest factors that we had to re-consider was the notion that we would not say no to a request or a project without doing a lot of deliberation, and if there was a chance, then we would be aggressive and push for doing the project. This worked beautifully for a while, since earlier we would be conservative, and when we would do a resource and risk assessment, if there was a chance of some risk (around 20-30%), we would say no to the project. This was giving the group the title as a No saying group. So, we worked hard at this aspect. Over a period of time, when a project was proposed and we were evaluating the project, we would do a calculation of the risk, but we would also do a strong focus on seeing whether the risks could be mitigated. So, when there were risks, senior members of the team which was doing the evaluation would be encouraged to take a look at the risks, and see whether there were steps that could be taken to manage these risks, and even if this required extra effort, it would be worthwhile to take the extra effort and get these things done. In addition, an incentive was given to the team, in terms of promises of higher rewards for higher productivity, and with differentiation between team members based on the effort that they would undertake (and this was a big deal in terms of encouraging people – if many team members felt that extra effort was being recognized, you had several of them putting in an hour or two of extra effort on a daily basis in order to show that they were capable of doing more effort).
Well, all this had the desired effort. This factor about being more aggressive had an important effect on the reputation of the team, and we were being known as the team that could get work done that seemed more difficult for the other teams. But, at the same time, there was a risk in terms of what we were doing. Since we were taking more chances on the risk front, we were pushing the envelope, and this did hit us in a couple of occasions where we ended up taking last minute risks with the project, and in one case, had to get people from other groups, else the project was a goner. These cases did cause some amount of re-thinking, but not a drastic change in policy, and we continued on. So, what were some of the pointers to the fact that we were heading towards a case where we were trying to chew more than we could do ? Well, for one, we had people from other teams and from senior management asking the team management whether we knew our limits / constraints, and was our risk calculations on the right side of sanity ? These queries were coming up more recently, and these also started a re-think on the level of aggressiveness we were following.

Continued in the next part …

Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness	How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results	Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity