Sven and his journey with Ericsson
There we were in 2006: hundreds of software engineers at Ericsson, entering unknown territory. We didn’t have any maps, but we had our battle cry: “Let’s run some projects!”, and an insatiable market. Our normal way of navigating couldn’t help us here. Instead, it was like our naïvety and unexperience actually facilitated a solution!
The period before and after the Millenium shift at Ericsson will cover many pages in the history books; the “Internet Boom” years became a unique experience for a Swedish corporation. The technology and the market moved at supersonic speed, and we acted in an environment of permanent growth and reorganization, while constantly rolling out new stuff to our customers.
When I became manager for a software development unit in 2006, our corporation had just provided the world’s first mobile broadband technology. Our software team came to serve four R&D sections, developing technologies like Bluetooth, Streaming, Digital Rights Management, and video telephony.
What we noted was that the old way of working underperformed in two different ways:
- Firstly, it was hard to coordinate the dependability between different work groups. At Ericsson, we were great at creating the pieces of the puzzles—hardware as well as software—but we were not that good at assembling them. When there was a delay, the entire system was often ready for shipment except for some single, crucial component.
- Secondly, things were moving so fast on the market that our planning and task management couldn’t keep up: we got stuck in the bureaucracy of modifying our plans instead of adopting fast and smoothly to a quickly changing reality.
As a manager, I spend a lot of time thinking on how we should organize things and how to find a way to handle the situation. One solution was—in a very agile spirit!—to form teams of professionals with different backgrounds. For the first time, developers and testers were members of the same team–something that raised some eyebrows in a company culture which normally kept these professions separate. I was also happy to see that the product manager—who formerly hadn’t been that interested in the activities of the R&D department—became very engaged in our work. He soon learned that he could gain a much better ability to steer the product development if he just didn’t hand over a list of features and fixes, but rather examined the possibilities and limitations together with the developers.
A golden opportunity to learn, implement, and assess agile methodology appeared when we were engaged and sponsored by the main corporation for a special assignment: to develop the very first terminals to validate the entire VoLTE solution (that is VoIP in a cellular network). Using this separate budget we could set up teams with a holistic and iterative approach. In these, a Product Owner worked directly with the customer (Ericssons Business Unit Networks) to set up a prioritized backlog so that we could deliver new functionality as a need emerged.
Agile ideas also diffused into the corporation with the help of our tech staff. Some of them started practicing the roles and structures of Scrum. I loved what I saw and just encouraged it. These were early days of Agile in Sweden, but somehow, we managed to come a long way without the help of today’s plethora of consultants and training companies.
Much of our work was about upscaling as we kept growing in many different ways: technologies, products, staff, organization. We managed to pioneer Scrum Methodologies for software development with excellent results, and—with some patience—we made top management trust our ways of working. The corporation itself was in a very dynamic phase during these years, but through the reorganizations, we could note that our implementation inspired our global colleagues. It was not always an easy ride, but looking back, it was a privilege to be a part of this industrial endeavor.
