News Stay informed about the latest enterprise technology news and product updates.

Adapting a Scrum framework in the real world: An interview with Mitch Lacey

In his new book, “The Scrum Field Guide - Practical Advice for Your First Year,” Mitch Lacey describes real world examples of Scrum transition efforts and challenges.

Scrum, a lightweight Agile framework designed for managing software development, seems simple enough. Yet in actuality, it is often quite difficult to implement. In his new book, The Scrum Field Guide - Practical Advice for Your First Year, author Mitch Lacey shows those who are in transition how to overcome some of the most common challenges.

SSQ: Mitch, each chapter starts with a case study of sorts that describes a challenge being experienced in Agile transition. You then follow with advice on how the Scrum framework and Agile practices can be used to help address the issues. Other than name changes, are these all true stories?

Mitch Lacey: Every last one of these stories is true. If it were not for those experiences, I would not have this book today. What is funny is the people that lived these stories have started emailing me saying, “Hey, I remember that!” It’s been a nice way to reconnect.

SSQ: As the book describes, real life is quite different from the ideal circumstances that are often described in text books. In these examples, were you able to coach the teams and see progress in Agile adoption?

Lacey: Most of the stories happened on teams I was on—not on teams I’ve coached. We struggled a bit here and there but mostly got through it because we understood why we were doing what we were doing. But, yes, I’m able to coach most teams through similar situations. The teams that don’t make it tend to fail because they never understand the why aspect of Agile. They take it as just another process and churn through it without thinking.

SSQ: Let’s talk about the first chapter, “Scrum: Simple, Not Easy.” The story is about a team that is new to Scrum and has taken liberties in quite a few areas. One of their issues is that the testers feel they have no time to test. It appears that the recommended answer to this is to test first using test-driven development (TDD). However, very often testers do not have a programming background or coding skills. How do you suggest handling this?

Lacey: Testers should be involved in the sprint from beginning to end. Sometimes that means test-driven design, sometimes that means sitting with a programmer and “pairing,” writing some tests as the code comes together. There is always work to do, and organizations should take a team-first approach, not a role-first approach.

SSQ: The development team in Scrum, as described on pages 358-359, “is comprised of the people needed to deliver the work – developers, testers, architects, designers – anyone who is needed,” and is ideally made up of a max of nine people (though your advices is six, plus or minus two.) If you count all the roles of traditional software teams, that would also include business analysts, operations, technical writers. How can you make sure everyone is staying in the loop and keep your teams that small?

Lacey: First, I use the Team Consultant model described in Chapter 3. Next, the product owner should be communicating with all stakeholders on a regular basis, as should the team. Take operations for instance. In one project I ran a few years back, operations was one of our biggest stakeholders. They essentially owned our fate. They had been burned by teams in our group in the past and were, well, skeptical of us. We realized early that in order to be successful, we need the operations team to feel safe.

As the product owner, I said to them that I wanted to release at least once a week. They laughed, said some words that I won’t repeat and escorted me out of the NOC. A few days later one guy came back and asked if I was serious about releasing that often. I said I was and I asked him what we needed to do to make it happen. We spent a few hours determining what was needed and I put those stories right at the top of the product backlog. They were involved during the development and, at the end of the project, we were releasing hourly if we wanted to. Compare that with other teams in our group who could not release twice a year and we were doing it hourly. It’s just good common sense to keep people involved, to communicate often and to be proactive.

In part two of this interview, Lacey answers questions about combining Scrum with XP or Kanban and reveals the biggest takeaway readers will get from his book.

This Q&A is based on the book, The Scrum Field Guide: Practical Advice for Your First Year, authored by Mitch Lacey, published by Pearson/Addison-Wesley Professional, March 2012, ISBN 0321554159. For more info, please visit the publisher site: For promo, see this site.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.