I am going to tell you about the journey we are doing in Amdocs for the last 2.5 years
Amdocs is considered to be one of the successful companies thanks to a unique business strategy
Some numbers which show the complexity of having multi-sites development groups, differentiated by time zone, language and culture, being managed (sometimes) by different managers, delivering one portfolio and some stand alone products. The challenges we faced at the beginning of the journey were: long over budget releases, and inability to meet market needs as it is one of the most dynamic markets.
We decided to implement Agile in PBG and called it Galileo.
We understood we need to make a culture change which will have an impact on each of these components.I will immediately describe the organizational and R&R changes we made.Changed management tools, changed processes from waterfall and gates to Agile, and measurements (for example started to measure E2E CT)
Galileo-started with Scrum for development teams, evolved into Lean and Kanban in the customer teams and our vision is to reach the enterpriseIn order to tackle the issues at hand we need to move up the phases of enterprise agilityPhase 1 – Development AgilityPhase 2 – Business Agility – bringing agility to the business leaders and product managersPhase 3 – Enterprise Agility – scaling agility to the entire enterprise
Change teams to colcation – for example in OSS there was a 60 dev team in Isr and a 60 testers team in India, after implementation we formed 2 teams of dev+test in both locations.Remove middle mgt. – removed GLs, dev reporting to PMs flat organization, less hierarchiesPdM vs. PdO – before Agile we had only PdMs, defining requirements in high level, which led to technical dev. And created features with no business value.We decided to create the PdO role that will work closely with the teams and bridge dev and business. We aimed for ratio of 1:12. eliminating waste, increasing business valueChange the eval process – 60% of employees evaluation is based on team performance, 40% on personal performance increasing teams exelenceMerge testing and dev – no more silos, one manager is managing dev and testing Increasing built in quality.
in order to support the business.(flexibility and agility to the market).the focus was made on Culture and leadership
We have 2 production lines: one is producing requirements from idea to ready for dev. There was a “wall” between business people to dev and design people, so we established the opportunity team, where they all sit together one team with one goal and decide upon backlog requirements and priority.On the bottom we have the scrum teams which develop the products. Our portfolio includes 30 products, so we have synchronized iterations-iteration per 3 months and then PIL. within the iterations each product work with its own heart-bit (sprints), but at the end of each iteration we have a working portfolio.
In the middle we have the entities hierarchy: Initiative (a big program which contains few projects), project (2-5m$), Feature (10-15 in a project), Epic and User Story which is being developed by the teams in the sprint.Each product is developed for the portfolio and also for the customers (as Amdocs is not a product company)
After 1.5-2 years….
Whiteboards for scrum teams work, but no visibility to upstream steps (before ready to dev), so we lacked the planning capabilities and teams could not see any roadmap
A domino effect of things not being ready for the next step, creating rework and defects.Backlog not ready, last minute changesPlanning runs over into sprintRework due to changes for started workRequirement/Design defects due to last minute crisis-mode
OT was harder to implement than FT, as they didn’t feel like a team with one goal. They are coming from different disciplines and groups, and as to the size of company, don’t necessarily know each other.
Bad statistics: 35% of designs did not reach dev Waste in requirement definition
We implemented a continuous flow for Opportunity teams process, Based on Lean/Kanban Pull/Flow and limited WIP principles, that ensures sufficient ready buffer before each step.We understood that only FTs worked Agile and other worked waterfall
I will describe the process that we are now doing with each and every customer team.We are still in the middle of the process, and the initial results looks great.
We are taking each OT through a 1 day workshop and mapping their E2E flow:process-steps+flow of workand informationStep timeRework, waste, bottleneckClasses of service, types of workAfter recognizing the potential improvements and changing the process to be better, this was the baseline for the Kanban board steps and the E2E flow managed by the OT.
Thresholds settings-WIP limit, step time, FPs limitViolation alertsCFD, CT measurements, and more
Actually what we have in the system is ScrumBan
Kanban trainingWe are using getKanban board-game and getting excellent feedbacks
The Kanban boards became the platform for OT work and collaborationKanban was backed up by methodology that defined a ceremony that involveRegular meetingsRetrospectiveAnalysis of major indicators such as EVM and metrics
We started by having an e-kanban which created visibility (first phase of Kanban implementation). then we saw people did not pay attention to WIP, now, after some coaching and trainings we managed to implement WIP limit thinking and process
We are coaching Executives/Managers to drive teams to pull more improvements and create the right environment for that.Lean Measures/KPIs Discussion of Measures - Opportunity to educate executivesOnce positive trend can be demonstrated, will generate fuel for further improvement – Results-driven organization - Pull to improve your resultsBiggest challenge – Executives want to see improved Productivity – which is hard to measure…Move from “Mandatory Package” to “Toolbox” – Pull what YOU need
Create velocity in sub organization level (group of scrum teams)Feature Points as units for relative estimates given in level of opportunity team (lead by Development representative)Kanban to support feature point so sprint readiness can be done more accurately
Some ideas we’re considering:Lean Budget/Planning processKanban for initiativesKanban for management team work. Personal Kanban for Managers…
2. Agenda<br /> Amdocs and PBG challenges Agile in PBG Phase 1 – Scrum for development teams Phase 2 – scaling to Lean& Kanban Roadmap and vision<br />
3. CUSTOMER EXPERIENCE SYSTEMS INNOVATION<br />“…we provide state-of-the-art customer experience system products and services, allowing Service Providers to achieve their business goals and gain a competitive edge”<br />
4. annual revenues in excess of<br />$3 billion <br />Some of our customers<br />global employees<br />17,000+<br />customers in over<br />50 countries<br />
5. PBG Division – Product Business Group<br />1500 developers and testers6 locations35 stand alone products5 lines of businessMore than 100 components1 portfolio<br />
6. Galileo<br />Agile&LeanImplementation in Amdocs Product Business Group (PBG)<br />
9. Phase 1 – Main Actions<br />Establish overall end to end agile process<br />Perform Organizational Changes<br />Establish organization heartbeat<br />Define the backlog entities and structure <br />
10. Phase 1 – Main Actions<br />Perform Organizational Changes<br />
11. Change the evaluation process<br />Change Teams To Co-Location where needed<br />Remove<br />Middle Management <br />Merge Testing and development organization<br />Perform Roles and responsibilities changes<br />Product Manager Vs Product Owner<br />
12. Two Strategic Themes for Creating the Change<br /> Culture<br />Flexibility & Agility<br /> LeadershipFrom Management to Leadership<br />Trust<br />Respect<br />Openness<br />Leadership<br /> Making an impact<br />Culture<br /> Flexibility & Agility<br />
37. Step 3: Limit the WIP and create a pull system<br />
38. WIP limit guidelines for customer teams<br /><ul><li>Set the initial WIP limits
39. Analysis should be made after 1 months and after 2 months. Only then make changes if needed
40. WIP limit is constantly violated probably too tight limit
41. WIP limit is never violated too loose limit, decrease it
42. WIP limit is sometimes violated good. Analyze the root cause for violation and solve it.</li></li></ul><li>Thresholds Customization<br />To ensure min’ work at each stage<br />What is the average time each item should stay at each stage – to identify the ones that are not active<br />And not more then what can actually be handled<br />
43. Flow/Pull Indications<br />And you get here a notice what is the problem<br />If one of the parameters are not met the column is colored<br />Indicates an “aging” note<br />
47. Continuous improvement<br /><ul><li>Coach teams to stop and observe
48. Perform Kaizen events
49. Implement Root cause analysis techniques: 5 why’s, fish bone diagram, …
50. OPS review
51. OT retrospective</li></li></ul><li>Root cause analysis (5 why’s)<br />
52. OT retrospective<br />
53. Complete all JUnits/TC mapping<br />Automate all Critical/High TCs<br />Start Code Review process<br />Incorporate Static code analyzer and code coverage tool<br />Understand and Use Story Points<br />Close all Medium Defects by End of SP2<br />Complete all outstanding NFT issues<br />OPS review example – “Continuous improvement spot”<br />Example<br />
54. Some more components<br /><ul><li>Feature Points
55. EVM for project management</li></li></ul><li>The need for sizing Features<br />Feature Points provide planning/tracking as long as Feature size varies<br />