| Essential Scrum |
|
Author: Kenneth S. Rubin Kenneth Rubin provides training and coaching in Scrum and Agile and wrote this book in response to requests for an in-depth reference. As outlined in at the beginning of this book, Scrum is a relatively new methodology that traces its roots back to 1986 and started to be documented in 2001. Scrum isn't an acronym; it’s a reference to rugby where a scrum is a way of restarting a game after the ball has gone out of play. In Chapter 1 we also learn how the author adopted Scrum in 2000 and why he advocates it for some domains, specifically complex domains, and not for others.
Part I covers Scrum's Core Concepts, starting with a chapter devoted to the Scrum Framework. This provides a preliminary overview of its practices including roles, activities and artifacts. Among the jargon introduced and explained here are Product Backlog - essentially the prioritized list of features; and sprints - the cycles in which work is iterated, typically lasting up to a calendar month and during which something of tangible value to the customer should be completed. The Daily Scrum, also known as the daily stand-up is the "inspect and adapt" meeting held each day during a sprint, ideally at the same time, at which team members each answer 3 questions:
Chapter 3 looks at the agile principles underlying Scrum, an amalgam of those in the Agile Manifesto, other works on lean product development and from Schwaber and Sutherland's The Scrum Guide (2011), contrasting them with those used in the plan-driven waterfall process. Rubin’s in-depth examination of these beliefs is highly readable Chapter 4 gives an overview of Sprints. In particular it discusses the merits of timeboxing. In this chapter Rubin manages to reconcile the core Agile principle of "Embrace change” with the Scrum rule that once a sprint goal has been established and sprint execution has begun no change is permitted that would materially affect the sprint goal. The chapter concludes with a discussion of the difference between Done and Done-Done using an analogy with his son’s attitude to homework – done is the point where it’s finished in terms of the amount of effort the boy is prepared to spend; done-done is when it is fully completed to the teacher’s satisfaction. This is a neat analogy. Chapter 5 is on Requirements and User Stories and here we meet the 3 C's – card, conversation and confirmation – and the INVEST criteria for stories, which are: independent negotiable, valuable, estimable, sized appropriately (small), testable. Chapter 6 returns to the important topic of the Product Backlog. It uses the acronym DEEP, standing for: Detailed appropriately, Emergent, Estimated, Prioritize to summarize the important characteristics of a good product backlog It then goes on to explain the process of grooming, the concept of "ready" and looks at alternative models of flow management. Staying on this topic, the next chapter looks at how much of the product backlog to tackle in a sprint. It looks at how sizes are estimated, velocity is measured and duration is calculated. Part I then closes with a chapter on Technical Debt that makes the interesting arguments that not all technical debt should be repaid. This is an interesting chapter that certainly repays of the effort of reading it.
Part II is on the various roles that constitute every Scrum team. I liked the distinction that: product owner is focused on building the right product and development team is focused on bulding the product right. Chapter 10 looks at the role of the ScrumMaster which, according to Rubin, is focused on helping everyone understand and embrace the Scrum values, principles and practices. The ScrumMaster also acts as a coach to both the development team and the product owner and is said to be variously: servant leader, process authority, interference shield, impediment remover and change agent. After describing these characteristics, Rubin provides a chart to show how the ScrumMaster a might spend his day during in the lifetime of a sprint, looks at who to choose for the role and discusses if it is a full timerole - with Rubin arguing if a ScrumMaster has spare time it is better deployed by being a ScrumMaster of more than one team. Chapter 11 is about the developmemt team which is characterized as being cross-functional - i.e performing all the roles to do all the work to produce vertical slices of working product functionality at each sprint. Its principal responsibilities are to:
For this it needs to be self-organizing and diverse, with sufficient skills between the team to get job done.Rubin refers to T-shaped skills, i.e broad and deep and argues that having an "all-in-it-together" Musketeer attitude and small teams of 5 to 7 members is best. For larger development efforts, Rubin argues for more teams rather than larger teams and Chapter 12 goes into how scrum teams should be structured if you have a multiple teams, looking at feature teams versus component teams and ways to coordinate them as a scrum of scrums or as a release train with cross-team synchronization. The final chapter in this part (13) looks at the role of mangers in a Scrum organization - and outlines:
It then looks at the role of the Project Manager in a Scrum organization. Part III on planning starts by dispelling the myth that Scrum embarks on development without planning. Chapter 14 discusses key principles such as not expecting to do all, or even the bulk of, planning up front but instead doing a "helpful amount" followed up with more detailed planning later on. This leads to smaller and more frequent releases, learning fast and pivoting if necessary. Chapter 15: Multilevel Planning uses a diagram of circles within circle to show the different levels of planning used when developing a product with Scrum. The highest level (outermost circle) is Strategy planning, which is outside the scope of the book. The lowest level innermost circle is Daily Planning (also indicated on the diagram as being the inspect and adapt process) that happens during the team's daily scrum meeting in which each team member outlines what he or she has done since the last daily scrum and what they intend to do today and whether there are any impediments. The intervening three levels outlined in this chapter are discussed in more detail in the following chapters:
Chapter 19 also starts Part IV on Sprinting. Sprint Planning is the recurring, just-in-time activity that takes place at the beginning of a sprint and involves the full team including the product owner also the ScrumMaster in the role of Scrum team coach. For a two-week to one-month sprint, planning should take no longer than 4-8 hours to complete and involves determine capacity, in story points or effort-hours - which in turn governs what it can deliver. The team can then select the product backlog items for the sprint. Two approaches are outlined in Chapter 19 and then Chapter 20 looks at Sprint Execution- something that will have been partly but not fully planned during sprint planning. As well as looking at flow management, in which Rubin considers the cost of multi-tasking and who does the work, Chapter 20 considers technical practices, including automated testing, and ways of communicating progress, advocating a task board and a sprint breakdown chart. The next two chapters examine the two important inspect-and-adapt activities that are conducted near the end of a sprint. Chapter 21 is on the Sprint Review, which is the time for everyone with an input to the product development effort to ask questions, make observations and suggestions and discuss how to move forward. It is one of the most critical feedback loops in the Scrum process. The Sprint Retrospective (the subject of C 22) is another crucial contributor to the continuous process offered by Scrum and it too happens at the end of every sprint but this time focuses on the process being used to develop the product. As in Chapter 21, Rubin outlines the approach to this event - its participants, inputs and outputs. For the retrospective it is important that participants follow up on the actions identified. The final chapter has the title The Path Forward and is intended to send readers away to implement Scrum for themselves. It concludes with the observation that people sometimes feel they are not ready to start using Scrum as they haven't worked out all the details. This is countered by the reminder: "When employing Scrum, you shouldn't worry about getting things perfect up front. You can't!" The book rounds out with a helpful glossary and a useful collection of references, many of which have been cited in the book. The other helpful inclusion throughout is the use of Visual Icon language, described as "a vocabulary of icons that have been designed to capture essential Scrum roles, artifacts and activities". This is used to good effect in over 200 figures and the book's companion website, www.innolution.com. If you want to know about Scrum. or more about Scrum, or want a reference book that will help you adhere to Scum methodology, this book is highly recommended.
|
|||
| Last Updated ( Tuesday, 12 March 2013 ) |
