Learn Software Development » Agile

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

ashish — Mon, 13 Feb 2012 20:00:19 +0000

In the previous post (Scrum of Scrums), we started discussing about what the Scrum of Scrums meeting is all about. In today’s post, we shall discuss more about the Scrum of Scrums meeting. This is a meeting that is typically not meant to be a kind of mega-status meeting, being meant to be a technical coordination type of meeting where representatives from the different Scrum teams come to discuss technical and coordination issues. Who actually attends from each team is left open, and there is no necessity that a Scrum Master or Product Owner from each team should be attending; in fact, a number of people to whom I have spoken also talk about one of the senior technical folks from each team attending this meeting rather than any manager kind of person attending.
But since this is a meeting requiring a fairly detailed level of coordination between different teams (some of the issues related to inter-team technical coordination can be fairly complex, requiring changes in the Product Backlog of individual teams and follow up), so you need a Scrum Master or a Project Manager to manage this meeting, coordinate the various actions; in some cases, have discussions with the Product Management organization for resolving conflicting priority of items and seeing through the various changes that would be required over a period of time.
Further, there is no time slot for the Scrum of Scrums, it does not require the same kind of time boxing as the Daily Scrum meeting which has some strict criteria on what can be discussed, the amount of time that such a discussion can happen, and so on. This follows from the fact that the Scrum of Scrums is not meant to be an update meeting, but a meeting between the various Scrum teams so that they can resolve their issues and do a much better level of coordination.

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

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 (link) ..

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

Working with remote teams, and some of the issues that come with this distance ..

ashish — Thu, 03 Nov 2011 16:47:30 +0000

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.

Difference in terms of client engagement in the case of Scrum ..

ashish — Thu, 22 Sep 2011 17:55:15 +0000

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.

Some of the properties to look for in a Scrum coach – Part 6

ashish — Thu, 25 Aug 2011 14:10:53 +0000

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.