In those days were software development is outsourced or companies are acquired and merged frequently, the problem of transferring the ownership of applications and software is more than relevant. In his book “Software Ownership Transfer: Evolving Knowledge Transfer for the Agile World”, Vinod Sankaranarayanan, explores this topic from both a theoretical and a practical point of view.

The main support of the book is an actual software ownership transfer project that took place between an Indian team and the its UK counterpart. The book discusses all the aspects of the knowledge transfer from the cultural differences to the measure of the ownership transfer progress and success. The book is well written, with a good balance between the parts discussing the concepts and the experience report from use cases. Although the title of the book might make you think that it is recommended only to people dealing with software ownership transfer, I think that it provides an interesting and unique perspective on many software development and maintenance issues that make it valuable for all managers involved in software development.

Reference: “Software Ownership Transfer: Evolving Knowledge Transfer for the Agile World”, Vinod Sankaranarayanan, Addison-Wesley, 170 pages, ISBN 978-0-13-418101-1

Website: http://ownershiptransfer.in/

Quotes

Organizations are particularly keen to understand how to transfer over projects that have been developed in an Agile fashion into maintenance mode, and they are asking this specific question to the service organizations they hire. No one has really broached this topic in-depth. This is primarily because development phases have picked up Agile models, whereas, in many instances, the maintenance and operations teams work with older methods.

Taking ownership requires a deep appreciation of expectations and empowerment. If you try to live by others’ expectations, then ownership becomes compromised. Someone truly passionate about her application will work for the best possible outcome no matter what others think. True ownership shows by itself. You need not talk about it.
But how can you ensure true ownership develops? True ownership will develop only through deliberate intent. You have to spend time with the application: Work with the application. Enhance it. Prune it. Release it. Make mistakes. Discover little nuggets of code that can still surprise you. Invest your personal attention to the code.
This shift in approach is all in the mind and not so much in practice. That is why it is extremely important for an ownership transfer event to occur over a considerable period of time. Having personal stories around the code and functionality is an excellent way to identify whether ownership is developing.

The fact is, there is no one specific timeframe that can be suggested for all ownership transfers. I strongly recommend that a transfer occurs over several releases. To my mind, it should take a minimum of four releases involving both the incumbent and the new teams wherein the new team takes increasingly higher levels of ownership. In the final release, the new team should have taken complete ownership for production support. However, this is not to say that four releases will always suffice. The time period required will also be a function of
* The cultural diversity among teams
* The geographic dispersion
* The complexity of infrastructure transfer

As organizations are in various stages of Agile adoption, team members are faced with the need to demonstrate contextual ambidexterity. Contextual ambidexterity is a unique skill that describes a team member’s ability to balance between aligning to an organization’s strictures and adapting to fluid on-ground situations. For example, some developers may be required to align with quality control metrics on the one hand, and at the same time they may need to don a tester’s hat to help complete a story.