際際滷

際際滷Share a Scribd company logo

Scrum Insights for Practitioners - partial

Hiren Doshi
Hiren Doshi

This document provides an overview and summary of the book "Scrum Insights for Practitioners" by Hiren Doshi. The book is intended to serve as a companion to the Scrum Guide by providing additional context and practical insights about implementing Scrum. It addresses common questions about Scrum, myths and misconceptions, best practices for Scrum events and roles, and a case study example. The author aims to help readers better understand Scrum and get more value from applying its principles in their work.

1 of 16
Downloaded 39 times
Scrum Insights for Practitioners
Scrum Insights for Practitioners T H E S C R U M G U I D E C O M P A N I O N Hiren Doshi
息 2016 Hiren Doshi All rights reserved. ISBN: 0692807179 ISBN 13: 9780692807170 Contents Foreword by Gunther Verheyen . . . . . . . . . . . . . . . . . . . . . . . . . xi Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvii Scrum Theory and Definition of Scrum. . . . . . . . . . . . . . . . . . . .1 What Is Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 What Is a Complex Adaptive Problem? . . . . . . . . . . . . . . . . .2 What Is Empirical Process Control, or Empiricism?. . . . . . .5 The Three Pillars of Empiricism (Scrum) . . . . . . . . . . . . . . .6 The Scrum Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Courage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Respect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 The Scrum Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 The Product Owner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 The Scrum Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 The Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Development Team Size . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 The Availability of the Three Roles . . . . . . . . . . . . . . . . . . . 21
Scrum Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Sprint Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Product Backlog Refinement. . . . . . . . . . . . . . . . . . . . . . . . .42 Scrum Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Product Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Product Increment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Artifact Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Self-Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 What Is Self-Organization?. . . . . . . . . . . . . . . . . . . . . . . . . .56 How Does Scrum Promote Self-Organization? . . . . . . . . . .56 What Are Some Signs That Teams Are Self-Organizing? . . .58 How Does Time-Boxing Promote Self-Organization? . . . .58 How Do the Scrum Roles Promote Self-Organization? . . .58 Myths, Mysteries, and Misconceptions of Scrum. . . . . . . . . . . . 61 What Are Sprint 0, Hardening Sprints, Release Sprints, and Stabilization Sprints?. . . . . . . . . . . . . . . . . . . . . 61 Is Scrum a Methodology or a Framework?. . . . . . . . . . . . . . 61 My Designation Is Development Manager. Does This Mean I Have No Role In Scrum?. . . . . . . . . . . . . . . . .62 How Is Architecture Handled in Agile? . . . . . . . . . . . . . . . .63 One Scrum Team Is Currently Developing a Product. What Impact Will It Have on Its Productivity When One More Scrum Team Is Deployed in This Product Development Effort? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 What Are Commonly Observed Scrum Myths, Mysteries, and Misconceptions? . . . . . . . . . . . . . . . . . . . . . .66 A Case Study on Scrum-Based Product Development . . . . . . . .69 An example of a PBI in Ready state . . . . . . . . . . . . . . . . . .71 Authors Thoughts and Conclusion. . . . . . . . . . . . . . . . . . . . . . .77 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Best Practice: Scrum Board, as a Visualization of Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Emergent Architecture: An Example . . . . . . . . . . . . . . . . . .80 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Author Biography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
To my wonderful parents; beautiful wife, Swati; and loving daughters, Aditi and Ashwini.
xi Foreword by Gunther Verheyen Scrum grew less and less complete and perfect over time. Practices and techniques were gradually removed from the offi- cial definition of Scrum in The Scrum Guide. As the global Scrum adoption grew and Scrum became the most adopted method for Agile software development, more and more space was created for variation in techniques and practices by eliminating specific in- structions from the official body of knowledge of Scrum. Scrum turned into the framework that it was always designed to be, a framework that enables practitioners to devise their own solutions. In his book Scrum Insights for Practitioners, Hiren has extend- ed the core rules of The Scrum Guide with practices he has found useful. Hiren answers questions regarding Scrum that potentially remain unanswered even after one reads The Scrum Guide. Hiren dismantles common misconceptions about Scrum, regardless of the source of such misconceptions. Hiren elaborates on basic in- formation provided in The Scrum Guide, as well as on the prin- ciples underlying Scrum.
xiiixii Hiren Doshi Hiren shows that experts understand that there are still many people new to Scrum looking for help and guidance, people who might not have the possibility to learn through extensive experi- ence. Hiren respects people looking for information additional to The Scrum Guide, without ever turning any of his advice, practices, or insights into must prescriptions. Reading The Scrum Guide and additionally reading Scrum Insights for Practitioners provides any aspiring Scrum practitioner with valuable base insights, without leaving the impression it can replace actual experience. Enjoy reading. Keep Scrumming. Gunther Verheyen Independent Scrum Caretaker Antwerp September 22, 2016 Recommendations One of the best things about Scrum is its simplicity. Its very easy to get started using Scrum, but if youre not careful, you can make a lot of mistakes. Take advantage of Hirens vast experience and avoid making the common errors people make as they begin their journey. This book contains a wealth of practical information that will be use- ful to readers as they work to implement the basic theory found in The Scrum Guide.Steve Porter, team member, Scrum.org Hiren Doshi has written a fine companion to The Scrum Guide, filling in some of the intentional gaps left in the Scrum framework. Using this companion along with The Scrum Guide will undoubtedly improve the outlook for those teams that internalize its teachings.Charles Bradley, ScrumCrazy.com This book will help you understand the nuances of Scrum. It takes a very practical approach toward imple- menting Scrum without compromising on its values and principles. Perhaps the first book on Scrum that newbies
xvxiv Hiren Doshi should read after going through The Scrum Guide. A useful and handy reference for Scrum practitioners!Gopinath R., Agile coach and practitioner Acknowledgments Im incredibly honored and privileged to have the best Scrum experts in the industry as the official reviewers of my first book. I owe a tremendous debt to Steve Porter, Gunther Verheyen, and Charles Bradley for reading and providing their expert comments on the manuscript. Each of them has provided valuable insights to make my writing more complete. Thank you. Very special thanks to Gopinath Ramakrishnan, a good friend and a Scrum expert himself, for reviewing and editing the manu- script during my early days of writing and providing me with valu- able insights. Thank you for being patient with me and helping me improve the manuscript. Thank you, Gunther Verheyen, for writing such a fantastic foreword. I am honored. Thank you, Ken Schwaber and Jeff Sutherland, for teaching me Scrum.
xviixvi Hiren Doshi Finally, a thank-you to my wife, Swati, for reviewing the book and giving her valuable insights. I also thank her for always being there for me throughout the journey. Thank you! Preface Scrum is a framework to manage complex product development. The framework consists of three roles, five formal events, three artifacts, and the rules that bind these elements together. The Scrum Guide is the one and only official description of Scrum and is freely available at ScrumGuides.org. The Scrum Guide is written and maintained by the cocreators of Scrum, Ken Schwaber and Jeff Sutherland. The Scrum Guide holds the bare and essential rules of Scrum. It provides sufficient information to understand Scrum but leaves much open for interpretation by readers and practitioners. When individuals and organizations follow The Scrum Guide blindly, without understanding the real, deep essence of Scrumthe prin- ciples and values underpinning the frameworkthey likely will fail to reap all the benefits Scrum has to offer. As noted in The Scrum Guide, Scrum can be compared to the game of chess: easy to understand but difficult to master. Why? As in the game of chess, the rules of the game are very simple, but the game has millions of strategies by which it can be played. How many grand masters do we know who have mastered chess?
xixxviii Hiren Doshi Scrum Insights for Practitioners Most likely we will be able to count the names on the fingers of our hands. Ten years back, I started my Agile software development journey via Scrum. I began my practice for a large organization in the United States by just reading The Scrum Guide. I enjoyed every moment of the journey, and I was under the impression that I was doing a fabulous job with the Scrum adoption in the orga- nization. Luckily, six months into the adoption, I started attend- ing Ken Schwabers Scrum-But sessions, held in his Burlington, Massachusetts, office. These sessions were eye-openers for me as I realized that I did not really have a deep understanding of what Scrum is and the way it is supposed to be practiced. In fact, it was much worse than that: I had not just limited my mud- died understanding of Scrum to myself, but I had distributed this knowledge to many others who collaborated with me on product development. Scrum Insights for Practitioners fills in some gaps in the un- derstanding of Scrum for individuals or organizations practicing Scrum. This book can be thought of as a companion to The Scrum Guide. I encourage readers to first read The Scrum Guide if you are new to Scrum before reading this book, as this will help you reap the maximum benefits. Scrum Insights for Practitioners is a perfect companion to The Scrum Guide that helps the practitioners master the Scrum frame- work by gaining in-depth practical insights and helps answer ques- tions such as these: What are some common myths, mysteries, and miscon- ceptions of Scrum? The Scrum Guide recommends three to nine members in a Development Team, but we have fifteen members. Is this Scrum? Can you share some tactics to do effective Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Product Backlog Refinement? My designation is development manager. Does this mean I have no role in Scrum? How is Scrum Empirical? Can Scrum Master and Product Owner be the same person? We dont have a Scrum Master. Are we still practicing Scrum? What does self-organization really mean? How does Scrum embrace the four values and twelve prin- ciples of the Agile Manifesto? Please share a case study on Scrum-based product development? This book is a collection of my experiences and learning and will provide you guidance and suggestions about adopting Scrum. It will also help clear up the myths and misconceptions of Scrum. Each organizations business context varies, and it is very difficult to prescribe a best practice that will work for everyone. You are in a better position to understand the exact circumstances of your business needs and adapt accordingly.
1 Scrum Theory and Definition of Scrum What Is Scrum? As defined in THE SCRUM Guide, Scrum is a lightweight framework founded on empirical process control theory that supports small teams in addressing complex adaptive problems while productively and creatively delivering products of the highest possible value.
32 Hiren Doshi Scrum Insights for Practitioners AN ALTERNATIVE DEFINITION OF SCRUM Scrum is an iterative way of developing software in a Sprint (a time-box of one month or less), incrementally delivering work- ing software every Sprint, incorporating customer feedback on the working software, and ensuring that the right business value is delivered in each Sprint. What Is a Complex Adaptive Problem? According to the Cynefin framework, by David Snowden, any soft- ware project that you pick up can be bucketed in one of four categories: Cynefin Framework By Snowded, 2014, Last modified July 6 2014. https:// commons.wikimedia.org/w/index.php?curid=33783436. Obvious: Everything about the project is known. Complicated: More about the project is known than is unknown. Complex: More about the project is unknown than is known. Chaotic: Everything is unknown. There is no proven approach. Each category requires a different approach: Projects in the Obvious and Complicated domains can follow a predictive modelplan driven or waterfalland a project plan can be put in place as most of the requirements, the technology, and people aspects of the projects are well known in advance and hold few uncertainties. Example 1: Rewriting an existing payroll application. Example 2: Building a sea link using a suspended bridge to connect two cities. Although this might not sound like a simple, uncomplicated project, it actually is. Humans have been building bridges for centuries, and we have accumulated plenty of data on the same. The data can be analyzed to put a solid plan together, and most likely one can comfortably predict the time and cost needed to build a bridge with no more than 5 to 10 percent vari- ance on the planned work. If we are very certain about the project requirements and the technology we plan to use, it is well proven that a predictive model is a better choice.
54 Hiren Doshi Scrum Insights for Practitioners For Chaotic projects no defined process works, as almost everything about the project is unknown and is subject to ex- tensive changes. The best model for such projects is to act in order to establish some type of direction and then decide on the next move. Software projects reside in the Complex domain, as it is ex- tremely difficult to envision the exact final outcome of the product and how the market will embrace it when it is released. Products and services like Uber, Apple, Google, Amazon, and Facebook have evolved over time. The founders of these companies most likely did not envision the exact products that we use today when they conceived the first ideas. The complexity in software aris- es from these facts: there are many unknown variables, and for known variables the variance is too much. These are some of the variables that make software develop- ment complex: 1. Requirements: Software requirements never stop chang- ing. The customer often will not know what he or she wants until the customer can actually use the product. 2. Technology: This is an ever-changing variable. 3. People: The people aspect is very unpredictable (e.g., attri- tion, leaves of absence, skill gaps). For complex projects, empirical process control, or empiricism, is the best-suited approach. What Is Empirical Process Control, or Empiricism? Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Here is an analogy to explain empiricism: Assume you need to develop twenty-five equally sized features for a product before it can be released to the market. You agree to develop five features in each one-month Sprint. This means you will complete twenty-five features in five Sprintsthat is, five fea- tures delivered by the end of each one-month Sprint. Suppose you complete seven features in the first Sprint instead of the planned five. This evidence of your real progress gives you the insight that you can take on more features in the next Sprint that is, seven features instead of the planned five. This also means that the project might turn out to be much simpler than you an- ticipated, and instead of five Sprints to complete all twenty-five features, you might end up needing only four Sprints. Suppose, however, that you complete only two features in- stead of the planned five in the first Sprint. This evidence of actual progress gives you the insight that you had better take on fewer features in the next Sprintthat is, two features instead of the planned five. This also means that the project might turn out to be more difficult than you anticipated. Instead of five Sprints to com- plete all twenty-five features, you might need over twelve Sprints.
76 Hiren Doshi Scrum Insights for Practitioners If you are not able to complete any features in a Sprint, then you still come away with the insight that you might need to slice and plan your work in a very different way. Thus, real data enable good decision making in a timely manner. Contrast this with a traditional predictive modellike waterfallwhere sponsors spend huge amounts of money with- out knowing the outcome for a very long period, often years. Scrum, due to its empirical nature, is very appealing to spon- sors as at the end of each Sprint, a potentially releasable Done Product Increment is available. The increment can be inspected and potentially released if deemed sufficiently valuable every one month or less. The Three Pillars of Empiricism (Scrum) Scrum is empirical and places great emphasis on mind-set and cultural shift to achieve business and organizational Agility. The three pillars of empirical process control are as follows: Transparency: This means presenting the facts as is. All people involvedthe customer, the CEO, individual contributorsare transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda. Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by every- one on the Scrum Team. The inspection can be done for the product, processes, people aspects, practices, and con- tinuous improvements. For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis. Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization must ask this question regularly: Are we better off than yesterday? For profit-based organizations, the value is represented in terms of profit. The adaptation should eventually relay back to one of the reasons for adapting Agilefor example, faster time to market, increased return on investment through value- based delivery, reduced total cost of ownership through enhanced software quality, and improved customer and em- ployee satisfaction. Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gath- ering customer feedback and embracing change. This results in faster time to market, better delivery predictability, increased cus- tomer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management.
9 Scrum Insights for Practitioners 8 The Scrum Values The Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone when the Scrum values are embodied and lived by everyone. The Scrum values are cour- age, focus, commitment, respect, and openness. Successful use of Scrum depends on people becoming more proficient in adapting their behavior to these five Scrum values. Gunther Verheyen has captured the values very well on his blog: Gunther, V. (May 2015). https://guntherverheyen.com/ 2013/05/03/theres-value-in-the-scrum-values/ Scrum Values This is my interpretation and adaptation of his text: Courage The Scrum Team members have the courage to do the right thing and collaborate on difficult problems. They show courage in being transparent and sharing risks and benefits as they are. They admit that requirements will never be close to perfect and show courage not only by acknowledging that but also by adapting to chang- ing requirements and direction. They show courage in admitting that nobody is perfect and accepting people for who they are. The Scrum Team shows the courage to promote Scrum and empiri- cism to deal with complexity.
1110 Hiren Doshi Scrum Insights for Practitioners Focus Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The time-boxes of Scrum allow a Scrum Team to focus on delivering valuable working software at a sustainable pace. The team focuses on simplicity (e.g., no gold plating) and deliver- ing to the needs of the customer. The team focuses on embedding good engineering practices for Lean software development and increased value and quality delivery. Commitment People personally commit to achieving the goals of the Scrum Team. They commit to the Agile values and principles as doc- umented in the Agile Manifesto. The Scrum Team commits to building working software, to quality, to collaborating, to learning, to self-organizing, to building the right thing for its customers, to excelling, to being creative and innovating, to con- tinuously improving upon regular inspections and adaptations, to the Scrum framework, to transparency, and to challenging the status quo. Respect Scrum Team members respect each other to be capable and inde- pendent people. They show respect for people. They respect di- versity. They respect the Scrum roles, rules, and principles. They show respect by building valuable, releasable-quality working software with every Sprint. Openness The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. They are open to collaborating within the team and with the organization. They are open to being transparent.

More Related Content

Scrum Insights for Practitioners - partial

  • 2. Scrum Insights for Practitioners T H E S C R U M G U I D E C O M P A N I O N Hiren Doshi
  • 3. 息 2016 Hiren Doshi All rights reserved. ISBN: 0692807179 ISBN 13: 9780692807170 Contents Foreword by Gunther Verheyen . . . . . . . . . . . . . . . . . . . . . . . . . xi Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvii Scrum Theory and Definition of Scrum. . . . . . . . . . . . . . . . . . . .1 What Is Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 What Is a Complex Adaptive Problem? . . . . . . . . . . . . . . . . .2 What Is Empirical Process Control, or Empiricism?. . . . . . .5 The Three Pillars of Empiricism (Scrum) . . . . . . . . . . . . . . .6 The Scrum Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Courage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Respect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 The Scrum Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 The Product Owner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 The Scrum Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 The Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Development Team Size . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 The Availability of the Three Roles . . . . . . . . . . . . . . . . . . . 21
  • 4. Scrum Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Sprint Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Product Backlog Refinement. . . . . . . . . . . . . . . . . . . . . . . . .42 Scrum Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Product Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Product Increment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Artifact Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Self-Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 What Is Self-Organization?. . . . . . . . . . . . . . . . . . . . . . . . . .56 How Does Scrum Promote Self-Organization? . . . . . . . . . .56 What Are Some Signs That Teams Are Self-Organizing? . . .58 How Does Time-Boxing Promote Self-Organization? . . . .58 How Do the Scrum Roles Promote Self-Organization? . . .58 Myths, Mysteries, and Misconceptions of Scrum. . . . . . . . . . . . 61 What Are Sprint 0, Hardening Sprints, Release Sprints, and Stabilization Sprints?. . . . . . . . . . . . . . . . . . . . . 61 Is Scrum a Methodology or a Framework?. . . . . . . . . . . . . . 61 My Designation Is Development Manager. Does This Mean I Have No Role In Scrum?. . . . . . . . . . . . . . . . .62 How Is Architecture Handled in Agile? . . . . . . . . . . . . . . . .63 One Scrum Team Is Currently Developing a Product. What Impact Will It Have on Its Productivity When One More Scrum Team Is Deployed in This Product Development Effort? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 What Are Commonly Observed Scrum Myths, Mysteries, and Misconceptions? . . . . . . . . . . . . . . . . . . . . . .66 A Case Study on Scrum-Based Product Development . . . . . . . .69 An example of a PBI in Ready state . . . . . . . . . . . . . . . . . .71 Authors Thoughts and Conclusion. . . . . . . . . . . . . . . . . . . . . . .77 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Best Practice: Scrum Board, as a Visualization of Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Emergent Architecture: An Example . . . . . . . . . . . . . . . . . .80 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Author Biography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
  • 5. To my wonderful parents; beautiful wife, Swati; and loving daughters, Aditi and Ashwini.
  • 6. xi Foreword by Gunther Verheyen Scrum grew less and less complete and perfect over time. Practices and techniques were gradually removed from the offi- cial definition of Scrum in The Scrum Guide. As the global Scrum adoption grew and Scrum became the most adopted method for Agile software development, more and more space was created for variation in techniques and practices by eliminating specific in- structions from the official body of knowledge of Scrum. Scrum turned into the framework that it was always designed to be, a framework that enables practitioners to devise their own solutions. In his book Scrum Insights for Practitioners, Hiren has extend- ed the core rules of The Scrum Guide with practices he has found useful. Hiren answers questions regarding Scrum that potentially remain unanswered even after one reads The Scrum Guide. Hiren dismantles common misconceptions about Scrum, regardless of the source of such misconceptions. Hiren elaborates on basic in- formation provided in The Scrum Guide, as well as on the prin- ciples underlying Scrum.
  • 7. xiiixii Hiren Doshi Hiren shows that experts understand that there are still many people new to Scrum looking for help and guidance, people who might not have the possibility to learn through extensive experi- ence. Hiren respects people looking for information additional to The Scrum Guide, without ever turning any of his advice, practices, or insights into must prescriptions. Reading The Scrum Guide and additionally reading Scrum Insights for Practitioners provides any aspiring Scrum practitioner with valuable base insights, without leaving the impression it can replace actual experience. Enjoy reading. Keep Scrumming. Gunther Verheyen Independent Scrum Caretaker Antwerp September 22, 2016 Recommendations One of the best things about Scrum is its simplicity. Its very easy to get started using Scrum, but if youre not careful, you can make a lot of mistakes. Take advantage of Hirens vast experience and avoid making the common errors people make as they begin their journey. This book contains a wealth of practical information that will be use- ful to readers as they work to implement the basic theory found in The Scrum Guide.Steve Porter, team member, Scrum.org Hiren Doshi has written a fine companion to The Scrum Guide, filling in some of the intentional gaps left in the Scrum framework. Using this companion along with The Scrum Guide will undoubtedly improve the outlook for those teams that internalize its teachings.Charles Bradley, ScrumCrazy.com This book will help you understand the nuances of Scrum. It takes a very practical approach toward imple- menting Scrum without compromising on its values and principles. Perhaps the first book on Scrum that newbies
  • 8. xvxiv Hiren Doshi should read after going through The Scrum Guide. A useful and handy reference for Scrum practitioners!Gopinath R., Agile coach and practitioner Acknowledgments Im incredibly honored and privileged to have the best Scrum experts in the industry as the official reviewers of my first book. I owe a tremendous debt to Steve Porter, Gunther Verheyen, and Charles Bradley for reading and providing their expert comments on the manuscript. Each of them has provided valuable insights to make my writing more complete. Thank you. Very special thanks to Gopinath Ramakrishnan, a good friend and a Scrum expert himself, for reviewing and editing the manu- script during my early days of writing and providing me with valu- able insights. Thank you for being patient with me and helping me improve the manuscript. Thank you, Gunther Verheyen, for writing such a fantastic foreword. I am honored. Thank you, Ken Schwaber and Jeff Sutherland, for teaching me Scrum.
  • 9. xviixvi Hiren Doshi Finally, a thank-you to my wife, Swati, for reviewing the book and giving her valuable insights. I also thank her for always being there for me throughout the journey. Thank you! Preface Scrum is a framework to manage complex product development. The framework consists of three roles, five formal events, three artifacts, and the rules that bind these elements together. The Scrum Guide is the one and only official description of Scrum and is freely available at ScrumGuides.org. The Scrum Guide is written and maintained by the cocreators of Scrum, Ken Schwaber and Jeff Sutherland. The Scrum Guide holds the bare and essential rules of Scrum. It provides sufficient information to understand Scrum but leaves much open for interpretation by readers and practitioners. When individuals and organizations follow The Scrum Guide blindly, without understanding the real, deep essence of Scrumthe prin- ciples and values underpinning the frameworkthey likely will fail to reap all the benefits Scrum has to offer. As noted in The Scrum Guide, Scrum can be compared to the game of chess: easy to understand but difficult to master. Why? As in the game of chess, the rules of the game are very simple, but the game has millions of strategies by which it can be played. How many grand masters do we know who have mastered chess?
  • 10. xixxviii Hiren Doshi Scrum Insights for Practitioners Most likely we will be able to count the names on the fingers of our hands. Ten years back, I started my Agile software development journey via Scrum. I began my practice for a large organization in the United States by just reading The Scrum Guide. I enjoyed every moment of the journey, and I was under the impression that I was doing a fabulous job with the Scrum adoption in the orga- nization. Luckily, six months into the adoption, I started attend- ing Ken Schwabers Scrum-But sessions, held in his Burlington, Massachusetts, office. These sessions were eye-openers for me as I realized that I did not really have a deep understanding of what Scrum is and the way it is supposed to be practiced. In fact, it was much worse than that: I had not just limited my mud- died understanding of Scrum to myself, but I had distributed this knowledge to many others who collaborated with me on product development. Scrum Insights for Practitioners fills in some gaps in the un- derstanding of Scrum for individuals or organizations practicing Scrum. This book can be thought of as a companion to The Scrum Guide. I encourage readers to first read The Scrum Guide if you are new to Scrum before reading this book, as this will help you reap the maximum benefits. Scrum Insights for Practitioners is a perfect companion to The Scrum Guide that helps the practitioners master the Scrum frame- work by gaining in-depth practical insights and helps answer ques- tions such as these: What are some common myths, mysteries, and miscon- ceptions of Scrum? The Scrum Guide recommends three to nine members in a Development Team, but we have fifteen members. Is this Scrum? Can you share some tactics to do effective Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Product Backlog Refinement? My designation is development manager. Does this mean I have no role in Scrum? How is Scrum Empirical? Can Scrum Master and Product Owner be the same person? We dont have a Scrum Master. Are we still practicing Scrum? What does self-organization really mean? How does Scrum embrace the four values and twelve prin- ciples of the Agile Manifesto? Please share a case study on Scrum-based product development? This book is a collection of my experiences and learning and will provide you guidance and suggestions about adopting Scrum. It will also help clear up the myths and misconceptions of Scrum. Each organizations business context varies, and it is very difficult to prescribe a best practice that will work for everyone. You are in a better position to understand the exact circumstances of your business needs and adapt accordingly.
  • 11. 1 Scrum Theory and Definition of Scrum What Is Scrum? As defined in THE SCRUM Guide, Scrum is a lightweight framework founded on empirical process control theory that supports small teams in addressing complex adaptive problems while productively and creatively delivering products of the highest possible value.
  • 12. 32 Hiren Doshi Scrum Insights for Practitioners AN ALTERNATIVE DEFINITION OF SCRUM Scrum is an iterative way of developing software in a Sprint (a time-box of one month or less), incrementally delivering work- ing software every Sprint, incorporating customer feedback on the working software, and ensuring that the right business value is delivered in each Sprint. What Is a Complex Adaptive Problem? According to the Cynefin framework, by David Snowden, any soft- ware project that you pick up can be bucketed in one of four categories: Cynefin Framework By Snowded, 2014, Last modified July 6 2014. https:// commons.wikimedia.org/w/index.php?curid=33783436. Obvious: Everything about the project is known. Complicated: More about the project is known than is unknown. Complex: More about the project is unknown than is known. Chaotic: Everything is unknown. There is no proven approach. Each category requires a different approach: Projects in the Obvious and Complicated domains can follow a predictive modelplan driven or waterfalland a project plan can be put in place as most of the requirements, the technology, and people aspects of the projects are well known in advance and hold few uncertainties. Example 1: Rewriting an existing payroll application. Example 2: Building a sea link using a suspended bridge to connect two cities. Although this might not sound like a simple, uncomplicated project, it actually is. Humans have been building bridges for centuries, and we have accumulated plenty of data on the same. The data can be analyzed to put a solid plan together, and most likely one can comfortably predict the time and cost needed to build a bridge with no more than 5 to 10 percent vari- ance on the planned work. If we are very certain about the project requirements and the technology we plan to use, it is well proven that a predictive model is a better choice.
  • 13. 54 Hiren Doshi Scrum Insights for Practitioners For Chaotic projects no defined process works, as almost everything about the project is unknown and is subject to ex- tensive changes. The best model for such projects is to act in order to establish some type of direction and then decide on the next move. Software projects reside in the Complex domain, as it is ex- tremely difficult to envision the exact final outcome of the product and how the market will embrace it when it is released. Products and services like Uber, Apple, Google, Amazon, and Facebook have evolved over time. The founders of these companies most likely did not envision the exact products that we use today when they conceived the first ideas. The complexity in software aris- es from these facts: there are many unknown variables, and for known variables the variance is too much. These are some of the variables that make software develop- ment complex: 1. Requirements: Software requirements never stop chang- ing. The customer often will not know what he or she wants until the customer can actually use the product. 2. Technology: This is an ever-changing variable. 3. People: The people aspect is very unpredictable (e.g., attri- tion, leaves of absence, skill gaps). For complex projects, empirical process control, or empiricism, is the best-suited approach. What Is Empirical Process Control, or Empiricism? Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Here is an analogy to explain empiricism: Assume you need to develop twenty-five equally sized features for a product before it can be released to the market. You agree to develop five features in each one-month Sprint. This means you will complete twenty-five features in five Sprintsthat is, five fea- tures delivered by the end of each one-month Sprint. Suppose you complete seven features in the first Sprint instead of the planned five. This evidence of your real progress gives you the insight that you can take on more features in the next Sprint that is, seven features instead of the planned five. This also means that the project might turn out to be much simpler than you an- ticipated, and instead of five Sprints to complete all twenty-five features, you might end up needing only four Sprints. Suppose, however, that you complete only two features in- stead of the planned five in the first Sprint. This evidence of actual progress gives you the insight that you had better take on fewer features in the next Sprintthat is, two features instead of the planned five. This also means that the project might turn out to be more difficult than you anticipated. Instead of five Sprints to com- plete all twenty-five features, you might need over twelve Sprints.
  • 14. 76 Hiren Doshi Scrum Insights for Practitioners If you are not able to complete any features in a Sprint, then you still come away with the insight that you might need to slice and plan your work in a very different way. Thus, real data enable good decision making in a timely manner. Contrast this with a traditional predictive modellike waterfallwhere sponsors spend huge amounts of money with- out knowing the outcome for a very long period, often years. Scrum, due to its empirical nature, is very appealing to spon- sors as at the end of each Sprint, a potentially releasable Done Product Increment is available. The increment can be inspected and potentially released if deemed sufficiently valuable every one month or less. The Three Pillars of Empiricism (Scrum) Scrum is empirical and places great emphasis on mind-set and cultural shift to achieve business and organizational Agility. The three pillars of empirical process control are as follows: Transparency: This means presenting the facts as is. All people involvedthe customer, the CEO, individual contributorsare transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda. Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by every- one on the Scrum Team. The inspection can be done for the product, processes, people aspects, practices, and con- tinuous improvements. For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis. Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization must ask this question regularly: Are we better off than yesterday? For profit-based organizations, the value is represented in terms of profit. The adaptation should eventually relay back to one of the reasons for adapting Agilefor example, faster time to market, increased return on investment through value- based delivery, reduced total cost of ownership through enhanced software quality, and improved customer and em- ployee satisfaction. Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gath- ering customer feedback and embracing change. This results in faster time to market, better delivery predictability, increased cus- tomer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management.
  • 15. 9 Scrum Insights for Practitioners 8 The Scrum Values The Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone when the Scrum values are embodied and lived by everyone. The Scrum values are cour- age, focus, commitment, respect, and openness. Successful use of Scrum depends on people becoming more proficient in adapting their behavior to these five Scrum values. Gunther Verheyen has captured the values very well on his blog: Gunther, V. (May 2015). https://guntherverheyen.com/ 2013/05/03/theres-value-in-the-scrum-values/ Scrum Values This is my interpretation and adaptation of his text: Courage The Scrum Team members have the courage to do the right thing and collaborate on difficult problems. They show courage in being transparent and sharing risks and benefits as they are. They admit that requirements will never be close to perfect and show courage not only by acknowledging that but also by adapting to chang- ing requirements and direction. They show courage in admitting that nobody is perfect and accepting people for who they are. The Scrum Team shows the courage to promote Scrum and empiri- cism to deal with complexity.
  • 16. 1110 Hiren Doshi Scrum Insights for Practitioners Focus Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The time-boxes of Scrum allow a Scrum Team to focus on delivering valuable working software at a sustainable pace. The team focuses on simplicity (e.g., no gold plating) and deliver- ing to the needs of the customer. The team focuses on embedding good engineering practices for Lean software development and increased value and quality delivery. Commitment People personally commit to achieving the goals of the Scrum Team. They commit to the Agile values and principles as doc- umented in the Agile Manifesto. The Scrum Team commits to building working software, to quality, to collaborating, to learning, to self-organizing, to building the right thing for its customers, to excelling, to being creative and innovating, to con- tinuously improving upon regular inspections and adaptations, to the Scrum framework, to transparency, and to challenging the status quo. Respect Scrum Team members respect each other to be capable and inde- pendent people. They show respect for people. They respect di- versity. They respect the Scrum roles, rules, and principles. They show respect by building valuable, releasable-quality working software with every Sprint. Openness The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. They are open to collaborating within the team and with the organization. They are open to being transparent.