Agile KT – Its Ownership Transfer; not just Knowledge Transfer

Agile KT – Its Ownership Transfer; not just Knowledge Transfer
Over the last several months, I have been working with my client, on transferring ownership and context of the largest program yet that ThoughtWorks had worked on.
ThoughtWorks had been working on this platform for over five years. At its peak we had more than 200 members on the program, making it the largest Agile Project at that point in time. Of course, since then there have been larger programs within the IT industry using the concept of Agile Factories.
On a steady state, we had close to a 100 members on the program and there were about 50 members at the customer location. Trainline decided to re-define the program steady state, so that from the 150 members, we reduce the overall size to about 60. This entailed that ThoughtWorks needed to transfer knowledge, context and ownership back to the members working in London.
As we started planning the program, we realized that this is not an activity that can occur over a couple of months. We already had several projects under play. Releases needed to occur every 6 weeks. These could not be jeopardized. And in a larger sense, we had the maturity to realize that in a couple of months, one can perhaps transfer knowledge. But ownership is a lot more than just knowing. Getting a medical degree is not the same as being a doctor of repute. That requires experience. Of successes and failures. Understand procedures intimately and know when to take deviations.
 
We developed a methodology for the program.
 


 
It takes time to understand the real scope. Given this is a capacity transformation program; we needed to look at other elements. On the engineering side, we started breaking down the monolith that we had ended up building over the last 5 years. The front-end and the services were broken up.  The service layer was untangled, so that different services could exist on their own. The entire build, smoke and deployment pipelines for each of the services were separated out and each got their own repository. Different teams in London were to own different services.
From an infrastructure perspective, we had to re-orient the set-up to reflect a smaller capacity. Bangalore which once had 576 VMs development set-up, shrunk down to about 250 VMs. Several environments were retired. A few others were transferred over to London. This was a project in itself, requiring the build and deployment teams to drive the changes involved.
The next challenge to look at was the process of delivering projects. Before the OT, we had feature-based teams in Bangalore. One team would deliver the entire functionality. The same team would work on the front-end, services as well as the database. With the OT, we had passed on different services to different teams in London. London historically used to have product-based teams. Hence, this made sense as we proceeded with the OT. But the challenge was, where earlier we had one team pick up an entire feature, now the same feature involved 2, 3 and sometimes 4 teams. Everything starting from the inception to handling dependencies during iterations had to be relooked. The same also percolated on handling regression defects. Defects typically would get identified in the front-end. But the issue could be in the service or in the database. The channel team though would get straddled with the onerous job of diagnosing where the issue is and then passing it on to the respective teams. Not everyone wants to be doing this activity. And chances of lobbing the ball back and forth increase substantially with this set-up.
 
As we shrunk in size from a significant 150 off members to a medium sized 60 members, we also had to make changes to the team structure itself. There was a time when we had separate teams to run, what we called as the end to end regression cycles, the automation cycles, a dedicated build and environment team as well as a dedicated database administrator. With a smaller size, we could ill-afford to keep so many discrete teams. Some of these teams had to be disbanded, and their activities had to re-aligned to existing functional teams or moved on to counterparts in London. The other angle to structure is the product alignment itself. Breaking up the monolith and creating them as independent products, allow us to create product teams. At that point in time, we felt that product teams will serve well, given the platform was significantly big. Rather than have Jacks plying all trades, we felt specialization is the way to go. Hence a product-driven structure.
 
While we did all of the above, the continuing theme into the whole process had been the code itself. One can easily get lost in a KT set-up by focusing on documentation, or the functionality, the process, dynamics, testing, cost and a plethora of other things. While each of these are important in themselves, the soul of the application is the working code. We could potentially get by without the others, but nothing can replace working code. Hence the transitions revolved around teams getting comfortable with the code. Comfortable to a point they could own it. Towards this cause, the engineering related projects, automation related activities and even infrastructure related activities were all picked up as potential projects where the knowledge sharer and the knowledge sharee could work together. As they paired on such projects, they became comfortable along the way.
 
We also picked up commercial projects as an opportunity to pair and transfer ownership. Care needs to be taken that the commercial stakeholders do not feel that they are paying for the Ownership Transfer. Expectations are set that it may perhaps take more time, but the cost to the project itself should not increase. The difference in effort needs to be charged to the Ownership Transfer program. We tried various ways of transfer. The most obvious methodology adopted was remote pairing. We identified the best tools for screen sharing. We obtained high quality circum-aural headphones for pairing. Team member should not feel constrained on such issues.
 
As with any project team, we did our usual rounds of norming. Since this was a distributed team, we had to do this over VC. While not as effective as the real thing, it still made a difference. The teams gelled and at a minimum understood each other’s constraints.
 
While there are specifics to Ownership Transfer, it has all elements of a generic project.  People are key. All the more in this case as it involves transferring knowledge and ownership. It does not come easy. Maturity is key for a program of this nature. We were fortunate to have an extremely mature and hearty set of members in our teams.  In different contexts, this will become key. People will feel insecure. The members giving the OT will fear for their jobs. The members taking over will feel overworked. In many cases, the new team picks up items over and above what they already perform. That makes the project more onerous.
 
Every person needs to find her alignment with the program. For some, it is the joy of learning, for others, it’s the joy of teaching. A few others will find joy in transforming.


By with 3 comments 0

Related Posts

No posts were found for display

3 comments on “Agile KT – Its Ownership Transfer; not just Knowledge Transfer”

  1. Vinod Sankaranarayanan

    thanks Balaji. How have you been? Long time!

    Reply
  2. Amit

    "We had the maturity to realize that in a couple of months, one can perhaps transfer knowledge. But ownership is a lot more than just knowing."

    Wow! So many of us don't understand this. And end up with months of pain sorting out things after what seemed like a quick and successful two month knowledge transfer and transition.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *