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.

How to report progress every morning in the Daily Scrum Meeting – revolt of developers

One of the biggest problems that we could see in the Daily Scrum meeting was in terms of getting the more ‘eccentric’ developers to accept such a system. Every other team has such developers – they are highly eccentric and very skilled, but you cannot pin them down to so many hours of work per day. So, they will think, roam around as if they are the biggest thinkers for many days, and suddenly over the course of a number of productive days, produce the required code (which normally contains the same amount of bugs that you would expect from somebody writing code consistently over the period of time).
We did expect some problems when we started thinking about changing our mode of software development to use the Scrum methodology, but the experience of other teams, and the various advantages that Scrum promised seemed to make this a major advantage for us. So, we went in for the required training, got a Scrum expert to guide us for some time, and so on.
But guess what ? In some time, we started running into problems during the Sprint Planning as well as the Daily Scrum. In the Sprint Planning, when we tried to break down the tasks into discrete efforts that would take 1 day or less, we started getting resistance from many of the developers. They stated that they did not really work that way, instead they would work in the fashion that I wrote about in the top of this post, and be able to able to provide a good estimate of their work progress on a weekly basis. On this occasion, we reasoned with them, and pulled rank on them in trying to force them to agree to this (big mistake, but by then there was a lot of pressure to ensure that the team was ready to show Scrum as a success, and the attitude of some of the developers was seen as something that could be modified over a period of time).
However, as we started moving on the Daily Scrum Meeting, things got even more tricky. After the first few such meetings, we were met by developers who seemed moody, and who certainly could not be called advocates of Scrum. True to form, they had not really completed the part of the tasks that they had stated in the previous Scrum meeting and felt that it was humiliating to them to state on a daily basis that they were not doing the tasks. This was how they had always worked, and trying to force them into a different pattern was not a healthy thing (hidden threats from the affected developers).
This grew more serious, although at the end of the week, things were fine on the overall dev work done since, true to form, things balanced out. Many of them put in that burst of speed and completed the required work in a frenzy like they were used to. But the morale issue and the grumpy mood was not going away. So, in this case, we decided on a compromise. We put in some filler tasks (labelled as investigations and the like), so that they could come into the Daily Scrum meeting, mention that they were doing some ‘investigations’, and on the day when they felt that things could happen, they would come in and state that they were working on the tasks.
This is how we solved this particular issue. Anybody have any similar situation, and what you did in such a situation ?

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>