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 6 years ago

Public Feedback


    • Liked Sunil Mundra
      keyboard_arrow_down

      Sunil Mundra - Getting A Partner To Adopt Agile

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

      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
      keyboard_arrow_down

      Shirish Padalkar - Application Security - The Agile Way

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

      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
      keyboard_arrow_down

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

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

      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
      keyboard_arrow_down

      Pankaj Kanchankar - Line Managers - an Endangered Species in Agile

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

      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
      keyboard_arrow_down

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

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

      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.