Linda was frustrated! A third-party server in the development environment was down again! She was in the midst of a rather large, high-profile feature enhancement for a new product. The feature involved a rather complicated integration with a third-party product. The timelines were tight (as usual). Under perfect conditions, she’d have felt confident she could finish on time. However, these were far from perfect conditions. The third-party application that she was integrating with had a notoriously unstable development environment. It went down regularly! It usually came up successfully, but on occasion, a call to Dave was required. He was the developer who had become the defacto expert. He’d done the initial integration with the product and had encountered almost every error scenario that was likely to occur.
If Dave’s intervention wasn’t required, Linda could have the server back up in 15 minutes. However, if a call to Dave was required, it would usually be 30 minutes to an hour before the issue was resolved. While a number of developers had spent a bit of time trying to make the environment more stable, each of them had ultimately given up when it began to look like there wasn’t going to be a quick fix. They had other delivery timelines.
Suggestions to management about making the environment more stable had been met with resistance. Everybody agreed it needed to be fixed. However, the real cost of the problem wasn’t tangible enough for management to agree to fix it, especially when nobody could provide a reliable estimate on how long it would take.
Linda was not the first to feel the pain. There had been numerous others before her who had worked on integrations with the same product. She had some creative ideas on how to fix the problem. One idea involved using another vendor. Another idea involved a refactor of the integration architecture. However, each of these ideas involved significant effort. When she’d suggested them initially, her manager had said that there wasn’t enough time. This new feature was too important, and was needed immediately.
So, she came to the same conclusion that the others before her had. She’d make a note during the sprint retrospective that somebody needs to make the development environment more stable. But at the present time, she was too busy! She restarted the troublesome server. Fifteen minutes later, she was once again making forward progress on this new high-profile feature that was going to "save the world."
If you are interested in seeing how this problem may have been avoided, check out this post on site reliability engineering.
One of the habits, as taught by Stephen R. Covey in " The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change " is called Sharpen the Saw. In this principle, Covey relates of a man who has been very busily sawing down a tree for hours. When a neighbor asks why he doesn't sharpen his saw, he replies that he's too busy getting work done. While this seems like an incredibly simple and obvious concept, it is often overlooked.
There are countless scenarios where teams continually encounter the same issues time and time again, yet do not invest the time required to fix the issue permanently. Often, these teams are so focused on tactical work such as producing more features, that they’d rather absorb the cost of working around a known issue. These issues usually become a "death by a thousand cuts," incrementally and continuously eating away a team’s productivity. The long-term cost of letting these issues linger usually is exorbitant. Additionally, this creates a culture in which engineers no longer seek to fix problems because they know that they won't be granted time to work on them.
While innovation to processes or technologies are occasionally stumbled upon by engineers, the odds of an accidental encounter are rare. They are most often discovered by teams that have created a deliberate and focused process for generating innovation. The skills and activities required to fuel this process are outlined by Jeffry Dyer, Hal Gregersen, and Clayton Christiansen in " The Innovator's DNA: Mastering the Five Skills of Disruptive Innovators " and described below as follows.
As a leader, you can talk about innovation all you want. However, you will not see results unless you allocate specific time towards innovative activities. Numerous studies have shown that organizations that devote time to discovery and experimentation activities are significantly more innovative than organizations that don’t. While this should come as no surprise, it is interesting how many organizations talk about being innovative, but then don’t allocate time for their development teams to engage in these types of activities.
The discovery and experimentation activities associated with innovation are often time-consuming. If your team is too busy with daily tactical work, there will be no time for your team to generate innovative improvements to your processes and products. Your team will become just another one of the many teams that is "too busy to save time…"
If you are interested in more ideas to foster innovation, you can view this post about Increasing Software Team Innovation and Collaboration.