André Dhondt is an agile coach for Rally Software and has more than a decade's worth of experience working with teams and organizations. In this interview, André discusses how to be prepared for sprints, the idea of speed grooming, and how agile has impacted the role of the tester.
André Dhondt is an agile coach for Rally Software and has more than a decade's worth of experience working with teams and organizations. In this interview, André discusses how to be prepared for sprints, the idea of speed grooming, and how agile has impacted the role of the tester.
Jonathan Vanian: Thank you very much, Andre, for taking the time out of your day to chat with us. Let’s start off by having you tell us a little about yourself. What do you do and how long have you been doing what it is you do?
André Dhondt: I'm an agile coach. I work for Rally Software. I've been an agile coach for maybe six or seven years. I was independent for a while and I joined Rally just for the adventure of working with more clients and bigger clients. I have been a programmer for multiple decades, if I'm allowed to say.
JV: You're allowed.
AD: If we count waking up Saturday morning, instead of watching cartoons I would crawl out and write an Atari logo or something like that, then I'm definitely getting multiple decades of programming experience. I don't program every day anymore, but I was programming today. I mostly interact with teams and help them work together either at a program level or even down to the individual team level.
JV: What got you interested in moving away from programming to more of the team-building activities?
AD: I read Tracy Kidder’s The Soul of the New Machine. I got really excited about building something that was bigger than what could fit in my own head. I was like, “That would be a really cool challenge.” I wanted to get experience working with bigger teams. I wanted to manage on my own and I tried and it didn't work out quite the way I'd imagined. I found out that my developers I was managing weren't building exactly what I would have built.
They weren't doing it the way that I would've. Sometimes it was better, sometimes it was worse. It was really frustrating. Sometimes it would work well with what the rest of the team was doing, sometimes it didn't. I was like, “Why is this so frustrating? What's going on?” It was a huge challenge for me and I realized that it's not command and control that works with humans. It's a much more subtle leadership strategy. That became a whole new obsession for me” How do I become a good leader? How do I become a good coach?
JV: Is this where you got interested in agile?
AD: I was doing agile before that. I started in agile in 1999 and I guess around 2002 is when I started managing a team. It was a small team. Four or five dubs.
JV: Why don't we talk a little bit about sprints and iterations and some of the stumbling blocks that can occur. What are some reasons sprint and iteration planning sessions can take longer than the fifteen minutes that people sort of expect?
AD: I think most of the time people show up at sprints and iteration planning unprepared. They haven't had the right discussions with the business or they haven't had a chance to look at the source code to remember how things work.
JV: Why is that? Why is it that people usually come unprepared?
AD: They're in the middle of a sprint. They're sprinting. They don't have a reminder to look ahead, to pay attention to this. To pay attention to what's on the next iteration. Or they maybe don't know. Or product ownership hasn't even decided.
JV: What are some ways that people can remedy the situation—this unpreparedness?
AD: What I've seen in the field is that people do these things that are called pre-backlog grooming sessions. They're calling it pre-sprint planning. There are all kinds of names. I felt like I needed to give it some kind of name and I called it speed grooming. Speed grooming basically makes it so when you get to read through the real backlog grooming or the real iteration planning, it's speedy.
JV: Why don't you describe a little bit about how you came up with the term?
AD: I guess that term evolved over time trying different words with clients. Sometimes I just tried to call it pre-planning or sprint pre-planning, just like everybody else was, and it wasn't clear to people that it was something different. I decided we needed a new name and speed grooming was catchy enough. People were interested, like, who wants slow grooming? Everybody wants speed grooming.
JV: Can you explain what exactly is speed grooming?
AD: Yeah, so it's a very structured twenty-five minutes, assuming you can do it co-locative. If you're remote you probably need to do an hour. It's a very structured format for talking at a high level of scope. Not any of the actual details for a story, but talking at a high level; what do we really want to accomplish for this story and does it meet our definition already?
You get through that with that help. Really understanding enough to implement the story but understanding enough that high-level design, interactions, and dependencies have been identified, and the right implicated parties have been notified; “Hey, we're going to be working on this. We can depend on your API. Can you help us next week?”
JV: When you're working with teams, how have they taken to the idea of the speed grooming?
AD: People like it. People feel like, “Ok, now we understand what we're supposed to do.” It's something that came from, like I said, watching advanced agile teams, watching to see what they do in the field. Then trying to find a way to get new teams to copy those same behaviors. When people do this, in the beginning it feels a little rigid, but after a while it starts to click and they're really excited about how quickly they can get through planning while, at the same time, still be in a state of just-in-time decision making.
JV: A little bit of a formality at first, but then once you get familiar with the regimen, it sort of comes a little naturally and it fits in with the sprinting session.
AD: Right. This is a training-wheels technique because pretty soon, and it depends on the team, but pretty soon the groups realize, “Ok, we get what we're supposed to be doing.” They evolve from doing this twice a week at twenty-five minutes a pop to doing it ad hoc. A product owner with a couple dubs here and there.
“Hey, I got something new coming from the business. Who can sit and talk with me about this? Let's speed groom it.”
Maybe then we have something that's with the whole team saying, “Here's the proposed design we came up with: Anybody have any concerns? Any estimates? Does it meet our definition of ready?” It becomes a lot more fluid then this regimented twice a week at twenty-five minutes a pop.
JV: What constitutes a great story?
AD: A great story, I like to call it a thin vertical slice.
JV: A thin vertical slice. Explain.
AD: Basically meaning, it can be done very quickly. That is one to three days. No task under it is going to be more than four to twelve hours. If you have ten tasks, that could be a huge story. Still, in calendar time, it could be done in about three days. That's the thin part of it. The next part of a good story is that it's a vertical slice. That vertical slice means that we can implement it.
We have everything we need to do to implement it, to deliver business value. Maybe what we're doing is we're preventing errors that our client or our business customer is manually rectifying an identifier. Patient record identifiers. They're having them manually dedupe them or something like that.
It's hard to write a story that's not technical to deal with that technical kind of problem. At the same time, it delivers a huge amount of business value. We find a way to express business value. That change to the system, that defect is now a vertical slice.
JV: It's almost like getting something that's so technical and explaining it so it meets the business objective. Making it a little bit clearer to understand.
AD: Right.
JV: You talk about in sessions about a customer-empathy mindset. What is this type of mindset?
AD: What we're doing is we're trying to understand not necessarily what they asked for, but we're trying to understand what their goals are. We're moving beyond the literal request. As Henry Ford said, “If I ask customers what they want, they'd say they want a faster horse.” That didn't get us a car. We're trying to help our developers get to a spot in which they understand so well what the business goal is, they can innovate something that's better than a faster horse.
JV: It goes more beyond the product, itself.
AD: Yeah.
JV: Can you explain the role of persona mapping?
AD: Persona mapping is a way to quickly fill up a backlog when you don't know what's coming down the pipeline; when you haven't done any work to do initial planning. This is when you first start on a team or when a team does not have released plans. What we do is we identify all of the users, or stakeholders, of our system. Write them out on individual index cards, for example.
Write them down and after you do that maybe you spend five minutes on that. Maybe ten, but no more than ten. Get all those names written out and then we say, “All right, now spend fifteen minutes or an hour walking through each one of those personas and identifying what do they want from our system.” Write as much as you can. You're writing just the name of the functionality. We could do this whole thing in fifteen minutes but if we're really trying to plan out a full three months' worth of a release, then you probably need an hour to do this.
You have walked across all the names. Come up with things that you know they want. You look at the whole slate. You're going to find certain columns are very empty. That suggests maybe we don't know very much about this kind of user or this kind of stakeholder. Maybe we should go talk to them and say, “Hey, this is what we know that you want. Can you tell us what else is important to you?” Very simple technique. Got it from Dan Messick. I love it. It's very fast.
JV: Yeah, it seems like it would speed up a lot of the work. Given that a lot of our readers are testers, how's the rise of agile affected testers and their work? What have you seen over the years?
AD: It's hard to say and give any blanket statement about it. I do see a lot of testers being pulled into agile teams. I see org changes where testers are being invited to look at what's coming down the pipeline at the design discussion stage. I think that it's really positive that the testers are really excited about this. They're like, “Oh finally, I get to know what's coming down the pipeline.”
JV: They're a little more connected now than before.
AD: They can then say, “Wait, if you build it that way it's going to be impossible to test.” They're there by influencing the design in addition to being aware of it, and this is really, really good for quality.
JV: It's a little bit more of an empowerment of the tester's role, you think? They get a little bit more input and everything.
AD: Yeah, yeah. Yeah, yeah.
JV: Finally, any New Year's resolutions for you?
AD: I'm a very goal-seeking person. My resolution is no more goals.
JV: No more goals. Very good.
AD: Just be. Just be agile.
For over a decade, André has led agile adoptions, providing guidance to teams and organizations seeking shorter development cycles, higher quality, and more effective discovery of customer value. Playing various roles, from developer, manager, product owner and scrum master, he’s done everything from hiring and building teams in startup environments to coaching teams for an organization with over 100k employees.
