Learn Software Development » Product

What happens when your product is not stable close to release date ? – Part 2

ashish — Tue, 08 May 2012 19:57:02 +0000

In the previous post in this series (Making the right decisions), I talked about some of the decisions that the senior management team has to make when they are near the release of a major product, and the balancing act that they need to make while making the right decision (in a situation where the wrong decision can break their career and cause huge damage to their companies). With such risks, it is a wonder that these managers are able to make a decision at all, and yet you see people making such decisions under these high pressure situations all the time.
So in this post let us talk about what should not happen. Given the tremendous pressure that exists to ensure that the schedule is met, there is a basic mental tendency to be optimistic and hope for the best, and this can get projected in a way that there is reluctance to hear bad news. You know the type – the QE team or other executing team members are told that they are free to report the exact situation that exists and there should be no hesitation in providing the correct situation rather than hiding stuff that they feel that senior managers would not like.
This is one of the biggest challenges that an organization can face. With large releases, there is a lot of emphasis on the importance of this release, on how the future of the company depends on this release and so on, and implicit is the suggestion that everybody should contribute to ensuring that the date is met, and not be the roadblock in meeting the schedule. This puts a huge pressure on teams which are by nature seen as reporting bad news (which is actually a bad representation of what the QE team does, but we need to be realistic on how many people see this all important function), enough that QE team members would be hesitant in being the bearer of bad news. As a result, there needs to be a lot of positive affirmation by the senior managers that it is critical for the exact status to be projected by the team members, that if there are apprehensions and worries from the team members, it needs to be known to the senior managers along with the reasons for the same.
What happens is that if the QE team members report some problems, or near the end, start making some suggestions that the product is not of good quality, there should be an environment already existing where such worries are evaluated by a core committee, where QE team members are invited to present their viewpoints and then the decision is made about these worries in a way that people are convinced.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

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.

Scrum – Provides you a good quick feedback on accuracy of estimates for tasks ..

ashish — Sat, 10 Dec 2011 21:24:28 +0000

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

How to define tasks for a User Story without spending a fair amount of time on these ?

ashish — Sun, 30 Oct 2011 18:56:46 +0000

We seem to find ourselves running into a fundamental problem during out Sprint planning meetings. Some of it is from our older methods, but partially it also seems to be a problem with the way we are using our Scrum processes. Consider the process before getting into Scrum. We would have a list of features defined and agreed upon by the Engineering and Product Management teams to be done in the defined product development time cycle. However, things were problematic when actually getting into the actual stage of working out the tasks for these features. Many of these features involved features that were not done before, and so it was required that these features be broken down into tasks, and the team leads were assigned to this purpose. It would take a matter of some time for the features to be actually broken down into a matter of tasks. The feature team would need to have a few meetings to discuss the feature, talk to the User Design specialist to understand the way that the feature would work, and then work out the tasks.
However, it would take more time to work out the estimates for the task, and in many cases, this was a matter of guesswork, since the work required for the tasks had never been done before; getting these estimates involved some amount of discussion. And once these estimates were in place, when the actual work was happening, these estimates did change many times (sometimes the User Design was different from the one initially considered, and in many cases, the estimates were actually different from the work that was needed to be done to complete the task). This meant that the total effort needed to complete a feature was different from the estimates; and this happened for many of the features.
Now, when we started using the Scrum process, this became an open question. For many of the major User Stories that were a translation of the major features, getting tasks broken down into the User Stories was a major effort by itself, and it was postulated by the team that earlier it would take so much time to break down the features into tasks, how would it be possible to do this during the Sprint Planning process ? It was somewhat difficult to answer this question, although we did some amount of planning on how to define User Stories in such a manner that they would be readily understandable and could be broken down into discrete tasks that could be estimated with some amount of accuracy. This took some time to actually happen, and there were many cases where the effort estimation did not match the actual effort needed for the tasks.

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.