Today’s world is layered with technology everywhere. Everyday objects have technology embedded in them that aid and convenience our lives. Routine activities and communications run on the highways of technology. It would be apt to say that technology is at the core of our lives. In a slightly different paradigm, the corporate world is also seeing technology getting to be the core of business. Technology in effect drives business. At the same time one must not forget that business is the purpose of technology. Technology exists to drive business. And so, it seems weird when it is time to transfer over this technology to a different group, our IT teams are ready to pause business to effect the transfer.
Therein lies the need for continuous business. Continuous Business fosters a philosophy of interleaving transitions with regular business activities. In fact transition activities may actually catalyse more functional projects and spur frequent releases. To understand this notion better, we must look at three elements of IT operations.
Releases
Releases are the only true measure of a transition going well. In many ways a release is like the examination for a transition. All of the knowledge transfer and paired development will be tested when the features are put out into production. The aftermath of a release normally unearths several issues. The teams are forced to think on their feet and respond quickly. They gain a lot of confidence and competence in the process.
Most elite academic institutions do not conduct a single examination at the end of the year. The curriculum is replete with several internal assignments, quizzes and mid-terms assessments. These provide a continuous basis for assessing the performance of students. The same analogy applies to transitions as well. The new team’s capability should be ascertained over several releases.
If this notion needs to be supported, then organisations who do not have frequent releases should find ways to do them. Such measures automatically bring out efficiency improvements outside the ambit of a pure transition. In a way, transitions surface the need for frequent releases and frequent releases by their very nature support continuous business.
Functional Projects
Transitions are not just about ensuring the availability of the system. Systems also need to grow. In practical terms it means that the systems will undergo enhancements. Needless to say a transition ought to cover the capabilities to add new features as well. And the best way to attain this is to ensure there is a smooth flow of new functional projects. Projects that give the new team an opportunity to hone their skills technically and also a chance for the stakeholders to interact with the new team. It is incumbent on the leadership handling transitions to scout actively for new projects to upskill the new team. Needless to say this only bolsters the notion of continuous business.
Business Continuity
The third and final side of continuous business is business continuity. Transitions do focus a lot on this element, albeit through processes and action plans for when a production defect is encountered. However, a transition executed through multiple releases opens up the opportunity for the new team to come face to face with real issues in production. Experienced IT professionals would know that most production issues occur immediately following a release. People in the trenches know all too well about patch releases and the challenges faced by teams in making one as well. A fully competent team should have gone through production deployments, production fixes and patch releases. These are possible only when executing a transition on the vehicle of continuous business.
In conclusion
Transitions are not theoretical exercises that checks-off lists of items that the new teams have observed or sat through. These are activities where one seasoned team is handing over responsibilities to another equally professional and capable team. It’s a bit like the co-pilot taking over controls when the pilot needs a bit of rest. The only difference being the co-pilot takes over not for a few minutes but for all future journey legs.
Excellent blog, especially the concluding statement:
“The only difference being the co-pilot takes over not for a few minutes but for all future journey legs.”
I could not refrain from commenting. Exceptionally well written!
many thanks Kiersten. Appreciate your comment. Vinod
It was a thoughtful reading and could relate Vinod. Yes, the prod releases are like exam and we can improve a lot by its results.