Guest Post by Tommy Quitt - Business Mentor at WECHANGE
By now we understand that in today’s world R&D and operations must work closer to achieve the goals of the company. Fast deployments, short iterations, quick value dictate cooperation between these two departments. (See Part #1)
Well, the main reason is that they are different. They are different in what is important for them, the tools they use and even their language.
How come two groups working in the same industry and in the same company can be so different? The first aspect is what they deal with every day.
Developers have challenges around Functionality. They must build code that isPerforming, Testable, and of course of good Quality. If they are really good they would also try to deal with Extensibility (minimum effort to use the same code again in different scenarios) and Scalability (software does not limit us to deal with infinite amount of data, users, traffic etc.). Some of other R&D challenges would be around the Release process: the effort to streamline code management, testing and packaging into a smooth working practice.
Our Delivery friends (often referred to as “operations”), have completely different thing on their minds. They're occupied with the effort to build a system or systems that meet customers or markets requirements and that can guarantee the revenue of the company. Thus, they're interested in Availability, Load management andSLAs. They try to implement proper Monitoring of the production systems and to have Diagnostic tools that would allow them, once a problem arises, to quickly identity the root cause.
If you would listen to a chat between two developers you would probably hear them discussing Code, how to Optimize memory or performance, or simply how to get one module to work with the other.
In a typical Delivery lunch you would hear stories on “how I was woken up in the middle of the night because the system was down” or how somebody managed to automate deployment or monitoring processes. They are all about standards, configuration and implementation of customer specific business processes.
Naturally, the language used is different. Developers use words like “Pointers, Sprints, Scrum, Compilation, Libraries” etc. while delivery talk about “Change management, availability, Clusters, DMZ, SNMP, Scripts” etc.
The most significant difference, to me, is about the definition of done: When do I deem something complete and finished.
Developers have a few items on their checklist: Have I implemented what I committed to in the sprint or release? Does it work? Have all of my unit tests passed? Most developers “make it work” usually on their own machine or in better cases on a “development server”. That is of course not enough for operations. To them testing must happen on multiple instances, different topologies, concurrent users and traffic, big amounts of data, complex network topologies and endlessly more scenarios that resemble real life customer situations. For the Delivery, a system is stable only when it was running for days while being stressed in all dimensions. They want to run parallel tests to make sure there is no regression of functional or non-functional aspects of the system in the newly released version. They want to make sure they can install the latest version and still be able to rollback in case problems arise post installation. In other words, when the developer thinks “it is ready”, the delivery engineer know that a long road lies ahead before this can go into production.
So can these two different worlds work together? Of course they can. Hold on for the next post…
Tommy Quitt helps software organizations' managers make the leap forward by implementing the changes and improvements they always wanted to happen.
No comments:
Post a Comment