What do you think?
Rate this book
Exploring Scrum: the Fundamentals: People, Product, and Practices
Are you a software developer? Do you manage software developers? Are you using scrum? Are you thinking of using scrum? Then you must have this book!
Scrum is the most popular agile software development process in use today, but implementing it has proven difficult for many people. Dan and Doug wrote this book in order to help people with their implementations of Scrum.
Both Dan and Doug have trained and coached thousands of people, most of whom are already using Scrum. In spite of the fact that they have read about Scrum, have been trained or coached in Scrum, and are using Scrum, their most common complaint is that they need help to do it right. And, Dan and Doug have found, many (if not most) of them need some help.
This book is for them and others like them.
This book explores the fundamentals of Scrum when developing software. At its core, Scrum is a simple development framework allowing a single, co-located, cross-functional, self-organizing Team to build high-quality software in an incremental, agile manner. This book focuses on this simple, constrained view of Scrum because organizations that can’t do at least this much successfully have no business trying to do Scrum on a larger scale.
This book is not an introductory text. Dan and Doug assume that those who read this book know, or think they know, something about Scrum. This book takes a deep, exploratory, look into the Scrum framework, and offers advice about how to use it. Some of this advice is philosophical, some is pragmatic, some is practical, and some of it is controversial.
The controversies happen because Dan and Doug are brutally consistent and true to the essence of Scrum. This book is not the result of an academic exercise; every suggestion or conclusion in this book is grounded in real-life issues they have encountered, and suggestions that they have made for teams and people they have coached or trained. This book contains both pragmatic advice and the philosophical underpinnings justifying that advice.
Scrum is a development framework that is very demanding of its adherents. Scrum is easy to understand, but doing it successfully (one might even say ‘right’) is very difficult. Scrum requires a mental shift in the way people think of the relationships between People, Product, and Practices. It requires changes in ‘process personality’ – especially changes about how people think of themselves as members of a team, and how they think of their product and its production. Some of the beliefs that Scrum requires are:
- A preference for People over Practices; understanding that solving complex problems requires brainpower, not recipes;
- An understanding that the best Products are developed by having a Focus on User’s Needs rather than relying on a requirements document;
- The acceptance that Reality Trumps Expectations, so when reality and expectations don’t match, it is the expectations that must change;
- The preference for Self-Organizing Teams over either lone-wolf-ism or tightly controlled management; and
- The realization that each of us is part of a ‘Team developing Product’ and that we are not simply ‘People doing Work.’
Scrum’s ‘out of the box’ process is just good enough to allow Teams, Organizations, and Individuals to develop software successfully while their ‘process personalities’ are maturing and becoming more scrummish. Once their personalities have changed, then they can adapt Scrum for their own situations and realities. This book focuses on helping you become more scrummish and discusses some of the adaptations you will make as you mature.
Scrum is the most popular agile software development process in use today, but implementing it has proven difficult for many people. Dan and Doug wrote this book in order to help people with their implementations of Scrum.
Both Dan and Doug have trained and coached thousands of people, most of whom are already using Scrum. In spite of the fact that they have read about Scrum, have been trained or coached in Scrum, and are using Scrum, their most common complaint is that they need help to do it right. And, Dan and Doug have found, many (if not most) of them need some help.
This book is for them and others like them.
This book explores the fundamentals of Scrum when developing software. At its core, Scrum is a simple development framework allowing a single, co-located, cross-functional, self-organizing Team to build high-quality software in an incremental, agile manner. This book focuses on this simple, constrained view of Scrum because organizations that can’t do at least this much successfully have no business trying to do Scrum on a larger scale.
This book is not an introductory text. Dan and Doug assume that those who read this book know, or think they know, something about Scrum. This book takes a deep, exploratory, look into the Scrum framework, and offers advice about how to use it. Some of this advice is philosophical, some is pragmatic, some is practical, and some of it is controversial.
The controversies happen because Dan and Doug are brutally consistent and true to the essence of Scrum. This book is not the result of an academic exercise; every suggestion or conclusion in this book is grounded in real-life issues they have encountered, and suggestions that they have made for teams and people they have coached or trained. This book contains both pragmatic advice and the philosophical underpinnings justifying that advice.
Scrum is a development framework that is very demanding of its adherents. Scrum is easy to understand, but doing it successfully (one might even say ‘right’) is very difficult. Scrum requires a mental shift in the way people think of the relationships between People, Product, and Practices. It requires changes in ‘process personality’ – especially changes about how people think of themselves as members of a team, and how they think of their product and its production. Some of the beliefs that Scrum requires are:
- A preference for People over Practices; understanding that solving complex problems requires brainpower, not recipes;
- An understanding that the best Products are developed by having a Focus on User’s Needs rather than relying on a requirements document;
- The acceptance that Reality Trumps Expectations, so when reality and expectations don’t match, it is the expectations that must change;
- The preference for Self-Organizing Teams over either lone-wolf-ism or tightly controlled management; and
- The realization that each of us is part of a ‘Team developing Product’ and that we are not simply ‘People doing Work.’
Scrum’s ‘out of the box’ process is just good enough to allow Teams, Organizations, and Individuals to develop software successfully while their ‘process personalities’ are maturing and becoming more scrummish. Once their personalities have changed, then they can adapt Scrum for their own situations and realities. This book focuses on helping you become more scrummish and discusses some of the adaptations you will make as you mature.
Kindle Edition
First published July 21, 2011
27 people are currently reading
110 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 2 of 2 reviews
August 2, 2011
When I work with people about to start their transition to Scrum, I always ask what they've read. Up until now, I struggled with what to suggest that would help them see how to live the Scrum principles and practices. Now I know. The answer is this book, Exploring Scrum: The Fundamentals (People, Product, and Practices).
There is no theory here. No sir. This is a book that arises from hard-won experience. That deep experience, all those years of teaching and coaching and consulting Scrum teams shines through, and provides the substantial value that Dan and Doug bring you.
For example, many project managers have accountability for project results, and Exploring Scrum explains why a project manager can then not be a Scrum Master and should be a product owner. The rest of the discussion of the multiple modes of Scrum Master and Scrum Master as change agent are brilliant.
Another example of the practical approach is the issue of feedback as the output of the sprint. Scrum suggests that the team produce potentially releaseable product each sprint. Many teams interpret that to mean that they always have to produce running tested features. But sometimes, you want feedback about the potential deliverables, such as the user interface or the performance of the system or the security or something like that.
Teams new to Scrum have trouble with determining how many stories they can plan to complete in an sprint and how to manage the work that isn't stories. Dan and Doug have a great solution here. They suggest that for a 2-week sprint, a team plan on about 10 stories. That's a great target because it helps teams realize when they have sliced their stories thin enough. And, because not all work is stories, they suggest that is enabling work for the team is called "Chores," and that the team expect to spend about 30% of their time on Chores. That's a great guideline for teams and for Product Owners.
I loved this book. I'm a sucker for books where the authors have put their hearts and souls into their books and have said to the reader, "Here's everything I know. Read it. Please. Use it. Do it. If you do it this way, you will succeed. I know you will." You will, too.
There is no theory here. No sir. This is a book that arises from hard-won experience. That deep experience, all those years of teaching and coaching and consulting Scrum teams shines through, and provides the substantial value that Dan and Doug bring you.
For example, many project managers have accountability for project results, and Exploring Scrum explains why a project manager can then not be a Scrum Master and should be a product owner. The rest of the discussion of the multiple modes of Scrum Master and Scrum Master as change agent are brilliant.
Another example of the practical approach is the issue of feedback as the output of the sprint. Scrum suggests that the team produce potentially releaseable product each sprint. Many teams interpret that to mean that they always have to produce running tested features. But sometimes, you want feedback about the potential deliverables, such as the user interface or the performance of the system or the security or something like that.
Teams new to Scrum have trouble with determining how many stories they can plan to complete in an sprint and how to manage the work that isn't stories. Dan and Doug have a great solution here. They suggest that for a 2-week sprint, a team plan on about 10 stories. That's a great target because it helps teams realize when they have sliced their stories thin enough. And, because not all work is stories, they suggest that is enabling work for the team is called "Chores," and that the team expect to spend about 30% of their time on Chores. That's a great guideline for teams and for Product Owners.
I loved this book. I'm a sucker for books where the authors have put their hearts and souls into their books and have said to the reader, "Here's everything I know. Read it. Please. Use it. Do it. If you do it this way, you will succeed. I know you will." You will, too.
April 16, 2017
This is a great book and definitely a reference on the topic! It is well written and structured, explanations and examples are easy to follow, and the authors are very knowledgeable. It is perfect for beginners or intermediate level scrum/agile enthusiasts, but even advanced practitioners should know and read this book.
Displaying 1 - 2 of 2 reviews