Recently, I spoke with a major airline about their adoption of Agile, which they considered critical for a major customer loyalty project. Based on previous experience, the dev team expected the business users involved in this project to move slowly, so they saw Agile as a strategy for being ready to pounce on any opportunity to make progress. How slowly? The current estimation for the project's completion was....[drumroll]...five years. Now that's a customer loyalty program ensured to be left with just the most loyal customers imaginable.
As hair-raising a situation as this might be, it's hardly unique. App dev teams contributing embedded software elements to hardware products must time their deliverables to arrive at key landmarks in the overall release schedule. Compliance requirements weigh down software development with extra documentation and validation. Flawed requirements force teams to go back to the drawing board. Dev managers live and die by the schedule, and there's always something that could jeopardize the schedule. Development is pretty pointless unless someone delivers the bits and bytes, but dev ops still remains a relatively mysterious and unpredictable process for dev teams, over which they have little control once they throw their code over the wall.
A new business model is emerging, and it depends heavily on software development. Many companies are dropping many of the traditional barriers between product development and customers. Without investing in software development, these efforts, no matter how well-intentioned, will have a better chance of failing than succeeding.
The simplest term I can concoct for this business model is "the transparent company." There are other defining characteristics of this corporate strategy, such as confidence in the ability to execute, and a very different sort of relationship with customers. However, as companies have been decidedly opaque to their customers, any transparency is a striking detail in itself. Hence the term "transparent company."
Wave Hello To The Engineer Fixing Your Bug
Here's an example of what I mean. I don't have to be a customer of Atlassian to know what issues Atlassian's engineers will fix in the next release of their wiki product, Confluence. That information is publicly available at this link. Diving into an issue at random — I chose "Database deadlock during initialisation of plugins in sql server" because it sounded fairly dire — I can see which engineer is working on this issue, Don Willis. I can even see the daily activity stream for Don Willis as he works on this issue and other projects.