This past fall, the U.S. government shutdown and the HeathCare.gov launch debacle both quickly devolved from ideological differences on policy to full-fledged finger-pointing exercises. It did not matter “why” things failed, it only mattered “who” was at fault. Those whose job it was to fix the issue seemed primarily concerned with looking good to their constituents and passing the blame to someone else. They were fixing the blame and not fixing the problem(s).
For developers, IT managers or anyone involved in the software development life cycle, this behavior is all too familiar. When an application fails, the first reaction is not often collective reflection and analysis. It is, “It was not my fault. It was theirs.”
(Related: Best practices for agile and DevOps teams)
This has to stop. The outcome of such IT finger-pointing might not mean the collapse of the world’s economy, or not being able to get healthcare coverage for your family. But the effects can severely damage any company’s customer and brand reputation and negatively impact revenue.
Here are some ways organizations can end finger-pointing, develop and release better-performing applications, and improve development and overall IT efficiency.
We all know the saying of what flows downhill. In a waterfall environment, it’s not always water.
The rigid structure of these development environments breeds finger-pointing. Long lead times and focus on only one release lead to an “all or nothing” mentality. At the end of six months (or two years), you either have a working application or you don’t. Even if it works, that app probably does not meet the current needs of your customers or business, as “requirements” were approved six months to two years prior.
With a top-down (command-and-control) and silo management approach, blame or praise is assigned individually rather than collectively.
With an agile approach, you benefit from a team environment, greater collaboration, and collective project success or failure. All stakeholders know what is happening on a daily basis, so there are no big surprises at the end of a build.
Lines of communication are open, nearer and more interconnected. If something needs fixing, a developer leans over to speak with the tester next to him or her and gets it done now.
This greater sense of ownership and accountability reduces finger-pointing and energizes team leaders and members to perform at their very best. They know if they stumble, the team will have their back, not stab them in it.
Along with agile, organizations that adopt a DevOps mindset will reduce internal bickering and fighting. Notice I said mindset, not restructuring. There are many ways to classify DevOps that do not include a new organizational chart. It is an alignment of all tools, people and resources across the entire software development life cycle.
The DevOps mindset is one of shared accountability. Development teams cannot wash their hands of problems the moment they hand an application over to operations. Operations cannot shift the blame to development when an application fails in production.
It is more pervasive than just the short handoff piece. It is a long-term approach that should involve executive stakeholders from the business and IT, performance engineers, capacity planners, and disaster-recovery specialists.
It is about breaking down silos and fiefdoms to develop, test, and deploy better applications faster and cheaper. It delivers the highest value to your customers quicker and significantly reduces the internal (wasteful finger-pointing) and external (competition) risks, all while developing self-managed, effective teams with high engagement.
Agile and DevOps focus on the human aspect of finger-pointing. But, in order to produce correct results, developers and testers need correct data. This is where virtualization plays a key role in improving organization efficiency and cohesion.
A common cause of finger-pointing is when an application that performance- or load-tested well in the lab fails in the real world. Development says that capacity was not where it should have been. Operations says it was not developed or tested correctly.
This argument can be avoided if organizations test applications under virtualized real-world network conditions. These can be taken from third-party sources or directly from internal APM data. Only with this data allowing for virtualized networks, combined with virtualized users (load) and virtualized services, can teams accurately predict how applications will perform in the hands of real end users and eliminate any surprise launch failures.
The last piece to reduce finger-pointing is to leverage automation in development, test and production. This prevents the excuse of forgetfulness at some point in the software development life cycle. If no one forgets to run an important test or merge builds, no one can be blamed.
Your release-management process needs to include automation of builds with functional and performance testing. Such testing should be built into the continuous integration, deployment and monitoring processes. This allows for the automated comparison of test environment results compared to current production environment results.
Automate for anything you can to take the human element out of the equation, while enabling you to drive quality through automated regression suites for functions, performance and security with every build in every environment. This will reduce time to production for your high-value features, build quality into your process, and enable your professionals to focus on measuring and increasing quality rather than figuring out what went wrong and when.
Increased quality, faster time to market, engaged and committed employees, and valued customers with high-performing and resilient applications. When this is your output, there will be no need for finger-pointing.
Todd DeCapua is the VP of channel operations and Services for Shunra Software, which sells network virtualization and application performance test tools.