Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
The Professional ScrumMaster's Handbook

You're reading from   The Professional ScrumMaster's Handbook A collection of tips, tricks, and war stories to help the professional ScrumMaster break the chains of traditional organization and management

Arrow left icon
Product type Paperback
Published in Apr 2013
Publisher Packt
ISBN-13 9781849688024
Length 336 pages
Edition 1st Edition
Concepts
Arrow right icon
Author (1):
Arrow left icon
Stacia Viscardi Stacia Viscardi
Author Profile Icon Stacia Viscardi
Stacia Viscardi
Arrow right icon
View More author details
Toc

Table of Contents (22) Chapters Close

The Professional ScrumMaster's Handbook
Credits
Foreword
About the Author
Acknowledgment
About the Reviewers
www.PacktPub.com
Preface
1. Scrum – A Brief Review of the Basics (and a Few Interesting Tidbits) FREE CHAPTER 2. Release Planning – Tuning Product Development 3. Sprint Planning – Fine-tune the Sprint Commitment 4. Sprint! Visible, Collaborative, and Meaningful Work 5. The End? Improving Product and Process One Bite at a Time 6. The Criticality of Real-time Information 7. Scrum Values Expose Fear, Dysfunction, and Waste 8. Everyday Leadership for the ScrumMaster and Team 9. Shaping the Agile Organization 10. Scrum – Large and Small 11. Scrum and the Future The ScrumMaster's Responsibilities ScrumMaster's Workshop 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.

You have been reading a chapter from
The Professional ScrumMaster's Handbook
Published in: Apr 2013
Publisher: Packt
ISBN-13: 9781849688024
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image