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.

Low Hit Ratio for Scrum – needs work from the team working on this

Scrum is an iterative, incremental framework for project management and agile software development. Rather than full process or methodology, it is a framework. Instead of providing complete, detailed description of how everything is to be done on the project, much is left to the team. This is done because the team will best know how to solve its problem. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as general project/program management approach.
The Scrum approach is sometimes compared to rugby, where the whole team tries to go the distance as a unit, passing the ball back and forth. The Scrum Team is self-organizing as there is no overall team leader which decides which person will do which task or how a problem will be solved. The team is cross functional so that everyone necessary to take a feature from idea to implementation is involved. Scrum projects make progress in a series of sprints, which are timed iterations no more than a month. At the start of the sprint, team members commit to delivering some number of features that were listed on the project’s product backlog. At the end of the sprint testing is done and the features are then integrated into the product. At the end of the sprint a sprint review is conducted and feedbacks provided influence the next sprint.
The co-developer of Scrum Ken Schwaber once said, “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it”. He also said that Scrum exposes every inadequacy or dysfunction within the product and system developed practices but many organizations change Scrum to accommodate the deficiencies instead of solving them. But contrary to this comment, it is often seen that the dysfunction exposed by Scrum is often not understood by the teams properly. Whenever dysfunctionality appears it is assumed that the problem is with the team because it is the American way that the people having the problems can pull themselves out of their problems.
It is more often the case that the root cause of blocked flow is somewhere else in the organization even though it is showing at the team level. Hence if teams start with Scrum arbitrarily the companies might not get the values they seek because they are not solving the real problem. And the problems in other areas are typically caused by violating lean principles which most people are not familiar of. The reason for people not being aware of the lean principles is that they are not discussed by most Agile consultants because it is believed that for success with Scrum you don’t need lean. Therefore the reason people accommodate the problems is that they really don’t know how to solve them. So the teams attempting to do Scrum from a team perspective should expect a success rate of only 25% because only part of the time the team will be on the main challenge and it requires a bigger view to view this.

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>