Log in

goodpods headphones icon

To access all our features

Open the Goodpods app
Close icon
Agile Weekly Podcast - How to Use Agile Metrics to Measure Your Team and Organization's Agility

How to Use Agile Metrics to Measure Your Team and Organization's Agility

Explicit content warning

03/20/13 • 16 min

Agile Weekly Podcast

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

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Jade Meskill: I’m Jade Meskill.

[laughter]

What Metrics Can I Use To Measure How Agile I Am

Clayton: We almost forgot you are here. I want to do Agile, and I want my teams to be awesome, and go faster and be better, and do more better. What metrics can I use to measure how good I am at Agile?

Jade: K‐Locks.

Roy: Velocity.

Derek: Velocity.

Roy: I already used that one.

Derek: For me, this is so difficult because in other question I always ask, “What is your company doing?” What are the goals of your company? If you’re doing the Agile, you’re succeeding at things you weren’t succeeding at before in your company, whether that’s making your customers happier, whether that’s achieving some new functionality, or gaining more users or doing something, moving in the market.

But, to me, unless you are a software consultancy that is getting paid to be more agile, why on earth would use any metrics of agility to measure whether you are successful? Being more agile has no purpose if you’re just more agile‐like.

If I’m a thousand percent more agile, but I don’t know what the hell to build with that new agility, what’s the point of being more agile?

Jade: We are talking about problems for developers here. I’ve got to get these developers in shape. Those are problems that I need to worry about. Everything’s cool there. We’re good. Don’t worry about that stuff. The developers are what’s holding us back.

How Do I Know If My Teams Are Agile

Derek: One of the things I’ve started to do a little more, at least at the team level is ask that the direct manager for the teams to say, “How would you know that these teams are better? What are some things that you would know?”

I, basically, right off the bat say, “If your answer is more, better, faster, I’m not interested in helping you.” What we generally started to see are things like, “We want the team to be interacting, more co‐creation to happen. We want it to be easier to on‐board new team members. We want the quality of the code or the technical debt to start to recede. We want more automation. We want to be able to deploy more often.”

There’s still shallow, technical things, but they’re not velocity, or story points, or that we’re doing process X or process Y. There’s something more tangible, like, “Hey, it used to take us three days to deploy the software, now it takes us a day. We’re getting better at being able to do the deployment of the software.”

To me, that’s something, and that’s better than velocity. But to me, great, if you can deploy every 30 seconds, but you don’t have anything worth deploying, what’s the point?

Clayton: I had a manager tell me recently that they wanted to do agile, because they wanted people to stop leaving.

Derek: I’ve seen that in a couple of the value sessions, or goal sessions that I’ve done with managers, where some of it is they identify, they want a culture that is more friendly. I’ve got one team that overtime, lot of overtime, and big pushes for major events are a problem. One of the things they really wanted was more of a sustainable pace.

The reason why is because they said, “We want to stop burning people out because we’re losing good people to it.” I think those are good and noble things from a technical and team perspective. If you’ve got this great sustainable pace, but you’re crappy in the marketplace, you’re not going to be sustainable as a company.

The Only Thing That Matters Is Customer Delight

Jade: That’s why Steven Denning says, “The only thing that matters is customer’s delight.”

Clayton: If I’m kind of some average manager guy, and maybe I read “Lean Startup,” the takeaway for me is you need data and experiments, the scientific kind of thing. Then I talk to kind of the run of the mill agilist, and they say, “Metrics are kind of wishy‐washy, you don’t really need those.” Do you think that’s some of it? Where people think that they need to measure something, and science is so important. I just need and data crunch numbers and have a yes or no binary answer?

Jade: Look at the success of Frederick Taylor and scientific management. It’s build wonderful companies where people want to work...not.

Derek: I think what happens in organizations, they want “organizational agility.” Organizational agility means everybody is “agile.” If I’m the person that’s, ba...

plus icon
bookmark

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

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Jade Meskill: I’m Jade Meskill.

[laughter]

What Metrics Can I Use To Measure How Agile I Am

Clayton: We almost forgot you are here. I want to do Agile, and I want my teams to be awesome, and go faster and be better, and do more better. What metrics can I use to measure how good I am at Agile?

Jade: K‐Locks.

Roy: Velocity.

Derek: Velocity.

Roy: I already used that one.

Derek: For me, this is so difficult because in other question I always ask, “What is your company doing?” What are the goals of your company? If you’re doing the Agile, you’re succeeding at things you weren’t succeeding at before in your company, whether that’s making your customers happier, whether that’s achieving some new functionality, or gaining more users or doing something, moving in the market.

But, to me, unless you are a software consultancy that is getting paid to be more agile, why on earth would use any metrics of agility to measure whether you are successful? Being more agile has no purpose if you’re just more agile‐like.

If I’m a thousand percent more agile, but I don’t know what the hell to build with that new agility, what’s the point of being more agile?

Jade: We are talking about problems for developers here. I’ve got to get these developers in shape. Those are problems that I need to worry about. Everything’s cool there. We’re good. Don’t worry about that stuff. The developers are what’s holding us back.

How Do I Know If My Teams Are Agile

Derek: One of the things I’ve started to do a little more, at least at the team level is ask that the direct manager for the teams to say, “How would you know that these teams are better? What are some things that you would know?”

I, basically, right off the bat say, “If your answer is more, better, faster, I’m not interested in helping you.” What we generally started to see are things like, “We want the team to be interacting, more co‐creation to happen. We want it to be easier to on‐board new team members. We want the quality of the code or the technical debt to start to recede. We want more automation. We want to be able to deploy more often.”

There’s still shallow, technical things, but they’re not velocity, or story points, or that we’re doing process X or process Y. There’s something more tangible, like, “Hey, it used to take us three days to deploy the software, now it takes us a day. We’re getting better at being able to do the deployment of the software.”

To me, that’s something, and that’s better than velocity. But to me, great, if you can deploy every 30 seconds, but you don’t have anything worth deploying, what’s the point?

Clayton: I had a manager tell me recently that they wanted to do agile, because they wanted people to stop leaving.

Derek: I’ve seen that in a couple of the value sessions, or goal sessions that I’ve done with managers, where some of it is they identify, they want a culture that is more friendly. I’ve got one team that overtime, lot of overtime, and big pushes for major events are a problem. One of the things they really wanted was more of a sustainable pace.

The reason why is because they said, “We want to stop burning people out because we’re losing good people to it.” I think those are good and noble things from a technical and team perspective. If you’ve got this great sustainable pace, but you’re crappy in the marketplace, you’re not going to be sustainable as a company.

The Only Thing That Matters Is Customer Delight

Jade: That’s why Steven Denning says, “The only thing that matters is customer’s delight.”

Clayton: If I’m kind of some average manager guy, and maybe I read “Lean Startup,” the takeaway for me is you need data and experiments, the scientific kind of thing. Then I talk to kind of the run of the mill agilist, and they say, “Metrics are kind of wishy‐washy, you don’t really need those.” Do you think that’s some of it? Where people think that they need to measure something, and science is so important. I just need and data crunch numbers and have a yes or no binary answer?

Jade: Look at the success of Frederick Taylor and scientific management. It’s build wonderful companies where people want to work...not.

Derek: I think what happens in organizations, they want “organizational agility.” Organizational agility means everybody is “agile.” If I’m the person that’s, ba...

Previous Episode

undefined - Team Working Agreements Deep Dive

Team Working Agreements Deep Dive

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.

Jade Meskill: I’m Jade Meskill.

Clayton: I’d like to start out by asking everyone if you could please go to iTunes and rate this podcast if you get it from iTunes. We would appreciate that. We like the feedback. We did see one comment. Someone mentioned that we sound inexperienced. We’re going to take a look at the equipment and see if we can get that fixed.

[laughter]

Derek: What do you mean “sound”?

Clayton: I assume it’s something wrong with the border.

[laughter]

Working Agreements In The Real World

Clayton: We’re going to start talking about “working agreements.” Here’s right off the bat. Roy, you work on a team where you have a working agreement with the team that says, “No production code will be siloed, so you’re going to pair all the time.” But, the rub is that you have an odd number of people.

How does that work?

Jade: ...and then odd group of people. [laughs]

Roy: Yeah, we have an odd group of people.

Clayton: It’s the second area of problem. [laughs]

Roy: For us, that currently works by, “If you can’t silo, and we always pair, that means that if we have an odd number of people, we have three people in front of a computer.” We talked about that last time, “stooging”?

[laughter]

Derek: Is that three keyboards? Three mice?

Jade: This isn’t XP, my friend.

Roy: It’s two keyboards and two mice, you can’t really sit all across, because then you’re at too extreme of an angle to the screen, you can’t see anything.

Jade: Let’s talk about what happens when you’re in this “stooging” set up, just to set the stage real quick.

Mandated Pairing With Odd Numbers

Roy: What happens when I’m in it? Or ideally what happens? Ideally, in this case, usually what happens is, there are two people that are pairing and one person that just sits behind and peers over both of their shoulders.

Jade: Has your team discussed this working agreement and the consequences of it?

Roy: Yeah, we discussed it this morning.

Jade: OK, how’d that go?

Roy: I got shot down with an absolute “no,” when I proposed abolishing it.

Clayton: Was the reason it got shot down was because they feel very strongly about not having silos?

Roy: Yes, the reason I got shot down which is a legitimate reason and a legitimate problem, was they don’t want silos and the reason they don’t want silos is because, if someone is working alone, they can make decisions that the team is not privy to.

They’re really concerned about somebody making some decision by themselves and then the rest of the team has to deal with the consequences. There may be other ways for us to solve that particular problem but that is the group fear that we claim to have.

Clayton: What are some ideas that you had for fixing it? How could you still have that working agreement where you don’t let people silo on production code, but not do this thing where you have to peer over people’s shoulders?

Roy: Did you say still have people silo or don’t have them silo?

Clayton: Not having people silo on production codes is a totally valuable, reasonable thing to have.

Roy: Sure. I agree and I don’t. There’s other ways to mitigate it. For example, what if we switched off pairs really, really frequently?

Then you wouldn’t get the opportunity to silo for long enough to do any real damage. If you were to do a no‐siloing thing, I don’t know. At this point, the way that I feel when we’re stooging is when I’m the odd man out that’s sitting in the back like, “I am just wasting time.” I could be doing anything like answering email, or doing self‐improvement, or something like that.

I feel like that would be a better use of my time.

Working Agreement Causes As Many Problems As It Solves

Jade: To not get distracted with trying to solve that particular problem. On a team, what happens when you end up with a working agreement like this where the team feels very strongly about trying to protect one thing, but they’re actually causing other problems with the working agreement that the team has agreed on? What do you do?

Derek: I don’t really think you can force teams to do things...

Next Episode

undefined - What Does Delivering Value Mean

What Does Delivering Value Mean

Roy vandeWater: Hi and welcome to another episode of the Agile Weekly Podcast . I’m Roy vandeWater.

Jade Meskill: Jade Meskill.

Clayton Lengel‐Zigich: Clayton Lengel‐Zigich.

Everybody’s Talking About Value

Derek Neighbors: I’m Derek Neighbors and today we’re talking about value.

Roy: Clayton you brought this up earlier. What kind of context were you talking about value?

Clayton: I brought it up because Derek and I were talking about it. Derek and Jade and I were talking about it.

Jade: Derek, Jade, and half of twitter, and Clayton were talking about it.

Clayton: I think the core of it is everyone talks about value. It’s like this litmus test. If you go to a Scrum user group and somebody’s talking about something, the way that you can make it seem you know what you are talking about is if you say something like “I just focus on delivering value to the customer.”

Everyone is like “I heard that once in an article, and I read that in a book so this guy knows what he’s talking about.” Then you scratch a little bit and then if you peel back the onion what do you get?

Jade: More value.

Derek: It’s because the quality conversation ran out of gas.

[laughter]

Derek: It used to be quality, and then, once people realized that, “Crap, that ship don’t sail anymore,” they...

[crosstalk]

Derek: ...to value.

[crosstalk]

Derek: Quality’s hard.

What Does Deliver Value Actually Mean

Derek: I’m actually thinking a lot of this Lean Startup. All the Lean Startup stuff came out, and it was really pushed in from our product perspective value. I think when you’re talking technical excellence, the word that everybody uses is quality.

When you start to talk about product ownership, product management, or the proxy side of things, it’s all about value.

My question was simple, I thought. Apparently questions piss people off. And that is, what is value? I don’t know. I hear it said so much that it’s like that void word that has no real meaning.

Clayton: What if you go with the easy answer, which I think may be...the easy thing to measure is money. Value is when I make more money. if I had a feature that makes more money.

Roy: That’s probably a good starting point.

Derek: The Lean folks probably come from that lineage that really says, value is that which makes you money, that which saves you money, or those things that help you discover how to make or save money.

I think that that’s not a bad definition. What if you’re working in an industry where money is not the end goal? How do you deal with things like customer satisfaction or delight, or some of the other elements that are important? May be you could push those back to; if your customers are happy they refer people enough. If they refer people, that makes you money.

You’re really talking about making more money. I think the problem is...I don’t think people are having those conversations. They just say, “Yeah well, I met my value stream and I’m going to provide a whole lot of value and the user stories have to have a value clause.”

When you say, “OK, what is it that you guys value?” “Value. I’m just talking value. Come on man, value.”

Roy: I guess it’s kind of specific to your vision, right? Because, if your vision is, for example, to make a huge impact in the world, money may be totally irrelevant.

Value Is What You Like

Derek: I think Ron Jefferies, I think kind of put it is...it’s what makes you happy. I think that that’s a fairly reasonable answer from a Zen kind of state, right?

Roy: Who is you in this context?

Derek: Value is what makes people happy, right? If you’re making your customers happy they’re going to give you money or they’re going to do whatever you’re trying to drive them to do. If you’re happy doing what you want, you get the personal satisfaction that what you’re doing is meaningful and has a purpose and everything else.

I think that’s over simplified. can you imagine if people ran around going “Your user stories have to make you happy. Do what makes you happy. Whatever makes you happy.” Right? I think that the problem is, not that people use the word value, but rather that I don’t think people are talking about what it means.

Not a single person that I talked to could r...

Episode Comments

Generate a badge

Get a badge for your website that links back to this episode

Select type & size
Open dropdown icon
share badge image

<a href="https://goodpods.com/podcasts/agile-weekly-podcast-80099/how-to-use-agile-metrics-to-measure-your-team-and-organizations-agilit-16475021"> <img src="https://storage.googleapis.com/goodpods-images-bucket/badges/generic-badge-1.svg" alt="listen to how to use agile metrics to measure your team and organization's agility on goodpods" style="width: 225px" /> </a>

Copy