What do you need now?


In the everyday struggle to get software up and running to support or even be your business, we often run into the same issues: complexity, dependency, slow builds, merge issues, etc.

As a former software engineer I know the struggles from some time ago, but unfortunately I still see the same problems popping up in my Agile teams in one form or another.

I often hear myself asking: "didn't you know this? Why is this a surprise for you? What have you done to mitigate this?" Etc, etc. At the same time I know about the complexity of software development. I know about legacy code and how easy it is to keep adding to it, to make it even grow faster.

The other day I was talking to a developer and after listening to his 'rant' about what was slow, complex and not efficient, etc. for some time I interrupted him and asked: "what do you need now? Right now, this very moment, if there's one thing that you can have to help you with this problems; what is it?"

"I need a faster build process so I know my tests are 'green' and I can push my code earlier, so my fellow developers can use my new code and in the process find (if any) bugs," he replied. "Who can do this," was my follow up question. He started to name some people, not in his team.

I said, "but what if, we plan a sprint for just you guys, to fix this one impediment?" He smiled and said, "but how does that add value for the marketing guys? We need to finish (please fill in whatever you can think of, in this particular case it was Google analytics integration) next sprint. That is what they need!"

So now what? Do we keep sprinting forward, adding value for our stakeholders or do we take this sprint to improve our own way of working? As I am not the product owner, it was not in my place to come up with this answer. And the product owner is not a technical person, so getting him to understand, let alone 'care' about a faster build process might be quite hard.

I took up this challenge because apparently the team itself wasn't able to get the needed attention (priority) from their PO on this technical stuff. The one thing I needed to do is to assess the value of this backlog item. If I wanted it to land on the backlog in the first place. Though I thought that was hard, in fact it wasn't. No, to assess value of this was actually quite easy. Remember that the developer was unhappy and he claimed inefficiency, leading to later discovery of bugs. Value, right there: happiness, efficiency increase, less time lost finding and fixing bugs!

The message to the stakeholders was, once the product owner was made aware and convinced: Wait one sprint extra on your feature and boom! the team did cool stuff that the customer or the marketing dept. might not get, but it has value for every sprint onwards: happier developers and increase in development speed.

The lesson I took from this is: "shall we get out of your way? You probably know best how to do your job and come up with improvements to perform better as a team."