You probably have tried to implement new processes before. Scrum is not a new process or methodology, but instead a workout procedure, set of rules or game to improve the enterprise. Furthermore, Scrum is simple enough to understand from books (this text is a summary from Ken Schwaber's book The Enterprise and Scrum).
Example Case
Adventure Works, a game producer in San Diego, was the first in its industry to benefit from Scrum. Joris Kalz, Adventure Works' CTO, attended one of the very first Scrum certification sessions in 2003. Enthusiastically, he went back to Adventure Works and adopted the Scrum paradigm. His story is one of insight, persistence, and hard work. The Adventure Works story is one of culture shock and then redemption.The product that was developed using Scrum was Vosod. It began to emerge in high-quality, regular increments. Joris adopted a sustainable pace of work, one of Scrum's practices. Everyone worked eight-hour days. Some people might look at that practice and think, "Oh, that means developers get out of working hard for the company!" Quite the contrary—a sustainable pace yields higher productivity and quality products.
Adventure Works was owned by a Japanese company. The Scrum practice of eight-hour workdays was unacceptable to the senior members of the Japanese management. They demanded longer hours, and the 12-hour work days that were normal prior to Scrum were restored. Defects rose 60 percent over the next several Sprints, more than offsetting the delivery of increased functionality. Joris restored Scrum's eight-hour workdays. When the Japanese managers in San Diego drove by the offices night after night, they again saw empty parking lots and darkened offices. This was intolerable to them. They reported to headquarters that employees at Adventure Works were indifferent and lazy. They recommended selling the company. The delivery of increments of high-quality software was good, but that was insignificant compared to the perceived sloth and cultural conflict.
The Japanese parent company sold Adventure Works to its American management in a management buyout. The parent company was glad to get rid of it. Two months later, Vosod was completed and ready to ship. Adventure Works sold Vosod to a game publisher for twice the price of the buyout. Did it make sense for the Japanese owners to sell the company when they did? Of course not, but the twisting paths of change often don't make sense. People and culture are involved—people who have feelings, beliefs, perceptions, and vested interests that cloud their perceptions.Players of Scrum
The Product Owner is the most senior executive in the enterprise. A Scrum Product Owner is responsible for directing the work of a Scrum team.
The ScrumMaster holds the team together and keeps it going using Scrum. He or she is the person responsible for the Scrum process being used correctly.
The Scrum team commits to a goal every iteration, or Sprint. The team members work with each other and do whatever is necessary to reach that goal. The team is a single entity and manages itself – all Scrum teams are self-managing. The teams manage themselves to build the Product Backlog and reach the goals. Team members need to trust each other to effect change, and they need to be ready to openly have conflict to reach the best solutions possible. Focus on proggress – even though there are always many things to improve, look back and savor the accomplishments already being made.
Scrum Tools
Product Backlog is a prioritized list of work that needs to be done, controlled by the Product Owner (i.e. Customer).
A Sprint is a block of time (usually 10-30 days) in which development of software is completed.
Sprint Planning Meeting The sprint planning meeting is time boxed to 8 hours and consists of two segments that are time boxed to 4 hours each.
Daily Scrum A daily meeting at which the Scrum Development Team gathers to inspect its progress toward the Sprint Goal to adapt its work and optimize its chances of building everything committed to. The meeting is time-boxed to 15 minutes, during which each team member answers the following three questions: ”What have you done since the previous daily scrum?”, ”What am I going to do today?”, and ”If there is anything impeding my work, what is it?”
Daily Scrum of Scrum When multiple levels of scrum teams exist, the lowest level Daily Scrum is called S1. The next levels are called Daily Scrum of Scrum S2, S3, and so forth. At the component level (S1) and activity level (S2), the Daily Scrum of Scrums are indeed held daily. On higher levels the meetings are held less often; twice a month or once a month.
Sprint Review Meeting The purpose of the sprint review is for the team to present to the product owner and the stakeholders functionality that is done.
1 kommentti:
I am missing the point of your blog entry. There is plenty of good material available online about Scrum if you want to provide a quick overview. If you want to network and possibly improve a corporate image there are better ways of attracting people than echoing the official propaganda from Certified ScrumMaster training and literature.
Overview of Scrum in the official homepage:
http://controlchaos.com/about/
And in wikipedia:
http://en.wikipedia.org/wiki/Scrum_%28development%29
There are certain items I would like to address because misunderstanding them can be dangerous.
Scrum as process:
I do not see how Scrum is a self-corrective process. With properly implemented Scrum the overall software development effort can be "self-corrective" as the overall project goal and software features are adjusted when both business and technical personnel gain more insight. But the Scrum process itself is not self-corrective, quite the contrary. Scrum is very difficult to do implement properly and requires much work and discipline.
In my Certified ScrumMaster training Jeff Sutherland insisted calling Scrum a framework and not a process. The rationale being that Scrum is a set of roles and responsibilities for those roles with little instructions on how those roles should be fulfilled. It is up the Scrum implementation to figure out how to best play those roles and follow Scrum's rules. And there lies the difficulty: if you want to do Scrum, you have to figure out yourself how to do it, Scrum only sets the rules of the game.
For example the primary tasks of the product owner are to create a product backlog, prioritize it according to business value, and be available to answer questions from the team. So simple that anyone can do it, right? But how do you determine business value? That may be obvious if you are lucky, or that may require months of work with a dozen people conducting market research and strategy planning. And Scrum does not help you in that work in any way, it only specifies the contract you have to fulfill towards your development team.
Scrum is a deceivingly simple process, but really difficult to implement because it only sets the rules and does not tell you how to do your job (= determine business value, develop software, build a team...).
About product owners:
The product owner by no means has to be the most senior executive of the enterprise. Does the CEO of IBM direct individual software development teams? Most likely not. The point here is not seniority, but (in ideal circumstances) responsibility for the business and money, but even that is not absolute. Sometimes a customer nor a marketing or product manager person is not available for assuming the product owner role and the team has to make do with a proxy product owner. Not an easy role to play, that.
It is dangerous to say that the product owner directs the work of a scrum team because that implies command and control á la traditional project management. For Scrum command and control is poison. The product owner tells the team what the team should build and in what order but that is all. He has zero control as to how the team works, who does what, what kind of technical solutions are used an so on. The product owner decides and is responsible of what the software being developed does, and he has to communicate that to the Scrum team. That is all.
Again that is merely the role and unfortunately Scrum does not tell how the product owner should play that role. As most things in Scrum: the principle/role/responsibility is simple, but execution is a lot of work and is entirely your problem.
About ScrumMasters:
ScrumMaster is not only a process coach (and process police), one of his primary responsibilities is resolving impediments for the team, and helping the team with their work in all possible way. In the bigger picture the ScrumMaster helps the customer maximize his return of investment and coaching, mentoring, and facilitating are only the means to accomplish that.
Sprint planning:
Sprint planning is not only a random meeting where things are discussed within a timebox. That is the meeting where the product owner and team chooses work from the product backlog to the next sprint. The discussion often resembles a bargaining process between the team and product owners. Since the team has to commit the team gets to specify the scope of the sprint and the product owner can only express his wishes and negotiate with the team. In the end of the meeting, consensus is reached at the team commits to the sprint.
This is one of the most important and controversial dynamics in Scrum, by the way. If all goes well, quality is set by the team, time is fixed to the length of the sprint, resources are negotiable and the team gets to decide scope. The product owner can only ask what he would like to be implemented next, but the team decides what they commit to.
About retrospectives:
One of the most important "tools" is not mentioned: the sprint retrospective. That is when the team looks back at the finished sprint and discusses things that went well and things that could be improved, problems, suggestions, gripes and so on. The retrospective is an essential part of Scrum it is the key for enabling continuous improvement. It is the the kaizen part of Scrum, if you will.
About Scrum of Scrums:
This is actually an advanced topic - how do you scale Scrum from one team to several teams? Whether you need Scrum of Scrums depends on your organization. If you have multiple teams working on one piece of software and essentially pulling stories from one product backlog, you need Scrum of Scrums. It is not something you need to consider when starting Scrum since you should make Scrum work first with one team before attempting to scale anyways. Of course it is good to know that Scrum can and will scale, if done right, but you should not worry about it when starting Scrum.
Lähetä kommentti