search menu icon-carat-right cmu-wordmark

Introducing Agile in Large-Scale Projects

April 2013 Presentation
Vladimir Koncar (Ericsson Nikola Tesla), Josko Bilic (Ericsson Nikola Tesla), Emina Filipovic-Juric (Ericsson Nikola Tesla), Zoran Kokolj (Ericsson Nikola Tesla), Drago Holub (Ericsson Nikola Tesla)

A presentation from the ninth annual SATURN conference, held in Minneapolis, MN, April 29 - May 3, 2013.

Publisher:

Software Engineering Institute

Abstract

When you work in an R&D company that develops software and hardware for next-generation products in radio access networks, your constant ambition is to find ways to increase the quality of your products and reduce development lead time. In this presentation, we share our experiences and lessons learned from introducing agile in our large-scale projects.

We are always searching for new ways of working that will help us achieve those goals, so at the beginning of 2011, when we were facing a new project that technically was our most challenging and difficult project so far, we decided to introduce agile methodology. We believed that in addition to raising quality and lowering lead time, agile could provide us with more efficiency and broaden the competence of our organization.

We were all very motivated to make agile work, and we believed in our developers and our teamwork, so we agreed on the agile framework and guidelines and promised to stick to it. We used independent, cross-functional teams as much as possible. We focused on frequent code reviews and software deliveries and continuous software integration. We introduced daily standups and frequent team retrospectives for continuous improvements. We wanted to do only the important functionalities, reduce unnecessary administration and handovers within a team and between teams, and remove waste as much as possible.

But how easy it is to introduce agile when you have a project that will

  • require an estimated 100,000 man hours, include design of completely new software and hardware, and take at least 18 monhts to develop?
  • involve teams on four different geographical sites and about 100 people?
  • finish all software development before it can be tested on completely new hardware?
  • include different stakeholders in organizations with different priorities and ideas?

One can just imagine how many things and can go wrong.

Now, with two years in agile methods, we have many lessons learned:

  • We learned that agile really empowers both teams and individuals to take charge. We saw how a team evolved through time and process, and we saw how stand-alone they could be but also what kind of difficulties they need to overcome and the kind of help they need to do that.
  • We learned the importance of team space, a team board with information and tasks, team life, and team ceremonies. We've seen how they change through time in the project in some positive but also some negative directions.
  • We saw the importance of team commitment, and it was amazing to see how innovative people could be in finding new solutions and possibilities.
  • We also learned how difficult it is to manage all the interfaces and stakeholders while keeping our teams independent in large-scale projects.

But we achieved the most important result: with agile we delivered our product with very high quality (very few faults found on the market) and cut the lead time by a third!



We are always searching for new ways of working that will help us achieve those goals, so at the beginning of 2011, when we were facing a new project that technically was our most challenging and difficult project so far, we decided to introduce agile methodology. We believed that in addition to raising quality and lowering lead time, agile could provide us with more efficiency and broaden the competence of our organization.

We were all very motivated to make agile work, and we believed in our developers and our teamwork, so we agreed on the agile framework and guidelines and promised to stick to it. We used independent, cross-functional teams as much as possible. We focused on frequent code reviews and software deliveries and continuous software integration. We introduced daily standups and frequent team retrospectives for continuous improvements. We wanted to do only the important functionalities, reduce unnecessary administration and handovers within a team and between teams, and remove waste as much as possible.

But how easy it is to introduce agile when you have a project that will

  • require an estimated 100,000 man hours, include design of completely new software and hardware, and take at least 18 monhts to develop?
  • involve teams on four different geographical sites and about 100 people?
  • finish all software development before it can be tested on completely new hardware?
  • include different stakeholders in organizations with different priorities and ideas?

One can just imagine how many things and can go wrong.

Now, with two years in agile methods, we have many lessons learned:

  • We learned that agile really empowers both teams and individuals to take charge. We saw how a team evolved through time and process, and we saw how stand-alone they could be but also what kind of difficulties they need to overcome and the kind of help they need to do that.
  • We learned the importance of team space, a team board with information and tasks, team life, and team ceremonies. We've seen how they change through time in the project in some positive but also some negative directions.
  • We saw the importance of team commitment, and it was amazing to see how innovative people could be in finding new solutions and possibilities.
  • We also learned how difficult it is to manage all the interfaces and stakeholders while keeping our teams independent in large-scale projects.

But we achieved the most important result: with agile we delivered our product with very high quality (very few faults found on the market) and cut the lead time by a third!