Ran Nyman
Gosei OyShort summary of Case Study, published at InfoQ in July 2015
Developing a High Capacity Network Gateway with LeSS
Introduction
At the end of 2007 we started having a discussion how to build a high capacity network gateway from scratch. We faced two fundamental risks. First, the technology was completely new and has never been used before in Nokia Siemens Networks (now Nokia Networks). Second, the use cases for first commercial deployments were not completely defined at the start - It became clear that we needed to adapt feature content heavily throughout, based on learning. Using the LeSS framework appeared to be the appropriate response to these major risks.
Organization and growth
Starting
Selecting LeSS as the development framework was easy; adopting it in practice was hard work. The first challenge was to convince all parties that feature teams were preferred over component teams, if we wanted to reduce cycle time and increase flexibility. The feature teams that we decided to use, after long debate, are long-lived, cross-functional and cross-component teams that complete many end-to-end customer features.
We decided to start with two teams, and this led to huge arguments between teams and very slow start in development because there were so many different opinions how the architecture and infrastructure should be done. There were several reason behind this: the main reason was that the people not having real Scrum experience were the stars and were not used to collaborating with others. The culture of winning arguments was strong and visible inside teams but worse between teams. We had common design session with both teams present were present which helped little to achieve agreement but there were so many moving parts beginning that teams managed to create conflicting solutions that needed to be solved. The positive impact was that we probably covered all possible options when designing the initial architecture with two feature teams each trying to convince other team that their solution is the best.
Growing the First Wave
We had our first growth point when we added two more teams (for a total of four). It was a challenge since they were transferred from a traditional organization. One of these teams refused to learn new testing tools and the new way of working. They did not produce anything that could be considered done for several Sprints. The team argued that the testing tools in their previous environment were much better and resisted the learning of new tools and did not want to write unit tests. In retrospect one crucial point that caused the resistance was that we did not provide the sufficient training and the reasoning how work is done when using iterative development. The new teams should be able to influence the ways of working so they can feel the rules as their own.
Growing the Second Wave
Adding teams to the same site was easy compared to next step where we decided to add teams at a second site, to (hopefully!) speed up development because the market demand for the product that we were creating was suddenly emerging. Here we found out that adopting LeSS and using automated acceptance testing paid off. We trained the subcontractor at the second site in our ways of working by having them spend several weeks with our local teams doing work as team members until we were confident that they could work by themselves.
During the growing phase we came to the point that one Product Owner was getting overloaded. So we started to classify the Product Backlog items into major requirement areas, and some teams would focus in a particular area. However, in retrospect we realized that we made the areas too small, with only two teams for example. That led to more complexity and less transparency, versus if we’d made bigger areas with more teams.
Current Team Structure
After adding even more teams we have now over 20 teams, and the majority are developing and documenting features. We have a couple of teams in supporting roles like performance testing, system testing, coaching and continuous integration system (CIS) team. The CIS team is taking care of building and automation system. The performance and system testing teams were focusing on executing tests that can not be done by feature teams because of the need for real network elements in a special test lab (located at different site). We have only a limited amount of these special network elements, and coordinating the usage of them between several teams at different sites is not feasible. The coaching team’s main responsibility is to support modern engineering practices, help teams solve difficult technical challenges and in general help the organization to learn faster.
Conclusions
The selection of the LeSS framework and agile development practices significantly accelerated the time to market and gave us the flexibility that our traditional development methods never offered. The previous gateway product where we used a sequential life cycle model took twice as long to develop, and the sequential life cycle and single-function teams and component teams would not have allowed us to make the major change in direction that we did. LeSS gave us that organizational agility.
Automated acceptance testing helped us significantly when we added new teams to development to keep the code base in high quality.