Getting a different team to take over an application brings in challenges from multiple perspectives. There will be differences around processes, engineering as well as culture. Larger transfers would also involve changes to infrastructure. For long, the industry has done a disservice to this field by calling it Knowledge Transfer. Knowledge Transfer, is but a subset of the scope of activities involved in this exercise. We propose to rename this as Ownership Transfer.
In specific - we put this process into practice with one of our customers. After more than 5 years of supporting the platform, ThoughtWorks worked with The customer teams to transfer knowledge and context back to the customer. A few highlights on the application.
• More than 80% of all online ticket sales are done through this application
• More than 400,000 visits a day
• Close to 5 billion USD of ticket sales
• More than 70 VMs supporting the production application
• Upwards of 300 VMs supporting other development and testing environments
A few highlights on the program,
• More than 150 IT members involved in the program
• A ramp-down was part of the process to get the final numbers to about 60
• The transfer had to occur from Bangalore back to London
• Infrastructure had to re-optimised from Bangalore over to London
• Two organisations were involved viz. ThoughtWorks and the customer
Since both Bangalore and London were following agile practices, the teams decided to utilise core agile concepts to effect the transfer. This became all the more important as business required critical features to be delivered on a continuous basis. 
Before we started off on this exercise, we created a methodology to effect the transfer. This methodology is fairly context agnostic and should support a healthy, sustainable and mature way to transfer ownership. The transition itself was about a year long and involved multiple aspects around agile such as remote pairing, program MVP and above all, continuous delivery and non-disruption to business through the process.
The session will introduce a framework that can be applied to most Ownership Transfer situations. In particular, this will be of interest to groups who are looking to transfer ownership from one team to another. These could be from a development team to a support team, or from one vendor to another as well. This will also provide insights on transferring ownership across distributed teams.  


Outline/Structure of the Talk

  • We start off by giving real life example of a similar program
  • Discuss on why not enough thought is rendered to these exercises, even though there is a lot of risk associated with them
  • Delve into the different dimensions on an exercise such as this

Learning Outcome

  • Understand the larger scope of a Knowledge Transfer exercise
  • Utilise Agile methodologies to effect a program at this scale
  • Understand how we can utilise distributed development for ownership transfer
  • Discuss on true effort for a large program. Understand how Agile Fluency gaps can have an impact apart from domain and technical skill gap

Target Audience

Senior IT Executives, Scrum Masters, Program Managers

schedule Submitted 5 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Tathagat Varma
    By Tathagat Varma  ~  5 years ago
    reply Reply

    Vinod - the problem statement is interesting, even if not most of the audience might be exposed to such scenario too often. However, you have raised some interesting questions in the synopsis. Just one concern from my side - 90 minutes seems too long for this, and the audience might get restless just listening to the talk. I would prefer a 45 minute session and a bit explicit discussion on challenges and outcomes.




    • Vinod Sankaranarayanan
      By Vinod Sankaranarayanan  ~  5 years ago
      reply Reply

      Hello TV,


      I hear you and your point is very valid. If we drone on for even thirty minutes, it will become boring. I intend to make the discussion interactive - learn from one another. In the last three places I have presented the topic, there certainly were a few people who have experienced some form of transfer and had experiences to share.


      Plus - this is a topic, where we propose to have our customer ( India offshore head as well. So, we can present two perspectives on the topic. Most often the "ifs and buts" are around, my customer does not allow for it, or management does not think so. Having the customer and vendor present this together, elevates the conversation and we can share experiences on how to convince the customer, and management as well.

      Iam happy to hear your suggestion on the format as well - if you suggest we wrap up the deck in 45 minutes to open up for conversation, we can do so - or we can do quick intervention  question answer sessions with the audience to trigger  discussions.

      Eager to hear back from you.




      • Tathagat Varma
        By Tathagat Varma  ~  5 years ago
        reply Reply

        Vinod - in my opinion, somethng like this might help:

        - recap of traditional approaches towards OT

        - in your experience/view, what are the problems with those approaches (is there any published data/anectodal that you can refer here)

        - what did you guys do differently

        - what were the challenges in doing it

        - what were the outcomes

        - how many of these were sustainable over time

        - if you were to apply the same approach on some other real-life existing problem, what might be issues and possible outcomes?


        secondly, audience involvement might be helpful. is there a way you could get audience to sort of work with you on calling out some of their pain points and see if your model is able to address them? 


        finally, i think 30-35 min of talk time should be the absolute max, followed by ~10min of Q&A. 


        What do you think?

        • Vinod Sankaranarayanan
          By Vinod Sankaranarayanan  ~  4 years ago
          reply Reply

          Fair enough Thathagat. These were talking points in any case.  We can rework the flow to suit your suggestion. We will work out a model to involve the audience as well. So long as there are PMs with experience in the group, they will be able to provide inputs during the discussion.




  • Liked Sunil Mundra

    Sunil Mundra - Getting A Partner To Adopt Agile

    Sunil Mundra
    Sunil Mundra
    Principal Consultant
    schedule 5 years ago
    Sold Out!
    20 Mins
    Case Study

    Due to the business benefits which accrue from Agile, clients are demanding their IT Departments/Partners to adopt Agile. It is quite common to find a situation where the client has adopted Agile, but its Partner/Vendor has not.

    This talk is based on my consulting engagement with a client who had adopted Agile and their partner had not, and the client wanted the partner to Adopt Agile.

    The talk will cover the critical challenges encountered in getting the partner to adopt Agile, especially given the wide difference in cultures of both organizations and also the organizations being located in different continents. The talk will also cover the key learnings from this journey.

  • Liked Shirish Padalkar

    Shirish Padalkar - Application Security - The Agile Way

    Shirish Padalkar
    Shirish Padalkar
    Lead Consultant
    schedule 5 years ago
    Sold Out!
    45 Mins

    Traditionally application security has involved upfront design and a big bang penetration test after development. This leads to the phenomenon of “bolt-on” security that translates into increased cost and complexity.

    Drawing on our experience on real-world projects, we show how security can be baked-in on an agile project. Using case studies we demonstrate how security concerns are captured during project inceptions, how developers write secure code, security testing is automated and how configuration management can help achieve secure deployments. This talk introduces several new concepts like secure by design, secure design patterns and lightweight code reviews.

  • Liked Vineet

    Vineet - Cook your Product better : story map and no estimate is the new recipe

    Product Management
    schedule 5 years ago
    Sold Out!
    45 Mins
    Experience Report

    I'll share my experience on how we shipped products faster using story maps and how team's focus on smaller goals than estimates / numbers / complexities helped us achieve it. 

    The session would give an insight on:

    • Aligning team with product vision 
    • Shiping features fast / faster 
    • Better product backlog management 
    • Delivering without estimation 


    Some of our challenges / questions were:

    • Are we delivering value ? 
    • How do we know we have delivered enough for our customers ? 
    • What is our priority right now ? 
    • Do we have a bigger picture ? 
    • Aligning team with product vision
    • Is tracking numbers the right thing to do ? 
    • How fast should we ship ? What are the related challenges ? 

    We solved these questions / challenges first by using story maps and then removed estimation. Story map gave a clearer picture of what's planned and what's in the next customer release. Other ideas helped us easily identify when to ship and what to ship (I'll discuss more about these in the session). 

    Story map is a great way to collaboratively identify the features, prioritize them and create milestones. We used story maps as our card wall also. It was an interesting experience :) 

    No estimate helps the team focus more on goals and less on numbers. It helps the team to think more about the customers and how would they use the product and less about velocity, charts and commitment. It changes team's perspective and team starts shipping a usuable product for customers. 


  • Liked Pankaj Kanchankar

    Pankaj Kanchankar - Line Managers - an Endangered Species in Agile

    Pankaj Kanchankar
    Pankaj Kanchankar
    Agile Coach
    schedule 5 years ago
    Sold Out!
    45 Mins

    The matrix organization of yore relied on maximizing returns on each skillset. This lead to having line managers and practice horizontals.
    Engineering managers looking after developers and practice managers looking after the respective practices of BA, QA and PMO. This lead to having multiple lines of reporting for team member whilst on the project.
    In Agile teams, focus is on the self organising teams of empowered employees working towards common success criteria (project success is team success). Not everyone can be a PO or a Scrum Master. So is the role of so called line managers or practice managers become redundant?
    Whats their role in the agile teams?
    How their role needs to transform

    In this talk I will be addressing these questions. Bring out how some of their responsibilities are now taken up by the team or Product Owner or Scrum Master. I will also be suggesting how line managers can take this as an opportunity to morph into more meaningful roles that help the organization and teams. 

  • Liked Sridharan Vembu

    Sridharan Vembu - Turning around a twice-failed distributed enterprise program into success

    Sridharan Vembu
    Sridharan Vembu
    Head Engineering
    schedule 5 years ago
    Sold Out!
    45 Mins
    Experience Report

    The common myth about agile methodology is, it is suited for smaller, co-located teams, would not scale up for big enterprises and is best suited for smaller, less complex programs.

    In this talk, I intend to share how we went about setting up, executing and successfully delivering probably one of the most complex and strategic programs for one of our customers. This program was the first ever successful adoption of the fully distributed agile implementations for the customer.

    Context: The client is the leading Telecom Operator in the UK, having their captive and other strategic partners based out of India. The program was highly strategic for the client and the predicted ROI was high.

     - The implementation was tried twice by different vendors for more than an year, but failed to deliver; root causes were not analyzed

     - The Program Sponsor had one last chance to try and deliver the platform successfully, against a very tight schedule

     - Continued Operational risk with the legacy system in place 

    Outcome of our engagement:

     - Core functional application ready in pre-production by the end of first release cycle (4 months from engagement start); fully ready to functionally scale easily and quickly

     - Adoption of the technical and execution approach to other related programs within the portfolio 

    Our Approach:

     - Outcome of initial assessment of the existing codebase was to go with re-write from scratch; was a really hard sell, but was the RIGHT thing to do

     - Re-define the release cycle: extend development period by embedding integration testing as part of development cycle and cut down on the low level design phase

     - Need-basis colocation of functional SMEs with development team 

     - Direct access to Product Owners: weekly video calls, must-attend iteration show-cases, etc

     - Remove unnecessary operational overheads, in terms of people as well as organizational processes

     - Well-defined, pragmatic strategy for Integration testing (major constraints - lead time for test data preparation, limitation in re-usability of test data, lack of e2e functional understanding within team)

      - Smart seeding of other vendor team members (with good functional/domain understanding) into the core team

      - Zero compromise on basic hygienic practices: IPMs, Showcases, communicate negative-news-first with alternate solutions/workarounds, strict removal of wastes, inclusive decision making, highest degree of code coverage, sanity test suite, e2e basic automation suite   

      - Building trust between distributed teams: cross-pairing, align on core work hours across time zones, joint showcases and retrospectives (shared responsibility)

    Challenges faced:

      - Big push to release the core functional platform into production in 3 months (immediate next release)

      - Working out of other vendor premises: seen as threat to their business, lack of cooperation and collaboration   

      - Product Owners based out of UK, no easy / frequent access

      - Functional SMEs/designers based out of different location

      - Release cycle that was in place: 8 weeks of design, 4 weeks of development and 8 weeks of testing!

      - Distributed and isolated testing teams

      - Highly manual and time-consuming E2E testing processes

      - Multiple interfacing systems, both upstream and downstream 

      - Client development team based out of UK, different execution approach, lack of trust between the teams

    In summary, I would like to share the unique aspects of the execution approach that made this program a real success for the customer, though some of the approaches might be tried out in different environments and project situations.