Who owns the release?With different teams responsible for development and release, we often end up with silos.
Your development team has written a great new feature. Customers have been clamoring for it. You’re ready to release it to the wild…
Who “owns” this release?
That is, who’s responsible if something goes wrong? …if the deployment fails? …if customers discover it doesn’t work as expected? …or the color scheme gives people a headache?
Unless there’s a really good reason otherwise, I hope the answer to all of these scenarios is the development team.
Of course we exect the operations or platform team to help maintain our deployment infrastructure, and customer service to report problems our customers are facing, and graphics designers to suggest color schemes, etc. But I believe responsibility for all of these things should generally default to the development team.
When different teams are responsible for different stages or components of delivery, we often end up with silos. Walls of confusion. Segmented work. Chaos.
Don't behave like a 2-year-old
Many software development teams seem stuck in the imitative stage, when it comes to business practices.
Is your team closer to the few-rules/high-context, or the many-rules/low-context end of the spectrum?
Improve your software delivery