Learn Software Development » Product Management 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 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 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 How to incorporate UI design as part of Scrum work, collaboration between Product Owner and UI Designer http://learnsoftwareprocesses.com/2011/10/18/how-to-incorporate-ui-design-as-part-of-scrum-work-collaboration-between-product-owner-and-ui-designer/ http://learnsoftwareprocesses.com/2011/10/18/how-to-incorporate-ui-design-as-part-of-scrum-work-collaboration-between-product-owner-and-ui-designer/#comments Tue, 18 Oct 2011 19:16:37 +0000 ashish http://learnsoftwareprocesses.com/?p=906 If you want to ensure that your product / software application is successful, there are a number of things you need to care of. If you look at the success of many of Apple’s products such as the iPod, the iPad, iTunes, and the iPhone, it is about ensuring that your workflow appeals to customers, [...]]]> If you want to ensure that your product / software application is successful, there are a number of things you need to care of. If you look at the success of many of Apple’s products such as the iPod, the iPad, iTunes, and the iPhone, it is about ensuring that your workflow appeals to customers, that they find using it so easy that they are even willing to pay a premium for such products. What this brings out is the importance of ensuring that you have workflows that appeal to customers, and this means that you need to get your UI designer into the product development process. However, it is not easy to integrate the working of processes with the working style of UI designers. In my experience, getting them to work with the kind of deadlines and schedules that you can impose on engineers and QE can be a difficult task, and this process can interfere with their creative juices.
So, what happens in the case of Scrum ? Well, for Scrum work, we typically say that features should be worked upon when you get close to the Sprint, since that is when the prioritization of features for a Sprint actually happens. However, when the sprint starts, the team starts working on the tasks, which means that the UI for those tasks should be ready. Which automatically means that the UI for tasks should start before the Sprint planning activities (seems a bit strange that some activities for tasks should occur before the Sprint in which the task should be worked on, but there is no other way to get the UI in place).
For this to happen, it is also necessary that there is a parallel planning process underway, whereby the Product Owner has a list of prioritized tasks (already there as part of the Product Backlog); with the difference being that the tasks for the next Sprint should be confirmed during the previous Sprint. In addition, there should be a schedule in place which tracks the work being done by the UI designer, and this planning needs to happen with the Product Backlog, so that it should never happen that the UI designer is getting too many tasks. If this happens, then the UI will not be ready when the team is starting work on the tasks in the Sprint.
So, in the Sprint before a particular Sprint, the Product Owner, one or 2 assigned team members, and the UI designer should be working on a list of tasks for which the UI is required at the start of the subsequent Sprint, and should aim to get a high level workflow document and a UI wireframe in place. Once the actual Sprint starts, the Scrum team will start working with the UI designer to get the final UI based on the User Stories outlined by the Product Owner.

]]> http://learnsoftwareprocesses.com/2011/10/18/how-to-incorporate-ui-design-as-part-of-scrum-work-collaboration-between-product-owner-and-ui-designer/feed/ 0 The compromise between having a Product Owner who tries to detail out too much .. http://learnsoftwareprocesses.com/2011/10/17/the-compromise-between-having-a-product-owner-who-tries-to-detail-out-too-much/ http://learnsoftwareprocesses.com/2011/10/17/the-compromise-between-having-a-product-owner-who-tries-to-detail-out-too-much/#comments Mon, 17 Oct 2011 17:42:00 +0000 ashish http://learnsoftwareprocesses.com/?p=904 Scrum suffers from problems where you have a Product Owner role that needs to have a person who has understood the role in good detail. In a lot of cases, just transitioning the role from that of a regular Product Management role to that of a Product Owner role takes some amount of getting used [...]]]> Scrum suffers from problems where you have a Product Owner role that needs to have a person who has understood the role in good detail. In a lot of cases, just transitioning the role from that of a regular Product Management role to that of a Product Owner role takes some amount of getting used to. So, you need to have a Product Owner who is setup to define a level of responsibility where the Product Owner gives enough detail about the feature without trying to get into a lot of detail.
In the regular Waterfall kind of product development methodology, the Product Management team / person defines a great level of detail for all the features and puts these into the Requirement documents. These are then signed off by the customers (in many of the cases), and then explained to the various teams. In turn, the teams then create design documents, test documents, and do a full traceability matrix from the requirements. This ensures that the requirements are adhered to in great detail, and there is no confusion among the implementation team with respect to the requirements.
So, when a member of the Product Management team starts working as a part of the Scrum team, they are used to the level of detail that they already do in the past. Consider the case where the team has a number of features, and the Product Owner looks at the features, and based on their past record, start breaking down the features into how the screens should look like. In the extreme case, the Product Owner will continue on this line and insist that the team should design the screens and dialogs exactly like how the Product Owner wants it to be, right at the beginning of the cycle.
In Scrum, the Product Owner should take the feature / User Story, and define the User Stories / tasks in such a way that they answer the various queries that the users of the product will have. So, when defining user interactions, these are defined in terms of problems that the users will be looking, not in terms of the screens that will be present in the application. This does not mean that the Product Owner will not look at how the UI of the application should like, it’s just that the UI definition should happen near the relevant Sprint; and in fact, the Product Owner should work with the UI designer attached to the team, and work in advance to get concepts of how the screen should look like.
The difference is that the Product Owner should focus on the ease of use of the application, get feedback on how the workflows can be made more user friendly, and so on. And, since the UI is part of the features that are demoed at the end of the Sprint, there can be more feedback that causes a change in the UI that has been designed earlier. The Product Owner should be ready to modify the UI as and when required.
I reviewed what I have written earlier, and it seems to match what our team does, but seems a bit confusing. Can you comment on how your team works ?

]]> http://learnsoftwareprocesses.com/2011/10/17/the-compromise-between-having-a-product-owner-who-tries-to-detail-out-too-much/feed/ 0