Fostering Innovation on Software Teams

Fostering Innovation on Software Teams

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.

Innovation as the Solution

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.

  • Questioning - encourage your team to ask "why", "why not", "what caused", and "what if". Encourage your team to dream up solutions to artificial constraints. For example, "We need the entire software release process to be automated, with no human intervention." Remove existing constraints by asking "what if?" For example, "How would we do things differently if we didn’t have any existing customers that required our support?"
  • Observing/Awareness - you need to encourage your team to be constantly observing what is working well and what isn’t working well. A structured approach to this type of observation will start generating innovative ideas on how to improve those things which aren’t going so well.
  • Networking/Socializing - when problems are discovered, each of your team members should be encouraged to socialize these ideas with other members of the team, other teams within the department, and other members and teams outside of the department. Sometimes the most innovative ideas are generated by those who are furthest from the problem, or those who seem the least likely to have the proper solution.
  • Experimenting - experimenting is one of the key differentiators of innovators vs non-innovators. Whether a success or failure, the value of an individual experiment is far greater than its conclusion. Often, the information learned during the execution of an experiment is surprising and unexpected, and not necessarily related to its conclusion.
  • Associative Thinking - Those who are continually questioning, observing, networking and experimenting often are able to draw insightful conclusions from the results of several unrelated experiments and associate them in ways to create innovative solutions to new problems. They tend to use both artificial and real constraints to stimulate associative ideas and solutions that often weren’t apparent.

Allocate Time for Innovation

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…"

Increase Software Team Innovation and Collaboration

If you are interested in more ideas to foster innovation, you can view this post about Increasing Software Team Innovation and Collaboration.

Related Posts