Learn Software Development » Pitfalls

The Product Owner as the liasion between the Product Management and the Engineering team

ashish — Sat, 26 Mar 2011 20:14:17 +0000

The role of the Product Owner is one of the most complex roles in the concept of Scrum. As opposed to the earlier role of the Product Management in a waterfall (or non-Scrum and non-Agile) who would deliver the requirements and provide inputs to the team once in a while, the amount of interfacing with the Product Team is much greater in the case of a Scrum model. The Product Owner should be able to provide inputs as and when the Scrum team wants, and given that the team works on a Sprint by Sprint set of features, getting inputs as and when the team requires it is important, else delay happens, which directly impacts the amount of work output in the given Sprint. As a result, most Scrum teams have a need to ensure that the Product Owner is available to them on a regular basis, or put another way, the Product Owner should not be away for long periods of time.
At the same time, there is a lot of expectation that the Product Owner (as a part of Product Management) is the person with regard to customer interaction, taking part in industry and trade shows, and working out all the usability testing and so on. This part of the job can be really tough as well, since it takes a lot of time to make all this happen; the problem that occurs is that we are trying to combine both of these roles into one person, and something has got to give. If the Product Owner is able to get a good customer perspective, then it can be a good chance that the team is not able to get the required time with the Product Owner.
So, a number of organizations realize that it may make sense to split these 2 roles for better efficiency and productivity (although there is a cost factor, since there is going to be an increase in the amount of personnel in the role of Product Manager / Product Owner – the benefits of going the Scrum way should be able to overcome the additional cost; and the problems if we don’t go down this route can be more costly). There are some huge benefits of going in for such an approach:
1. The team is able to get the required amount of time with the Product Owner; this increases the efficiency of the Scrum team
2. The Product Owner can be in the same location as the Scrum team while the Product Manager who works with the customer is located in the actual country where customers are located (in cases where the Scrum team is located in a low cost country)
3. The Product Managers are able to spend the necessary research and working with customers, thus ensuring that the team gets all the required info at the right time.

This article will be contd in the next post ..

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Sun, 19 Dec 2010 19:23:07 +0000

I have been writing a series of posts that talk about what a team can do to improve its efficiency, and as a result, improve its velocity (refer previous post). In this post, I will continue with this topic, and provide some more commentary on how to improve the Velocity of a Scrum team.
For many software companies that are in the service industry, I have heard frequent issues from their project managers about how quickly resources can be moved between teams depending on their need (and depending on specific requests from clients for technical capabilities and so on). So, the specific problem from some of the project managers was, that they get people who do not have experience, spend a lot of time in terms of training these younger workers, and when a person is sufficiently trained, many of these people are pulled out when newer projects are unveiled, where the amount of money per person is higher, or where there is a need to ensure that the client is happy with the level of technical expertise you get.
Nothing wrong with that, since it is seen as being in the best interests of the company, but it does have its own byproducts, specifically when the teams are following the Scrum based method of development. Consider that Scrum is different from the traditional development methodologies where the team members are assigned roles, and project manager and leads do the assignment with team members having to follow whatever they are assigned to do.
In Scrum, team members have a much higher amount of responsibility, undertaking to do the task breakdown, estimation, and driving the schedule; the managers in the team are more of coaches and the whole process is not a top driven approach. It takes time for team members to understand the philosophy, takes time for them to learn the processes and to unlearn the waterfall model. So, when the team members are suddenly moved out and new ones are brought in, even training in Scrum is no substitute for experience that one gains by being part of a Scrum team. This can cause havoc to the team members efficiency, and impact heavily their work done in the cycle and the Velocity of the team.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Tue, 30 Nov 2010 19:18:19 +0000

I have been covering a series of posts on the topic of how to improve the Velocity of the Scrum team (how to improve the Velocity of the Scrum team). In this post, I will continue on the same line and mention some more points that can help in increasing the effectiveness of the Scrum team:
- Make sure that design issues are resolved promptly. For Scrum teams who work on simpler projects, there may not be a lot of complexities in terms of architecture, but for teams where the architecture is complicated, one does need to think ahead. Even though the Scrum model talks in terms of breaking up the tasks during the Sprint Planning session and doing estimation, there is the need to work through the design and architecture issues beforehand. For complex Client Server application (such as where you would normally have made complicated designs to depict the architecture of the system), the need for proper design does not go away just because you are using Scrum. Make sure that enough effort and thought goes into doing the proper design and architecture for building such complex applications. Combine this with the proper sequencing of such tasks as a part of your Backlog such that the design of such tasks happens in the desired sequence. You may also need to ensure that there are enough experienced people to oversee the design process (else you would find that you start running into cases where for lack of enough effort, design issues start to hit people and the tasks that the team has to do take more time, or there is waiting required).
- Make sure that there is enough time and effort being spent on planning for dependencies. When a product is being built, there are a large number of dependencies that could go towards delaying the various tasks inside the product development cycle (for example, there could be software being developed by vendors, or a new version of a Browser / Operating System that could affect your product, or the ability to get some of the features taken through a user review process where the inputs from such a review could cause changes in the product (small incremental changes or product rework)). These have the potential to have a huge impact on the product cycle (in terms of wreaking havoc on the product cycle) unless there is intense planning and scheduling of such tasks. For example, if a critical piece of technology from an external vendor is required in order for some tasks to get completed, and then the technology is of poor quality or gets delayed, it can have a cascading effect on the various tasks that follow. Hence, there needs to a very look at such dependencies and have contingencies plans ready to take care of different situations.

Engineering Practices Not Taken Care of by Scrum – Some details

ashish — Tue, 31 Aug 2010 19:07:46 +0000

Scrum never talks about engineering practices which is a good thing but this sometimes lands teams into trouble. The teams not only adopt the Scrum practices but also the principles which makes their progress sluggish and results in the code base being in a mess. This is a situation which is present in most of the cases where a failure has happened and the teams state that they have been implementing Scrum. Given that it is far easier to blame a process rather than do the necessary hard introspection, teams blame Scrum about not being able to provide engineering practices but they miss the entire point; Scrum is not about engineering practices, it’s about management. Engineering practices are whole and sole responsibility of the teams. Scrum only creates organized teams. They organize themselves, they organize their tools and they organize their engineering practices, and Scrum then opens up the entire process in terms of more information that teams have to learn to handle, and use to improve the way that they do things.
Consider some examples: The definition of Done (DoD) is defined by the development team. The criteria for done can be different for different teams; some teams might consider a piece done once the code has been reviewed others may consider is done only then functional tests are carried out and still others may call it done when the documentation is also done. It becomes necessary to keep an optimal level of done so that technical debt does not come into picture too much. And what is ‘technical debt’ ? Well, the concept of technical debt states that while adding a piece of functionality, two different approaches can be used. The first one is doing a quick job and the other one is a clean design. The quick design would mostly be messy, and one of the bigger problems is that making further changes become harder in future. So doing things in a quick and dirty way, results in technical debt which in turn requires extra effort to be put when future development is done. Doing a quick job is useful when you need to meet a deadline and can afford the extra effort later. However, you need to be sure that this is the approach you want to take, and not be surprised at the extra effort needed to be put in later.
The main difference between classical approach (Waterfall, etc) and scrum approach of development is that in scrum developers have more freedom to define level of done and amount of work to be done. They decide on the User stories to work in each of the sprint (through the estimation, although the priority comes from the Product Owner). Developers who do not use professional practices fail; but they fail independently of the processes used; blaming the processes of Scrum is convenient, but some inspection by external parties can easily reveal problems in the way that they do things.
There is sometimes a talk about too much quality being pumped into the product. Sometimes it may be a cause of concern for the owner if the team takes too much time for quality. The concept of iron triangle comes into picture here. This concepts states that Scope (features, functionalities etc.) , Resources (cost) and Schedule (time) can be considered to be three vertices of a triangle and Quality is the area enclosed by this triangle. Different groups have different priorities: users want more scope, senior management wants cut in time, financial team wants cut in budget and development team wants more quality. The end aim is to strike a balance into all the four entities. Scrum sets resources and time and lets developers decide the scope. Speed is scope/time and it’s a measure of output. If the product owner wants a higher velocity then he must work towards removing impediments; but dropping of engineering practices is not a solution. Compromise in quality is a slippery slope best avoided, and can result in so many problems later that any benefits from reducing quality are to be avoided. Consider advising a stuntman to drop safety equipment; he will never and so should be the case with developers (and even more so with the people responsible for the quality of the features and the product).

In the Daily Scrum meeting, why is it so hard to get people to discuss with each rather than the Scrum Master (project manager in disguise)

ashish — Tue, 30 Mar 2010 17:48:40 +0000

The Daily Scrum is a very simple, and yet a very integral part of the Scrum process. The idea is to get the team to work with each other, and discuss the items that they have done, are going to be doing next, and any obstacles (impediments) in their path. These are 3 questions:
1. What tasks have you done since yesterday’s meeting?
2. What tasks are you going to get done today?
3. What impediments are blocking you?
However, there are many problems in this simple concept. Ideally, what would need to happen is that the team acts like an empowered group of people in charge of executing all the tasks for the Sprint cycle. Every day, they would get together for a short meeting, and discuss these 3 questions (without getting into 2 much detail). This is supposed to be like a discussion between team members, with each team member taking their turn to explain their activities to the other team members. This makes them feel empowered, and also feel that this is different from giving the status to a project manager.
However, I have seen most cases where this is not what happens. In the project, it is typically a manager who plays the role of a Scrum Master (and to further qualify, it would be the Project Manager or Program Manager) who plays the role of the ScrumMaster. For a person in this role, it is very hard to explicitly move away from turning this into a daily status meeting (since for a Project or Program Manager, this is a very handy meeting to get detailed status on a daily basis as to what is happening in the project). This entire feeling rubs off onto the team members, and they also feel that they are in fact reporting daily status to the project manager (in the shape of a Scrum Master). So what happens ?
Information that the team members share is done while addressing the Scrum Master rather than addressing the group, and it is the Scrum Master who then asks the questions. This inhibits the other team members from asking questions (including questions that would help them), and pretty soon everybody is talking to the Scrum Master only. The next effect is that the team members stop realizing any value to them of the Daily Scrum, and look for reasons to avoid it. I have seen this happen in 2 teams where the team members finally pushed back and got the Daily Scrum changed to happen only 3 times a week. I can be pretty sure that if this would continue, the next couple of Sprints may see the team members calling for the Scrum Master to get the current status directly from the team members rather than have a Daily Scrum meeting where they are expected to sit and hear other people talk about issues that seemingly don’t affect them.
How can this be addressed ? Unfortunately, this is something that the Scrum Master has to guide, in terms of ensuring that people do not start to address their Daily Scrum information to them, and instead address the team. In addition, the Scrum Master needs to realize that the primary aim of this role is to facilitate the discussion, and to ensure that impediments faced by the team are removed quickly.