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 2

In the first post of the article, I wrote about how senior executives need to see the list of features before approving the product development (the list of features is reviewed in terms of competitor analysis, projections of the direction where the product should be heading towards, and also whether these are features that customers would be willing to pay money for).
Going by classical Scrum approach, the Product Owner generates a Product Backlog. However, the Product Backlog is not an approximation of the list of features that will make it in the product in the defined schedule, since there has been no breakup of the features into user stories, no estimation has happened, and so on (these steps happen in a very accelerated manner in the conventional process we used at the start of the project). So, either we still do such a process at the start of the Scrum cycle, which also means that we are going in for the breakdown of the features, going in for task estimation, and so on.
However, this sort of breaks down the core advantages of Scrum. Scrum allows you to respond fast to changing market needs, which means that features are prioritized and detailed at the Sprint planning level (with a Sprint typically being for a period of 2-4 weeks). If you confirm the list of features right at the beginning, then you are not able to modify the features through the cycle. Getting this past the executives was a bit complicated, with having to take through the broad directions of the product, as well as a list of features in the Product Backlog along with a list of priority.
Now, since this was the first time that the team was implementing Scrum, and this was an important product, the executives wanted a quick summary from the Sprint review meeting at the end of every Sprint. Now, the first few Sprints were where the team was learning about the Scrum process, and it took time for us to see progress in terms of getting the Scrum process working. However, in this case, since the executives were seeing progress from the first set of Sprint planning, and did not get a detailed schedule in terms of timing of implementation of features, they were focused on seeing whether the features that were planned for each Sprint were making it. This added a high level of pressure to the team managers, and also on the Scrum team. With the first few sets of Sprints not showing the desired progress, the review sessions with the executives got more and more uncomfortable; and it was getting harder and harder to justify the use of Scrum.
By the third month, we were behind the feature implementation (as seen in the Sprint Planning meetings), and given that we did not have a Product Feature Schedule in place, there was a feeling increasing in senior management that there was some foul-up happening. At this stage, there are 2 possible options – Either we slowly start to turnaround matters, and when we are confident that things are indeed improving, start projecting a much more positive attitude to senior management; or we face so much pressure that we are forced to go back to a Standard Waterfall process. Either case is a huge setback to the process of Scrum implementation.
What can improve matters in such cases:
– Get more success stories in terms of Scrum implementation in the organization, so that the senior management can have more confidence
– When projects are so critical, then the monitoring of the projects in terms of ensuring that Scrum processes are being followed needs to be much more careful
– Do more detailed interactions with senior management in terms of laying out what Scrum is, what are steps that need to be taken, what are some of the challenges, and so on.

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>