Happy Friday,

I took a short break from my newsletter without announcing it, and I apologize for that. My clients have called me back out to some limited travel and I'm adjusting to my new schedule, albeit slower than I'd prefer.

Our year is coming to a close, and so is a major project that one of my clients is working on. I was thinking back on the whole arc of that process and something sticks out that I just can't ignore.

How most groups are hardwired to avoid failure instead of address it.

Allow me to explain.

Most projects are built to achieve some purpose, and everyone gets really excited about the new project and its potential and wants to hurry and start building it. However, there is never a plan to validate or gather evidence that this project will achieve its purpose.

Development starts, and everyone is so eager to show progress and so they show off their flashiest bits of progress like velocity charts or completed, "Screens." However, silence fills the room when someone asks to show the software working before the end.

Sales, Marketing, Training, and Support all want to know when the thing is done so they can coordinate their support for the roll-out of the product. However, they aren't included in the process to aid their effort, and neither are end-users to know how well they'll respond to the product.

It is a pattern I've seen over and over again in both start-ups and large enterprises. It is the field of dreams approach, but if you build it, they won't come.

For my client I interviewed previous groups on their experience, considering they were coming off their turn on this merry-go-round. One said, "The whole time I was watching this unfold, your words were in my head, but I couldn't do anything about it!" They had finished a large product that went to the market and has since struggled to deal with the negative feedback and production issues.

I warned the newest group that these were the results they should expect, and I offered a few adjustments.

Instead, they pushed forward and are now experiencing the exact result of the other group.

My adjustments all hinged on a few tweaks to provide feedback to not only the efficacy of the product but to the approach to building it. I wanted people to fail smaller and fail early to address it. Instead, all the risk was accumulated until there was no possible way to ignore it or address it without causing issue.

If this is a pattern you see, look for how and when your groups seek feedback. Raise the bar for the type of feedback they experience. If they have sprint reviews without external stakeholders? Put just one external person in. If there is a track record of poor quality, adjust the definition of done and require only done software is shown/discussed in that review. Those two changes create feedback early and often in a way that helped people adjust their methods to address the risk and failure they'd otherwise happily accept.

Happy Holidays!

Ryan