Book Image

The Professional ScrumMaster's Handbook

By : Stacia Viscardi
Book Image

The Professional ScrumMaster's Handbook

By: Stacia Viscardi

Overview of this book

A natural and difficult tension exists between a project team (supply) and its customer (demand); a professional ScrumMaster relaxes this tension using the Scrum framework so that the team arrives at the best possible outcome."The Professional ScrumMaster's Handbook" is a practical, no-nonsense guide to helping you become an inspiring and effective ScrumMaster known for getting results.This book goes into great detail about why it seems like you're fighting traditional management culture every step of the way. You will explore the three roles of Scrum and how, working in harmony, they can deliver a product in the leanest way possible. You'll understand that even though there is no room for a project manager in Scrum, there are certain “management” aspects you should be familiar with to help you along the way. Getting a team to manage itself and take responsibility is no easy feat; this book will show you how to earn trust by displaying it and inspiring courage in a team every day."The Professional ScrumMaster's Handbook" will challenge you to dig deep within yourself to improve your mindset, practices, and values in order to build and support the very best agile teams.
Table of Contents (22 chapters)
The Professional ScrumMaster's Handbook
Credits
Foreword
About the Author
Acknowledgment
About the Reviewers
www.PacktPub.com
Preface
Index

Dysfunctions or true constraints?


Scrum is based on the lean concept of turning an idea into a feature as efficiently as possible. The Scrum framework is designed to surface obstacles that get in the way of delivering value. The game rules of Scrum are in place to protect the team from chaos so that they may finish their commitments for the customer by the end of a given sprint.

Because of the short cycle time and the relentless pursuit of identifying obstacles, there seems to be a never-ending list of challenges that the ScrumMaster needs to fix. The team surfaces—on a daily basis—any interruptions or impediments to their work. The product owner and other stakeholders inspect the product in the sprint review, which frequently leads to adaptations in product backlog and thus the evolution of the product. Finally, the retrospective provides time for the team to focus on process improvements so that the experience is smoother in the future. In conclusion, there are three built-in mechanisms in the Scrum framework for discovering obstacles. As they say in Texas, "If you go hunting for trouble, you'll sure find it." Scrum can feel very challenging because of what it brings to the surface.

So how do we handle these tough challenges as ScrumMasters? We have to ask ourselves: is this issue/challenge/hardship a constraint within our organization or is it a dysfunction? An example of a true constraint would be a document that must be written for U.S. Food and Drug Administration (FDA) compliance. The team mentioned it in retrospective because they think it's wasteful, but the product won't make it to market if it doesn't achieve FDA compliance. Therefore, it's a true constraint that must be worked around.

On the other hand, let's say that a team member mentions in the retrospective that he is being pulled away from the team to work on another project for a different manager. Is this a constraint? Maybe. But perhaps it's a dysfunction. Why? Well, Scrum says that team members are dedicated so that they can focus on and finish the functionality they've committed to implement. When a team member gets pulled onto another initiative, this makes for an unhappy developer who now must multitask and probably feels inadequate because the workload is too much to bear. It is likely that he or she won't finish either of the teams, commitments. Without finishing features, it's impossible to inspect and adapt, which breaks the benefit of empirical process control. This scenario is simply not acceptable; team members are not to be pulled from their teams. In this case, the ScrumMaster should alert the product owner that the developer's commitments are now in jeopardy. The situation may have to be escalated to managers to put a stop to this behavior. Eventually, team members must learn to say no, but that is not likely to happen in the beginning.