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

Transcript

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’s point ‑‑ you really do need to be up to snuff on your technical skills and you do need to be able to demonstrate pair programming, test first, and those kind of things.

I think that’s going to alienate a lot of people right now who are using the phrase ‘Agile Coach’ because they’ve spent a lot of, the last say five years, driving towards the organizational, C level, that kind of coaching. They don’t have any concept. Maybe they weren’t even ever developers, or they were developers 15 years ago. How do we re‑align? What’s the new normal?

Derek:  Yes. I’ll use baseball here, an analogy ‑‑ I think one of the things that pissed me off more than anything with the Scrum Alliance, is CSC Application Process is their definition, I believe, the way that they look at a coach right now, is a coach is basically a Scrum Master that works with the organization instead of with the team. I think that’s an absolutely bullshit approach to what should be considered a coach.

I think you can be a coach, and only work with a single team, and make that team excellent. To me, if you’re working with multiple teams, doesn’t that make you a manager, instead of a coach? So I think we need to reframe a little bit what we consider a coach. I think, if you look at the XP coach definition and terminology, it’s much different than the “Agile” coach or the Scrum coach type of designation.

When I look at it ‑‑ I go into the baseball analogy here ‑‑ is I don’t know any manager currently in baseball that doesn’t know all aspects of the game at a pretty deep level. If they see somebody hitting, they know the hitting techniques. Maybe they haven’t played for a while, but they are still up to date on the most current hitting techniques, batting stances, how the pitchers pitch ‑ they’re fully informed, or they have access to staff that is.

They have a hitting coach, they have a batting coach. If you go to football, you’ve got a line coach, a kicking coach, a quarterback coach. That’s for a reason. When it comes to technical things, there are certain things that you can only know from experience.

You don’t have to be the best software developer, the best coder, or the best tester, but you have to understand the principles about being the best coder, the principles about being the best tester, so that you can get the most out of people who are talented and maybe do a little more.

I think we’ve gotten so far removed now that I think most Agile coaches, if you tried to ask them to code an application and do it all test‑driven, they would fall all over themselves. That would be an impossibility for most of them.

Roy:  I understand where the Agile coaches are coming from by specializing and dealing with the organization rather than the developers directly so much. I think we’ve seen that going into a lot of organizations as well that a lot of the organization’s problems stem at the top.

There are definitely technical practices and things you can bring into a team, but, a lot of times, implementing those technical practices is something that’s blocked from on high. Like, you want to bring in something like pairing, and the teams wants to try it, but they try it, love it, and then, all of a sudden, you get management coming in saying, “Why the hell am I paying two guys to sit in front of a computer? I don’t understand.”

Derek:  I absolutely agree, in the sense of, sometimes a team can’t be empowered to do the technical practices until the organization is ready. So you have an organization that says, “I’m ready to be Agile,” but in reality, that just means, “I want my team to work faster and have less bugs.”

Sometimes, it does take some organizational coaching. The quality teams out there, or the quality organizations out there, are ones that have people that have a broad skill set, either have a broad skill set to be cross‑functional, or, if they’re going to specialize, that they have multiple people on the team, just like the baseball team.

If I go into engagement, I’m going to bring a technical coach to work with the teams on the technical issues, get CI, pairing, whole‑team co‑collective code after refactoring, get all that stuff under there. Maybe I’ll get another person on my team that is the organizational coach, and he’s going and talking to the CIO and the product development team in another group.

Maybe I’ve got another process coach, that’s more about the Scrum framework and how to get the most out of the business value, and those things. So, if you’re going to be specialized, I think, if we’re going to change it, we need to say, “OK, there are multiple coaches.”

If you’re not a coach that can coach all of the different pieces, then we need to call coaches what they are ‑‑ I’m a technical coach. I’m an organizational coach. I’m a process coach. If I can do all three of those things, then I need to specifically say what I can do.

Roy:  That makes a lot of sense, to split it up like that, because I’ve seen before where we’ve gone into our organizations, where, if you start out by helping developers, it’s almost like you’re seen as a developer as well.

That puts you in the wrong position among your social hierarchy of that organization to help out with, for example, executive‑level coaching, where, even if you have the knowledge and the ability to do that stuff, you are almost seen as beneath that role, and you are no longer able to effectively help those people up there.

By splitting that up into multiple people, even though those people are able to work across those different fields, it almost makes sense to have those be distinct, different people, just so that they can fill their own slots in the social hierarchy of the company.

Clayton:  It sounds like we’re agreeing that, to further Agile, that coaching and leadership in Agile needs to be in tune with technical excellence. Is that a fair statement?

Derek:  Yes. Don’t confuse technical assholes with the software craftsmanship.

[laughter]

Clayton:  That’s a good distinction. OK. To change gears a little bit, we wanted to go to Twitter and look up an interesting tweet. This one comes from Sandy Mamoli. That’s @smamol. She says, “Dear manager, it’s self‑organizing, not self‑managing. We still need you. Cheers, your team.”

What do you think? Managers in Agile ‑‑ do we need them, or can we throw them out the window?

Roy:  I don’t know quite what the tweet is trying to imply.

Clayton:  Were you tempted for a second thinking about throwing the manager out the window?

Roy:  [laughs] I mean that might be kind of fun.

Clayton:  Cause you to pause for a moment?

Roy:  I think that tweet almost sounds like a cry for help from the team. I don’t know. It’s hard to tell if the person is the manager that’s saying that.

Clayton:  No, I think they’re saying that we still need managers. I don’t know if this person is a manager or not, but…

Roy:  I think that’s a very difficult thing to say, because there are so many different views of what a manager’s roles are. I think that some managers think it’s their role to completely control everything and then figure out who it is that screwed up, and that’s all that matters.

There are other people who think it’s very important that they protect the team from the outside, and that they need to allow the team to make their own decisions and provide a safe environment for them to do that type of stuff. I think those are two entirely different roles that can both be called manager.

Derek:  To me, the two key terminologies they use to sum it up were self‑organizing versus self‑managing. I think that’s something that a lot of people get confused. A lot of times, a team will be given the empowerment to say you’re self‑organizing.

The delineation is if you are self‑organizing, you get to choose how to do the work. If you’re self‑managing, you get to decide which work to do. It’s very difficult to be on a team where you get to decide what work to do and you get to decide how to do the work. That is a lot of leeway, and it takes a very disciplined team or a very disciplined set of people to be able to work in that style.

I think what this person is saying, and I don’t want to put words in their mouth, is that, when a team that has been given the ability to self‑organize, the management is not stepping up and telling them what needs to be done, they’re just saying, “Hey, man, come on! Perform”! And the team is saying, “We want to perform, but you haven’t told us what you want us to do.”

A lot of people have a lot of anxiety. I know, in Integrum, we’ve had periods in our culture where we’ve allowed things to be fairly self‑managed, either by design or by accident, neglect, and I think we definitely saw people’s uneasiness really grow, because there’s a lot of doubt ‑‑ “Am I doing the right thing? Am I supposed to…”

So, if you have a structure, but your boss isn’t telling you what to do or what will make them proud, this would be like a parent saying, “Do good, kid”! “What would make you proud, dad”? “Just do good. Just do good stuff, and I’ll be happy.” That’s very difficult to get approval. I think teams crave approval, and you can’t have that if you are self managed.

Clayton:  One example that I keep seeing come up in a few different places is the question of in an Agile team, or on an Agile team, how do I gauge individual performance? One thing that keeps coming up is that the manager can assess individual performance, even though they’re working together as a team.

There’s still a role for management. I think this question is topical. It comes from both sides. There are probably lots of managers who are in organizations that are adopting the Agile, and wondering, “Hey. Where do I fit into this whole thing”? There’s also some people on the teams that are, kind of what Derek was saying, they’re craving that, I don’t want to say approval, but they need some direction.

Roy:  And feedback probably. OK. Thanks guys.

Clayton:  OK, thank you.