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 do you determine whether a team is just treating Scrum as a buzzword – Part 2

In the previous post (Scrum as a buzzword), I had mentioned how it can be determined whether the team is actually treating Scrum as a buzzword, or is actually serious about implementing Scrum. It is not that easy to determine whether a team is really serious or not, since in many cases, the team actually implements part of the Scrum, but does not implement some of the other requirements. For many of such teams, they are not able to get some of the benefits that a Scrum team brings, and are also unable to understand the reason as to why they are not getting all the desired benefits.
– When you ask the team about what Scrum means, they typically start with describing that Scrum means iterative development, done using something called Sprints. When you ask further as to what is usually done in a Sprint, or how does the team determine the required length of a Sprint, the typical response is that somebody in the team suggested a duration of the Sprint (some typical manager), and hence the Sprint length was set. There was no actual analysis to determine which Sprint length would be most useful for the team, and so on.
– Another simple idea is to ask some of the team members about what Scrum means to them. For Scrum, it is required that the team members (who are the main people responsible for the actual processes that make Scrum) should be able to answer some brief questions about Scrum, and be able to talk about what makes some of the important attributes of Scrum, what are some of the responsibilities of team members, and how is Scrum different from the methodologies that they were following previously.
– The Product Owner is a key part of Scrum. It is the Product Owner who looks after the breaking up of the requirements into User Stories and tasks, and if such such processes are not happening, then there is a fair chance that the team is not seriously implementing Scrum; or the Product Management organization is not geared towards the processes involved in the implementation of Scrum. This is a problem in terms of the implementation of Scrum, and presents a high risk that the team will not get all the benefits of Scrum.

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>