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.

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.

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.

It is good book to understand the concept of agile methodology, I used this book and passed my PMP exam on first attempt.