One day, I was driving my 2008 Volvo back home after a few routine repairs. I had moved into a new apartment almost a year earlier and I finally decided to give a local garage a chance.

Things had gone pretty well so far — they did all agreed repairs in one working day and quoted me a reasonable price. I was feeling quite positive about this new place. It also didn't hurt that it was so close I could get home in 5 minutes. I didn't manage to go back, though, because I noticed something. At the nearest junction, I turned the car around.

The conversation I was about to have has shed new light on my own approach to clients as a software engineer.

Picking an Agile Team

If you know me, you would never think of me as a 'car guy.' I have close to zero car knowledge or related interests. Despite that, I do my best to keep my Volvo in good shape. I was glad about my previous local shop, but it was too far from my new location. I chose the place based on its rating on Google and a forum. They also had a charming picture of the team on the landing page:

Looking back, it must have been the picture that brought me there. It is so much like the one on Evojam's careers page:

Anyway, I got back to the repair shop and explained what the problem was. I was able to set the temperature for all the driver air vents, but the ones on the right were all stuck in heating mode. I knew the engineers had looked into another issue with air-conditioning, so it looked to me like they broke a part of climate control.

This is where things didn't go as I expected. The manager argued that this new malfunction could have nothing to do with them. He followed me to the car to see what the problem was. Sitting next to me, he reproduced the issue and agreed that something wasn’t right. Still, he said there was no way it was their fault.

Either way, I asked them to look into it. It wasn’t ideal but still fine with me to leave the car with them for one more day. At that point, the manager made it clear that he didn’t like the idea. They already had a lot of other work planned for that week.

Can you imagine?!

If you ask me, the climate control system was working fine when I came the first time.

This is not to say that I cared whose fault it was. All I wanted was for them to look into it and find a way to fix it. The weather was only getting warmer at that time of the year. Whoever was going to sit in the passenger seat would definitely need functioning air-conditioning.

So, they didn’t want to look into it immediately. They had other work planned.

The misery of Agile

Persuading the manager to let me leave the car took some effort. All I got from him was a promise that they would try to look into it till the end of the week and let me know. On my way home, I felt quite upset. The manager treated me like I was trying to blame him for something he had nothing to do with. He also put his plans for the rest of the week before my problem.

Luckily, when I need to calm down, nothing works better than a short walk. And as I had to leave the car there, I was forced to take one. The weather was not bad, which motivated me to look for a less unnerving perspective on the events.

All the guy did was protect his people from unplanned work. Above that, he had other customers coming in for the next few days. They also needed their cars fixed. What was I expecting? Were the engineers supposed to look into my unexpected issue after hours?

What the manager did for his people was not different from sticking to the scope of a Sprint in Agile. If you think about it from a quality assurance perspective, he reproduced the problem to check if it was a ‘bug’ (their fault) or a ‘change request.’

So, this is what it’s like to deal with an Agile team that sticks to their fancy rules. Not very pleasant, I must say.

Finding empathy in Agile

This whole thought process was a big effort. To consider the situation from this angle, one needs to look past the initial emotional response. Put the rational part of one’s mind to work. It is a lot to expect from someone you charge for your services. In that case, does rejecting unplanned work go against maintaining good client relationships?

The customer is not always right. If they were, they would not need our expertise or guidance. But I reject the idea that they are the enemy. Being treated like one when I came back to that repair shop is what made me angry. Yet another thing was not working, and I had to leave the car again. It does not take that much empathy to understand that I would be upset.

Simple things like telling someone how sorry you are for their trouble can change a lot. You can still reject unplanned work afterwards, in fact, it could even make saying ‘no’ easier.

In software development teams, we like to unite against ‘the business.’ These vicious enemy forces, trying to break our beautiful project scopes all day long. It is not very often that we wonder who benefits from the code that we ship. Or what's the best way to lead these people from the initial sketchy ideas all the way onto working solutions.

Instead, completing tasks and watching them move across our Scrum boards make us feel good. It is the chemical called dopamine speaking — the same feeling of excitement as when a new notification pops up on your phone. And it is very addictive.

The only problem is that moving tasks from left to right can feel pretty pointless in the long run. Especially if you have no idea what good your work does.

Let me give you an actionable idea. It is called the Empathy Map. You can work on one either by yourself or treat it as a team exercise. It is very simple.

You pick one person that benefits from the work that you do. It can be a stakeholder of your current project or even a team member in case you work on internal tooling. You place that person in the middle and divide the space around into four. Then, you tag each quarter with one verb: ‘says,’ ‘thinks,’ ‘does,’ and ‘feels’. Try to fill in each section with at least three of your guesses about the person you picked. It would be perfect if your work can help with some of those things.

Here is an example of an Empathy Map that I worked on of you as my reader. Go ahead and try to fill in the blank notes with more examples:

Developing empathy for the people that benefit from your work is good in more than one way.

If you understand the needs driving the requirements, you will write better code. All the change requests coming your way will make more sense. When things make sense to you, it is less frustrating to change the same code again and again. But most of all, you give yourself a chance for a little oxytocin. Your body releases it as a reaction to positive social interactions. It is the feeling you get when you are glad that you were able to help someone.

The alchemy of Agile

You could wonder which is more worthwhile. Is it a dopamine shot after merging another pull request? Or is it oxytocin once you ship a feature that makes someone's life easier?

Imagine you are walking down a street. Your phone buzzes and you see that someone liked your last post on social media. As you hide your phone back in your pocket, you notice a wallet falling out of someone's bag. You pick it up, stop that person, and give it back.

Now, try to guess which you are going to remember — having done something kind for a stranger or the likes you got under your post? If you are thinking ‘the wallet,’ you are going for oxytocin.

Relationships with the ones that benefit from your work are more complicated than that. The customer is not always right. If your primary goal is to help them, saying ‘yes’ to everything is reckless. And for that matter, most people don't want to always hear ‘yes.’ They expect to use the knowledge of experts in the field to their advantage. Meaningful advice in turn is only possible if we commit to understanding the problem.

No one spends all day trying to make our job more difficult. If we are clear about certain ground rules, unplanned work can come our way a little less often. This does not mean that it will never happen. If there is a good explanation for it that you understand, are you going to prefer sticking to a plan?

I don't know about you, but I never remember ‘completed Sprints,’ while I do remember the times I was able to help.

Timely delivery

I did not hear from the garage till the end of the week. It was late Friday afternoon when I got a call from the repair shop. The car was ready. When I asked if I could still pick it up, the manager said he would stick around for up to an hour past closing time, just so I could have it.

In the end, they did look into the issue in my car as soon as they got a chance. Driving back home, I felt very positive about their work ethic. They had not committed to unplanned work, but they managed to squeeze it in. It would all have been for nothing, though, if I could not have the car for the weekend. The manager went out of his way to make sure I did.