Table of Contents
"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 - http://news.scrumalliance.org/m000NL2000782ZIHTeB0SH0
Supporting Learning Consortium report - http://news.scrumalliance.org/gC0H0NZ07202TH08S000MeI
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