Thanks for the advice. It makes me feel even more useless.

Collaboration is a great thing. Helping a peer, or a colleague, is wonderful.
It helps us both get better at whatever it is we’re doing.

When someone is doing a job and others from the outside offer advice, tips, suggestions, or whatever, it’s meant to help. Sure. We all get that. But when someone is doing a job, and sees a seemingly insurmountable multitude of areas for improvement, and someone else keeps offering them ideas and suggestions, it can have the opposite effect. Instead of being taken as good advice or a welcome suggestion, it sometimes feels like there’s just another thing that you’re doing wrong, or are doing as well as you could.

Choose your battles, go for little wins.

I’ve seen teams that have such major issues in their code, their teamwork, their organization. And it’s impossible to fix everything at the same time. As an outsider to the team, trust that the team is improving, and find out what’s going on before you offer suggestions to fix something. It’s likely the team already knows. Offering your suggestion, while likely intended to help, can have the opposite impact, in pointing out yet another thing that isn’t going well.

Instead, find something that is going well. Instead of offering suggestions, find a way to congratulate the team on what they’ve managed to accomplish. Find out what the team is working on now to improve. If there’s nothing, sure, offer a suggestion. If there are already things being worked on, shut up. Seriously. Don’t point out yet another thing that’s not working. It’s not possible to fix everything at the same time. And your suggestion, while likely valid, can impact those who are trying to make thing better – when all you do is offer ways to make things better, you’re pointing out things that aren’t working the way you’d like them to, and I’ll bet they’re things the team also knows isn’t working the way they want them to be working.
It’s a great way to help people feel even more useless and depressed that they’re not fixing everything. It’s a great way to point out that people aren’t contributing as much as you think they should. It’s not meant to be a negative thing – I get it. You’re genuinely trying to help make things better. Be aware of how others might perceive your suggestions.

As I’ve been writing this, I’m reminded of a time I took my car in for servicing. One day, my car wasn’t working. At all. I couldn’t even start it. It turns out, something in the engine had locked up, or so the tech thought. But, my window wash pump was also broken. And a belt was looking a little worn, so needed to be replaced. 

But until the tech could get my car started, the belt wasn’t an issue. The window washer pump didn’t matter. The car wouldn’t start. So replacing the belt isn’t the fix I needed. At least not at this exact moment.

Thanks for the suggestion, car service consultant. But you need to make my car go. That’s the only issue we should be talking about.

When there’s disfunction on a team, or when code quality isn’t where it should be, or when there are dependencies on other teams for systems, or when the daily stand-up isn’t being done the way the book says it should be, or when the stories are written cleanly… None of this matters if you can’t check out code. None of this matters when your local environment crashes every four hours.
Suggesting that the team should do a code review (or whatever suggestion you might have) doesn’t really help. At least not now.

Thanks for your suggestion. Thanks for your advice. I know you mean well. But it makes me feel like you don’t think I’m doing my job. It makes me feel even more useless because I can’t fix everything. You’ve just pointed out yet another thing I know isn’t working the way it should be. If you want to be helpful, have a look at the action items the team has identified from their last retrospective and help us fix those. We’ll get to whatever you might want to suggest today when it’s really our most pressing opportunity.

Don’t be too focused on doing Agile

A friend recently sent me a post about agile. It was an interesting take on what’s happened since the Agile Manifesto was written 14 years ago. And it reminded me that too often, we see companies, teams, groups of people focused on doing, what they consider to be, agile. It’s what makes frameworks like SAFe and DAD appealing to large companies. They don’t know what to do, and these frameworks offer a solution to that problem… They propose that by following their process, the company will realize the benefits of agile. Or maybe it’s not that much – perhaps it’s a team or two trying to follow the Scrum framework. The interesting thing about all of these is that they’re starting points, and not destinations.

I was working with a new Product Owner on a Scrum team recently. In one of our first interactions, he asked me what we could be doing to be more agile. I think I may have scared him a bit when I explained that I don’t think our goal should be to quantify or focus on how agile we’re being. That shouldn’t be the goal. Odd, given that I tell people I’m an Agile Coach (not that I really know what it means to be an Agile Coach, but it sounds cool). I explained to him that our goal should be to deliver higher quality software, working software, delivering value to our customers, however we want to define value. At this company, profit and NPS are two key metrics. So let’s figure out a way to do deliver more shit that our customers love and will advocate to others about, and let’s also figure out a way we can make more money. It just so happens that one of the ways we can do this is through a better, tighter, shorter feedback loop with our customers. And that’s where agile fits in this case.

It’s not about following a process. Being agile isn’t about doing Scrum, or whatever flavour of process or framework happens to float your boat. It’s about uncovering better ways of developing by doing it, and helping other do it. (Wait… I’ve read that somewhere before).

In my opinion, it’s about finding ways of continually improving. Too often I’ve seen people and organizations focused on “doing” agile (or what they consider this to mean), rather than focusing on continually finding ways to get better. And I’m not talking about a little better. Or working a bit less overtime. No… I’m talking about massive improvements, and gigantic changes in the way we think about business, development, and our customers.

If you’re using a framework, use it as a starting point, and not a destination. Figure out what works for your business, employees, and customers today. My guess is that what works for you today won’t be what will work for you down the road. It’s been said that the only constant is change. Agile is all about adapting to and responding to the change that’s inevitable in a way that works for you.

Don’t be Focused on Doing Agile

A friend recently sent me a post about agile. It was an interesting take on what’s happened since the Agile Manifesto was written 14 years ago. And it reminded me that too often, we see companies, teams, groups of people focused on doing, what they consider to be, agile. It’s what makes frameworks like SAFe and DAD appealing to large companies. They don’t know what to do, and these frameworks offer a solution to that problem… They propose that by following their process, the company will realize the benefits of agile. Or maybe it’s not that much – perhaps it’s a team or two trying to follow the Scrum framework. The interesting thing about all of these is that they’re starting points, and not destinations.

I was working with a new Product Owner on a Scrum team recently. In one of our first interactions, he asked me what we could be doing to be more agile. I think I may have scared him a bit when I explained that I don’t think our goal should be to quantify or focus on how agile we’re being. That shouldn’t be the goal. Odd, given that I tell people I’m an Agile Coach. Not that I really know what it means. But it sounds cool. I explained to him that our goal should be to deliver higher quality software, working software, delivering value to our customers, however we want to define value. At this company, profit and NPS are two key metrics. So let’s figure out a way to do deliver more shit that our customers love and will advocate to others about, and let’s also figure out a way we can make more money. It just so happens that one of the ways we can do this is through a better, tighter, shorter feedback loop with our customers. And that’s where agile fits in this case.

It’s not about following a process. Being agile isn’t about doing scrum, or whatever flavour of process or framework happens to float your boat. It’s about uncovering better ways of developing by doing it, and helping other do it. (Wait… I’ve read that somewhere before).

In my opinion, it’s about finding ways of continually improving. Too often I’ve seen people and organizations focused on “doing” agile (or what they consider this to mean), rather than focusing on continually finding ways to get better. And I’m not talking about a little better. Or working a bit less overtime. No… I’m talking about massive improvements, and gigantic changes in the way we think about business, development, and our customers.

If you’re using a framework, use it as a starting point, and not a destination. Figure out what works for your business, employees, and customers today. My guess is that what works for you today won’t be what will work for you down the road. It’s been said that the only constant is change. Agile is all about adapting to and responding to the change that’s inevitable in a way that works for you.