Guest Post by Tommy Quitt - Business Mentor at WECHANGE
The spotlights on the dance floor are on a couple dancing passionately. Ms. Development and Mr. Delivery are finally together. But is this really a dance or a power struggle? Who leads? Who is being pulled?
In the upcoming few posts I will be discussing the challenges that delivery organizations face today and how they can solve some of these issues by adopting principles and agile methodologies.
Delivery functions developed in organizations that needed some level of customizations or even simply installation and integration of their products to final customers. The delivery group would take the finished product and using either internal or external (we will explain that later) customization options made sure the system will provide value to the customer and more importantly, be stable and resilient.
If we do not talk – we have done a great job…
In the organizations I used to work for, the level of “independence” of the delivery organization used to be the measure for the completeness and the quality of the code delivered by the R&D organization. If my code was well designed, with the right customization options (like configuration files, business rules, etc.), then a delivery engineer should not have to contact me with questions or worse, with requests for code changes that she needs for a successful on-premise installation. In other words, minimal interaction between delivery and R&D are the indication of a well architected system.
But see what happens in reality: The delivery team struggles to install and integrate the system and often they are frustrated because real life, production system requirements like performance or configurability were not considered by the R&D.
Now, that was very logical. We had two completely different skills here: on one hand, the engineers, “scientists” that are busy with writing the most general, best performing, bugless code and on the other hand the guys “on the ground”, “the infantry” if you will, that knows best the customer and should bridge between the product and the specific customer requirements and integration. The bridge between these two sometimes distant universes was the implementation (carried out usually by non-compiled code or interpreted code or scripts, parameters, etc.).
The “Solution”?
So imagine the CEO having a serious talk with the R&D Manager: “I expect you to care not only about functional requirements, but also think about nonfunctional requirements like performance, stability, load balancing, security etc. I do not have the luxury of investing weeks of works after your release in installation and integration. I need the software deployed as fast as possible.”
Then the CEO turns to the delivery manager: “At the same time I need my professional services team to work very closely with the R&D team for the same reasons – I need a flow of releases deployed to production contradictory to the previous long cycles of release->customization->testing->deployment we used to have earlier.”
So the next steps seem very logical: let’s bring these two together or even put them in the same team. That is what often happens: management takes a decision to “implement DevOps” by forcing R&D and delivery to work together for the same goal, “deploy a release every week”, for example, and then finds out that it does not work.
The reasons for that are diverse and routed deep in the nature of these two professions. But let’s leave this for our next post.
What type of relationship have you witnessed between Delivery and Development? Share with us in the comments below.
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