Code is just the beginning. Welcome to the rest of your journey.

When Product Focused Development Doesn't Work

Contemporary agile software development processes suggest that in order to deliver great, reliable software we should focus on making the next smallest possible change that brings the most value. Usually this works great, fantastically even, and if you're not already doing it you should definitely read more about it.

I say usually though because like most things, it doesn't work 100% of the time (always read the packet carefully folks). What they don't talk about, is what happens if the smallest change you can make is going to take a dev-pair month? What if the next 3 or 4 'highest priority' changes - as decided by the team as a whole - bring no direct value? This may sound absurd (how can they be prioritised if they bring no value?) but it does happen, especially when stories depend on technical improvements.

If you find yourself in this situation though, most likely there has been a failure somewhere along the way and your approach may no longer be working. We have plenty of strategies and blog posts about moving towards a product focused style of delivery, but what do we do when we feel like we need to move away from this mode of working?

"If your team make a bad decision which then causes them to run more slowly for several months, is that considered a failure?"

Failure is a tricky thing these days in that you really don't hear about it as much as you might expect. I've heard some say that all projects fail eventually, just to differing degrees; I'm not sure I agree with that per se but it's certainly an interesting perspective. Given how important failure is to the learning process though, we really should see more much written about it. Has it become unfashionable to talk about project failure?

On the other hand, perhaps it's more simple than that. Gone are the times where a software delivery team could easily fail spectacularly and definitively, wasting millions of pounds in the process. With a focus on iterative, agile delivery we are protected from catastrophic failures, instead experiencing only minor setbacks or a need to 'pivot'.

Under these circumstances failure becomes a very difficult thing to define. If your team make a bad decision which then causes them to run more slowly for several months, is that considered a failure? They may still release a product, and that product may be riddled with bugs, but they usually still manage to release something.

"You need a big-bang solution in order to shake off the technical debt, or the impact of previous bad decisions, but you need to continue providing value to your customers."

It's a typical catch-22 situation for the product focused development team. You need a big-bang solution in order to shake off the technical debt, or the impact of previous bad decisions, but you need to continue providing value to your customers. This means building more functionality on top of the already fragile structure, which then leads to more rework in the future, which means more delays to features, ad infinitum.

It can be very difficult to demonstrate the value of accepting a failure and cutting your losses vs bumbling along and trying to get out of the hole (dig up, stupid!). If you do find yourself in this go-slow mode as a result of previous bad decisions, there are a few things you can try:

• Centralise responsibility with a strong tech-lead - Don't go all out dictatorship, but beware that design by committee is the enemy to a quick turnaround, and can slow things down even further. The aim is to get back on track as soon as possible.
• Don't be too dogmatic - now is not the time to be following processes to the letter. You're going to have to play a few stories with little or no value proposition to get back on track.
• Consider returning to an 'alpha' stage or even a discovery stage - If you can afford to, split the team in order to work on both features and rework in parallel. Be careful to rotate pairs often to avoid anyone getting disgruntled.

If all else fails, you can try throwing everything away and starting again, but then you'll have to convince your client or your boss that you need to write this off as a total loss. Good luck with that one. Realistically, you may not have the luxury of being able to do any of these things at all. So if the process has let you down and you need to find an alternative, what then?

"It's rarely the process that is at fault... it's decisions that are made in *ignorance* of the information currently available that usually cause the problems"

Here's the nugget of truth - it's rarely the process that is at fault. Bad decisions made in the past can often irrevocably affect the future, but it's decisions that are made in ignorance of the information currently available that usually cause the problems. It's rare that decisions made to the best of your ability will cause catastrophic failure later on, even if hindsight later renders those decisions incorrect.

While we can't control anything that's already happened, the important thing is that we adapt, learn, and factor in new information as soon as possible. We shouldn't be afraid to make new decisions that supersede previous ones.

As with many such things, prevention is the best cure. There are a few things you can do to mitigate the effects of a slow-down in a product-focused team, but they're still sub-optimal. The best thing to do by far is to avoid situations in which you have to prioritise technical matters over your customers altogether.

After all that, maybe I'm coming around to this 'every project is a failure' way of thinking. Even though we have fewer catastrophic failures and we're less worried about it, the amount of time we spend feeling like we're failing seems to be greater. Maybe it's just a matter of perception, but the impact of this feeling on morale is very real.

We need to reset the bar on failure... to hold ourselves to higher and higher standards. Your biggest potential stumbling block is still the thing you most want to avoid."

Without the fear of a catastrophic failure, we're more likely to let things slip. This is good to a certain extent as it's a great learning experience. Winning or losing isn't so important, it's the taking part that matters, and the experience we gain along the way that improves our ability to deal with future situations.

There's a balance to be struck of course, but if failures are no longer as severe as they used to be then we need to reset the bar on failure. Rather than accepting our new smaller failures as routine, we need to hold ourselves to higher and higher standards. So remember - it doesn't matter how severe it is - your biggest failure is still your biggest failure, and your biggest potential stumbling block is still the thing you most want to avoid.