Learn Software Development » Scrum http://learnsoftwareprocesses.com All about the processes involved in software development Tue, 07 Feb 2012 19:53:10 +0000 en hourly 1 Do Scrum of Scrums meetings add value to the project – Part 1 http://learnsoftwareprocesses.com/2012/02/07/do-scrum-of-scrums-meetings-add-value-to-the-project-part-1/ http://learnsoftwareprocesses.com/2012/02/07/do-scrum-of-scrums-meetings-add-value-to-the-project-part-1/#comments Tue, 07 Feb 2012 19:53:10 +0000 ashish http://learnsoftwareprocesses.com/?p=975 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 [...]]]> 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
]]> http://learnsoftwareprocesses.com/2012/02/07/do-scrum-of-scrums-meetings-add-value-to-the-project-part-1/feed/ 0 Expanding the Scrum process to a larger team, some problems .. http://learnsoftwareprocesses.com/2011/12/13/expanding-the-scrum-process-to-a-larger-team-some-problems/ http://learnsoftwareprocesses.com/2011/12/13/expanding-the-scrum-process-to-a-larger-team-some-problems/#comments Tue, 13 Dec 2011 18:54:49 +0000 ashish http://learnsoftwareprocesses.com/?p=936 We were successfully running Scrum on a team that was just at the appropriate size, with around 8 people in the team, all well trained in Scrum and believing in the way forward being Scrum. They understood how to use Scrum, and had developed a nice understanding with the managers of the team to ensure [...]]]> We were successfully running Scrum on a team that was just at the appropriate size, with around 8 people in the team, all well trained in Scrum and believing in the way forward being Scrum. They understood how to use Scrum, and had developed a nice understanding with the managers of the team to ensure that they got the desired independence to estimate tasks and track the progress of the tasks. As a result, they were the team that everyone pointed to when there was a need to point out success stories and were also called to present to other teams that were planning on using Scrum.
Soon, there was a plan to take another team through the Scrum process, and with team members from the first team providing training and support, the plan was started. The idea was to get the division of the team done properly (since this was a 20+ member team), along with separation of the features into some significant areas such that multiple teams could handle each tasks separately, set Product Owners for these tasks. The thought was that this would be a smooth experience.
Well, it was not. Soon, within a couple of Sprints, the Product Owners started complaining that many integrated features were just not making it as the original plan, and the product was falling apart whenever integration was supposed to be happening. Soon, there was an emergency session on to figure out what was going wrong, since individual Scrum teams were working fine. After some analysis, the following were found to be some of the main problems:
- Coordination between the multiple Scrum teams was just not happening to the desired level. There were informal contacts between the team members, and the Product Owners met up on a regular basis, but the deep technical discussions that should have been happening were not present; this was primarily because the teams were too focused on their own specific work (and this was enhanced by the emotional attachment they had developed due to the process of estimation and assignment, as well as because of the Daily Scrum meeting).
- The teams were no longer thinking of the big project. Originally, you had the managers who would always have a conception of the big picture in terms of the integrated product, but after passing on a fair amount of the operational authority to the team members, the picturisation of the big picture when doing the regular daily work was getting lost. The only alternative that seemed to occur to the managers was to get more involved, but they also did not want to seem to interfere with the work being done by the team.
- Daily meetings. With the big teams being split into smaller teams, the management was getting very heavily stretched just in terms of the amount of meetings, and if they did not attend the meetings, the managers were not sure of being aware of status of what is happening in the project, and hence had to stretch to know more. This in turn prevented the managers from spending the desired amount of time that they would normally spend on other items such as optimizations, improvements, and looking at the big picture.

Succeeding with Agile: Software Development Using Scrum The Elements of Scrum
 A Practical Guide to Distributed Scrum
]]> http://learnsoftwareprocesses.com/2011/12/13/expanding-the-scrum-process-to-a-larger-team-some-problems/feed/ 0 Scrum – Provides you a good quick feedback on accuracy of estimates for tasks .. http://learnsoftwareprocesses.com/2011/12/10/scrum-provides-you-a-good-quick-feedback-on-accuracy-of-estimates-for-tasks/ http://learnsoftwareprocesses.com/2011/12/10/scrum-provides-you-a-good-quick-feedback-on-accuracy-of-estimates-for-tasks/#comments Sat, 10 Dec 2011 21:24:28 +0000 ashish http://learnsoftwareprocesses.com/?p=934 One of the major dependencies for a successful project schedule is in terms of the accuracy of estimates versus the reality. In short, you want to measure the difference between the time estimate for a project (or a task inside the project), and the actual effort needed. For such a measurement, you would want to [...]]]> One of the major dependencies for a successful project schedule is in terms of the accuracy of estimates versus the reality. In short, you want to measure the difference between the time estimate for a project (or a task inside the project), and the actual effort needed. For such a measurement, you would want to ensure that variables such as changes in feature specs or design between the estimate and the actual execution are eliminated; if your design changes between the initial estimate and when you sat down to do it, then it is very difficult to make such a measurement, or to learn something from such a measurement.
Consider the following example; a colleague of mine used to review the actual time spent on a task, and then compare it with the estimate for the same. He used to do this for multiple tasks, and where the variables (such as requirement changes, or design changes, etc) did not change too much during the time period, he would slowly start to learn which person tended to do the task earlier than the estimates given by the same person, and also the reverse. The next time he would ask these people for an estimate, he would accordingly make the relevant changes in the estimate he got, and then use the modified estimate for the final planning.
Scrum makes this review even more easier. In Scrum task tracking, the team is supposed to provide an update every day on what has been done, and which tasks will take up more time than initially planned. As a result, and especially because tasks tend to be defined in terms of hours and a few days rather than 5+ days, it becomes immediately clear as to which tasks are getting delayed. So, when you are using Scrum in your team, you will immediately start to see the variance between estimates and actual figures. Now, the development team may think that you are trying to find fault, but getting the estimates to be as close to actual figures is very important. This helps you better estimate the deliveries at the end of the Sprint, and prep the customer / product owner about what all is going to be delivered for which you want feedback. This also helps stakeholders get more confidence in the work done by the team.
Being able to see variance could also help you to figure out more research into why the estimates are getting varied; is it because the details provided by the Product Owner are not detailed enough to generate the right estimates, or is it because there are some design issues that cause more effort than people estimate. Make sure that this investigation is done.

The Elements of Scrum The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper
 Practical Software Metrics for Project Management and Process Improvement
]]> http://learnsoftwareprocesses.com/2011/12/10/scrum-provides-you-a-good-quick-feedback-on-accuracy-of-estimates-for-tasks/feed/ 0 Mining the Daily Scrum meeting for issues related to the team, organization, etc http://learnsoftwareprocesses.com/2011/11/22/mining-the-daily-scrum-meeting-for-issues-related-to-the-team-organization-etc/ http://learnsoftwareprocesses.com/2011/11/22/mining-the-daily-scrum-meeting-for-issues-related-to-the-team-organization-etc/#comments Tue, 22 Nov 2011 19:40:58 +0000 ashish http://learnsoftwareprocesses.com/?p=923 It is often said that Chickens should not be present in the Daily Scrum meeting, since they tend to start interfering in the work of the Scrum team, question progress, volunteer suggestions (more like order), etc. All this can be very disruptive to the team. However, there is a catch. What we have found (and [...]]]> It is often said that Chickens should not be present in the Daily Scrum meeting, since they tend to start interfering in the work of the Scrum team, question progress, volunteer suggestions (more like order), etc. All this can be very disruptive to the team. However, there is a catch. What we have found (and what literature seems to suggest) is that the Daily Scrum meeting is one of the meetings which brings out the truths of a project, things that need to be handled for improving the productivity of the team, and make it more efficient. Some of these items remain hidden when the team is not empowered (such as when the team is working on a waterfall model where the managers and lead assign work, monitor progress and make adjustments accordingly), and in the process of raising up of progress and obstructions during the Daily Scrum meeting, many of these problems come to the surface and can be handled.
For this purpose, it is important that managers of the teams be there in the Daily Scrum meeting to understand the issues brought out and when required later, take the necessary corrective action. However, they need to also ensure that they do not interfere with the progress of the Daily Scrum meeting and let the team go through the process of explaining their work done, impending work, and any problems that may come up. What are some of the problems that may come up?
- When people are getting delayed. Consider the fact that people are working on Daily progress, and their progress is not as expected. When this happens on a regular basis, it can become quite clear from the Daily Scrum and the concerned manager can do the required counseling of the person.
- Team members are working on multiple items. When team members are there on multiple projects, any delays due to their commitments to other projects become clear and these need to be handled; or else, only the amount of time that they have available should be factored in.
- Lack of commitment. If people come to the Daily Scrum in a casual manner, do not provide quality updates, and so on, it can become quite clear that something is not right. Either the morale of the team is not good, or there are other issues that need to be handled and which have not been handled properly so far. This is something that needs to be handled quickly, else the efficiency of the team can get affected.
- Design problems. When the team keeps on running into daily issues where they have to work around design or architectural limitations, it can be quite clear that enough time has not been spent on design issues.
- And so on, a lot of problems emerge in the Daily Scrum that can be used to better optimize the team.

]]> http://learnsoftwareprocesses.com/2011/11/22/mining-the-daily-scrum-meeting-for-issues-related-to-the-team-organization-etc/feed/ 0 Distributed Scrum: Mistake to have only the Product Owner in a separate location http://learnsoftwareprocesses.com/2011/11/19/distributed-scrum-mistake-to-have-only-the-product-owner-in-a-separate-location/ http://learnsoftwareprocesses.com/2011/11/19/distributed-scrum-mistake-to-have-only-the-product-owner-in-a-separate-location/#comments Sat, 19 Nov 2011 19:31:32 +0000 ashish http://learnsoftwareprocesses.com/?p=921 Given the bad economy and the relentless surge to reduce costs, there is a lot more focus to see how all the costs involved in a software project can be reduced. Over the past couple of decades, a model where the development work moves to lower cost countries such as Romania, India, China, Philippines, etc [...]]]> Given the bad economy and the relentless surge to reduce costs, there is a lot more focus to see how all the costs involved in a software project can be reduced. Over the past couple of decades, a model where the development work moves to lower cost countries such as Romania, India, China, Philippines, etc has gained ground and there have been no significant failures to get this movement rolled back. When there is relentless pressures on senior management to show that costs are controlled, and there are no easy cuts (there is already a lot of monitoring of other expenditures such as travel, etc), the next question is about why the development effort cannot be moved over to Bangalore; after all, other companies are also doing it and by the way, their costs are now lower with no appreciable impact to quality. It is difficult to resist such an argument, unless the cost is a small fraction of the overall revenue.
So, what slowly ends up is that the development work (both coding and testing) gets moved in parts to a lower cost economy and eventually reach a point where all the development work is done in a remote location. We call it remote since there is an impetus to ensure that the Product Management remains connected to the market, and for most software products, the sizable revenue earning markets are the US, Japan and parts of Europe. So more often than not, the Product Manager / Product Owner remains in a city in the US, while the entire development effort moves to some part of India. And then the team goes ahead and implements Scrum.
You now have a scene whereby the meetings are such that the Product Owner attends from the US, the remote team attend from their locations, and the meeting is held at a time that is decided by all of them (for most of these meetings, the guiding principle is that the pain should be equally shared, so that no one feels that they are being discriminated against). However, for the case of Scrum, where there is a lot more interaction between the Product Owner and the Product team, it can get very tricky to have only the Product Owner in a separate location. For one, the Product Owner will sooner or later tire of having to disturb their entire schedule in order to attend the Daily Scrum Meeting, or even if they do not attend the Daily Scrum meeting, there can be a lot of discussions needed between the team and the Product Owner. When the Product Owner is located in the same location, there can be a lot of discussions that can happen through hallway conversations, or striking up quick call meetings where the Product Owner provides clarification or quick feedback to the team.
One way that I have found teams have worked this through (but which can slightly increase the planned expense) is when there is a Product Owner who also sits with the development team. This Product Owner works with the main Product Owner through frequent interactions, and has enough authority and clarity that he / she can answer most of the queries of the Product team and only need to go to the Product Owner for detailed queries that may not have been discussed before.

]]> http://learnsoftwareprocesses.com/2011/11/19/distributed-scrum-mistake-to-have-only-the-product-owner-in-a-separate-location/feed/ 0