The book The Scrum Field Guide - 2nd Edition by Mitch Lacey, a "what to expect" book for organizations transitioning to agile, aims to help teams to deal with commonly occuring issues and to fine-tune their own agile implementations.
InfoQ readers can download a sample of the book Scrum Field Guide.
InfoQ interviewed Lacey about what has changed in the second edition of the book, the essentials of Scrum, factors that influence sprint length, why he advocates to have full time Scrum masters, how teams can make time available for solving defects, dealing with legacy issues, or reducing their technical debt, why teams should do retrospectives, what companies can do to prevent bad hires, and advice for increasing benefits from working with Scrum.
InfoQ: What made you decide to publish a second edition of the Scrum field guide?
Lacey: Over time, I find that things change. Not only in how I approach Scrum and agile, but also in how companies have evolved in the last few years. I had several new techniques I wanted to share, such as my approach to hiring, and I also wanted to follow up on and even revise other sections. Basically, I wanted to refactor the existing content and bring new concepts and ideas to market.
InfoQ: For those who have read the first edition, can you describe what is new and what has changed in this edition?
Lacey: New information is available throughout the book. Although some of the original chapters have changed only 10%, others have changed 80% or more. One example that springs to mind is Chapter 11, “Release Planning”—I heavily revised that chapter to better convey my original concept and also to incorporate feedback and learning since the first release.
The second edition also contains 5 new chapters, 31-35, which cover topics that I have been experimenting with since the release of the first edition. Chapter 31, “Driving to Done through Collaboration,” is a story of a team who did everything by specialty versus collaboratively as a team. This chapter introduces a task estimation technique I call Task Poker, which is very similar to planning poker with a few twists. Chapter 32, “How Story Points Relate to Hours,” describes one of those dangerous practices I’ve seen in which some well-meaning but uninformed manager somewhere believes that X points = Y hours. I wanted to make very clear that there is no direct correlation between points and hours to help prevent future managers from making that mistake. Chapter 33, “Immersive Interviewing and Hiring,” is the result of many experiments I’ve run at companies around the world on how to change interview practices. Some of this was shared in a 2013 talk I gave at the ALM Summit at Microsoft with my friend Jonathan Wanagel (Technical Interviewing - You're Doing it Wrong). Chapter 34, “Aligning Incentives with Outcomes,” comes from an experience in 2008. I was working on a project that was sold by the sales team to win the business but created a lot of pain for the development team. We shifted to align not only the sales folks, but also account management and leadership to an agile way of thinking. Chapter 35, “Risk Management in Scrum,” comes directly from my experience of watching project managers struggle with letting go of risk management and trusting people to take on that accountability to own various risks in projects.
InfoQ: What's the intended audience for this book? Why did you pick this audience?
Lacey: The intended audience is anyone or any team who is struggling with the growing pains that transitioning to an agile process like Scrum inevitably causes. In the book, I liken it to being a first-time parent, where you struggle to understand whether what you are experiencing and worrying about with your child is normal or not. I mean, whole books have been written about the transition from non-parent to parent, including What to Expect the First Year.
The thing is, when we encounter a new situation, knowing that others are experiencing the same pain, the same struggles, and the same misunderstandings as we are is very comforting to people. This book is kind of a what to expect book for the first year (and even beyond) of Scrum and XP.
The problem is, unlike a what to expect book, I can’t tell you exactly what your team should be doing or worrying about during months 1 to 3 or 9 to 12. Teams, unlike most children, don’t develop at a predictable rate. Instead, they often tumble, stumble, and bumble their way through their first year, taking two steps forward and one step back as they learn to function as a team, adopt agile engineering practices, build trust with their customers, and work in an incremental and iterative fashion.
That’s why I chose to structure this book with more of an “I’ve got a pain here, what should I do?” approach. When your team is hurting or in trouble, you can turn to the chapter that most closely matches your symptoms and find, if not a cure, at least a way to relieve the pain.
The Scrum Field Guide, Second Edition, is meant to help teams fine-tune their own implementation, navigate some of the unfamiliar terrain, and more easily scale the hurdles we all encounter along the way.
InfoQ: What are the essentials of Scrum, what do teams need to focus on when they want to be successful with Scrum?
Lacey: The key to Scrum is buying into the concept of development through inspection and adaption. Teams will have to get used to developing potentially shippable software inside a short time box, and working outside their own silos to get the work done. Former project managers have to learn to let go of their so-called control (which they never really had anyway) and trust the team to self-organize to complete the project successfully. Stakeholders and product owners have to learn the hard lessons of prioritization and compromise. ScrumMasters will have to learn to lead without authority and learn to be somewhat political in their negotiations on behalf of the team. The secret to success is different for every team and every situation, but it all comes down to understanding the principles behind why they are doing daily scrums or sprint reviews or working in iterations in the first place.
InfoQ: Can you elaborate on the factors that influence sprint length?
Lacey: As I mention in the book, there is no one-size-fits-all, magic bullet for determining a sprint length that works well for every team. The only “rule” is that the sprint can’t be more than one month. In the end, choosing the right sprint length is about determining an appropriate stimulus-to-response cycle. And the factors that help you determine the appropriate stimulus-to-response time are varied and include the expected duration of the project, your customers’ or stakeholders’ availability and their familiarity with an agile way of working, and the team’s experience with Scrum and agile technical practices such as TDD and continuous integration.
One big factor to keep in mind is how long your project is expected to take. A 3-month project that is broken into monthly sprints is not a good idea—you’ll only have 2 sprint reviews to listen to feedback and make adjustments to the completed and planned work. On the other hand, monthly sprints on a year-long project give you almost 11 opportunities to inspect and adapt what you are building.
The more feedback you have, the better able you will be to tolerate risk. Shorter sprints enable you to identify potential risks sooner but come with a cost of increased customer interaction and more interruptions for the team. Longer sprints mean that it will take longer to find the risks but have the benefit of fewer interaction points and interruptions. Balancing feedback with interaction and disruptions is a challenge that your team and customer will perfect over time.
InfoQ: In your book you advocate to have a full time ScrumMaster for a team. When teams are new to Scrum there's a lot to learn and improve, but what about experienced, mature teams; would they still need a full time ScrumMaster?
Lacey: Even experienced, mature teams can benefit from a full-time ScrumMaster to some degree, but as I mention in the book, a good ScrumMaster should strive to work himself out of a job by creating a high-performing team. For some, this may be impossible to achieve, but it should always be the goal.
If your team is truly so high-performing that it doesn’t need a full-time ScrumMaster, I recommend transitioning to a full-time ScrumMaster whose time is split between multiple teams. That way the experienced teams still have access to a coach, but your experienced ScrumMaster is also available to help new or struggling teams. Believe me, the Denver Broncos aren’t going to fire their coach now that they’ve won the Super Bowl… So don’t be too hasty in believing you have no need for a full-time ScrumMaster.
InfoQ: Do you have suggestions how teams should make time available for solving defects, dealing with legacy issues, or reducing their technical debt?
Lacey: Here’s an excellent example about how my understanding of Scrum and agile continues to evolve even after all these years. Just after the second edition went to print, I had a conversation with a friend of mine, Bill Hanlon, who suggested that my approach to fixing bugs could be improved. His idea? Fix every bug when it’s found or decide not to fix it at all, no exceptions.
Now, I have always advocated fixing high-priority bugs in real time but I have always suggested that teams put lower priority bugs on the backlog to fix later. But after trying Bill’s “fix it or forget it” approach with a client and seeing the results, I’ve changed my mind.
So here’s my new stand on this issue. Don’t put bugs on the product backlog. Just fix them, or mark them as won’t fix. Not only does the average bug age go down with this approach, the team delivers higher quality code, faster.
Using Bill’s approach has fixed one of the biggest issues I’ve had with teams over the years: The debate over the quality of new feature development. Having the ability to file a bug and have it on the product backlog means there is a way to deprioritize quality by moving bugs farther down the product backlog, and instead focusing on delivering stories. It just creates extra work for the team to triage, and keeps the debate of quality versus new stories/features alive. That’s a debate I’m tired of having. Bill’s approach eliminates that conversation altogether.
You can read more about it in Managing Bugs in Scrum and Agile Projects
InfoQ: How can teams convince their product owner that they have to invest time in this kind of work over finishing user stories?
Lacey: Once you start to collect the data, the decision becomes fairly obvious. Going back to my friend Bill’s approach--Bill found that fixing bugs in real time and abandoning a traditional bug tracking system made his teams so much faster than his peer teams that his manager took notice and started implementing it with all her teams. And the average bug age also was significantly lower. In my experience, all the metrics support real-time bug fixing—you just have to start measuring it.
InfoQ: One of the keys to success for retrospectives is to "show the why". Can you elaborate what you mean with this, and how it can be done?
Lacey: New Scrum teams sometimes drop retrospectives because they fail to understand the purpose of the meetings—the why. Retrospectives are a time to inspect and adapt the process—to purposefully look for opportunities to improve, to produce a higher quality product more quickly, to better understand customers’ needs, to work together more effectively. Skipping this step is like failing to brush your teeth every day—you might save a little time but you’ll soon have a mouth full of decay. Eliminating retrospectives makes it far too easy for the team to lose sight of becoming high performing and just go through the motions of “doing Scrum.”
InfoQ: Do you have some suggestions what companies can do to prevent bad hires?
Lacey: The most important thing to do is to screen for the correct attributes when hiring. Too often, hiring managers focus on candidate’s skills without regard for their abilities—their willingness to work as part of a team, their tolerance for constructive feedback. In my opinion, that’s totally backwards. It’s so much easier for me to take a good team member who is open to feedback and teach him a new programming language than to start with someone who knows C# but hates working in a shared team space or thinks TDD is a waste of his time. Chapter 33 goes into great detail on how to structure interviews to screen candidates for these important—but often hard to detect—abilities.
InfoQ: Which advice do you want to give to organizations that would like to increase their benefits from working with Scrum?
Lacey: As I say in the book, Scrum is elegantly deceptive. It is one of the easiest frameworks to understand yet one of the hardest frameworks to implement well. I say “implement well” because Scrum’s inherent simplicity can seduce teams into thinking it is easy to do, when in reality it can take years to do it well. Scrum seems to go against the common wisdom acquired through many, many years of waterfall development. Therefore, it stands to reason that it will take a while to unlearn bad habits and adjust to a new reality. Give teams that time.
The second thing I’d say is don’t assume that because a practice is hard to adopt that it won’t work for your team. Believe me when I say that every team thinks it is the exception to the rule—that Scrum can’t work for them. And those same teams learn, when they really give Scrum a chance, that the pain they are experiencing with Scrum has been there all along—buried perhaps, but there nonetheless.
That’s why I believe that having a coach or a mentor is essential in the early stages of an agile adoption. It’s like the difference between trying to exercise on your own and hiring a personal trainer. You need someone to hold you accountable, to check your form, to motivate you on those days when the old habits feel so much easier than learning new ways. Without a mentor/personal trainer serious injury can occur which can cause people to stop exercising or teams to quit agile.
So I guess that’s three things: Be patient. Be persistent. Be willing to accept help from someone who can remind you that what you are experiencing is normal and that, given time, you and your team will survive and thrive with Scrum.
About the Interviewee
Mitch Lacey is an agile practitioner and trainer and author of the popular book, "The Scrum Field Guide, Agile Advice for Your First Year and Beyond." With over 10 years of Agile experience, and 18+ years managing projects, Mitch's well rounded approach is suitable to any business. Companies that trust Mitch for his knowledge include Microsoft, Oracle, Bio-Rad, Costco, DemonWare, Morningstar, Qualcomm, Salem Health, SAP and more. As a Certified Scrum Trainer (CST), PMI Project Management Professional (PMP) and Agile Certified Practitioner (ACP), Mitch shares his experience in project and client management through Scrum Alliance Certified Scrum courses, agile coaching engagements, conference presentations, blogs & white papers.
