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 – A case of not getting the Daily Scrum correct

In this post (and in a few other posts), I am going to be writing about some of the reasons as to why Scrum could fail. A lot of Scrum practitioners claim that typically it is not Scrum that fails, it is the people implementing it who fail. In this particular case, it is certainly a problem with the way in which Scrum was being practised.
The situation was where the team was developing the next version of a leading software, a cycle of around 9 months. Out of this, around 6 months was the time period of development (coding and testing), and then the last 3 months was dedicated towards just pure testing, bug fixing, and stabilization of the product (and this time period division was perfectly normal).
In the previous version, the team had problems in getting the number of required features developed in the desired interval, and the number of bugs was very uncomfortable in the last phase of the cycle; this meant that the team was very panic-stricken in the last phase of the product cycle and had to move some of their last cycle milestones so as to get the bug count down to a respectable level. As a result, and because of other teams using Scrum and being comfortable, the team decided to try and see whether Scrum would work.
The team decided, after a couple of presentation and training, that Scrum was the way to go; so the team went through the required training and presentations (and did so fairly well, with their questions and answers happening throughout on a pretty involved level), and pretty soon, it was time to start the next cycle. So, the team started with their process of going through the Daily Scrum, defining a Product Backlog, maintaining their charts and progress, and so on.
A couple of months later, the team went through a major crisis, things did not seem to be going well enough, Product Backlog did not seem to be met on any of the Sprints, and there were major crisis. But the biggest problem was that the team did not seem to be the least bit enthusiastic about attending the daily Scrum. This seemed to be the biggest problem that was required to be handled. So, other people were called in as observers to try to figure out what is going wrong with the Daily Scrum, and we found the problem after some easy observations.
The basic problem was about the way in which the Daily Scrums were being run. These were meant to be a place where the teams would quickly talk to the group about their issues, about what they had done, and what they planned to do. However, since the managers were used to running the group, they would sit in the meeting, and structure in such a way that team members had no choice but to make it more like a status meeting rather than a group talk. It took some time and multiple rounds of discussions before we were able to convince the managers to leave it to be a regular Scrum meeting. Because of the way that they had structured it, people were seeing the meeting as just a way to pass on status, and did not see any value. After some discussions and some reassurances (and re-reading the rules of the meeting), we managed to get the meetings back on track for the teams.

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>