An Introduction to Agile Project Management with Scrum

pdf
Số trang An Introduction to Agile Project Management with Scrum 16 Cỡ tệp An Introduction to Agile Project Management with Scrum 439 KB Lượt tải An Introduction to Agile Project Management with Scrum 0 Lượt đọc An Introduction to Agile Project Management with Scrum 0
Đánh giá An Introduction to Agile Project Management with Scrum
4.3 ( 16 lượt)
Nhấn vào bên dưới để tải tài liệu
Đang xem trước 10 trên tổng 16 trang, để tải xuống xem đầy đủ hãy nhấn vào bên trên
Chủ đề liên quan

Nội dung

THE SCRUM PRIMER An Introduction to Agile Project Management with Scrum By Pete Deemer and Gabrielle Benefield Version 1.04 goodagile> scrum training in india and asia | www.goodagile.com Pete Deemer is Chief Product Officer, Yahoo! Emerging Markets Group. Gabrielle Benefield is Senior Director of Agile Development at Yahoo! Inc. They lead Yahoo!’s large-scale global adoption of Scrum. A note to readers: There are many concise descriptions of Scrum available online, and this primer aims to provide the next level of detail on the practices. It is not intended as the final step in a Scrum education; teams that are considering adopting Scrum are advised to equip themselves with Ken Schwaber’s Agile Project Management with Scrum or Agile Software Development with Scrum, and take advantage of the many excellent Scrum training and coaching options that are available; full details are at scrumalliance.org. Our thanks go to Ken Schwaber, Dr. Jeff Sutherland, and Mike Cohn for their generous input. © 2007 Pete Deemer and Gabrielle Benefield 2 Traditional Software Development The traditional way to build software, used by companies big and small, is commonly known as “The Waterfall”. There are many variants, but it typically begins with a detailed planning phase, where the end product is carefully thought through, designed, and documented in great detail. The tasks necessary to execute the design are determined, and the work is planned using tools like Gantt charts and programs like Microsoft Project. The team arrives at an estimate of how long the project will take by adding up detailed estimates of the individual steps involved. Once stakeholders have thoroughly reviewed the plan and provided their approvals, the team starts to build. Team members complete their specialized portion of the work, and then hand it off to others in production-line fashion. Once the work is complete, it is delivered to a Quality Assurance organization, which completes testing prior to the product reaching the customer. Throughout the process, strict controls are placed on deviations from the plan, to ensure that what is produced is actually what was designed. This approach has strengths and weaknesses. Its great strength is that it is supremely logical: think before you build, write it all down, follow a plan, and keep everything as organized as possible. It has just one great weakness: humans are involved. For example: this approach requires that the good ideas all come at the beginning of the development cycle, where they can be incorporated into the plan. But as we all know, good ideas appear spontaneously throughout the process – in the beginning, the middle, and sometimes even the day before launch, and a process that doesn’t permit change will stifle this innovation. With the Waterfall approach, a great idea late in the development cycle is not a gift, it’s a threat. The Waterfall approach also places a great emphasis on writing things down as a primary method for communicating critical information. The very reasonable assumption is that if I can write down on paper as much as possible of what’s in my head, it will more reliably make it into the head of everyone else on the team; plus, if it’s on paper, there is tangible proof that I’ve done my job. The reality, though, is that most of the time, these highly detailed 50-page requirements documents just don’t get read. And that’s probably just as well, because when they do get read, the misunderstandings are often compounded. A written document is an incomplete abstraction of a picture I have in my head; when you read that document, you create yet another abstraction, which is now two steps away from what I’m really thinking of. It should come as no surprise that serious misunderstandings would occur. Something else that happens when you have humans involved is the hands-on “aha” moment – the first time that you actually use the working product, and you immediately think of 20 ways you could have made it better. Unfortunately, these very valuable insights often come at the end of the development cycle, when changes are most difficult and disruptive – in other words, when doing the right thing is most expensive. 3 Humans also have a poor ability to predict the future. For example, the competition makes an announcement that wasn’t expected. Unanticipated technical problems crop up that force a change in direction. Furthermore, people tend to be particularly bad at planning things far into the future – guessing today how you’ll be spending your week eight months from now is something of a fallacy, and it’s been the downfall of many a Gantt chart. In addition, the Waterfall also tends to foster an adversarial relationship between the teammembers that are handing work off from one to the next. “He’s asking me to build something that’s not in the spec.” “She’s changing her mind about what she wants.” “I can’t be held responsible for something I don’t control.” And this gets us to another observation about the Waterfall – it’s not that much fun to work within. In fact, we’d go a step further and say that the Waterfall is a cause of great misery for the people who build products, and the resulting products fall well short of expressing the creativity, skill, and passion of their creators. People aren’t robots, and a process that requires them to act like robots often results in unhappy people. A rigid, change-resistant process will also tend to produce mediocre products. Customers may get what they first ask for, but is it what they really want once they see the product begin to emerge? By gathering all the requirements up front and having them set in stone with little chance of change, the product is condemned to be only as good as the initial idea, instead of being the best it could be once the team knows more about the possibilities. Many users of the Waterfall experience these shortcomings again and again, but it seems like such a logical approach, the natural reaction is to turn the blame inward: “If only we did it better, it would work” – if we just planned more, documented more, resisted change more, everything would work smoothly. Unfortunately, many teams find just the opposite: the harder they try, the worse it gets! Agile Development and Scrum The Agile family of development methodologies was born out of a belief that an approach more grounded in human reality would yield better results. Agile emphasizes building working software that people can get hands on with quickly, versus spending a lot of time writing specifications up front. Agile focuses on small, cross-functional teams empowered to make decisions, versus big hierarchies and compartmentalization by function, and Agile focuses on rapid iteration, with as much customer input along the way as possible. Often when folks learn about Agile, there’s a glimmer of recognition – it sounds a lot like back in the start-up days, when we “just did it”. One of the fastest-growing Agile methods is Scrum. It was formalized over a decade ago by Ken Schwaber and Dr. Jeff Sutherland, and it’s now being used by companies large and small, including Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne and the US Federal Reserve. Many teams using Scrum report significant improvements, and in some cases complete transformations, in both productivity and morale. 4 For product developers – many of whom have been burned by the “management fad of the month club” – this is significant. Scrum is simple, powerful, and rooted in common sense. Scrum Basics Scrum is an iterative, incremental framework. Scrum structures product development in cycles of work called Sprints, iterations of work which are typically 1-4 weeks in length, and which take place one after the other. The Sprints are of fixed duration – they end on a specific date whether the work has been completed or not, and are never extended. At the beginning of each Sprint, a cross-functional team selects items from a prioritized list of requirements, and commits to complete them by the end of the Sprint; during the Sprint, the deliverable does not change. Each work day, the team gathers briefly to report to each other on progress, and update simple charts that orient them to the work remaining. At the end of the Sprint, the team demonstrates what they have built, and gets feedback which can then be incorporated in the next Sprint. Scrum emphasizes producing working product at the end of the Sprint is really “done”; in the case of software, this means code that is fully tested and potentially shippable. Figure 1. Scrum Scrum Roles In Scrum, there are three primary roles: The Product Owner, The Team, and The ScrumMaster. The Product Owner is responsible for achieving maximum business value, by taking all the inputs into what should be produced – from the customer or end-user of the 5 product, as well as from Team Members and stakeholders – and translating this into a prioritized list. In some cases, the Product Owner and the customer are the same person; in other cases, the customer might actually be millions of different people with a variety of needs. The Product Owner role maps to the Product Manager or Product Marketing Manager position in many organizations. The Team builds the product that the customer is going to consume: the software or website, for example. The team in Scrum is “cross-functional” – it includes all the expertise necessary to deliver the potentially shippable product each Sprint – and it is “self-managing”, with a very high degree of autonomy and accountability. The team decides what to commit to, and how best to accomplish that commitment; in Scrum lore, the team are known as “Pigs” and everyone else in the organization are “Chickens” (which comes from a joke about a pig and a chicken deciding to open a restaurant called “Ham and Eggs,” and the pig having second thoughts because “he would be truly committed, but the chicken would only be involved”). The team in Scrum is typically five to ten people, although teams as large as 15 and as small as 3 report benefits, and for a software project the team might include analysts, developers, interface designers, and testers. The team builds the product, but they also provide input and ideas to the Product Owner about how to make the product as good as it can be. While team members can split their time between Scrum projects and other projects, it’s much more productive to have team members fully dedicated. Team members can also change from one Sprint to the next, but that also reduces the productivity of the team. Projects with larger teams are organized as multiple Scrums, each focused on a different aspect of the product development, with close coordination of their efforts. The ScrumMaster is one of the most important elements of Scrum success. The ScrumMaster does whatever is in their power to help the team be successful. The ScrumMaster is not the manager of the team; instead, the ScrumMaster serves the team, protects the team from outside interference, and guides the team’s use of Scrum. The ScrumMaster makes sure everyone on the team (as well as those in management) understands and follows the practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with Agile methods. Since Scrum makes visible many impediments and threats to the team’s effectiveness, it’s important to have a strong ScrumMaster working energetically to help resolve those issues, or the team will find it difficult to succeed. Scrum teams should have someone dedicated full-time to the role of ScrumMaster (often the person who previously played the role of Project Manager), although a smaller team might have a team member play this role (carrying a lighter load of regular work when they do so). Great ScrumMasters have come from all backgrounds and disciplines: Project Management, Engineering, Design, Testing. The ScrumMaster and the Product Owner shouldn’t be the same individual; at times, the ScrumMaster may be called upon to push back on the Product Owner (for example, if they try to introduce new deliverables in the middle of a Sprint). And unlike a Project Manager, the ScrumMaster doesn’t tell people what to do or assign tasks – they facilitate the process, supporting the team as it organizes and manages itself – so if the 6 ScrumMaster was previously in a position managing the team, they will need to significantly evolve their mindset and style of interaction in order for the team to be successful with Scrum. In addition to these three roles, there are other important contributors to the success of the project: Perhaps the most important of these are Managers. While their role evolves in Scrum, they remain critically important – they support the team by respecting the rules and spirit of Scrum, they help remove impediments that the team identifies, and they make their expertise and experience available to the team. In Scrum, these individuals replace the time they previously spent “playing nanny” (assigning tasks, getting status reports, and other forms of micromanagement) with more time “playing guru” (mentoring, coaching, helping remove obstacles, helping problem-solve, providing creative input, and guiding the skills development of team members). In making this shift, managers may need to evolve their management style; for example, using Socratic questioning to help the team discover the solution to a problem, rather than simply deciding a solution and assigning it to the team. Starting Scrum The first step in Scrum is for the Product Owner to articulate the product vision. This takes the form of a prioritized list of what’s required, ranked in order of value to the customer and business, with the highest value items at the top of the list. This is called the Product Backlog, and it exists (and evolves) over the lifetime of the project (figure 2). At any point, the Product Backlog is the single, definitive view of “everything that could be done by the team ever, in order of priority”. Only a single Product Backlog exists; this means the Product Owner Figure 2. The Product Backlog 7 is required to make prioritization decisions across the entire spectrum of work that could be done. The Product Backlog will include a variety of items, such as features (“enable all users to place book in shopping cart”), development requirements (“rework the transaction processing module to make it scalable”), exploratory work (“investigate solutions for speeding up credit card validation”), and known bugs (“diagnose and fix the order processing script errors”). Many people like to articulate the requirements in terms of “user stories”: concise, clear descriptions of the functionality in terms of its value to the end user of the product. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth. The team provides the Product Owner with rough estimations of the relative effort required for each item on the Product Backlog, and this helps the Product Owner make prioritization decisions (since some items become less of a priority when the Product Owner learns that major effort will be required to deliver them). Since these estimations are relative, they can be measured in “points” rather than real-world units of effort such as person-weeks; over time, though, as the team gathers data on its velocity (how many of these relative “points” it is able to complete in a period of time), it is able to use this data in projecting release dates and other longer-term planning. The items in the Product Backlog can vary significantly in size; however, the larger ones will often be broken into smaller pieces during the Sprint Planning Meeting, and the smaller ones may be consolidated. One of the myths about Scrum is that it prevents you from writing detailed specifications; in reality, it’s up to the Product Owner and Team to decide just how much detail is required, and this may vary from one Product Backlog item to the next. The general advice is to state what’s important in the least amount of space necessary – in other words, one doesn’t have to describe every possible detail of an item, one should just make clear what is necessary for it to be considered completed. The further down the Product Backlog one goes, the larger and less detailed the items will be; as they get closer to being worked on, additional detail gets filled in by the Product Owner. Sprint Planning Meeting At the beginning of each Sprint, the Sprint Planning Meeting takes place. In the first part of the Sprint Planning Meeting, the Product Owner and Scrum Team (with facilitation from the ScrumMaster) review the Product Backlog, discussing the goals and context for the items on the Product Backlog, and providing the Scrum Team with insight into the Product Owner’s thinking. In the second part of the meeting, the Scrum Team selects the items from the Product Backlog to commit to complete by the end of the Sprint, starting at the top of the Product Backlog (in others words, starting with the items that are the highest business value for the Product 8 Owner) and working down the list in order. This is one of the key practices in Scrum: the team decides how much work they will commit to complete, rather than having it assigned to them by the Product Owner. This makes for a much more reliable commitment; first, because the team is making it, rather than having it “made” for them by someone else; and second, because the team itself is determining how much work will be required, rather than having someone else decide how much “should” be required. While the Product Owner doesn’t have any control over how much the team commits to, he or she knows that the items the team is committing to are drawn from the top of the Product Backlog – in other words, the items that he or she has rated as most important. The team does have the ability to pull in items from further down the list if it makes sense (for example, pulling in a slightly lower priority item that can be quickly completed as part of higher priority work). The Sprint Planning Meeting will often last a number of hours – the team is making a very serious commitment to complete the work, and this commitment requires careful thought to be successful. The team will begin the Sprint Planning Meeting by estimating how much time each member has for Sprint-related work – in other words, their average workday minus the time they spend attending meetings, doing email, taking lunch breaks, and so on. For most people this works out to 4-6 hours of time per day available for Sprint-related work. (Figure 3.) Figure 3. Estimating Available Hours Once the time available is determined, the team starts with the first item on the Product Backlog – in other words, the Product Owner’s highest priority item – and working together, breaks it down into individual tasks, which are recorded in a document called the Sprint Backlog (figure 4). Once tasks are identified, team members will volunteer for them, thinking through dependencies and sequencing, making time estimates for each task, and making sure the workload of each individual is reasonable. There will be back and forth with the Product Owner during this process, to clarify points, verify tradeoffs, break down bigger Backlog items 9 into smaller pieces, and generally ensure that the team fully understands what’s being asked of it. The team will move sequentially down the Product Backlog in this way, until it’s used up all its available hours. At the end of the meeting, the team will have produced a list of all the tasks, and for each task who has signed up to complete it and how much time they estimate it will take (typically in hours or fractions of a day). Many teams also make use of a visual tasktracking tool, in the form of a wall-sized task board where tasks (written on Post-It Notes) migrate during the Sprint across columns labeled “Not Yet Started,” “In Progress,” “To Test,” and “Completed.” Figure 4. Sprint Backlog One of the key pillars of Scrum is that once the Team makes its commitment, any changes from the Product Owner must be deferred until the next Sprint. This means that if halfway through the Sprint the Product Owner decides that there is a new item they’d like the team to work on, they cannot make the change until the start of the next Sprint. If an external circumstance appears that significantly changes priorities, and means the team would be wasting its time if it continued working, the Product Owner can terminate the Sprint; this means the team stops all the work they are doing, and starts over with a Sprint Planning meeting. The disruption of doing this is great, though, which serves as a disincentive for the Product Owner to resort to it except in extreme circumstances. There is a powerful, positive influence that comes from the team being protected from changing goals during the Sprint. First, the team gets to work knowing with absolute certainty that its commitments will not change, which only reinforces the team’s focus on ensuring completion. Second, it disciplines the Product Owner into really thinking through the items he or she prioritizes on the Product Backlog. Knowing that the commitment is for the duration of the Sprint makes the Product Owner much more diligent in thinking through what to ask for at the beginning. 10
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.