User Tools

Site Tools


"Learning Consortium Webcast - Large-scale Agile at Ericsson" -- Steve Denning

Scrum Alliance sponsored presentation with Steve Denning and Paul Madden from Ericsson.

Our speaker for the January 20, 2016, Learning Consortium webinar was Paul Madden, head of Ericsson Product Development, OSS-RC & SON, in Athlone, Ireland. Paul hosted the Learning Consortium’s site visit to Athlone in July 2015.

In this webinar, Paul discussed Ericsson’s journey as a world leader in implementing Agile at scale in large enterprise projects. “Self-managed teams are not just tiny curiosities,” writes Andrew Hill in the Financial Times. “They can scale up to handle complex cross-border work. Ericsson — hardly a fresh-faced start-up at nearly 140 years old — has given autonomy to 2,300 engineers in 110 teams, coordinated from Athlone, Ireland, to produce enterprise software for huge telecoms operators.”

Paul also discussed how Ericsson lives the Agile mindset to cope with these challenges. At the Athlone site, many teams are working in a coordinated fashion on the next-generation product that will be released in about 18 months. The teams are encouraged to be autonomous and self-managed. Autonomy happens by leadership specifying the constraints on teams (about 17 people, cross-functional) and then letting the engineers organize themselves according to those constraints.


Webinar recording and slides -

Supporting Learning Consortium report -


Reinforcement that practice of pair programming leads to real benefits:

  • More of a team ethic
  • De-throne the go to guy, remove bottlenecks
  • Better burndown, staircase removed
  • Super competence development

Recommendation is that you do pair programming “for everything” otherwise you see a failure pattern where people are more and more selective about when to use. In the end, if you are producing code and pairing helps, why wouldn't you do it for all code?

Note: According to Ericsson pairing has no impact on ability to produce in the beginning where “people wanted to do it”. For teams that don’t there was a dip for a couple of sprints, then it comes back.

Way to think about how to balance “autonomy” versus “alignment” (and not go too far either way). Have high alignment in “what” and “why” (places customers at the center) and have high autonomy in the “how” (gets you motivated engineers). Note: this fits in with my thinking on “common reporting” and “common check in” but “don't care how you get there” approach.


Myth - Agile only for software, doesn’t scale, can’t handle complexity, not reliable, and is just a fad. Actually none of these are true.

Ericsson has given autonomy to 1000s of engineers

Paul responsible for 20 Ericsson teams, 40-50 teams in India Supply systems for networks, don’t make phones any more

Mobile data growing 50 fold over last 5 years Cut throat the business. Mergers. New competitors

Complex networks Drop calls drive customers to another operator.

Build large enterprise systems for telecoms around the world

Largest project – 110 teams on next gen

PO role very important. And need team.

Scale – 110 teams on a single product Strike balance between team autonomy and alignment Too much alignment is to bureaucratic Process developed for one problem, but then applied to all, and this is often pure waste as makes no sense in other teams Processes often issue because of approval and serial workflows Most time in meetings and writing minutes Leads to aligned but no autonomy (no progress)

All teams have same cadence More subtle stuff – supports rather than constraints

Example DoD Team definition But also need to have some common – this is support eg check into main

What is the balance Idea (from diagram) Have high alignment in “what” and “why” (places customers at the center) and have high autonomy in the “how” (gets you motivated engineers)

Teams that do well in the creative economy Firm revolves around the customer, not the other way around Copernican Revolution in management

Visited Menlo Innovations Have real pair programming – everyone doing it, this is a practice that has been around for more than 15 years

Ericsson – yes we do it, but only sometimes and no real evidence if you looked around the office Did work – set up pilot – try it Required coaching and some interventions But resulted in people striving to achieve goals, reduction in one expert (remove bottlenecks), better burn down (user stories closed on every sprint), “turbo change competency development“ Pair on everything Allow teams to establish their own routine

Why not more widespread Manages don’t buy into it – 2 people doing a task doesn’t seem to make sense. Engineers don’t want to do it – unless they have tried it Pairing is exposing

Team vs management 42% says “yes” this is an issue, another 40 “to some extent”

Traditional organization Top down No customer to be seen Command / control Reporting

For agile Management <> customers / users <> workers (employees, contractors, suppliers) <> and back to management More flat

This means it work together well. Either boxes will crush agile or agile will crush the boxes Is a journey so may not be all or nothing

Looked at SAFe, have used some of the practices Is very context specific when you scale

India – they need to own their transformation This is what we want to achieve Don’t want to create first class vs second class Spend a lot of times in airplanes supporting it

Pairing No impact on bandwidth from start where people wanted to do it For teams that didn’t there was a dip for a couple of sprints then comes back

Product owner One for every two teams Backlog in place Must be available to the teams. Learned the hard way that you build the wrong thing if they not available Customers have not been passive – very demanding Therefore role is heavy on prioritization

How did Ericsson handle documentation Have coaches available to the team Have support – things they must do and have in place (eg check in to main track) Support also through line manager

How do backlog refinement with so large Big then decided out 5 “requirement areas” Then to product owners taking a suite of epics each that are executed in the teams

Alignment artifacts and Err on too much support than too little All have access to testing (technical) coaches – here’s the objective and let’s figure out how to get there Make sure everyone knows what / why they are doing it. Starts with POs. Have more coaching than you think it is necessary and remove when you don’t need it

3 agile teams for a line manager Performance feedback through the teams

Interaction between hardware and software? Not is not such a big issue.

What aspect of development is not iterated Architecture is what you actually implement There is some upfront. Nothing that is heavy upfront, but mostly get to implementation as soon as possible

Organization Start with existing structure and work within that Evolve over time Don’t spend time with big reorganize up front

Try to have cross functional teams Stories used to get closed day 10 and 15 on a sprint One effect of pairing has been earlier delivery

Have teams using scrum and Kanban Customer support are often more Kanban Development teams are more Scrumish as have planning horizon No religious wars – pragmatically using what worked

Do you use scrum of scrum for coordination Yes – 8-10 teams

My Downloads

/home/hpsamios/ · Last modified: 2020/06/04 11:34 by hans