What if your developers were able to deliver a better design than you had envisioned?
Significant shifts in thinking need to take place in an organization that wants to become more agile. A big one is embracing the attitude that including people from all levels of the software organization earlier in the design process gives you more agility. If you have an idea for a new feature, you should want to hear the thoughts of those responsible for developing it, testing it, deploying it to prod, and supporting it in prod – as well as the users – as soon as possible.
In other words, you don’t want to spend a month talking about it with just a few people and fully form your proposal before having a meeting to show the developers what you have designed for them to build. The problem with that approach is that as soon as they’re introduced to it, they are under the gun to get it done quickly. Regardless of how valuable developer suggestions might be – even if they would prevent future problems or be more cost-efficient – there just isn’t time to consider them. Doing so at that point would cause you to have to start from scratch with the design when you’ve already spent a month (and considerable cost and effort) headed in a certain direction. That’s a lot of pressure to keep pressing forward, pressure that is hard for most teams to resist for the greater good.
But prioritizing inclusion over specialization has some pretty powerful side effects.
Recently, a team I was working with made a shift to start including the developers in the story-creation process before anyone else had done anything but discuss the name and general idea. We started experimenting with the idea of having a meeting where we used story mapping to talk about how to implement the feature, and what our goals were, and how to split it into small stories to utilize the power of small-batch sizes. It was only for a single new feature, and we waited to have the meeting until the pair of developers who would work on it was done with their previous story and were ready to pick up new work. That way, there would be no time to forget what was discussed between the story creation and the actual work being done. It worked, but nothing remarkable came of it.
Or so it seemed.
See, at the same time, the team had been working on moving from a “rush” culture to a “quality” culture. The managers had been regularly reiterating the importance of doing things well over doing things fast, which led to an increased sense of psychological safety.
As a result, when the time for the story demo came, a surprising thing happened. The developers diverged from the stated acceptance criteria in the story and developed a better solution than was thought possible at story creation. The change they made had been discussed in the story-mapping session as something that would be nice to have. But at the time, it looked to be too difficult, so a lesser solution was decided on.
What happened here? The developers, without even realizing it, had begun to feel the freedom and empowerment to improve things because they understood the goals better and had less fear around not doing exactly what they were told to do. They were all starting to experience the benefits of an atmosphere of psychological safety and inclusion. The business discovered a little more that they could trust the developers to make good decisions around the design, and the end users benefitted from an easier-to-use interface.
That is how the culture of an organization starts to shift to a high-trust environment with greater psychological safety, which has been linked directly to high producing, high performing companies.
