Learn Software Development » Agile 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 Working with remote teams, and some of the issues that come with this distance .. http://learnsoftwareprocesses.com/2011/11/03/working-with-remote-teams-and-some-of-the-issues-that-come-with-this-distance/ http://learnsoftwareprocesses.com/2011/11/03/working-with-remote-teams-and-some-of-the-issues-that-come-with-this-distance/#comments Thu, 03 Nov 2011 16:47:30 +0000 ashish http://learnsoftwareprocesses.com/?p=912 Outsourcing is a major factor in all software projects. When your projects are under stress to be competitive (and when you see your competitors sending work to many locations such as China, Philippines, India, Romania, etc and reducing your costs), the pressure to also outsource your work can be fairly significant. This is true whether [...]]]> Outsourcing is a major factor in all software projects. When your projects are under stress to be competitive (and when you see your competitors sending work to many locations such as China, Philippines, India, Romania, etc and reducing your costs), the pressure to also outsource your work can be fairly significant. This is true whether you are using software methodologies such as Waterfall, or Scrum, or any other. With the pressure to outsource work to these low cost centers being driven by management at senior levels, the actual coordination has to be done by people at the actual team level, and they have to deal with the pressures of doing the cross-geography coordination. In the case of Scrum, there are some specific challenges that come up and which the cross-geography teams need to resolve:
- If the remote teams are having their own Scrums, and your local team is working on its own Scrum meetings and interaction, then this model only works when the teams are working on their own projects. If however, the multiple teams work on the same project, and yet their Scrum interaction is not happening, then the teams run into more problems, namely:
* The teams still tend to think of themselves as being separate teams, and there are a lot of problems in terms of ‘us’ vs. ‘them’
* There is a great deal of gap between the teams even in terms of the actual definition of features and tasks
* There are huge issues in terms of ownership of code between the teams, and one team tends to feel that they own the code and other teams need to ask for getting access to code and so on; this in turn leads to ownership and detachment issues.
* The above problems leads to impact on the productivity of the teams
* Culture differences between the teams can lead to difficulties when it comes to items such as the amount of queries that team members have during the Sprint Planning processes, or during the Retrospective meetings. In such meetings, the teams are supposed to be as open as possible, whether it be in terms of asking queries to the Product Owner, or in terms of questioning some of the practices followed by the Sprint team (in order to point out issues, or make suggestions regarding improvements in the functioning of the Scrum team).
- One recommended method to prevent such problems is through the concept of distributed Scrum of scrums, or fully integrated Scrums where the remote team and the local team interact to a much greater degree

Already, there are enough problems in terms of getting common time frames between the various cross geography teams for the various Scrum meetings; I know some organizations that have spent a fair amount of time in terms of breaking up the work into discrete tasks that can be done separately by the separate product teams, and then the coordination in terms of what all has been achieved is through a common Product Owner.

]]> http://learnsoftwareprocesses.com/2011/11/03/working-with-remote-teams-and-some-of-the-issues-that-come-with-this-distance/feed/ 0 Difference in terms of client engagement in the case of Scrum .. http://learnsoftwareprocesses.com/2011/09/22/difference-in-terms-of-client-engagement-in-the-case-of-scrum/ http://learnsoftwareprocesses.com/2011/09/22/difference-in-terms-of-client-engagement-in-the-case-of-scrum/#comments Thu, 22 Sep 2011 17:55:15 +0000 ashish http://learnsoftwareprocesses.com/?p=883 Dealing with a client is one of the most important elements in making a software project successful. In the classical Waterfall method, the initial interaction with the client is mainly done by the Business Specialists / Product Management team. They interface with the client, understand the requirements, and eventually end up preparing a massive and [...]]]> Dealing with a client is one of the most important elements in making a software project successful. In the classical Waterfall method, the initial interaction with the client is mainly done by the Business Specialists / Product Management team. They interface with the client, understand the requirements, and eventually end up preparing a massive and detailed requirements document. This requirements document is signed off by the client (or rather by a set of people who represent the possible different functional areas of the client team). Based on this requirements document, a design document is drawn up and then the whole process goes through the development cycle, testing, release, end user testing, etc.
However, practical experience typically shows that end users from the client side don’t have their requirements in the form of a list of bullet points, and when faced with such a list, they are not easily able to confirm. Even when they confirm the list, it has been seen in a number of cases that there are many requirements that are not captured during the requirements phase, or there can be differences in the way that the requirements have been captured and the way that they have been designed. When the client gets an interim release, they could see issues in the implementation and would want changes to be done. If these changes are big enough, there is still the possibility of making these changes with some impact (may be minimal) to the schedule.
In many other projects, the client is really not engaged with the software company after the requirements phase and comes into action much later, during the beta phase or the user acceptance phase. However, in the situation described above, the possibility that the software that has been created matches the client requirements fully may not happen; which can lead to problems for both the client and for the software company. One would tend to think that one way to change this is by engaging with the client on a regular basis; however if you consider the classical waterfall methodology, the system of design, development and testing does not really lead to a process whereby the client can get engaged.
On the other hand, when you start using the Scrum methodology and get the client involved with the whole process with confirmation, you are basically involving the client as part of every Sprint. So, the Product Owners are engaged with the client on an ongoing basis to determine the features / user stories for every Sprint, as well as being there when the evolving product (and features done in the Sprint) are demoed to the client and the team. At this point (in every Sprint), the client can suggest changes or even point out things that are not done in the right way. By this method, continued engagement with the client helps in ensuring that the product matches what the client wants.

]]> http://learnsoftwareprocesses.com/2011/09/22/difference-in-terms-of-client-engagement-in-the-case-of-scrum/feed/ 0 Some of the properties to look for in a Scrum coach – Part 6 http://learnsoftwareprocesses.com/2011/08/25/some-of-the-properties-to-look-for-in-a-scrum-coach-%e2%80%93-part-6/ http://learnsoftwareprocesses.com/2011/08/25/some-of-the-properties-to-look-for-in-a-scrum-coach-%e2%80%93-part-6/#comments Thu, 25 Aug 2011 14:10:53 +0000 ashish http://learnsoftwareprocesses.com/?p=867 In this series of posts (Finding a Scrum coach), I am trying to post some points about what you should look for when trying to hire a Scrum coach. I have covered a lot of such points in the previous 5 posts in this series, and in this post, will post a few more points [...]]]> In this series of posts (Finding a Scrum coach), I am trying to post some points about what you should look for when trying to hire a Scrum coach. I have covered a lot of such points in the previous 5 posts in this series, and in this post, will post a few more points (and that should end the points I would have on this area). So here goes:
- Be careful when an over-enthusiastic Scrum coach turns up when you are near an important milestone, or are in deep problems and looking for solutions. In such times / situations, it is fairly easy to look upon anybody who offers a solution as a savior and be more flexible in getting solutions. This is the time when teams drop their guard and can then, in many cases, repent later at leisure. You can be in a difficult position, but do not cut back on some of the essential requirements that you have for a Scrum coach.
- Look for specific areas that you need help in. Consider that teams working on Scrum projects can have specific areas that they are having issues on, and it is in those areas that you need help. So, consider that you are having issues related to the estimation and task breakdown (from the User Stories that are written), and you find that the Scrum coach you are currently interviewing for your team is actually having competence in the area of release processes under Scrum. In such cases, you need to take care about the level of competence of the Scrum coach and the fitment with your needs. If it turns out that the Scrum coach is an expert in the area of release, and is also very good in the overall area of Scrum, then that would work for you. However, if the person is not able to demonstrate the required experience and expertise in the area of estimation, then such a Scrum coach would probably not work for you. Be very careful about this area, else you will find that you will not be able to get the benefits of having a Scrum coach.

]]> http://learnsoftwareprocesses.com/2011/08/25/some-of-the-properties-to-look-for-in-a-scrum-coach-%e2%80%93-part-6/feed/ 0 Some of the properties to look for in a Scrum coach – Part 1 http://learnsoftwareprocesses.com/2011/08/01/some-of-the-properties-to-look-for-in-a-scrum-coach-part-1/ http://learnsoftwareprocesses.com/2011/08/01/some-of-the-properties-to-look-for-in-a-scrum-coach-part-1/#comments Mon, 01 Aug 2011 18:19:01 +0000 ashish http://learnsoftwareprocesses.com/?p=852 In previous posts, I have mentioned about the importance of the Scrum coach. In this post, I am going to trying to provide more details on what a Scrum coach needs to do. You can find a lot of people who claim to be Scrum coaches, but whether you are finding the best person for [...]]]> In previous posts, I have mentioned about the importance of the Scrum coach. In this post, I am going to trying to provide more details on what a Scrum coach needs to do. You can find a lot of people who claim to be Scrum coaches, but whether you are finding the best person for your team and organization can take a bit of time. Since the Scrum coach can effectively make or break your Scrum team and have a huge impact on the productivity of the Scrum teams in your organization, it is important that you take the right amount of time and effort in order to get a Scrum coach that meets your needs. So how do you find a Scrum coach:
- A good Scrum coach should project an air of being an expert in Scrum. A coach should be a person who seems enthusiastic about the teaching of Scrum, who believes that Scrum is the way to do software development. If a Scrum coach has doubts or seems to project an air of less than competency, then such a Scrum coach is probably not the right choice for you. A Scrum coach would consider it terribly important to ensure that every Scrum team is successful in its effort, all issues that the team is facing are resolved as best as possible.
- Scrum coaches have a good amount of experience and a lot of knowledge about the various processes involved in Scrum teams. You want a Scrum coach who seems to have experience in the issues you may face, and is able to use the right techniques to solve your problems. For this purpose, the Scrum coach you hire for your team or organization should have a wide amount of experience in solving Scrum issues, know about the right set of processes and techniques to follow, and be able to guide your teams through these. The Scrum coach should be able to show their past experience in Scrum, their experience with different Scrum teams, be able to talk about difficult Scrum problems they have solved (and this experience should seem believable). If you have team members who have been working on Scrum, some amount of discussion with them can help determine easily whether the Scrum coach has a good amount of experience. Do not compromise on this, since the Scrum coach you hire can mean the success or failure of your Scrum teams.

I will provide more information on the properties that a Scrum coach should have in the next post ..

]]> http://learnsoftwareprocesses.com/2011/08/01/some-of-the-properties-to-look-for-in-a-scrum-coach-part-1/feed/ 0