Jade Meskill, Roy van de Water, Derek Neighbors and special guest Alan Dayley discuss:

• If agile faster
• What it means to be better

Transcript

Roy van de Water:  Hello, welcome to Agile Weekly Podcast. I’m Roy van de Water.

Alan Dayley:  I’m Alan Dayley.

Derek Neighbors:  I’m Derek Neighbors.

Jade Meskill:  I’m Jade Meskill.

Roy:  Today we’re going to be talking about “Why is Agile Faster”? Alan brought this to our attention. Do you want to give a quick intro?

Alan:  This is something you see all the time online and that I encounter with clients and so on. People say, “We want to do Agile because we want to be faster, because faster is better and Agile will be so much faster.”

I recently did a blog post about this and thought it would be fun to bring up here to talk about the perception of Agile being faster ‑‑ is it really faster or not? Why would it seem to be if it is or isn’t ‑‑ all those kinds of issues.

I proposed in my blog post that Agile isn’t necessarily faster. Just because you’re doing Agile or you’ve done it for three sprints or iterations, that doesn’t mean people are coding faster or the testers are testing faster.

Roy:  Does it mean you’re delivering value faster?

Alan:  Well, I’d rather you use the term sooner than faster in that case.

Jade:  I think a lot of it is biased towards action. If you look at the core of what the Agile principles and values get you doing as a team, you’re looking at moving towards some goal sooner.

Alan:  That can be one of the factors right there.

Derek:  I guess, for me, when I look at the Agile manifesto and corresponding artifacts, I don’t know if I’ve ever seen anything talk about faster, sooner. I’ve seen “better.”

“Better” could include faster or sooner. I don’t want to call them illusions, because I think ultimately, over time Agile teams do tend to perform better. I’m not discounting that that’s the case, but I think some of it is the illusion of speed ‑‑ how quick you get feedback.

I like metaphors, so maybe I can explain with a metaphor. If you are in a car and you are going 70 miles an hour and you look out the front window, it very often does not feel like you’re going 70 miles an hour.

If you’re in the same car going 70 miles an hour and you hang your head out the window and you look at the little striped lines and you see how fast they’re going by, it feels a lot faster than when you’re looking out the window.

You’re going the same speed. The difference is you’ve got some indicator that is giving you perception that you have movement.

I think one of the things that Agile methodologies tend to do is make things visible. They make movement visible where you didn’t see movement before. Even if you’re in a long iteration, if you’ve got burn‑down charts, if you’ve got card walls and other things that are showing movement it feels like “Man, we’re really getting a lot done,” or “We’re really going fast” because we’re seeing lots of movement.

Where before it’s “Hey let’s go do this stuff and we’ll come back in X number of weeks when the project manager comes by and says “Are we on track for this”? And nobody on the team is really seeing any movement except maybe the person doing the individual silo‑ed work.

Alan:  One of the interesting things that I point out many times in these discussions is the retrospective and the focus on improvement. Most teams traditionally are not spending any time trying to improve. The reality is that you are going to end up spending less time coding because you are going to spend time trying to improve.

The payoff is in the long term ‑‑ some iterations down, some months down ‑‑ the team will actually have more efficient processes and better ways of communicating, et cetera, because they have taken the time in the early iterations to build some of that. I think that really does help improve actual higher production, or more output.

Roy:  So they will eventually be faster? That’s what I’m buying if I’m converting my company over to Agile?

Derek:  I don’t think you will necessarily be faster. You’ve made an investment in being able to respond better and you’re hopefully focusing on doing the right things. If we’re doing the wrong things really fast, we haven’t actually made any progress.

Alan:  Yeah, that’s kind of the input side which we can address here in a little bit.

Derek:  Iterating to nowhere. I think it was Carlos Segura or some fairly famous designer I thought put it really well. You see a lot of design firms that get paid millions of dollars to make a logo and other designers say “Well that’s crap, how dare you get paid a million dollars to make the Nike swoosh logo? Come on, that’s just drawing a little flip of the wrist. That’s so easy.”

I think Carlos put it as “It’s not that I drew a little “fwoop”, it’s that I knew what “fwoop” to draw that was worth a million dollars.” I think that Agile teams start to become the same thing because they are collaborating with the customer, because they are iterating with things, because they are putting working software, they are getting feedback.

They learn what the right things to be doing are. It’s not that they are able to do more things. It’s they’re able to do the things that have bigger impact. Again it gives that illusion of, “Man, this team is really fast.” No, maybe they’re just really good at saying no to stuff that doesn’t matter to anybody.

Alan:  That, again, drives to the input side of things. One of the powerful things about many of the Agile frameworks is the collaboration with the customer and having somebody that’s picking the right thing to work on and the right target to shoot for.

Of course, in many organizations, that is still a very neglected part, and most organizations are focused on output ‑‑ make sure the programmers are shipping and sending stuff.

But eventually, you have to address that other end that says, “Are we working on the right thing”? How do you help the product owner and the infrastructure around that whole management of portfolio and feature ideas, to pick the right ones that’ll have the most impact?

Jade:  I’ve met a lot of organizations who have an amazing tolerance for wasting everybody’s time. It just blows me away every time.

Derek:  There are some organizations that I’ve been in, they introduced me when I started there by saying, “Oh yes, this project is really cool. It only took three months of discovery.”

I said, “OK, so what did that produce”? They said, “Well, here’s this document.” I said, “Well, where’s the back‑log”?

“Well, we don’t have one yet. That’s going to take another month.”

Roy:  Well, wait until you see the product. It’s going to be [sarcastically] so cool and awesome…in five years.

If I’m trying to justify it to a superior, I’m trying to sell somebody on it, what I’m hearing is I can’t really go, “We’ve got to use Agile because it will make us faster and it will make us more efficient.”

I’m hearing…

Derek:  [jokingly] Use ComBomb for that!

Roy:  We need to use Agile so that our teams will tell us “No,” when we want stupid things. It totally makes sense, but I feel like that’s going to be difficult to sell.

Derek:  If I were to try to sell an executive who was on the fence on Agile, I would start with a couple of things. “How engaged are your employees in your teams towards the work that they’re doing”?

If their answer is, [unenthusiastically] “Yeah, I got a bunch of eight to five people. They don’t really care.”

You’re probably going to do a better job solving that problem if you really start to become Agile, than you are going to solve the “going faster” problem.

You can come in and you can do Agile wrong and implement Agile. As part of that, you might get teams to go way faster, but they might completely disengage and I like to call it “iterating to nowhere”.

“Your velocity is just climbing like a beast, but you’re not shipping any software.” Or, “You’re shipping software, but nobody likes it. Everybody thinks it’s horrible. It’s not selling better. You’re not…”

The big thing is I can tell what an executive is looking for by how they want to measure Agile. If they want to measure Agile like, “I’m doing Agile this year and I want 100 percent of my teams to be using Rally and have increased velocity. That’s how I’ll know I’m successful.”

It’s like, “You don’t really care about agility, right”?

If it’s, “My problem is we’re only shipping our software every six months and I want to be able to give features to customers every week and get feedback. I want to be able to have really high net promoter scores and have my customers love our product.”

To me, it’s, “What are you trying to do by being Agile”?

I think the thing that we’ve done in this community that has been a travesty is we have sold Agile as more quality, faster, and…better. The problem is we did that because everybody wants that. That is good to the bottom line…

Roy:  It’s easy to sell.

Derek:  …in some ways. It’s easy to sell and we can produce that fairly quick with XP and Scrum and ComBomb and these things. We can see those things pretty quick.

The problem is that going faster without meaning, without purpose and without collaborating with the customer doesn’t mean crap.

Roy:  That’s perhaps another good benefit, too ‑‑ the using it to entice people. If you believe in the principles that are in the Agile manifesto and you want to attract people, then that might be like trying to create a culture that attracts more of it, so you can get the people that you want on‑board.

Derek:  This would be a great witness test for me. Those of you that are sitting in the audience, if you think you’re Agile and it takes you more than two minutes to deploy your software, and more than two minutes to undeploy your software, you are not Agile.

It’s all about responding to change. I don’t know how many teams I talk to that say, “Oh, yeah, we’re doing ComBomb. We’re doing Scrum. We’re doing whatever and we are totally Agile.”

They have a [slowly and dramatically] 64 hour deployment process.

Jade:  You mean deployment sprint.

Derek:  Right. I mean, how on earth can you respond to change…

Jade:  Deployment epic.

Derek:  …when it takes you 64 man hours to get something? Can you imagine going to Walmart to buy a block of cheese and them going, “We’ll check you out in 64 hours, if you can just stand in line and wait there, we’ll gladly ring you up in 64 hours.”

Jade:  They’ve got to grow that cheese.

Alan:  Well 64 hours…

Jade:  Cheese tree.

Alan:  …in some environments is very, very fast, by the way!

Jade:  Not Agile ones.

Alan:  Not Agile ones, no. The other part of this that we touched on earlier that I think we could address is the talk about collaboration and communication, right?

Over time, an Agile team, I think, does lose a significant amount of the overhead that it takes to collaborate and communicate and that can help make them work faster. If you’re spending less time in meetings, reading documents, arguing about what it really means we’re really fully collaborating.

That’s another place that it looks and can feel much faster. Overall, the real benefit there though isn’t speed. The real benefit there, again, is focusing on delivering the right thing. That’s where that’s valuable and has nothing to do with being faster.

Roy:  That makes it difficult from a measuring standpoint because the feeling that I get from it is, “It’s going to be really hard to measure, but if it’s done right, you’ll know,” type of thing. “You won’t have to measure anymore at that point to see if you are Agile.” That’s difficult to sell at first, but it kind of…

Derek:  I think it goes back to people instantly wanting to say, “Well, OK, how do we know we’re getting better?” You’re selling me this.

Roy:  I think that is a good quality in general.

Derek:  Most people say, “You should do Agile because it allows you to do more, better, faster.” Then people say, “OK, how do I measure that I’m doing more, doing it better, and doing it faster?”

We get into the increased velocity point, reduced defects. You get to all kinds of weird things. To me unless you’re in the business of selling agility to people, why on earth would you use any of those metrics to tell if you’re successful?

If I’m making hot dogs and I want to become an Agile hot dog vendor, do I really care that I’m making more hot dogs if I don’t have more people buying the hot dogs? Do I really care that the hot dogs are better quality if nobody is buying more hot dogs? Do I really care that the hot dogs are 20 percent bigger if nobody is buying the hot dogs? I should care, “Am I selling more hot dogs? Are my customers happier with the experience of the hot dog”? Those should be the measurements that I use for success.

Alan:  You don’t want to measure saying, “Well, it only takes me 30 seconds to cook a hot dog, instead of a minute and a half.” Therefore, I must be better.

Derek:  I might want to measure that if I’ve got so many…

Jade:  If you’re trying to sell…

Derek:  …customers queuing up that they’re leaving me because I can’t serve them hot dogs fast enough, right? But, I mean, it should be around those things, right?

If part of we’re not responding to change or we’re not adding the features at a rate to be competitive with whoever our nearest competitor, like, “OK, those are great,” but usually that’s not the case.

People are saying, “Well, I don’t know how to measure a software development team, so these outputs tend to be what I should measure them on.” They don’t look at the system, they look at the team.

Roy:  The role to figure out who works on what, what is being worked on and what provides a lot of value has traditionally been more of a management decision than an individual developer decision.

Derek:  That’s a huge shift in Agile and why if what you’re looking for is more, better, faster for your team, you’re not really ready for Agile, because Agile requires that you look at the whole stack. The team, the product owner and the management team, all the way to the CEO have to really be having discussions about “How are we getting better at what we’re doing”?

If we’re the hot dog vendor, how do we sell a better product to more people, make more money doing it? That conversation involves everybody from how we market the hot dog to the customer experience…

Alan:  To where do we buy them from…

Derek:  The whole thing. You can’t do that if you’re just talking more, better, faster.

Jade:  The challenge is that’s so convoluted in most companies to understand that whole picture, that it’s hard to even have the discussion.

Alan:  There are multiple layers on both ends, from collecting the requirements, there are 14 layers…

[crosstalk]

Derek:  You get to the point where when you’re at a big company, you might have a sales team that is 2,000 miles away doing something totally different from the marketing team, doing something different from the development team. It’s not that they don’t collaborate, it’s like they don’t even know each other exist. That’s how removed they are.

Roy:  Thank you for joining us today. Alan, thank you for joining us.

Alan:  Thanks for having me.

Roy:  Please join the discussion at facebook.com/agileweekly and give us your thoughts as well. Good‑bye.

Alan:  Bye.

[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.

Announcer 2:  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.

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

Announcer 4:  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.