Technical Excellence in Scrum
The Agile Weekly Crew discuss Dave Rooney's article Technical Excellence in Scrum
Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors talk about a blog post entitled “Technical Excellence in Scrum” by Dave Rooney. Jeff Sutherland suggested that Agile Leaders are not doing their job if they are not pushing Technical Excellence. Rooney writes that sometimes it’s the teams that refuse, no matter how hard the leader pushes.
Implementing Scrum causes impediments
Technical Excellence practices can remove these impediments
Sometimes the leader can mandate some practices if they can demonstrate the benefits
Leaders should know how to do the practices they advocate
Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich.
Roy VandeWater: I’m Roy VandeWater.
Derek Neighbors: I’m Derek Neighbors.
Clayton: Today we’re going to be talking about a blog post that Derek sent out to the team. It’s titled “Technical Excellence in Scrum,” from Dave Rooney. Derek, can you explain a little about that post and why you sent it out.
Derek: It was talking about technical excellence missing from Scrum, but specifically there is some talk about leadership. I believe it was Jeff Sutherland who had sent an email at one point ‑‑ or there is a famous email floating around ‑‑ where they talked about the first Scrum team that really was an XP team that started implementing Scrum in all of the XP practices in some form but were held up during their tenure.
When Ken and Jeff decided to take Scrum to the bigger community or to the industry, Ken thought it was worth taking the technical practices or XP portion out of it and focusing just on the Scrum framework ‑‑ not because XP wasn’t important, but because they felt that if you implemented Scrum properly, you would have impediments and when you ran into the impediments, one of the first things that you should do is look at the technical, excellence pieces or the XP principles to help unblock the impediments that you got to.
There was a recap at Snowbird recently, a 10 year anniversary, and one of the things that came up from a number of people is that if you are not really gung‑ho pushing towards technical excellence then you are not an Agile leader.
That Agile leadership has completely fallen apart from a standpoint of ‘they no longer push the technical practices in the ways that they should,’ and it’s to the detriment of teams and projects. I believe that the author was saying, “Hey, is that really true”?
Meaning, do most Agile leaders actually spend quite a bit of time trying to press, push forward, technical practices, but the business and the team pushes back and says, “We don’t have enough time to pair,” or, “We don’t have enough time to test,” or, “It’s too hard to get to continuous integration up.”
Is it the actual teams that are pushing back on the technical practices and not the coaches or the leadership that is failing to communicate those practices? That’s the argument. I thought it was relevant because I fall on the side that we don’t talk about technical practices enough ‑‑ we just gloss over them.
Clayton: There are two questions here. Is it a case of taking the author’s perspective and saying “Hey we’re working really hard to get these technical practices out there but the teams just aren’t responding”?
Is it the way that we’re delivering that message or talking about those things? Maybe that’s not effective. As Agile leaders we need to find new ways to explain those things to teams. Which side of the fence do you guys fall on?
Roy: When I was first reading through it and he was talking about “Well I push these things to the team and I’ve been doing it for years. Every time I get the same excuse. I get the, “We don’t have time to test.” I get the, “We don’t have time to pair because we’re coming up on a deadline.” It’s something that I’ve seen a lot in teams as well.
Part of what he is saying too is “I keep trying and they keep pushing back. At some point, when do I give up? And is that bad on my part that I kept pushing but I wasn’t able to convince them to actually go though with doing testing or doing pairing or any of the other XP practices”?
I think he tries to absolve himself from responsibility. I don’t want to necessarily put those words in his mouth but I feel that you do almost get that as a reader where “Oh, it’s not my fault because it’s the team’s fault that they’re not doing Agile…”
That’s a dangerous position to take, no matter what you’re doing. You should always go from the perspective of, “What can I do to make it different”? That said, I don’t think it’s right for a Scrum Master or a product owner to dictate to a team that they have to do everything test driven or they have to do everything paired. I think if you do that the team is going to rebel against it and it’s been mandated from the top and it won’t work. There are other ways to get the team to buy into that.
Derek: I definitely think it’s a leadership problem or a co‑team problem. To me, it’s two‑fold. One is when I look at most people that are currently coaching ‑‑ they’ve not been technical practitioners for than a decade. It’s really hard if the last relevant project I coded on was a C project for a Curses interface and I’m working with a team that’s delivering huge data sets to the Internet via APIs, high availability.
It’s really difficult for me to have any kind of respect from the development team when I say, “Well, just test, just pair, and just this,” and I’m not able to sit down and do those things with them.
I like to use the Dreyfus model, some people like to use Shurahi. I think some of it is the the Miyagi‑san thing. “Daniel‑san, paint the fence.” At some point Daniel‑san blows up and says, “Hey, bastard, why are you making me paint the fence”? Miyagi’s able to show him that painting the fence was a blocking technique that he needed to perfect.
We fall into two different categories. One is, we, or most coaches are not able to actually demonstrate the techniques to the team, therefore the team tries it once and says, “Testing is hard, it’s too slow, it’s way, way slower.”
When the teams that I’m on and the coaches that I see are highly proficient, testing doesn’t slow them down at all. If I can sit down and complete things as fast as a pair that isn’t testing, that throws out the argument that testing is slower.
I can frame the argument as, “Because you haven’t practiced testing enough, you are currently slower. You need to work on your skills as a tester to the point where testing does not slow you down, because it is possible to write tests and not be slower.”
If I can’t prove that, it sounds like, “Yeah, sure, asshole. You just want me to work harder and faster and put all this time in and you’re just a liar.” Some of it goes back to these little practices where you might say, “You need to do this because I say you need to do this for right now, because you don’t know better. You’re too early in the Dreyfus model to really know.”
The problem is I think we have a lot of coaches who do that, but then they’re never able to pull a team into maturity. When Daniel‑san says, “Hey, I’m pissed off. I don’t want to do this anymore,” they’re not able to go, “Here, let me sit down and show you, based off observation and my skill, what’s happened over the last three weeks when you’ve done this. And this is what you’ve really learned from that.” Instead they just go, “Don’t question me, just keep doing it.”
I do think it’s a leadership problem. I think teams have valid reasons why they don’t, but the best reasons are the worst excuses.
Roy: I’ve seen the exact same thing happening with pairing, where the Scrum Master, or whoever, comes in and says, “All right, we’re pairing now.” And the two people go to the Internet and look up what pairing means, and are like, “Oh, that means we stick two people in front of a computer.”
Then after a week of taking turns coding while the other person plays on their cell phone, they determine that it slowed them down significantly. Well, yeah. No shit! That’s what’s missing a lot ‑‑ if somebody came in and paired with you, taught you the appropriate ways or showed you some different pairing techniques that helped you stay focused, and brought out the benefits of pairing ‑‑ that would make a huge difference.
When we see a lot of people who are in Scrum Master positions, especially with a lot of the large organizations that are converting over to Agile, you’re getting project managers have taken that role, or you’re getting organizations that don’t even have Scrum Masters, and product owners which are former project managers. These people haven’t even touched code in a very long time.
Derek: I definitely think that contributes to the problem.
Clayton: Right now, at least in the community, there seems to be this kind of delineation between, “I’m an Agile Coach, and I do stuff for the organization,” versus someone who does technical coaching.
What it sounds like you’re saying, Derek, is that we cannot afford to have that delineation. If you’re the person that’s going to be doing coaching of an Agile nature ‑‑ I guess this kind of gets to Sutherland