Roy van de Water, Clayton Lengel-Zigich, and Derek Neighbors discuss:

• Executives in Agile
• The Big Rewrite
• Ignoring information Radiators

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors:  I’m Derek Neighbors.

Roy van de Water:  I’m Roy van de Water.

Clayton:  Today, we have a few things we want to talk about. First thing we’re going to talk about is executives in Agile. How do you handle executives in Agile? Is that even a question, a valid question? It presumes that there’s something to handle, right?

Derek:  Yeah. To me, when Agile first started, there was no Agile to talk about, so executives were completely not aware of it. If you look at almost everything that exist, that is Agile or has to do with Agile, it largely focused around teams and really, the team level.

From my perspective, I don’t even think you need “executive buy‑in” to do Agile. You could do Agile just within yourself. You could get that to stand to your team.

To get it outside of your team, you probably need some level of support every rung you go up, but I think you’re probably in a losing proposition if you have to “convince” your executive that they should be Agile. They are not going to have the mindset that it’s going to take to do it.

I think it’s a different story if the executives are saying, “We want to be more Agile, and we don’t know how to get there. Can you help us?” Then, I think, there’s a role that you could play in helping guide them through that process.

Clayton:  I could see that in a small organizational structure where if you have maybe like an executive only a few levels above the team, where teams start performing up to the limit of what they are currently allowed to do or the limit of their self‑organized ability.

Roy:  [laughs] That’s trademark. If they’re up against a limited app, I can totally see the team approaching the executive and being like, “Listen, we really want to get better and right now, you’re behaving in way X that is holding us back. What can we do about that?”

Derek:  I think that’s different than trying to sell Agile. I think the problem that people have is that they try to sell executives on Agile opposed to saying like, “Here are the things that aren’t working. We’re not trying to prescribe an answer.” I think that’s a much better sales technique than like when you do this Agile thing. I think we can see it in a difference in our client’s that come to us.

There tends to be two funnels. There tends to be the funnel that says, “I want to be agile, and I want my whole company to be agile, and all I care about is agility.” What the hell does that mean?

You manufacture widgets, so why do you care if your company is “doing Agile.” Then there are the people that come to us and say, “We’re not the best company we can be and we know it’s because we have these problems and this baggage that is holding us back, and we think some of these Agile principles, values, and frameworks could help us get past those problems. I think it’s very rare that we hit the second one, where they’ve been sold Agile.

Roy:  I think the first one is much more common. It’s usually that some executive has read a book, talked to a CO or an executive at another company over a game of golf or something like that. Or they have recently been acquired from a company that did “Agile.” They don’t really know what it means themselves, but they have been sold this tale of success that it means more, better, faster, stronger.

Clayton:  Speaking of tales of success, what do you guys think of the big rewrite?

Derek:  Never, ever do it ever.

Roy:  I don’t think I’ve ever seen a tale of big rewrite success.

Derek:  I’ve been part of big rewrites.

Clayton:  It’s very alluring, right? It seems like it would be a very good idea. You’ve got this big clue with a bunch of technical data that’s causing all kinds of problems, so just get rid of it.

Derek:  The thing that I’ll say is that in twenty years of doing this stuff with a ton of different companies I’ve never seen a new rewrite replace the old thing. What you end up doing is having to maintain two things indefinitely. The second thing becomes the ugly thing. Then you end up with the new rewrite which is the third thing. You can never really phase these things out. I think the two approaches that you can take to deal with the big rewrite, meaning there’s definitely technical depth that exists in products, and there’s definitely problems that need to be dealt with.

There are two ways that I have seen people successfully deal with them. One is that you take the product, and start to apply technical excellence to it. You start to say, “Every time we touch the code we’re going to make it even better when we’re inside of there.” The other way is you say, “We’re going to basically create a competing product that’s going to try and kick this products ass. If that product can take the market share from our existing product, then it’s gone.” That’s really hard to do if you’re talking about a payroll system or something bigger.

Clayton:  That’s bigger than the big rewrite. That’s an entirely separate thing you’re talking about now.

Roy:  I like that, I believe I read somewhere an article from “Thoughtworks” that says like, “Never do the big rewrite,” or something like that that got posted a few weeks ago.

They said something similar where they said like, “Write a competing product, and let it be market driven, and don’t try to replace your existing product. Rather build this product to fill all those holes that your current product doesn’t fill. Let the market drive the features of your new product. Then, eventually, it may or may not replace your old product.”

Derek:  Yeah, I think that’s one of the big problems with the rewrite, is it never feature complete to what the other product was.

Roy:  Right. The features of the other product usually 60 percent or there’s some large percentage of those features that I never use anyway. Why are you wasting a bunch of time rewriting those features?

Clayton:  I heard it described by Luan Falco, actually. I thought it was a good way to describe it. Imagine if you had your family, and you suddenly replaced your husband or wife, your spouse, basically. You replace them, and you want your kids to act like nothing is different.

Roy:  It sounds like the American way.

Clayton:  Like, “Hey kids, we’ve got a new wife and everything should be just fine.” That’s kind of the big rewrite. Everyone thinks it’s going to be that way. You’re going to get this newer, better thing that solves all the problems, and no one is going to notice, but everyone does notice.

I want to talk about working on one thing or imposing a weapliment. There’s a lot of scrum teams that have that problem where they work on five things all at once, and they never get anything done. Derek, you and I were talking today about thinking of things, I think it was an article you’d read about like doing an hour class board, where there was this visual limitation of whip, basically, where you could only work on one thing.

You were talking about maybe splitting that up and making those smaller things so that you can only work on a few stories. Maybe you could explain that a bit more.

Derek:  I think one of the things we see in teams all the time, or I see in teams all the time and seems to be, is that you’ll be multiple days into a sprint and there are no points burned down. We’ve got five people on the team, we’ve got 10 stories. Person A is working on one story, person B is working on another story, person C.

You’ve basically got all five people split across all five stories. They get towards five, six days into a sprint or whatever, and none of the stories are done yet. They’re all 80 percent complete, 90 percent complete, opposed to actually getting completion.

I think one of the things that is interesting is I try to encourage teams. Try to get points knocked out as soon as possible, really trying to finish functionality, trying to have swarming type of behavior as much as humanly possible. Usually there’s also the pushback and excuses and reasons.

I think if you’re going to be prescriptive on a team, you could probably do something where you enforce some kind of weapliment at a story level instead of a task level. You could say like, “We’re a team of five people, and there could be no more than three stories being worked on at any given time.”

When you, physically, pull those three stories down you can’t go get another story until one of those stories is complete.

Roy:  That makes sense. I’ve worked on a team where we try to do some forming and at first there was a ton of resistance, because we’d have two to three pairs working on the same story. I felt like we’d be stepping on each other’s toes a whole lot.

Then, with some extreme cases where we had extremely linear tasks where one had to be done before the other or [inaudible 08:42] serial. We’ve noticed that instead of stepping on each other’s toes a whole bunch, it causes us to talk a whole bunch because we now have to. The entire team is in constant communication which helps the entire team stay focused, and everybody is aware of everything that’s going on.

Derek:  I like to say that teams that really back against swarming, especially extreme swarming. Usually, it means their design sucks, or their code is extremely monolithic. If everything is all in one giant method, yeah, I believe it is very hard for us to all work in the same code.

Where if we’ve got a much more modular way of thinking, it becomes a lot easier to say like, “Hey I’ll go add the verification stuff while you’re adding this stuff, and while you guys are doing the front end stuff.” Now we can very easily split up, if all that’s lumped into one file, one method that’s much more difficult. Then even on the serial thing, you’re exactly right. The problem is they just don’t want to talk.

If you’re forced to, basically, say like, “Hey we’re going to build a rail road track coming from each direction, and we’re going to meet in the middle.” You need to be calibrating that every step of the way, or you’re going to end up grossly off.

Clayton:  In a situation where the team might get five stories almost done. It seems like every time that happens everyone seems surprised at the end.

I’ve seen a team recently who I feel like has been ignoring their information radiators. I noticed that because they had a build monitor that, after a power outage, came back on and was just stuck on the screen saver. It’s been maybe two weeks now and no one has noticed, I don’t think.

I was wondering what is about that where it was a visual thing that played noise, and all that stuff, but it seems like it didn’t take them very long to forget about it. I’ve seen the same thing happen with boards and anything that you would put up on a board. Why do you think that is?

Why do you think people have a short memory for that stuff?

Roy:  I think in such instances, there’s sometimes a lack of demand from the information radiator. For example, a CI server is really important if you’re releasing really often because you need to make sure your code is stable at any time.

If you’re not releasing for another nine months, who cares if your code is stable for the next month? There are all sorts of reason you should care, but…

Clayton:  That’s the mindset maybe they get in to?

Roy:  Right.

Derek:  It’s fucking hard to be a cannibal. I think information radiators help us hold ourselves accountable, because they air our dirty laundry for us.

I think when nobody else talks about it, why would I talk about it? If my room is messy and I know I’m not allowed to go out and play until I clean my room, I’m probably not going to want my mother to come into my room, if I know I want to go out to play.

I’m going to do everything possible to try to get out to play before she looks at my room. I think teams start to have the same behavior around information radiators in a sense of like, “Hey, if one of them shut off or stopped updating, and nobody has said anything, I’m not going to jump up and say something, because that’s just going to mean more pain for me at some point.”

Clayton:  I’ve heard people talk about how, like a burn down chart for instance if it looks like maybe after the first few days of the iteration that burn down chart is going, basically, horizontal, I’ve heard people describe that as being useless.

But I feel like that tells a very important story, so I could see that maybe there are some times where the team might see that stuff and say, “Well, we forgot to update it, and it doesn’t really show us anything. It’s not burning down, so it’s a waste of time.” It seems like the waste of time stuff is the first trigger for, “Let’s not look at it.” I feel like that’s always a cover for, “Am I doing it right?”

Roy:  When the information radiator is giving information that people feel like a waste of time, or shows something wrong, like it would normally be small, like in your case with a burn down chart that’s level half‑way through the sprint. Or, for example, a combine board that keeps getting stuck with weapliment three and that seems to be like a bottle neck when things go wrong.

I usually see people try to start ignoring those things, or instead to start making rules around their information radiator to cover up that problem. What I really rarely see is people actually address the problem that the information radiator is trying to indicate.

Clayton:  I guess, what you’re saying, Derek, is it’s hard to be good, right?

Derek:  It was really funny the other day. One of the teams I’m working with has a retrospective goal to increase some of the test coverage. They are all very committed to it, and they really want that to happen, but they’ve really been going all out trying to do some work that’s really challenging for them to do.

They had put up an information radiator to show their code coverage on a couple of pieces of the code, and it’s been flat. I had updated it for them the first couple of days just to show them how it went, and I haven’t for the last two days.

One of the guys really cares about quality, really cares about what they are doing, come up to me and I said, “Hey, nobody updated the challenge goal. Are you up‑to‑dating it?” He says, “It hasn’t changed at all. We probably shouldn’t even have that chart.” I said, “Didn’t you commit as a team to make improvements to this.” He’s like, “Yeah, but how are we going to do that?” I said, “Well, are you talking about it in stand‑up?” He’s like, “No.”

I’m like, “Why do you have the visibilities?” He’s like, “Man, if we do that, how are we…? That means everybody is going to have to do more testing when they’re doing features.” I’m like, “But, isn’t that what you wanted?” He’s like, “Yeah, but, that’s hard.” I’m like, “Hey, man, not everybody plays in the NBA.” He says, “You’re right.”

I think that is the essence of it. It’s really easy to say, “I want more testing. I want to be a good developer. I want blah, blah, blah.” Then, when the rubber hits the road, it’s like, “Well, that’s hard.”

Clayton:  Do you think that’s the case where maybe someone like the Scrum Master can kind of play “Captain Obvious” in that situation? When the team makes a goal to do something? Let’s say they go as far as making an information radiator.

Then, they don’t do anything with it and it’s very obvious that they are avoiding it. Is that the role of the Scrum Master to say, or somebody, the coach or whatever to say, “Hey, you remember about this thing?” Kind of have that conversation.

Derek:  I really struggle with, “Can you hold people accountable or not?” Part of me says, “No, you can’t, because everything is going to be after the fact.”

But, I think you can encourage accountability and especially if you do it via culture. I think one of the things you could do, like if I’m a soccer coach, and I see somebody not training hard. I have a conversation, “Hey, Roy, you’re really not training hard. If you want to start this weekend, you are going to need to step up your training.” If that doesn’t happen, then I don’t start Roy, and he doesn’t play.

Yeah, it’s after the fact, meaning I wasn’t able to hold him accountable during the actual practice, but I’ve set something in motion that says like, “Hey, I know coach is watching, and if next week I don’t perform during practice, there is a consequence to it, or there is an action.”

I think you do need somebody out there saying, “Hey, you’re goal, you’re retro‑goal was X, and here’s a chart and it’s not moving. What’s going on?” Can I force you to increase the coverage? No. But, what I can do is say, “I’m instilling in you that somebody is watching this, and we’re having a conversation about it.”

Clayton:  With that, we have run out of time. Thank you guys.

Derek:  Thank you.

[music]

Announcer 1:  If there is something you’d like to hear in a future episode, get over to integramtech.com/podcast where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques and events in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free.

The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.

Announcer 2:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline. It’s free. Call 866‑244‑8656.