If You Want Process Improvement to Work, Explain the Why
I recently talked to Adi Yahas of Amdocs about its agile project management journey. Particularly around the techniques, tools, and best practices that Amdocs used to overcome the complicated challenges involved with adopting Agile across a large organization.
Adi will present ‘Agile at Scale: Your Size is Actually Your Advantage, Not Your Obstacle’ at APQC’s Process & Performance Management Conference.
What was the impetus to move away from Waterfall to Agile?
Over the years the Waterfall methodology became our organization’s DNA. We would commit all our resources to one enormous, all-encompassing scope, and fool ourselves that we had already acquired all the crucial inputs at the project kick-off. For years we assumed that this was the way to go. We felt that our greatest achievement was to define the entire scope at the start of the project, which would enable us to achieve the most successful implementation possible.
But the fast changes in the market have caused our customers to change their needs faster than ever before. Therefore our projects have developed a new rhythm, one that required us to acknowledge that our Waterfall approach didn’t fit the new world, where the unknown is typically greater than the known.
We started to navigate our journey to agility by way of the Kanban method. Kanban is an Agile approach, in which you do things step-by-step. You start with what is familiar to you, and evolve slowly. You learn from experience and improve gradually. Once we felt comfortable with Kanban we decided to transform into SAFe (Scaled Agile Framework). Due to the size of our organization and number of projects we needed an Agile framework that would help us implement Agile on a large scale basis for both internal and external projects.
Can you describe, at a high-level Amdocs’ Agile transformation strategy?
The first thing we created as part of the transformation to Agile was an Agile implementation kit. The kit comprises four main phases:
- initiate and plan,
- set up,
- rollout, and
Each phase contains a list of activities that need to be done in order to implement Agile in every project. The kit has been modified on an ongoing basis based on inputs and feedback from the field. The transformation is led by project managers with ongoing feedback, improvement loops, and Agile coach assistance.
However the most important thing is to match the Agile flavor to the customer pain points, goals, and vision; ultimately allowing us to give the right implementation approach per customer. These days we see more and more customers who want us to implement DevOps as the next phase in the agile world.
Was there a lot of resistance in regards to the switch? How do you change a global organization’s culture regarding Agile?
Part of human nature is to be afraid to move out of our comfort zone. In our comfort zone all is known and to change means to try new things for which the end result is less clear to us. Hence, every organization change should start with “WHY?”
Why is this change needed? Why now? What issues will this change resolve? What are the risks?
We start by answering all of those questions through a massive communication campaign based on the motivation for the change.
After evaluating the change maturity levels, we identified that we were behaving like the innovation adoption lifecycle in the diagram below.
Innovation Adoption Lifecycle
The innovation adoption lifecycle helped us understand how people reacted to change and adopting new practices. The innovators and early adopters (we called them “the brave people”) started to implement the change in their projects and it very rapidly created a buzz all over the company. Once more and more people felt the good vibes of the change, they also wanted to adopt it.
We continue to face resistance, but it’s not as severe because people are now more mature in the Agile world so the behavior and resistance types are changing with it. Therefore we are constantly improving how we market the change and handle those that lag behind in order to move them into the early majority or late majority population.
How did you measure success of the transformation?
During the transformation process there was a need to adjust the existing measurements and quality key performance indicators (KPIs). We had to make sure all steps in the program lifecycle were transforming and improving in the change process. As you can see in the diagram below, each phase of the program lifecycle has quality KPIs that should be met on an ongoing basis as part of the iterative program lifecycle.
Program Life Cycle
The main KPIs we had to add in order to be able to measure the success of the transformation are:
- Time to Market –measured by the cycle time and amount of annual productions.
- Customer collaboration and satisfaction –measured by the number of annual demos and customer satisfaction via surveys.
- Quality – measured by the number of escaping defects, defect density, technical depth and more.
- Efficiency – we check the efficiency by measuring the velocity (e.g., the team’s productivity) and pace of continuous integration.
What was biggest struggle to make the transformation successful? How did you address it?
Without changing people, processes, and tools you can’t transform the culture of a big organization. In order to have a successful transformation we acknowledged that it is not enough to have the right processes and tools, but you also need the right organizational structure. The way we were structured was great for the Waterfall but not the Agile world. After we started to adopt SAFe we had to change the organizational structure. For example we changed the development teams and managers’ orientation from product to value stream, development teams to scrum teams by embedding the quality assurance people inside the teams, and shifted from business analysts to product owners.
Adi Yahas is an experienced agile coach in Kanban, Scrum, and SAFe leading projects in Amdocs in their agile transformation journey. You can connect to Adi on LinkedIn.