Tuesday, October 14, 2014

Looking at some of Scrum implementations known to me, I have a feeling that it is a bit like an ice

Why Scrum does not work? - Third coffee
A team of developers decided to implement in their work Scrum framework. One of the people on the team read the book under the title of the Scrum Guide and told others how this whole Scrum looks - told that they are sprints that last the whole world so doing, they will be more effective and that all will be nice and pleasant.
They were taken to work. Established roles - Frank was the owner of the Product, and Mark was the Scrum master. It was found, where it will be held backlog and learned that the finished code changes archive now called the increment. Established long sprint, calendars See the most recent meeting called sprint planning, daily scrum, review and retrospective. Everything started to roll, the product owner priorytetyzowaƂ tasks in the backlog, product backlog has changed in the sprint backlog, sprint backlog change in the increment, and graphs combustion moved it up and down.
Everything had to be beautiful. However, after some time, the band members came to the conclusion that basically nothing has changed. The tasks are the same, the quality of the delivered product, in principle, still leaves much to be desired, and the recipient archive all the time is just as unhappy. And basically what this whole Scrum us more of him harm than good ...
Looking at some of Scrum implementations known to me, I have a feeling that it is a bit like an iceberg. Sam Scrum is a set of rules that combine the roles, artifacts and events. And these events, artifacts and roles are precisely those things that can be seen above the water. These are easily archive identifiable elements - very easy to determine whether we have Scrum Master, how long is the sprint and how many items we have in backlog. The problem is that it is a framework for the people - and the people although sometimes guided by the rules, it is much, much more likely to pursue their own beliefs, values or habits.
Scrum actually fairly well defined set of values. At the outset, archive we have listed Scrum GUIDE three pillars of the process: transparency, inspection and adaptation. There is also a very much emphasized self-organization and interdisciplinary development team (self-organizing and cross-functional teams). As we look further, we can find five values that are highlighted by Scrum: courage, openness, respect, focus and commitment. Emphasizing find work at a steady pace. Scrum is a mainstream agile methodologies, so as most apply to it the Agile Manifesto: people and interactions over processes and tools; working software over comprehensive documentation; cooperation with the customer over formal arrangements and responding to change over following the plan.
It may happen that the members of the set of values described above are very close. Team members can not even define in any way the values (do not know that they speak prose ...), but somehow these values are familiar to them, feel them, they have them in your blood. In such a situation, the implementation of Scrum like "wow effect" and the flashbacks often repeated joyful archive word "finally". "Finally, the tasks are clear and transparent", "finally appears aim", "finally decide something," or "finally began to work together as a team." Scrum Master does not have too much work, it is lovely.
It may also happen that the team members do not value teamwork, autonomy, self-organization - but they are open and able to learn. Slowly discovering the charm autonomiczneo decide how to do their job, they discover inspection and adaptation, learning mutual trust and teamwork. The task of the Scrum Master is katalizacja this process, pay attention to the things that work poorly and helping the team in discovering these values.
But it can also happen, so that team members appreciate the different values than those defining the framework. What - beware, beware! - Does not mean that this team is bad or needs to be ineffective. archive Under certain conditions, this team can work quite well and deliver good projects. But I can not find a good environment Scrum'owym.
What the team may be in conflict archive with the values of Scrum? For example, the team may not want to adapt. "We have his method of work, checked in all the projects, there is no need to change it." And if all the projects are similar to each other, it can actually work quite smoothly. The team may not want to work together on tasks - it can happen that people feel good by sharing their tasks according to pre-known key: "SQL query always says Piotr, HTML does not move no one except Jack, with tests only to Basia". The team may not like to work at a steady pace, "calmly now let's focus on the selection archive of the interface color, and how there are any problems, archive then squat harder

No comments:

Post a Comment