Essential Scrum

I first met Kenny Rubin when I attended his course, Certified Scrum Master Training, in late August, early September of 2011. That course was a fresh start for me. With 30 years of information technology experience under my belt, Scrum resonated deeply with me and provided a new spark of passion and enthusiasm for my IT career that I could have only dreamed of a short time ago. This book is the textbook that I was looking for that course, but it's also much more. Kenny Rubin has, in a 4-part book, given us a roadmap that describes the Land of Scrum, and then shown us all the major highways and byways that traverse the landscape. Based on my recent, personal experience as a Scrum Master, this book has become an indispensable roadmap and companion for my Scrum journey. I've read it from cover-to-cover, and was able to, within a 5-week window, develop and prioritize a product backlog with our product owner and a new development team, plan and execute our first sprint, and begin developing a "potentially shippable product increment" using the Agile framework described in Kenny's book in a timeframe that no other methodology has been capable of. The events unfolded just-in-time and the timing of each step and the parallel support from the book was impeccable. In the Introduction (Chapter 1), Kenny uses the Cynefin complexity model to describe the situations in which Scrum can be applied, and whether or not it makes sense to do so. This is immensely helpful up front to decide where you find yourself, and then, how to apply the material to bring success to your efforts. It's refreshing to read a book that tells you when NOT to use what's being described. When I read, "Scrum is not a silver bullet or a magic cure," I knew that the book would be useful to me and a realistic resource rather than a one-size-fits-all pitch. The book is organized into four parts. Part I, "Core Concepts" (Chapters 2-8), gives the lay of the land. It would be worth buying the book for Kenny's definitions, terminology, and description of the mindset that makes up Scrum. It provides the orientation to the landscape, the major landmarks, and "true north" for the Scrum framework. Part II, "Roles," (Chapters 9-13) describes who you are likely to run into along the way as you travel around in the land of Scrum. Your enjoyment and application of the scrum principles will be more satisfying when you know who should be doing what, and the reasons behind the activity. Part III, "Planning," (Chapters 14-18) is the "trip planning" portion of your time spent touring around Scrum. Part IV, "Sprinting" (Chapters 19-22) is like the daily itinerary for your two-week trip in the Land of Scrum. Both Parts III and IV describe how the people playing the various Scrum roles apply the core concepts to deliver the business value sought by those using this framework. The diagrams in the book are plentiful and clearly (and uniquely) capture the essence of the terms and narrative in a clean, uncluttered, and concise way. (The figures remind me of the Duplo toys my kids grew up playing with.) I have posted several of these in our Scrum team room for reference, and have been able to leverage them to great advantage in our working discussions. They build on themselves throughout the book so that by the time you reach the planning section of the text, you'll have a complete, graphical depiction of a Scrum cycle. I have used the Scrum framework (context) diagram (for example, see Figure 2.3) as the basis for presentations in my organization to not only describe my team's progress, but also to advocate for the adoption of Agile development. If you're new to Scrum and want a birds-eye flyover of the landscape, Chapter Two, "Scrum Framework," is an excellent way to get grounded. Kenny defines and describes all of the key topics in a simple fashion so that the language of Scrum and its mechanics can be understood: the Scrum roles, activities and artifacts. Chapter Three, "Agile Principles," is particularly useful for teams and companies that are in the process of adopting Agile for their development method, and are familiar with the waterfall (plan-driven) style of development. For example, the principles of Agile become clearer when compared to the classic, legacy style of development that so many of us cut our teeth on. One foundational section, "Prediction and Adaptation" (p. 37) is especially useful to understand the Agile mindset of keeping your options open. In the rest of Part I, you'll learn about: sprints and why a good definition of done is so important, user stories and what they have in common with and how they're different from requirements, the product backlog which following the metaphor, is like a fueling station for the vehicle you're driving around in the land of Scrum, estimation and velocity, your compass for your travels in Scrum, and technical debt, the extra weight, disrepair and drag that slows down our trip. In Part II, Chapter 10, "ScrumMaster," what I read was particularly useful to me as a new one of these. Though the responsibilities of this role are a bit daunting, Kenny's description afforded the right perspective. An example of this balance comes in the section in which he describes being an agile coach for the scrum team. If a member faces a problem that they can solve, the ScrumMaster's attitude is, "I'm not here to solve the problems for you; instead, I'm here to help you solve your own problems." (By the way, "If the problem is an impediment that the team can't resolve, the ScrumMaster takes ownership of getting it resolved.") If you're a product owner, member of the development team, or manager, the rest of Part II contains similar gems and pearls of wisdom to understand the part you play on the scrum team and that, to use a Jim Collins construct, you're one of the "right people on the bus." To adopt the mindset of agile planning, I strongly recommend a read of Chapter 14, "Scrum Planning Principles" in Part III. I say this because this is one of the areas in which Scrum practitioners take the most grief from its opponents. The argument goes that agile methodology doesn't, can't or won't fit in to their organization because there's no planning involved. Kenny dispels this rumor by masterfully articulating the Zen of agile planning. I can best sum this up by citing a passage on page 248, "When developing using Scrum, we don't believe we can get it right up front, so we don't try to produce all of the planning artifacts up front." Simply put, this calls out the "elephant in the room belief" held by dogmatists of the waterfall approach that massive Gantt charts can't possibly be wrong because they're so detailed. The rest of Part III is further support that Scrum development leverages the right kind of planning across all levels and timeframes of the product development lifecycle. Figure 15.1 on page 257 is an excellent illustration of these levels (and the description in the following pages). It shows that Scrum planning happens from the point of view of a strategy, a portfolio, a product, a release, a sprint, and down to the daily activities of the development team. One of the areas that I was confused by when first learning about Scrum was where the actually tasks were parked. There didn't seem to be much, if any, discussion about them, and my waterfall bias rendered the expectation that no real work could be done in a scrum until the tasks were defined and assigned. I discovered, by reading in Chapter 19, "Sprint Planning" that task planning in Scrum terms defined by Kenny is called, "Acquiring Confidence." Because the development team is empowered to commit to the goal of a sprint, it's imperative that they do so with a high degree of confidence. Often, in plan-driven development, a pile of tasks are assigned to (unloaded on) a developer without much discussion of the precision of the estimates of how long someone thinks it might take to complete the task, or with minimal regard to their current capacity. In Scrum (described on page 344), the development team breaks down "the product backlog items down into the tasks that are required to complete them to the Scrum team's agreed-upon definition of done." Because of the development team's participation in the definition and sizing of the User Stories (see "Planning Poker," Chapter 7, page 129), the work to be done, a developer's commitment to an estimate of a task's duration is much stronger, even if the estimate is wrong. Kenny paints this value quite well. Chapters 20, "Sprint Execution," 21, "Sprint Review," and 22, "Sprint Retrospective," round out Part IV of the book. These chapters, respectively, are analogous (if you stretch the landscape metaphor) to the current Interstate being traveled, a new car showroom, and a rest area for motorists along the way. Kenny provides the key signposts to watch for along the way to ensure that your sprints go as much according to plan as possible, and avoid unnecessary hazards and detours. In Chapter 23, "The Path Forward," Kenny concludes the book with some gourmet food for thought. Our desire when adopting something new is usually to find a pattern or template that we can copy and follow thus avoiding known hazards. We try to find those "best practices" like wild game, and shoot it, dress it and can it for later consumption. Kenny points out the latitude that exists when undertaking to use Scrum eliminates that need. On page 396 he writes, "Throughout this book I have used the term practice to mean a core or essential aspect of Scrum. An approach is a particular implementation of a Scrum practice. When people ask me about best practices, I take that to mean best approaches." Later he writes, "Approaches, therefore, are unique to each team..." I highly recommend this book! I read the Kindle version from Amazon on my iPad using the Kindle app, and made extensive use of the digital highlighter, and captured several notes. It won't make you a seasoned expert on Scrum: that comes with time and experience. What it will do is provide a well thought out and insightful map with which you can start your journey in the Land of Scrum.

I have highly enjoyed reading Essential Scrum. As an IT Manager that is several years into an Agile transformation, I expected to get a small amount of value out of reading this book. However, I was surprised by the depth of information and analysis around each topic. For example, the compare and contrasts between traditional Waterfall development, Scrum, and Kanban was very interesting. I have used some of the tables from chapter 1 to help my non-Agile-initiated colleagues gain some appreciation for why incrementalism, continuous delivery, etc. are often better than traditional PM and development approaches. Some other examples: Being less familiar with Lean and Kanban, I also benefited greatly from the information about Work in Process (WIP)/small batch sizes, and this translated into re-inspecting my organization's support & maintenance workflow for improvements. I also got a lot out of the chapters on User Stories and Product Backlogs: handling non-functional requirements, ideas for improving our story writing workshops, story mapping, managing multiple backlogs, and managing multiple products. I also really appreciated the section on Making Technical Debt Visible, and the economic approach toward the problem. The chapters on the Roles of Scrum were also quite interesting, even though a bit of review for me and my team. Product Owner is one of the roles that we struggle with, and it was nice to see such a thorough exploration of that role and its characteristics, responsibilities, etc. This has helped me in engaging stakeholders and turning them into Product Owners for our projects. It also validated some of feelings we've had about the tradeoffs inherent in using Product Owner Proxies. The ScrumMaster chapter was also very valuable in helping me coach my ScrumMasters and increase our depth in that capacity. As an IT-Manager (now Director), I got the most value out of the chapter on Managers. I found the chart on Functional Manager Responsibilities to be a very fine illustration of the activities that Agile Managers should focus on. The phrase "managing the value-creation flow" really stuck with me. The was also a wealth of knowledge about defining boundaries (critical in maintaining self-organizing teams), forming teams, energizing people, and more. No matter what your level of experience, entry point, role, or perspective on Scrum is, I highly recommend this book to you. You will learn something useful from every chapter.

I took my first graduate course this spring at the Harvard Extension School. The course was on agile project management, and this was our required text. After being out of school for years, I had expected our textbook to be digital, but was pleasantly surprised by this book. By the end, I preferred having the physical copy to take notes and bookmark pages. The language and style of the book are clear, simple, relatable, and comprehensible. I found myself taking in the information at first read and being able to internalize the concepts quickly due to the effective writing style. If you are looking to increase your skill in project management, I highly recommend this text.

Scrum presents a vision of iterative, team-based product development that accelerates delivery of high-value products or services designed to attract and delight customers. Essential Scrum offers reliable guidance to those who want to put this vision to work at their company or team. Three features contribute to my appreciation and use of this guide: 1. The structure of the book Four sections include a) an exploration of core Scrum concepts; b) a description of the roles people play in the Scrum framework; c) Scrum planning principles and the various planning events that scaffold the work of product development; and d) a description of key events and activities that occur during a Sprint. This structure makes it easy to find information on the various components of Scrum, and clearly shows how they integrate as a whole. 2. Graphic layout and visual language Throughout the book, Rubin uses graphs and pictograms to explain and reinforce his text. 204 figures illustrate key concepts and demonstrate how parts relate to a larger whole. See for example figure 2.3, which charts the overall Scrum framework, or Figure 15.7 which diagrams the hierarchy and relationship of Scrum planning events. The book uses visual language to communicate a systems view of Scrum. Chart and diagrams constantly remind us to relate each specific Scrum process or role to its supporting framework, or the underlying principles that give it power. This format communicates the systemic nature of Agile methods, where simple rules are used to navigate a complex and rapidly changing environment. 3. Exploration of Organizational Strategies that Support Agile Adoption As Scrum teams mature, their success may be helped or hindered by a range of processes beyond their direct control. For example, portfolio and product planning has a major impact on the work of the Scrum Team, yet may not involve direct input from team members. Rubin presents eleven strategies for effective portfolio planning “in a manner that is well aligned with core Agile principles.” These strategies include establishing Work In Progress (WIP) limits, estimating the cost of delay for features to be ranked, and adopting smaller and more frequent releases, Strategies such as these, he suggests, provide an organizational framework that enables a fast, flexible flow of work for on-the-ground Scrum teams. In the long run, alignment of processes top-to-bottom increases the agility and performance of the entire organization. I turned to Essential Scrum to assist my understanding of how facilitators can support the work of Agile teams. Rubin’s explanation of Scrum matches my own experience of facilitation: effective processes are grounded in simple and reliable “rules" of human communication and teamwork that enable effective action in unpredictable and complex settings. Whether you have specific questions about Scrum ceremonies, or are interested in how to scale Agile methods up and throughout your organization, this book can become a trusted advisor on your journey, guiding you to action that will encourage learning and fuel success.

Having been a scrum practitioner since about 2004, I expect that reading a scrum book will be a way to simply refresh my Scrum knowledge Reading this book did more for me than that. It helped me re-think some practices and consider ways to move beyond my current approach to Scrum and consider ways to do thinkgs better. This book covers the whole spectrum of Scrum related issues. Not only does it cover the usual Scrum mechanics, such as how toexecute scrum meetings. It also covers the questions that often leave those adopting Scrum for the first time puzzled: how Scrum fits in the larger organization, the the role of Managers (yes, there is one), and how to deal with obstacles. The book has an excellent discussion of the various Scrum roles, and how they work in real situations. (For example, what to do when you can't have a decidated Scrum Master). This is a book on process, but it does not let you forget that people and communication are at the core of Scrum. This is a rather complete book on its own, as it covers the full spectrum and full lifecycle of Scrum from planning to retrospective, and from Portfolio to sprint. Rubin also provides a selection of good references throughout should you want to go deeper. Readable and useful by everyone on the team and in the business, Essential Scrum can help you adopt Scrum more effectively, or reenergize your Scrum thinking if you are Scrum veteran.

I run a large team of hundreds of developers (at Amazon, ironically, if you're reading this review!). After spending a couple years reading all the books about "scaling agile", etc, we have instead decided that we can get 90% of the benefit of Scrum and Agile by focusing on making each individual team rigorous and productive, and not focusing on the large scale so much. We then spent another year looking around for a method to follow. There are as many ways to do Agile as there are teams and projects; but we found that if we all adopted one philosophy/approach together, we could both help each other by moving teammates around between teams as their careers and desires led them but also so that all of our own tooling (a very heavily customized Jira instance) could benefit everybody. We found Ken's book to be the one that we can all align on. It's prescriptive enough to be useful but loose enough that teams feel freedom to innovate. The examples and pictures are at just the right level. You can tell it's written by somebody who lives Agile, and this helps developers respect the content and have more open minds. I now give a copy of Ken's book to every new manager, product manager, and senior engineer, with their name written on it, by me, with a welcome note from me inside the cover. Ken's book has been a huge help to our team and perhaps it can be to yours as well!

Essential Scrum by Kenny Rubin helped shaped many of the decisions we made as our IT department began our agile transformation – from forming teams, to the role of both the manager and project manager, Ken’s advice was critical to the cultural change required to sustain agile development practices. This is a great book for those new to scrum – it was essentially required reading for our team members as we embarked in our transformation and it became the basis for our agile training curriculum. The book is also fantastic reference material for experienced agile practioners – I frequently find myself consulting the book when situations arise and the organization of material makes it easy to quickly find what I am looking for. My book is well worn, dog-eared and annotated from frequent use! Kenny’s balanced approach and real examples help move scrum from theoretical to practical. The tables, illustrations and diagrams are fantastic – really helps readers to visualize the topics. I frequently use Ken’s diagrams to help as I explain a topic. The topics of scaling agile are thoroughly covered with sections on multilevel planning, portfolio planning and release planning which are crucial to be successful with enterprise agility. In addition to Kenny’s book, his coaching services were instrumental to our transformation success and we had instances of pivoting based upon his experience, wisdom and advice. Highly recommended!

I have a long workday commute via bus & subway, so I try to find kindle books that will help me on the job, to put my transit time to best possible use. I also like books that are not so cerebrally intensive that they can be read during the normal distractions that occur with public transit. This book was perfect for me--I'm new to Scrum, my team uses it, and the book provided useful reading that I could absorb during my commutes. It's pretty clear that the author is trying to give all the useful Scrum information he knows (a considerable amount) in order to maximize the book's value for the reader, and he also provides the information in an organized way that readers will benefit most from. There is some degree of repetition within the book, concepts in one chapter carry over in a different setting to others, but much of it I would say help enforces the principles of Scrum while you're reading. The Kindle version text is formatted quite nicely, the diagrams/pictures all look good, however you usually will need to use your Kindle's image enlargement feature for diagrams you wish to read through closely. I have no regrets in choosing the digital over the paper version. I did find distracting the author's seemingly uniform (100%) usage of "she" and "her" throughout the book whenever referring to a generic developer or manager ("The Scrum Leader can optimize her meetings by...", "The developer can use her task list...") I can understand splitting it 50/50 between "she" and "he", but whatever philosophical objections about using "he" ("developers can be female too!") occur likewise by using "she" all the time, and actually is even worse, because a solid majority of most development teams are, in fact, male.

Comparte información sencilla de asimilar, ejemplos e ilustraciones claras, es claro que el autor tiene un gran dominio de scrum y lo mejor de todo es que sabe como compartir su experiencia.

Un perfetto manuale di SCRUM. Tutti gli aspetti sono dettagliati e integrati con esempi e casi reali. Uno dei migliori testi per cominciare a lavorare agili.

New to scrum, this book is excellent explains all the best pratices of this method and culture. The different roles, acronymes, steps, etc.... you will get to know them all

Seit 2000 macht Ken Rubin Projekte nach Scrum und bringt das anderen bei - inzwischen mehr als 200 Unternehmen und mehr als 19000 Kursteilnehmern. Jeder Andere hätte mit seinen Kenntnissen und Erfahrungen schon 5 Bücher geschrieben. Zum Glück durfte Ken Rubin das nicht. Seine Frau hat ihm es nämlich nach seinem ersten Buch (Succeeding with Objects, 1993) verboten. Zum Glück hat sie irgendwann ihre Meinung geändert (Frauen;) Aber wer weiß, ob und wann er noch ein Buch schreiben darf. Was heißt es für uns Leser? In nur einem Buch finden wir: - Alle wichtigen Themen (Wann brauche ich Scrum und wann nicht? Sowie Konzepte, Rollen, Planung, Sprinting) - Geballte Erfahrung des Autors - Sehr undogmatische Erzählweise - Viele Herangehensweisen für bekannte Probleme und Fragen (z.B. Was mache ich wenn mein Product Owner keine Zeit hat? Was mache ich mit den Änderungen während des Sprints? Brauche ich User Stories oder kann ich auch anders meine Product Backlog Items formulieren? Was machen Manager in einer Organisation, die nach Scrum arbeitet? Darf eine Person gleichzeitig Scrum Master und Product Owner sein?) - Ständige "Übersetzung" aus dem "Technischen" ins "Monetäre" - alles wird beziffert, sehr praktisch um zwischen Entwicklern und Managern zu vermitteln. - Klare, ja wunderschöne Struktur - Gut formulierte, verständliche und durchdachte Sätze Für wen ist das Buch interessant: - Für alle, die Scrum anwenden wollen oder bereits anwenden - übrigens nicht nur in der Software Entwicklung. Der Autor selbst hat auch z.B. Marketing-Projekte nach Scrum gemacht. - Für alle, die Scrum-Konzepte kennen lernen wollen und das beste für eigene Projekte rauspicken wollen. - Die Kapiteln "Can Scrum help you?", "Agile Principles", "Technical Debt" würde ich allen, die in Software Entwicklung tätig sind, ans Herz legen. Es war ein Vergnügen dieses Buch zu lesen.

This book provides a comprehensive description of the Scrum framework backed up by plenty of discussion, illustrations and practical tips. It's an excellent guide for the adoption and ongoing implementation of Scrum. It also covers advanced concepts such as Portfolio Planning, Envisioning and technical debt. Also useful is how the book relates key aspects of Scrum to economic realities by providing cost/benefit calculations to show how they support and affect decision making in the framework. This is excellent material to demonstrate the value of Scrum to commercial stakeholders. The author's accessible style and excellent layout of chapters make it very easy to read. An added benefit is the author's use of a set of icons and diagrams that can be downloaded from the books website and used in internal presentations.