Amdocs: Thousands of People to Kanban, No Big Bang

Amdocs had already gone through a major project-management change a few years earlier using Critical Chain Project Management. That change had helped, but it had also left the organization with little appetite for another revolution. The next move had to improve responsiveness without pushing a large delivery organization through another big-bang methodology rollout.

The scale made that difficult. The LKNA 2014 case study described a 4,000-person delivery organization working on customer-specific delivery over Amdocs products. Some programs involved up to about 70 groups of experts. The first project that pulled the new way of working was a mega-project for a large North American telecom provider, with about 400 people working on one board, releases around every four months, and customer change requests that could be 50-70 person-months before being broken down.

The problem was not that people were not working hard enough. They were. The system was overloaded. Leaders wanted to accept more useful customer scope, reduce risk, protect quality, and avoid burning people out. Doing that required a different operating rhythm, not just more project control.

Yuval worked with the internal Amdocs change leaders, including Keren Yahalom and Yaki Koren, on an evolutionary, pull-based Kanban implementation. The choice was deliberate. Scrum would have looked like a new operating system imposed on a complex delivery organization. Kanban let teams and managers start from the work they already had, make the flow visible, and improve it without pretending the organization could be redesigned overnight.

The implementation started when leaders with a real customer-scope problem pulled help. Instead of first writing a methodology and mandating it, the team helped the first account visualize the end-to-end flow, split large change requests into smaller slices, and manage the work through a board that the delivery organization and management could actually use. That first board quickly became a concrete example for senior management: not a slide about a future process, but a live program using flow to handle real customer delivery.

From there, the change spread across different kinds of work: large business transformations, ongoing releases with existing customers, projects ranging from roughly 10 to 150 person-years, and groups with very different levels of enthusiasm. A key lesson was that pull mattered. When managers chose to adopt the approach, they owned the problems it surfaced. When change felt mandated, the same issues became something the coaches were expected to fix for them.

The work moved Amdocs away from treating late scope as a project-plan exception and toward treating it as a flow-management problem. Large requests were broken into smaller items. Managers could see where work was stuck. Teams and leaders had better conversations about capacity, quality, and sustainable pace.

The 2014 case study reported meaningful improvements in escaping defects, cycle time, and the ability to take on scope. Just as important, the implementation created internal capability. The coaching team grew, managers learned how to use boards and reports with their own programs, and the method spread because parts of the organization could see it working in contexts that looked like their own.

Keren Yahalom and Yaki Koren shared the Amdocs story at Lean Kanban North America 2014. You can watch the conference session on YouTube.

This became one of the stronger examples of Yuval’s large-enterprise change pattern: start with a real business constraint, make the current system visible, let the people closest to the work pull the next step, and scale through evidence rather than slogans. The Amdocs partnership started in 2008 and continued for more than a decade, with the case study later shared at Lean Kanban conferences as an example of evolutionary change at serious enterprise scale.