How high is your wall?

One of the most common complaints heard on software projects where inter- and intra-team communications have broken down is that something has been ‘thrown over the wall’. In comes a deliverable (documentation, code, tests, even whole applications) with no warning, no instructions, and no context for the recipients.

Developers throw software over the wall to the QA department for them to sort out the bugs. Business analysts throw requirements over the wall to developers so they, the analysts, do not have to talk to the technical staff in any meaningful way. The more handoffs you have, the more opportunity this phenomenon has to cause waste. Many agile and lean practices are focused on breaking these walls down within teams, or, better yet, preventing them from being built in the first place. 

But those who have likely suffered the most from this dysfunction are deployment and support organizations, those responsible for shepherding software projects to the point where they can be used and supporting those applications once they get there. In many organizations, project teams have thrown a lot of bad software over the deployment wall and, in response, the gate keepers on the other side look to build their wall as tall as possible. If you keep getting hit hit on the head by failing software coming over the wall at you, making it harder and harder to get faulty software into production is the natural response.

How is the done? Many ways, of course, but perhaps you have seen unnecessarily lengthy release documentation, onerous approval processes requiring coordinating a huge number of uninvolved stakeholders, and quality assurance process that are all backloaded to the end of the project but don’t actually assure quality.

The problem with all of the above is that these approaches do not actually keep faulty software out of production. It still gets to production, it just takes longer. Even worse, even if the project teams have put together quality software, the journey to production just takes longer without adding any value. 

In contrast, some organizations look to build bridges between their delivery and their support organizations. By this I mean establishing a clear and predictable path from the development process to the production environment, as free from obstacles as possible but still focused on close observation of those applications attempting to move into the production.

There are lots of technical practices available to help out, like continuous integration, testing automation, and deployment automation. But one of the most straightforward techniques is to keep project teams focused on their software until it is in production. This eliminates unnecessary handoffs between teams and links a project team’s success to the ultimate goal: software in production that delivers value to the business not an interim goal of merely getting software ready to deploy.

It is right and proper that organizations control deployment of software into their production environments. But the right mission is to get quality software into production as soon as possible, not make it as difficult to as possible to get any software into production.

---