Transferring a Software Project - Lessons Learned

Transferring a software project (or indeed any project) to your team from another team is a daunting task. For the purpose of this article, let's call the giving teams the "Throwers" and the receiving teams the "Catchers". To transfer a project, the Throwers dump their brains and give their thoughts to the Catchers hoping most of it sticks.

The complexity is compounded the more teams you add to the mix. Most of the time, it is like asking a bunch of toddlers to paint a masterpiece and then getting a different bunch of toddlers to give an analysis of the artwork.

First of all, the Throwers likely don't care too much if the Catchers get it wrong. Even worse, if the Throwers are losing their jobs, as is often the case, then there is a certain level of resentment towards the Catchers.

Secondly, if you manage the project, you have to note down all the tasks, dependencies, edge cases and expertise you can think of and try to extract as much information as possible from the Throwers for each item. This includes code, product architecture, business cases, documentation, bugs, ad hoc expertise, testing...the list goes on. Even if you get the maximum amount of information from the Throwers, it doesn't really matter unless the Catchers absorb the information.

This is the position I was in a few years ago, where a large product involving 10 teams was transferred to my teams. The product came from a different part of the world in a different timezone. I was a product owner at the time.

Here are some lessons I have learned and mistakes we made that might help you if you are in a similar position. The good news is, we eventually got there and the project is now thriving, but it wasn't easy.

We didn't follow all of these suggestions, but I wish we did. We made a lot of mistakes and cost ourselves a lot of weekends and failures.

The rules to transfer a project are as follows:

• 20/80 Theory/Practice Split.
• Define team goals quickly.
• Get a backlog in place.
• Take ownership of the product.
• Brainstorm improvements.
• Keep an expert available for questions.
• Don't take on too much work.

20/80 - Theory/Practice

It is important to understand the ratio between learning something theoretically and learning something practically. In a software project, theory will only go so far.

There is a difference between thinking you understand something and being able to apply it in a practical situation. The same goes for your teams. Very often, your teams will find that theory does not apply to the practical application.

The Throwers are often tempted to make a bunch of slides and online videos detailing how they interpret the system and how they picture the software working. The problem here is while theory is nice to have as a background, it is of zero use if the Catchers do not understand how to apply it. For this reason, I suggest to spend about 1-2 hours max each day in knowledge-sharing sessions. Anything longer and your Catchers will get tired and zone out. The rest of the day should be spent on technical exercises such as writing code, debugging, writing documentation and so forth.

Let's be crystal clear on this. If your teams learn something theoretical and don't immediately put it into practice, then it has been a waste of time. In this early stage of the project, it is critical to value your teams' time as much as possible. Just because they sit at a computer and listen to someone speak does not mean their time is well-utilized.

Define Team Goals

The danger of any kind of team-based learning is that the team are left by themselves to 'transfer knowledge'. From the beginning, goals must be defined. The danger of not having any goals is that the knowledge is endlessly abstracted and taught as if the software it applies to works perfectly.

The goals should be broken down starting at a high level.

• What use cases do you want this team to understand?
• What set of tasks do they need to be able to do on a technical level?
• What questions to you want them to be able to answer?

As you break down the goals further and further, it will become clear where the gaps are. Fill in the gaps with more goals and keep going until you run out of ideas.

Once the goals have been defined, discuss them with the team and get their feedback - they may have a better idea on what they need to learn.

Backlog, Backlog, Backlog

Once the high level goals have been defined and you have discussed them with the Catchers, it's time to get the team focused. This is where the backlog of tasks comes in.

The Catchers will want to break down the high level goals so that they can identify their knowledge gaps and raise questions quickly with the Throwers. The onus for learning the project is not on the managers of the project, it is on the team. The team will be the ones developing features, solving bugs and answering questions. They need to hone their skills going forward, and that comes from the backlog.

It is tempting not to create a backlog until the project has been transferred and the teams feel 'ready' to start developing features. This is a mistake. The team need to create velocity and work as a team on the project from the beginning. The team lead or scrum master should keep a focus on the backlog so that the team can have small, manageable goals each sprint and start moving towards an ownership of the project.

Take ownership of the project

High performing teams always have ownership of a product or a subarea of that product. It is important for your team to feel they have ownership over the product as quickly as possible. This will make them feel responsible for the product and give them purpose in their daily work.

Teams take ownership by carving out responsibilities for the product.
When defining the team goals and backlog, group work into categories. Once the work is somewhat categorized, it is a good idea to assign a category of work to a single team if possible. This way, the team will get that 'feeling' they have an area of responsibility.

I have seen teams that struggle to secure a place of responsibility in the product. This decreases morale and you will hear it turn up as an issue at the retrospectives. Things like "We don't know our what we are responsible for" or "What is our team vision?" repeatedly get said. This is normal to hear at the start of transferring the product, but you should move to rectify it quickly.

Think about this when you assign the team features and backlog. If you assign a team tasks that are not related to each other, it will confuse them as to what the long term goals are and what they should concentrate on owning. By assigning tasks that are in a similar category, the team can deepen their knowledge in a particular area.

Sometimes you can directly assign an area of responsibility to a team. Here are some examples of use cases a team could be easily assigned.

• Ensure our product installs successfully.
• Develop all future features related to login.
• Develop pipelines to automatically test the product each night.

Once an area of responsibility has been established, the team can make themselves experts for their responsibility. Having at least one area of expertise (most teams have multiple) gives the team a sense of ownership over the product and purpose. This helps to gel together as a team.

Brainstorm Improvements

No software is perfect. Your teams will realise this straight away, while some more outspoken persons will comment exclusively on the quality of the software they are receiving. Hopefully, it's not as bad as everyone says!

A fun way of learning about the product is to brainstorm improvements for the difficulties your teams encounter. Very often, the Catchers find improvements that have been discussed by the Throwers. The Throwers can give the Catchers quick feedback on their ideas and whether or not it is worthwhile to improve.

Since the Catchers are a brand new team to the product, they will also find improvements to difficult problems that nobody has touched before. In particular, if the project has been under a lot of pressure for deadlines, then there will be a lot of technical debt and rushed code. The Catchers should take notes as they go through the project and keep a backlog of improvement ideas they can return to in the near future.

If capacity is available, the Catchers can even begin to work on some of these improvements. Making the product better is always a bonus, even if the improvements are small.

Fix bugs

In my opinion, this is the quickest way to learn the new product. Code is always best learned by solving practical problems. As the team work together through the problem, they will encounter pieces of code that will not make sense to them. They can record these difficulties and bring them up with the Throwers.

Once the team are aware of their responsibilities, they should research the most relevant bugs in their responsible area. Imagine having a document of problems and solutions you could search through to find answers to your questions. This is what a bug backlog does.

As an exercise, the Catchers could take some sample bugs from historic tickets and work them out themselves. If they get stuck, the answer is (or should be) in the ticket.

Keep an expert available for questions

This is crucial to a smooth transfer. As part of any project transfer, there must be a gradual period of transfer. During this period of transfer, the teams do what we have gone through above. At any point, the Catchers could have questions and ideas that need feedback from someone who understands the software. This means that the project experts should be kept on hand for questions and support.

Ideally, an expert should be kept on as long as possible. As the catchers take ownership of the product, they will find that there will always be unknowns. This is ok - it's part of transferring a product, so don't worry.

Your team needs to develop a baseline knowledge so that they have the tools to figure out the rest of the unknowns. Until this baseline knowledge is achieved, it is good to have someone close by.

Don't take on too much

A danger of transferring tasks to your team is that the team takes on too much work. You don't want to set yourselves up to fail. Ensure that whatever you take on is manageable. If you don't know, then don't agree!

My team were in charge of a particular area during the product transfer. We were given a large responsibility to make sure a particular part of the application stays functional each release.

As it turns out, this part of the product never worked properly in the first place. We didn't have the environments available to troubleshoot and our feedback loop for any single line of code was about 1 day. In the end, we failed our responsibility and the product couldn't be released that same quarter.

So be careful what you take on - don't let management force work that is not manageable onto your teams. The Catchers are new to this - it will take time to get settled so don't rush into it!