Learn Software Development » Product Management

Having a decisive Product Manager for the project, and what if this does not happen ..

ashish — Tue, 17 Apr 2012 15:13:59 +0000

In many cases, especially for small projects / new teams, the Product Manager is typically somebody who is also not very experienced. The idea is that the Product Managers who are highly skilled or with a lot of relevant experience are assigned to the teams that are doing more important work. But this can sometimes result in significant problems for the project, to the extent that the project can become unsuccessful. There is an argument that people need time to get experience, and working in smaller or less important projects is necessary to groom people, and that may be a fair and true argument, but there is no getting around the fact that this can cause a lot of problems for the team.
When you have a team with newer people, there is a far less acceptance of what is possible and what is not. People have not had the time or the experience to learn a dose of realism, and figure out the speed at which things move as a part of software project development. When you add an inexperienced Product Manager to the mix, things can get even more complicated.
Consider the case whereby the team is working on a new feature, and something that is not really a copy of another product’s feature. In such cases, the team can have a lot of fresh ideas when working on the requirements and design of the feature, and when you have a user experience designer working on the project, the person will have a lot of ownership of the design of the feature. Now, based on some experience in such situations, what I have typically observed is that feature requirements are not really closed for long periods of time, or get closed and are then re-opened some time later. This would typically happen when the user designer has an idea, and then when it is implemented, the team members or even the designer has some modification of the idea, and far worse, the modification is seen as an improvement.
Now, if you are in the shoes of the project manager, in order to get the project moving, you can appreciate incremental improvements in the product as described above, but if these happen all the time, the schedule (even if you are using Scrum or other Agile methods) will never really get close to a conclusion. In such cases, what you really look for is a strong Product Manager who can take calls about whether the feature is good enough for customers, even when it is not perfect (and this may seem strange to a lot of people, but successful project management is about striking a balance between the improvements that you make to the application, and also about the discipline needed in the project in order to get achieve progress in the schedule).
In all such cases, a strong Product manager can ensure that after some due iteration, the feature requirements and design are closed, or even more, when newer queries are raised, they need to be striking improvements before they are allowed to be open. A good Product Manager is worth his or her weight in terms of gold if they are able to make these kind of calls and ensure that the schedule is adhered to.

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

Distributed Scrum: Mistake to have only the Product Owner in a separate location

ashish — Sat, 19 Nov 2011 19:31:32 +0000

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.

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.

How to incorporate UI design as part of Scrum work, collaboration between Product Owner and UI Designer

ashish — Tue, 18 Oct 2011 19:16:37 +0000

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.