A year working on the MOT modernisation project

Hi, my name is Jorge, I joined Kainos as Scrum Master a year ago. During this year I have been part of one of the development teams working in the MOT modernisation project. We were working remotely, around the globe:

• Our team is not working on site (Nottingham, UK), but remotely (Gdansk, Poland).
• Product Owners (POs), Business Analysts (BAs), UX/UI are working on site.
• Other development teams are on site and another remote team is in Belfast, UK.

Since the new app launched, there have been over 31.5 million MOT tests recorded, with 80,000 MOT testers and 22,700 garages using the service - it was a huge undertaking! As the project was of such a large scale, I decided to share my recommendations, and what worked well to those working on large projects like this. 1. Self-organised teams work best Good teams are made up of people with different strengths that collaborate to move teamwork forward. Increase the flexibility of the team is key to ensure a dynamic workload distribution, avoid bottlenecks and enable the team to respond rapidly to change. Some examples: bridging the gap between test and develop by skilling up developers in testing and testers in QA, reducing the dependency between classical developers and DevOps, integrating DevOps work within the team. 2. Communication Remote communication can be a challenge. Chats, email, issue tracking systems, video conferences, face to face meetings with some remote attendants, etc. It is very easy to lose context, miss some made decisions or just create noise. Coaching the team in how to communicate more effectively and respectfully made our team more efficient and transparent. Plan regular visits on site, choose video conference over voice calls. It forces you to make clear statements with context, define communication paths, ensuring that offline decisions are shared. 3. Continuous improvement Each team is different, each project is different, each customer is different. Adapting is often necessary. However, there are no perfect environments and change is essential to keep improving practices. It is very easy to turn retrospective sessions into games or routines, but teams should use such moments to challenge any single piece of process/activity and come up with their small experiments to adjust accordingly. Create a space owned by the team to challenge, experiment, fail and adjust is key for this transformation. 4. Build trust Trust comes with ownership, commitment, transparency, trade-off decisions and respect within the team and outside it. Once your team is trusted, negotiating with different stakeholders becomes natural, and your position is stronger to Build the Thing Right. 5. Continuous delivery Software can be immensely fragile, especially in different environments. We try to bring together developers, testers, delivery teams, product team, DevOps, etc. in order to create a reliable process for releasing software often. Among other benefits, releasing often will make pain points more visible, making them easier to address. Gradually automating these set of problems can help reduce the cycle time, risk and stress. Another benefit is the ability to extend the definition of Done for teams, where 'Done' means released into production and value delivered to users. 6. Understand! Using my ears and eyes to Go See. Depending on the case you really need to understand for yourself the fine details about what is going on within the team, very often a technical background is essential to understand an issue and what is more important, if required, escalate it properly and facilitate decisions quickly, without becoming a simple proxy. 7. Knowledge & sharing is key Encouraging the team to understand the value of documentation and when to document in order to reduce the time for the handover of specific components/functionalities. Especially when dealing with remote teams, it is easy to find silos, component teams. Plan and help define how to share efficiently this work into other teams is an important part of self-organisation at project/product level. 8. Plan While the team should understand the scope of the next sprint, there should be a clear understanding of what is the incoming work in a longer term. In a changing environment trying to bring the correct level of details in the appropriate moment can make the difference and ensure your team make better decisions. Raise any risk or insight in advance could help settle more real expectations giving everyone the ability to plan properly their work. 9. Get attached to the user Bring the development teams as closer and attached to the user as possible. For example: user research presentations, visits to the user place, etc. Teams who deeply understand the user and their pain points can help customer and product teams Build the Right Thing. 10. To be confirmed .... In this role, you're always learning. So watch this space for an update on my next project! Find out more about careers in Kainos here. Want to make an enquiry to our sales team? Visit our contact page here.