1. India Agile Week-2014
14th June 2014, Pune
An Enterprise's Journey towards Agility
Sutap Choudhury, Vinaya Muralidharan
Agile Coaches
Amdocs
www.agileinbusiness.com
3. UNICOM Presents
India Agile Week-2014
“Amdocs has a proven
track record with
demonstrated
transformation
capabilities in various
service provider accounts
around the world.”
Delivery in Amdocs
4000
PROFESSIONALS
Global foot print with development
centers around the world (inc. Israel,
India, Brazil)
100+
PROJECTS running in parallel
Proven track record of 95% successful project delivered on budget, on time, with quality
and at large scale
Industry standard 60% -
“Amdocs has shown it
has the size, scale and
stability to reliably
supply telecom
software professional
services to CSPs.”
24. India Agile Week-2014
Organized by
UNICOM Trainings & Seminars Pvt. Ltd.
contact@unicomlearning.com
Sutap Choudhury, Vinaya Muralidharan
Sutap.choudhury@amdocs.com
Vinaya.Muralidharan@amdocs.com
The Journey Continues…
Editor's Notes
Good Morning everyone.
I am Vinaya and this is Sutap – we are both agile coaches from Amdocs.
And we are here to share our experience from Amdocs’ Agile journey.
Since its not easy to do we also have a third person here to help us take you through the presentation – and that’s Agilina.
She will be your constant companion for the next 40 mins or so.
One side note about Agilina and other images – they are all hand drawn by Sutap.
I tried my hand at the sketches too but the less said about that the better.
One request – please hold your questions till the end – we will save enough time for that
Before we start speaking about the Agile journey itself, a little bit about Amdocs.
How many of you know about Amdocs?
Amdocs is more than 30 years old and primarily operates in the Telcom IT space.
We have more than 20,000 people across multiple locations.
We have customers in over 70 countries – with many tier 1 customers like AT&T, Sprint, T-mobile in NA, Vodafone, and others in Europe, Astro, Globe, VIL In APAC and an increasing footprint in other emerging markets like South America and Africa.
Amdocs has various units – some focusing on Product development while others focusing on Services.
Within the Services Business Group we have Delivery – we have over 4000 people in multiple location working on over 100 projects in parallel on an average.
Some of these projects are small – with roughly 20 people working on it and at the other end of the spectrum we have huge projects with over 300 people working on them.
We have excellent delivery track record of meeting our milestones and many other success parameters so it’s a very successful unit.
Which brings us to the next slide – why did we feel the need for change?
What were the challenges we were facing?
Amdocs offers a suite of products to our customers – each of these complex products have several modules within them
So we have a lot of super specialization and we used to work in silos and try to tie it all together during testing.
And that integration was never pleasant – it was integration hell.
Also working in silos did not create an env where one would take the ownership and feel accountable for the end to end flow of any piece of work.
The metrics and measurements were set up in a way that was harmful too.
For example – when I was a developer which was admittedly a while ago, when I used to get a defect it would get my immediate attention. Not to solve it but to somehow move it to someone elses plate. How many of you did this?
So I would put in a lot of effort in moving the defect to a different module. And the defects would get moved around from module to module till it came full circle back to the tester – with a comment asking the tester to reproduce the defect. This made the tester an unhappy person.
One of the other big problems was our turn around time – from the time we get a request from the customer to the time we analyze, design, develop, test, deploy – it took so long that it didn’t make sense for the customer. One of the contributing factors for these long response times was also the fact that we were batching a lot of stuff together into big releases.
One of our UAT managers described the situation to us very well – so he said it is the season for mangoes and everyone in the market is saying “mangoes, mangoes” so we decide to join in and stock mangoes to sell as well. But we take so long to procure and make the mangoes available that the season has changed and now everyone is saying “litchis litchis”. So we kinda missed the bus on that one.
We were also planning and working in a way that didn’t leave a lot of flexibility to accept late changes from the customer – at least not easily.
It was like extracting a tooth. A long drawn out painful procedure. And even if we did eventually accept the change, two things suffered in the process, our relationship with the customer and our people – because the only way to accept late changes was to push people harder make them work longer etc.
Which brings me to the next slide.
Look at poor Agilina…she has just completed a release – put something into production. The whole release drama has left her completely exhausted and burnt out.
A lot of our people were looking like this – also we saw a sharp rise in the number of cases of caffeine addicts.
Look at Sutap – he lost his hair putting stuff into production…no he didn’t but he could have.
Have any of you looked like this after a release? I know I have.
These were situations we definitely didn’t want to be in – we were committed to changing the way we worked.
To top all of that , our customers were growing smarter, and more impatient.
They were demanding more flexibility, better collaboration, more business orientation from us.
And there were others who were actually spelling it out for us that they want us to be more Agile – and adopt Agile practices.
So the writing was on the wall and the need to change was very much there.
So all this put together primed us for the change.
Where did we start our jouney? We didn’t start looking at agility right away.
Taking you back a few years to 2007, Amdocs implemented CCPM based on TOC – which helped us understand the need for maintaining a low WIP, to move away from fixed schedule plans, create more focus on critical items.
Then in 2012 Amdocs Delivery was undergoing some transformation – as a part of this we did something called IDDP – Integration Driven Development Practices – which helped us focus on identifying integration issues early on - by at least viewing complex flows integratively and working on them integratively in iTeams, doing some early integration tests etc.
So now the stage was set for us to look at more industry wide accepted practices like Kanban and Scrum.
And we chose Kanban.
Why did we choose Kanban?
Amdocs delivery has a lot of veterans who are good at what they do, who have been delivering in the past.
So we wanted to not bring in a big bang overnight change – we wanted something evolutionary.
And Kanban allowed us to retain roles, titles, processes and to gradually change and grow into something that worked for us.
It allowed each acct to figure out what change and how much they wanted to pull. It recognized that one size doesn’t fit all and it allowed people to learn and grow.
For example – some accounts decided as a first step to simply view their current work flow using a kanban board – so we had projects which were essentially doing waterfall but with a kanban board.
We had a lot of accounts starting with being agile only in the construct phase without touching scoping or UAT phases initially and then gradually broadening the impl to these phases.
If I look at Agilina – I am glad she was allowed to grow into what she is today gradually – which is a much more humane way of doing the change and a much more sane way.
So how did we get people to join us on this journey?
The first thing we decided was that we wouldn’t have directives from higher management mandating it for all projects to use Kanban.
We wanted projects to pull the change. To encourage the pull we did a lot of buy-in sessions, we engaged external consultants to run various workshops.
Some early adopters started enthusiastically pulling the change – and once they tasted success – others were attracted to try this as well.
Over time we were able to put together some metrics, success stories, best practices, a framework etc – to get the majority onboard
We still do have laggards – in their comfort zone, don’t have a compelling need to change.
But since majority is already onboard these will also eventually see the benefits and join.
Thanks Vinaya. It’s my turn to drive you all through the rest of the journey.
Vinaya talked about why and how we started the journey. An interesting question at this point of time is where does our implementation stand?
In the 1.5 years of our journey, we have more than 30 global telcos having their projects delivered using a Kanban board. We have more than 130 avtive boards, ranging from a small 20 people team to a big 300 people team. An interesting point here is that our teams are globally distributed…we have team members joining the daily standup call from across the globe.
Now Let me talk about the implementation of the Kanban core practices.
We started with Visualization. We had some teams using the board for their construct activities, some for their infra and testing while some had E2E implementation on the board. Also we have personal Kanban boards.
I, for example had lot of things going on and nothing was getting done. Getting a passport renewed was pending fro ages till I put up a Kanban board and started focusing on closing things. One key takeaway is – if you use Kanban boards, you’ll have a happier spouse Why- because things start getting done!!
We started having iTeams- Cross functional teams with testing to take a card from design to delivery.
We earlier had our scope breakdown by modules. We have changed that and now we have the scope decomposition as per independent & testable units.
We started implementing better engineering practices like continuous integration, light weight design documents, automated unit testing,…
We also have started putting explicit Work in Progress limits. Though WIP limits in something we intuitively do (thanks to our CCPM implementation), we started making it explicit.
We also started coaching people on Agile practices like standups and retrospectives.
A snapshot of one of the Kanban board.
Did we have roadblocks. No. Joking. A lot.
We had on one hand large transformation projects which were apprehensive whether Agile is a right fit for them and on the other hand smaller projects just didn’t want to invest
We had people not willing to invest in the initial period of pain and learning. They wanted immediate results.
We have people in their comfort zones. Successful project managers who just didn't want to change
We had super specialization teams who didn’t know how to work in cross functional teams.
We had people who just wanted prescription for the change.
And we had people who didn’t want to think beyond the tool change from MSP to Kanban board. They just implemented the tool and started claiming Agile without actually understanding that it is much beyond the tool.
Did we get results// I’m happy to say that we have some remarkable success stories.
We had projects start with waterfall and just visualization with the help of the Kanban board. As the implementation matured, the waterfall became mini waterfalls and within a couple of releases we can see a nice flow. Just what the doctor ordered.
We also had other success indicators.
We have cycle time going down and consequently more frequent releases
We have escaping defects going down indicating we are catching defects much earlier in the game.
We have better capacity to accept changes late in the game
We also realized that one of the key benefits of agile is that people can and should have a better life.
And this encouraged us to come up with our sustainable pace manifesto.
So lets look at what it is.
We all know that pushing for due dates can lead to people cutting corners . Therefore the focus should be on people finishing work.
Just trying to meet construct budget and making compromises makes us bleed later – therefore instead of being short sighted it is important to think of the project on the whole.
It is important for people to find some time to think of improvement items and we believe people will have enough slack to do this.
So here we are – with the Sustainable Pace Manifesto
What are the next steps for us??
Apart from making the Kanban implementation deeper, broader and more matured, we are keenly looking at DevOps.
What are we doing? To start with, reading The Phoenix Project . It is a nice, easy to understand novel on DevOps written by Gene Kim.
To give a brief about what devOps is, not that I’m an expert yet,
The term “DevOps” typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e., high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.
Did you get that? …I didn’t
So let me try that again.
Devops is Development and Operations working together more closely for primarily two things – one frequent deployments, two smoother production.
I will share the Amdocs DevOps vision – the idea is to take Agile further.
From Agile Scoping to Auto deployments
Coming to the end of the session, I would like tto say this journey has been a challenging and at the same time exciting. The idea is to experimenting and keep evolving .
A side note: We do conduct Limited WIP Society Pune Chapter. Look for it in Meetup and join us!
And now we are open for questions – also answers
Thanks!!
