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.

Scrum: Should not discourage the Scrum team members in the Daily Scrum meeting ..

There are all sorts of people who you can be working with; some of them can be pretty accomplished at what they do, others are not so good. But that is the nature of the software development field, for every person who is an expert, there will be more people who are not so expert, but who continue to do good work. If this was not true, there would be a lot of problems during the appraisal process, since it would be impossible to differentiate between the team members who get rated higher because of their performance, and those who get rated earlier. And no company can build their foundation on only having very skilled people with them, even though they would like that. You do not kick out people who are rated at a lower end of the appraisal process, since that is a never ending process. And of course, there is the other problem of subjectivity. During initial planning, something may seem to be doable in a certain time frame, but when actually in the process of doing it, it might turn out that it would take a lot more time to get the work done, and that is natural in a large number of cases; the probability of somebody suddenly turning in a poor performance, or even more seriously, somebody deliberately doing something wrong.
Why all this story ? Well, consider the case of the Daily Scrum meeting or the Sprint end retrospective. When you have team members dependent on each other, a delay on the part of one person can cause problems to the schedule of the person down the line. This can happen many times during software development cycles, and it sometimes happens that this can happen more than once to a person. However, I have seen cases where this turns acrimonious. Since there is a delay in the part of the first person, the people who are dependent on them completing this task can raise this issue in the Daily Scrum meeting or in the retrospective meeting at the end of the Sprint. This sounds tricky, since the Daily Scrum and the retrospective are all supposed to be areas where the team works with each other, not point fingers at each other.
The other problem is that if during the Daily Scrum, the first person finds that the work is not yet done which was supposed to be completed by that time, it can be uncomfortable to present this to the whole Scrum team. If there is a pushback against this, then the next time the person is not able to get the work done (even if it is a perfectly logical reason), the person will be uncomfortable to stand in front of the whole group during the Daily Scrum and talk about the delay. This causes problems since the whole expectation in the Daily Scrum is that each and every team member presents a correct picture of where they are, and do not stand up to be criticized or their effort be suspected.
What needs to be done in this case ? Well, there can be several reasons. The work could be more complicated than initially thought, or the person could be providing estimates during the Sprint planning process that are lower than what the work would actually take, or other similar reasons. It is expected that the Scrum Master and the team setup a separate small or group level discussion to find out what the problem is, and try to come to a solution to the problem. This is a constructive way of resolving such problems, and even though this process may seem a bit harder to follow, a team will be able to progress only if they move down this route.

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>