Since 2002, Isode has been developing and supporting commercial off-the-shelf, client and server software for secure messaging and directory systems. Their software is at the heart of great solutions, built by their partners, for Government, Military and Aviation Authority customers in over 150 countries. Isode has a strong software engineering focus (of 40 staff, 30 write and/or test code).
Within the company’s forty staff, thirty work in the software engineering department, and eight are on the team responsible for XMPP projects. XMPP is an open standard network protocol for messaging, used for a variety of systems including ‘chat’ systems (on the Internet, private networks and within massively multiplayer online games), Internet of Things communication and video conferencing.
In the summer of 2018, the XMPP team began an evaluation of their development approaches, led by a belief that although the team was producing high-quality software that it took longer to develop than they believed they were capable of, and that their ability to estimate delivery timelines could see significant improvement. Upon reflection, the team decided that increased collaboration and insight across the team were the main areas they wanted to initially improve. After a period of research, they decided to trial Scrum, as others using the framework had found improvement in these areas.
The Isode team took private Scrum training with Simon Kneafsey (TheScrumMaster.co.uk). The Scrum Team and key Stakeholders attended and learnt about Scrum and the empirical approach. The course was hands-on and practical and the group experienced using Scrum to build software whilst learning the theory required to understand and implement the framework.
The team’s Scrum Master also attended dedicated training around the Scrum Master role so he was better able to support the team as they learned and experimented with Scrum. After the training, the team decided to use Scrum and adopted 2-week Sprints.
Shortly before adopting Scrum, the team had started work on a long-term project to rework the current product codebase’s design with an emphasis on testability, testing and correctness. Work continued towards this goal during the first few months of adopting Scrum.
As Scrum was adopted, the Product Backlog became better refined and the scope of the project became better understood. Good progress was made. In spring 2019 the goal was selected to redevelop one of the products aiming to have an initial version ready for release at the start of January 2020.
Scrum’s empirical approach and focus on the transparency of issues and progress led to several changes in scope. Compromises were made and scope changed to remove non-essential nice-to-have features. A particular example was the new configuration system introduced in the codebase. Development of this was progressing slower than anticipated, with it looking unlikely that all features would be ready in time for the release. Given the honest picture that emerged of actual progress against the initial plan, it was decided to redirect effort to support some necessary features elsewhere in the code outside the configuration system, which saved significant time and reduced the risk of missing the planned release date.
This graph shows a number of interesting features of the progress towards the release. It shows how the scope was adjusted over time to meet the delivery date, how the team added estimations to Product Backlog items over time (the October spike in % un-estimated tickets was due to the removal of estimated tickets).
Sprint Retrospectives led to more improvements to how development is carried out, the tools we use and the way we plan than was occurring pre-Scrum. As the team is distributed it was often the case that discussions at that level (such as the one that sparked the initial interest in changes that led to adopting Scrum) only happened when the team was entirely collocated, which was sometimes only every few months. Many important discussions would not have happened without the time-box that Scrum dedicated to it via the Sprint Retrospective.
The Daily Scrum provides good opportunities for everyone in the Development Team to be involved and kept up to date on progress and re-planning. They also surface issues on a daily basis which enables faster handling. Highlighting things that needed change was uncomfortable, but a necessary and positive thing.
Often, an issue surfaces via the Daily Scrum that leads to a break-out session with an interested subset of the Development Team. Given the distributed nature of the team, having these natural opportunities to hold further discussions is an unexpected, but significant benefit.
The adoption of Scrum has not been entirely smooth sailing, with the focus on making the true state of work and progress transparent being sometimes uncomfortable. The previous difficulty with estimating was one of the reasons for adopting Scrum, and this did not immediately improve. However, what did improve with Scrum was transparency into the issues being faced during estimation and Isode continues to work to minimise and eliminate these issues.
The emphasis on a refined Product Backlog has been both a blessing and a curse. It has enabled the delivery of a Product with all the items evaluated based on value, while conversely requiring significantly more effort to refine than previous approaches, which mostly revolved around a single developer owning all aspects of a piece of work. The benefits of team refinement, which include an increased understanding of work and scope ahead of time are there but are harder to quantify.
It became clear that knowledge was not shared effectively between all members of the team, with some developers understanding issues well and others lacking the necessary background. This led to improvements in approaching understanding, with a system in place now to ensure that members of the team who are missing background knowledge are able to flag this and trigger discussion. This has led to a number of intra-team training and knowledge-sharing sessions to raise the team’s overall understanding and knowledge of the product and technology.
The 19.0 release of the Product was put into production in December 2019, a little ahead of schedule. Two issues were immediately revealed. The first, an interoperability issue due to a bug in another vendor’s systems and the second an interoperability issue with a different system due to a misreading of a specification. A workaround for the first and a fix for the second was developed, tested and deployed immediately. No further issues or defects were found in the following months.
Being able to determine real progress and better predict deliveries was the main goal for the team that led to the adoption of Scrum, and this was a considerable success. The delivery on-time would have been less likely under the previous development approach. Scrum helped to highlight when it was required to drop lower value work in order to de-risk and successfully deliver higher-value features.
The fact that the system was put into production early with no significant issues far exceeded expectations. The high quality achieved is thought to be down to the focus on testing and correctness. Talking about Release 19.0, the team’s first release following the adoption of Scrum, Isode’s CEO said “I’m very pleased with 19.0 and was really impressed with how easily it went into production … it feels like it [Scrum] is right for the team and I like the results“.