Italtel

LeSS Adoption at Italtel

(by Fransesco Sferlazza)

Italtel builds products and solutions for networks and next-generation communications services based on IP protocol.

Our experience in LeSS adoption started in 2011, may. At that time, the product portfolio was organized around a single, huge, “multi-purpose” architecture intended to enable the company to “compose” Telco products as needed by the market.

A strongly waterfall process was in place. The R&D organization laid on some big groups: Design, Platform Development (O.S., firmware,…), Real time Dev ( focused on RT protocols, telephony apps and stack implementations), Operation And Maintenance (FCAPS, GUI,..), Testing and Q&A, located in Milan, Rome, and Palermo.

As you can see, the Development groups was organized by architectural layers. And, inside every group, the Org was mapped into componen teams.

In this scenario, every new market requirement was tricky to manage. The process constraints were too difficult to overcome. Every single decision had to be approved by all the involved component teams and their top-manager. And, almost always, technical choices were based on non-technical aspects.

The cost of change was too expensive for the Company, ending in an high rate of lost opportunities. So, in order to quickly respond to the market, the management had to create “tiger teams”, “task force” and other creative shortcuts.

Federico Descalzo, the head of of R&D, observed those dynamics and many other wastes within his organization. So he contacted a guy who bored him about some new ways to build products. This guy was very passionate about the agile world (it’s me!). I had learned about LeSS from Craig Larman, in Rome, in 2008.

That’s when I convinced Federico to adopt LeSS. And we started to work together.

Kick-off

When we decided to adopt LeSS we tried to identify risks, challenges and impacts on the on-going activities. As first step, we wanted to share the big idea of Scrum with people. We wanted involve everybody and gather feedbacks. Many were enthusiastic but also many skeptic. We also had to involve and get sponsorship from HR and, mainly, from the CEO.

We started ours experiments with a single product and 2 team composed by 7 people. Teams were cross-functional, having people coming from different groups.

The beginning of this coexistence was not really easy. We had to face with several issues, spreading from technical to old-fashion habits. First of all, we had to help people to move from a component vision to a product-wide perspective. Then we started to talk about TDD/ATDD and Continuous Integration, as well as other XP practices.

We also experienced other obstacles:

• resistance from the middle management
• How to split the work, in order to have a potentially shippable product increment every week.
• Learning that the design is a continuous activity and the architecture lives and changes with the product.
• What about the governance, old processes, tools, and so on.
  
  

Many other problems become visible day-by-day and the pilot project was able to show us many hidden dynamics.
It was also hard to make people understand that the issues were not generated by scrum. So, after 2 months we decided to extend the scrum adoption the whole R&D: 300+ people.

It was clear that external coaching was needed. So, Craig Larman was personally available on site in order to help us to move the first steps in the LeSS adoption.

We had to change & improve on many things, starting from the organization. So, we implemented many LeSS rules: cross-functional teams, co-located teams and so on. Here was where we experienced several issues, especially while moving from Component teams to Feature teams:

• Many teams did not have any knowledge about many components. So, those team were not able to take in charge features involving the unknown components.
• The bug fixing management was very complicated. Due to SLA, we had to assign bugs to the team already able to fix it (knowledge about component was requested)
  
  

The following picture shows the actual organization:

The Product Development includes all the skills. The “Technology Unit” (platform, persistence, UI, Real Time, Applications) work as Community of Practice. People from the various TU are full time Team Members. TU has not a manager, but a moderator, a “coach as teacher” available for every team member.

Other Communities have emerged, solicited directly from developers interested to share some topics: Architecture, Java, Testing, — Here people can share knowledge, learn, improve.

Teams are “long term teams”. They are dedicated to the products. Every team has a Scrum Master. Every product has a single Product Owner, coming from the Product Management group.

Today

Let’s say that LeSS framework is in place. Anyway, we are still working hard in order to improve several critical aspects. In facts, some of the engineering practices were new to our R&D. Regarding TDD/ATDD, as of today, every new development has its own automated test case. But we still have several parts of software really not covered by ATDD.

We really implemented many of the experiments suggested by LeSS, spreading from organizational tips to facilities, from engineering practices to testing. In many cases we got an immediate advantage. In some other cases we realized that “the art of the possible” is the only way to deal between the market, the huge technical debt we have, and the human habits in our System.

We have a lot of work to do. But we also changed and improved.

Today, our main product, NetMatch-S (Session Border Controller) is entirely developed in a LeSS context, from scratch. It is now positioned into the Gartner Magic Quadrant, between “Visionary”.

Today, all of our R&D has adopted LeSS. And we know that we are at the beginning of the game.