You need more than a whistle to coach an Agile team.
Rachel Davies and Liz Sedley are recognized experts on Agile coaching. The release of Agile Coaching, their definitive book on the subject, inspired this interview with these two coaches.
ms: Shall we start by defining our terms? Maybe you should tell us what an Agile coach is, and what one does in carrying out the role of an Agile coach.
ac: Sure. An Agile coach works with software development teams to help them improve their performance and get the benefits of applying Agile principles to their work. The way we do this is by guiding the team to become more aware of their workflow and of ways to collaborate more effectively. An effective coach brings to the team knowledge of how to apply Agile techniques, and should be able to help a team acquire competence in Agile techniques.
ms: Can a project manager also be the Agile coach for the team?
ac: One can, yes. A coach has to serve the team and be available to all team members. Some are player-coaches and take on a team role, like developer or project manager. But you may find that taking on responsibility for project deliverables distracts you from coaching your team.
ms: Are there specific skills or personal traits that are necessary or desirable for a coach?
ac: You have to be pretty passionate about being Agile. You also need some experience in applying Agile practices before you attempt to coach people in them. You need to have good people skills and enjoy working with teams. Communication skills are especially important. Problem solving skills help too, so you can help the team spot opportunities for change. You’ll also need to keep your ego in check: the team gets the credit for success, not the coach!
ms: What’s your take on electronic boards and Agile planning software?
ac: We like to keep it simple. We prefer a physical board in the team workspace. We appreciate that distributed teams will need to rely more on electronic plans, but even then spreadsheets and wikis are usually fine. Agile planning software is expensive and often leads to over-complicated plans. Liz has written a sidebar on this in the book entitiled “Agile Planning Software Won’t Help.”
ms: You are seasoned experts in coaching, and teach people how to become Agile coaches. You can talk to people at all levels of experience. For what audience did you write your book? Future coaches, experienced coaches, mere team members?
ac: We wrote this book for the people we used to be—coaches learning how to coach Agile teams. We didn’t write for an expert audience—although we’ve heard from a few who picked up useful tips from our book. What we say in the Introduction is, “It’s for anyone who wants to coach their team in Agile development—whether you are a manager, a technical lead, or simply working in a software team.” That’s who we wrote it for.
ms: What flavor or flavors of Agile development does the book address?
ac: We don’t want to get into debates about which flavor of Agile is best. There’s no definitive answer, because it all depends on the context it will be applied in. So throughout the book we talk about vanilla Agile—a generic mixture of Scrum and XP with a sprinkling of Kanban.
ms: Your book goes beyond the basics to address problems that will come up in Agile teams and what to do about them. I’d like to ask you to talk about some of those instances where things don’t go according to plan or best practices, and you have to be light on your feet and, I guess, agile in your Agile coaching. For example, problem customers: the customer that doesn’t know what it wants, or the customer that isn’t there, meaning that there is no on-site customer.
ac: The role of customer/product owner is critical to the success of Agile projects. If you don’t have someone willing to take on this role then you’re unlikely to get the full benefit of an Agile approach. Where the customer has limited availability, the team needs to make the best possible use of the time they have with him/her. As a coach, your role is to focus on building a strong relationship between the customer and the team, to create a sense of shared commitment.
ms: What do you do if the customer has a hard launch date and the team is asked to overcommit?
ac: If you see that the team is about to commit to far more than their velocity/history shows they’re likely to achieve, alert the customer to the risk that all the stories may not be delivered. If the team insists that they can do it, encourage them to slice the user stories down quite ?nely, so that for each area of functionality they have something that they can really deliver.
ms: What about really awful organizational challenges, like your team just isn’t assembled on Agile principles? For example, the company organizes by discipline and your team doesn’t have members from different disciplines? Or the team is too big? How does the coach deal with situations like these?
ac: You may be wasting your time coaching a team to try Agile when faced with these impediments, so seriously consider whether you attempt an Agile approach. Our recommendation in situations like this is to take a step back and work on educating the organization about what it means to be Agile first.
ms: What about problems within the team? For example, what can a coach do to head off or resolve problems stemming from cultural differences among team members?
ac: A coach doesn’t necessarily need to step in to resolve these situations. You can educate the team so they become more attuned to cultural differences by running a workshop to explore Geert Hofstede’s Cultural Dimensions (at www.geert-hofstede.com).
ms: And other team problems, like a member of the team being ostracized by the others, or meetings getting overly emotional, or teams that just plain hate planning, or team members who hate pair programming?
ac: The focus of an Agile coach is to help the team work productively together. So you don’t necessarily need to jump in to play the peacemaker. Where the issue concerns team process rather than individual motivation or capability, you can bring up your concerns in the team retrospective. Where a situation is more personal, consider consulting HR and involving line management.
ms: What about when the team fails? The software doesn’t run in the demo, or you don’t get to “done” for all the stories by the end of the iteration?
ac: We encourage the team to get to the bottom of why this happened in their retrospective. Ask the team for their ideas to prevent this happening again. Remember that it’s also likely to affect how much work the team can reliably commit to next time. We talk about both these situations in the book.
ms: In your experience, what’s the most common problem you encounter in working with Agile teams?
ac: One common challenge is that the team doesn’t feel empowered to change things. For example, they feel they’re not allowed to stick their plan on the wall. In this case, what you as coach need to do is to encourage the team to think big and consider what they can do. Most people don’t like change and hang back from it. Expect this. As their coach, you’re there to guide them along on their Agile journey. In our book, we include lots of tips that you can use to encourage teams to become more Agile. But the most important thing you can do is to be a role model and inspire them to keep experimenting and learning.
Rachel Davies works as an Agile coach helping teams adopt and improve their Agile delivery capability. She has a wealth of experience in a range of Agile methods, including XP, Scrum, Lean/Kanban, and DSDM. Rachel supports the Agile community both as a long-serving director of the Agile Alliance and as an organizer of many Agile conferences. Find out more at www.agilexp.com.
Liz Sedley is both a .NET Developer and an Agile coach, which means that she delivers software while improving team culture and process. She lives in London, UK, with her husband and 3 kids, but she’s orginally from Wellington, NZ, and she says she still has an awful accent.