Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Learn about Scrum – Why does Scrum fail – The sponsors worried about the lack of a schedule of features in the overall project, this worry extending to the end of the project: Part 1

In the previous post (Problems in letting the team be self-empowered), I talked about how it was difficult for managers to transition to a role more akin to a coach rather than being the traditional decision-making, hard task driving individual who is responsible for driving their teams. In a number of cases, the managers are not easily able to switch over, and it is hard for them accept that the teams are responsible for a number of technical and even process related decisions in the Scrum process.
In this post, I talk about another case which causes problems during Scrum implementation, and can actually derail the progress of a Scrum project. This is the case where the executives have just paid lip-service to the cause of Scrum, but do not understand the changes that are needed for a Scrum project, and then find themselves uncomfortable during the course of implementation of the project. Let me narrate the example, and then we can learn how to try to overcome some of the problems that we see during the Scrum implementation.
During the course of a project, we have multiple reviews by a team of Senior Managers, who are ultimately responsible for the overall project (in terms of ownership of the overall business unit), and as a result, they need to ensure that the project team is handling the project in a satisfactory manner. For this purpose, during the start of the project, and during the course of the project, there are several review sessions where the team managers present progress to the managers. One of the most important reviews is at the start of the project where the team presents their readiness to start the project, as well as the list of features that will be implemented during the course of the scrum project.
And this is where the key problems started. If we went by the traditional waterfall project, we would have projected a list of features that we were sure would be done during the course of the project, since we would have spent the first few weeks before the meeting planning and estimating for the features. Based on this analysis, we would be able to have a clearly defined list of features, and use these for the review meeting. With Scrum however, following a strict implementation, we would only have a prioritized backlog of features, and during the course of each Sprint meeting, we were able to define a list of features that would be done in this Sprint. In this manner, however, we were not able to generate an initial list of features that we could project with confidence.
So, when we had the first discussion, we had explained the whole concept of Scrum to the executives, taken them through case studies, and also how Scrum would help in doing a project with a higher chance of success. However, when we did the discussion, it was clear that the executives were not confident without a tangible list of features that they could refer to, especially since this was a $250 million product, and competitor analysis was a key part of this review (the market was very competitive, and getting features in the project was key for good reviews and higher customer uptake).

Contd .. in part 2 of this post ..

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>