A tale of two teams
This is my first blog post ever! On the gnarly subject of legacy software handover from a different department.
We were recently tasked to onboard some software products from a different department. These products are central to our business function. They evolved over 15+ years by a single, remote developer working with a single business analyst as a link with the business teams. As an indicator of size: there are 16 deployable software systems. A mix of C# ASP.net web forms websites and supporting WCF services, all dependant on a large central SQL database. The database has ~4000 stored procedures, ~1000 tables and little in the way of useful schema. There was also a human aspect to this work. Our respective departments held different opinions on development practises and principles and had different ways of working. We hadn’t collaborated like this before. We had 6 weeks for onboarding, as the current developer was leaving the organisation.
This posed several challenges for us:
· Assessing a complex suite of software products and functionality in a short timeframe.
· Remote developer couldn’t come into office, and little existing documentation.
· Different development culture and working practices between departments.
The onboarding has been a success. Our team is now able to provide effective and timely support for these software products and has also helped increase visibility of the products complexity to the business enabling us to start a discussion to look for a different longer term solution. We reflected on our successes and lessons learnt during our onboarding attempt. We wanted to share our key insights for anyone who might be facing similar challenges in the future.
We used fresh faces — We assembled a new team who hadn’t worked with the other department before. New relationships helped us avoid existing assumptions that might have affected onboarding success.
We had a multidisciplinary team — We used a multidisciplinary team for onboarding. Developers and operations worked together to assess systems and architecture.
We built trust early — This was crucial in the context different ways of working. We communicated early, were inclusive and transparent about work in progress. The little things help like using people’s names, saying ‘please’ and ‘thanks’. We made assumptions clear and highlighted the shared objectives of work.
We communicated often — We decided against a single intense home visit with the developer handing over, opting for regular video calls instead. This gave us more time to get stuff done.
We met users early — We spoke to users early to help us identify key functionality. This helped us to avoid distraction faced with an overwhelming amount of functionality.
We identified unknowns — Our delivery manager, Eleanor Mollett, introduced us to Donald Rumsfeld estimating, a planning technique to identify unknowns. This helped us to prioritise unknowns over more obvious work.
We produced diagrams — Creating some key diagrams early helped us to understand the breadth of the systems. A system landscape diagram (from the C4 model of visualising software architecture) showed us users, systems and key interactions. A database schema diagram highlighted the coupling and complexity. Don’t underestimate the value of a good diagram.
We did a show and tell — We held an early show and tell for our wider team for awareness and feedback. This also helped us to organise and confirm our own knowledge. Show and tells aren’t only for new product development.
Lessons learnt for next time
Tasked with a similar job again, we would do some things differently.
Prioritise handover not finishing planned work — We got burnt by this. Ad-hoc changes were being made by the other developer throughout the handover period. This was in an attempt to finish work in progress, and we didn’t realise the extent of this until too late. We should have prioritised knowledge handover over finishing planned work on the systems.
Do a simple deployment early — Aim to make first deployment early to maximise learning of a new system. We could have learnt important lessons about process and dependencies earlier, instead of documenting. You learn most through doing.
No unreleased work — We didn’t realise until too late that there was an unfinished, unreleased change. Work item tracking wasn’t clear and there were no deployment pipelines at the time. We didn’t have time to release this during the handover period. This blocked us from hot-fixing for a while until resolved. Ensure the code is in a releasable state before handover.
It’s easy to underestimate complexity. We thought we could migrate the systems to our infrastructure alongside onboarding. We soon realised we had underestimated the complexity of the systems. We settled for supporting the systems in place. We lost some time because of this.
Hopefully this might be of some use to those working in the gnarly land of legacy system handover.