Essential Scrum by Kenny Rubin is a book about getting more out of Scrum. It’s an introduction to Scrum and its values, principles and practices, and a source of inspiration on how to apply it. This practical Scrum guide gives you information on how to plan and execute projects with Scrum, and on interfacing parts of the organization that use Agile with parts that don't, which is crucial to assure successful Agile software development.
There are four main topics described in Essential Scrum:
- Core concepts of Scrum: The framework, principles and practices
- The roles of the Product Owner, Scrum Master, team and managers
- Planning of Scrum at different levels, from portfolio planning to sprint planning
- Sprinting: Planning, execution, sprint reviews and retrospectives
This book contains several nuggets that make it a valuable addition to the plethora of existing Agile books. For instance, there is extensive coverage of the concept of technical debt, which shows how you can use it to manage quality of your software products. As Kenny describes:
...technical debt requires interest payments, which come in the form of extra future development effort.
The description of both the technical and business aspects of technical debt helps to make better decisions, which enables better collaboration between managers and engineers on this difficult but very important topic of software development and maintenance.
Also concepts from "The Lean Startup" by Eric Ries, like Minimal Viable Product and Pivoting are combined with Scrum. For instance by showing how you can use Agile to build up knowledge about your customers, and use that to deliver valuable solutions. The book also explains the association between “fail fast” and “pivoting”, which makes clear how Scrum helps you to use feedback from customers to manage innovation and decide when to change direction.
If further investment in a product is not economically justified, we should decide whether to deliver, pivot, or terminate the product.
In relation to retrospectives, Kenny states:
...the sprint retrospective is one of the most important and least appreciated practices in the Scrum framework.
He describes who should attend the retrospective (and why), how retrospectives can be organized and what you can do to enable continuous learning and improvement. Many examples are given, like the use of root cause analysis, data gathering and how to set the atmosphere where professionals will share their opinions and listen to each other.
The experience and the examples described by Kenny Rubin in Essential Scrum can help you to get more out of Scrum, as a Scrum Master or Agile Coach, and to become more agile as a company. It is a very comprehensive and practical book. Here is also a sample chapter from the book.
Recently the author spoke to InfoQ about the book.
InfoQ: There are already several interesting books on Agile and Scrum available. What made you decide to write your book on Scrum?
I wrote the Essential Scrum book to fill an important void in the industry. I teach many Scrum classes and in most every class I get the question, “Which single Scrum book would you recommend that we give to our team members and managers to help them be successful?” I found that there wasn’t a single up-to-date book that I could recommend that covered the core Scrum framework and the most popular approaches for applying Scrum. As a result, I would rattle off a list of books that I felt would provide the requisite knowledge. That list would add up to several thousand pages of reading, which is overwhelming to anyone. So, I decided to write the book that would be the single, stand-alone resource providing essential Scrum knowledge to team members, managers, and executives.
InfoQ: How can your book help professionals become better in training or coaching agile teams?
To help organizations succeed with Agile, trainers and coaches need to be prepared to address the full organizational value chain. Training and coaching just the technical people frequently does not lead to the desired organizational benefits of using Agile. I wrote the Essential Scrum book for all team members, managers, and executives. So it is not a book specifically for product owners, or Scrum Masters, or members of the development team. Instead, it is a book intended to give everyone involved with Scrum, from all the members of the Scrum team to those with whom they interact in the organization, a common understanding of Scrum based on a core set of concepts with a clear vocabulary for discussing them. With this shared foundation my hope is that trainers and coaches can help organizations more successfully use Scrum to deliver business value.
One unique aspect of the book that has great appeal to trainers and coaches in the new Visual AGILExicon™ (pronounced visual agile lexicon) a language for describing and communicating core agile and Scrum concepts in a graphically rich and visually appealing manner. The Visual AGILExicon was used to create many of the over 200 pictures in the book (see the image for an example). Trainers and coaches can use the Visual AGILExicon to promote agile through the value chain.
InfoQ: You state in your book that "idle work is far more wasteful and economically damaging than idle workers." Can you explain that? Do you have an example of it?
Work frequently sits idle when we are blocked waiting for another team or when we have too many things to work on at once. When work is idle we are not advancing towards our goal of shipping value to our customers. There is a cost associated with delaying the delivery of value and that cost must be quantified to understand the true economic consequences of idle work. For example, the next release of a product might generate $200k/month in revenue. So if idle work delays putting the product into the marketplace by two months, the costs of that idle work would be $400k.
An idle worker, a person not current 100% utilized, appears wasteful. For example, if we pay a developer a salary of $100k/year (fully burdened) and that person is only 80% utilized, then we might conclude that we are experiencing a $20k (20%) under-utilization waste. In this example a 20% idle worker has an economic consequence of $20k. Delaying the shipment of a product by two months due to idle work has an economic consequence of $400k.
What’s really interesting is that idle work and idle workers are paradoxically interwoven. Consider this. In an attempt to keep people busy (eliminate idle workers) companies frequently have people work on multiple concurrent projects to achieve 100% utilization. The result of multitasking across a number of different work items frequently extends the time to complete each work item, therefore introducing delay into ALL of the work items. As a result, we end up eliminating one form of waste (idle workers) and increasing another form of waste (idle work across all of the projects). Since the cost of delay from idle work is frequently much more expensive than having a little slack in the system, we realize that most organizations are focused on eliminating the wrong form of waste. We should organize the value-delivery system to minimize idle work even if that means we experience some idle-worker waste.
InfoQ: You describe different kinds of technical debt in Essential Scrum: naive technical debt, unavoidable technical debt and strategic technical debt. Which one creates the biggest losses in a company? And what can they do to reduce it?
The issue of “larger loss” is not specifically related to how the debt was accrued, but instead the economics of the specific debt. To explain this, let me first define my terms.
I use this taxonomy to distinguish how technical debt might come into existence, not to distinguish high-loss versus low-loss debt. The economic consequences of technical debt have to be evaluated on a case-by-case basis. For example, we might choose to accrue strategic debt if we feel that the benefits of faster time-to-market far exceed the cost of the debt we accrue to go faster. In other words, if we take on strategic debt we are expecting a net benefit, not a net loss. If we have accrued debt, by whatever means, we need to decide how to service it. First we must acknowledge that not all debt is equal in terms of its economic impact and therefore how it should be managed. For example, we pay a higher ‘interest rate’ on debt in code that we frequently modify versus code that we rarely if ever touch and is not likely to experience a significant failure. A simple analog is the difference between the 18% credit card debt and the 6% home mortgage debt. Unless there are extenuating circumstance, any reasonable person would payoff the high-interest credit card debt before the low-interest mortgage debt. When managing technical debt it is important to identify the high-interest debt and reduce that first.
- Naive debt is a form of technical debt that accrues due to irresponsible behavior or immature practices on the part of the people involved.
- Unavoidable debt is a form of technical debt that is usually unpredictable and unpreventable and accrues through no fault of the team building the product.
- Strategic debt is a form of technical debt that is used as a tool to help organizations better quantify and leverage the economics of important, often time-sensitive, decisions.
Paying off high-interest debt first is one of several debt-servicing strategies I discuss the Essential Scrum book. Another is to apply the Boy Scout rule of always leaving the campground a litter cleaner than you found it (service technical debt when you encounter it in the code you are modifying and leave the code a little cleaner than you found it). We should also repay technical debt incrementally while performing customer-valuable work. By doing so we typically avoid the need for the product owner to sequence technical-debt reduction work in the product backlog since debt servicing will take place with the work associated with every product backlog item.
InfoQ: In Essential Scrum you make the connection between Scrum and Lean Startup. For instance you mention that "If further investment in a product is not economically justified, we should decide whether to preserve, deliver, pivot or terminate the product". Can you elaborate on this?
The specific sentence you are referring to is in the Essential Scrum chapter on portfolio planning. This is just one of many places where Scrum and Lean Startup are well aligned. At is core, both Scrum and Lean Startup focus on what Lean Startup refers to as validated learning. Validated learning describes the progress made when important assumptions have been confirmed or refuted by subjecting each assumption to one or more customer validation tests. We acquire validated learning when we obtain knowledge that confirms or refutes an assumption that we have made. In the Essential Scrum book I illustrate how validated learning is a good way to describe three core agile principles.In the book I show how these principles apply to the various levels of planning (portfolio, product, release, and sprint). Now let me address the portfolio planning issue of deciding when to preserve, deliver, pivot, or terminate a product. Just because we agree to work on a product or project doesn’t mean we should finish it. We should periodically and frequently (perhaps every sprint) review our validated learnings on the product and decide if we are progressing towards an economically sensible solution (in Lean Startup this would be measured through innovation accounting). If the evidence shows we are building something of value, and the marginal economics of performing the next sprint (or other unit of work) look favorable, we should preserve.
- Validate important assumptions fast. Letting an important assumption go unvalidated for a long time can have significant economic consequences because we create many artifacts on top of what might be a wrong assumption.
- Leverage multiple concurrent learning loops. In Scrum we have daily, sprint, and release learning loops. In each loop we sequence through the steps of: assume, build, feedback, inspect, and adapt.
- Organize the flow of work for fast feedback by specifically sequencing the work to acquire validated learning quickly.
If we conclude that the marginal economics of the next expenditure are unfavorable, we have three options: deliver, pivot, or terminate. If the economics of continuing are unfavorable and we have produced a minimum viable product (Lean Startup MVP), we should consider delivering what we have. If the economics are unfavorable down the current path and we don’t yet have an MVP, but we believe there is an alternative path to a viable product, we could pivot to that path. Finally, if no such pivot is reasonable, we can choose to terminate the product-development effort and cut our losses (hopefully we found out early that what we were pursuing was not viable).
InfoQ: The book describes that you can also have a product owner team. Are there certain situations where this would be a viable solutions? And situations where you would not recommend this solution?
Before we discuss the concept of a product owner team, let’s make sure we are clear on the product owner role within Scrum. Every Scrum team must have a single person who is identified as the product owner and is the only person empowered and accountable for fulfilling the product-owner responsibilities for that Scrum team. Okay, having said that, should we ever allow a team of people to perform the product owner role? Not if a group of people would have shared decision making and accountability. To properly apply Scrum, we need one individual to be the product owner, making decisions and acting as the single voice of the stakeholder communities to the Scrum team. Now for a variety of reasons some organizations might form what they call a “product owner team.” For example, in cases where a single individual cannot do the job without a select group of people like subject matter experts, UI designers, architects providing input and guidance. This is almost always the case since a product owner doesn’t operate in a vacuum.
Another scenario is when the workload of being a product owner is greater than any one full-time person can reasonably perform. In this case, the product owner delegates some product-owner responsibilities to other people. One obvious example of this is on very large development efforts. We might have the same person be the product owner for a few Scrum teams, but what about efforts that involve many Scrum teams? Certainly one person cannot be the product owner for tens of teams. In such cases a product owner team is formed where there is a hierarchy of “product owners” that ultimately report to one “chief product owner” who has the overall responsibility for the full product being built.
Forming a product owner teams in these circumstances is acceptable as long as there is one person on the team who is the ultimate decision maker and as long as having a product owner team does not degrade into design by committee, with every decision needing approval from a lot of other people. I will point out that I have frequently seen product owner teams created for the wrong reasons. For example, product owners who are not properly skilled to be the empowered central point of product leadership don’t need a committee—they need a different role. Similarly, product owners who are too busy to fulfill their responsibilities might not need a team. Perhaps the real problem is that the organization has chosen to start too many development efforts at one time, or there are just too few product owners to cover the necessary products.
InfoQ: In your experience, what is the most challenging part of Scrum for organizations to implement? Why?
Scrum is a tool that helps expose the dysfunctions that plague organizations. Some organizations have no appetite for addressing these dysfunctions and actually become quite uncomfortable having a bright light shone on their problems. These companies are likely to adjust the (Scrum) light to obscure the problems rather than address them head on. Organizations that are poised to be successful with Scrum are prepared to face the brutal facts head on and address their impediments.
About The Book Author
Kenny Rubin is Managing Principal at Innolution, LLC, an agile training and coaching company that helps organizations develop products in an effective and economically sensible way. A Certified Scrum Trainer, Rubin has trained over 18,000 people on agile and Scrum, Smalltalk development, managing object-oriented projects, and transition management. He has coached over 200 companies, ranging from start-ups to Fortune 10.
Rubin was the first managing director of the worldwide Scrum Alliance, a nonprofit organization focused on the successful adoption of Scrum. In addition to authoring the book Essential Scrum: A Practical Guide to the Most Popular Agile Process, he is also the coauthor of the 1995 book Succeeding with Objects: Decision Frameworks for Project Management. Learn about his background at: http://www.innolution.com and follow him on his blog at the same site. Follow him on Twitter using @krubinagile
/filters:no_upscale()/articles/essential-scrum/en/resources/fig1large.jpg){kind=link}