Downloaded 56 times
Uploaded byAGILEMinds
Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
This document discusses how Amdocs, a global provider of software and services to telecommunications companies, scaled their agile development process from team-level Scrum to an enterprise-level approach combining Scrum and Kanban. In Phase 1, they established Scrum processes for individual teams. In Phase 2, they introduced Lean/Kanban techniques to provide visibility across the end-to-end process and ensure flow of work, including value stream mapping, limiting work-in-progress, and continuous improvement practices. The approach aimed to balance agility, flexibility, and leadership while driving collaboration across customer teams, development teams, and the portfolio.
More Related Content
Similar to Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
- 1. Scaling Scrum usingLean/Kanban@ AmdocsSeptember, 2010Shirly Paster-Benor
- 2. Agenda Amdocs andPBG challenges Agile in PBG Phase 1 – Scrum for development teams Phase 2 – scaling to Lean& Kanban Roadmap and vision
- 3. CUSTOMER EXPERIENCE SYSTEMSINNOVATION“…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”
- 4. annual revenues in excess of$3 billion Some of our customersglobal employees17,000+customers in over50 countries
- 5. PBG Division –Product Business Group1500 developers and testers6 locations35 stand alone products5 lines of businessMore than 100 components1 portfolio
- 6. GalileoAgile&LeanImplementation in AmdocsProduct Business Group (PBG)
- 7. Agile as Plannedorganizational ChangeBalanceBalanceBalanceBalanceBalance
- 8. From Team Agilityto Enterprise Agility
- 9. Phase 1 –Main ActionsEstablish overall end to end agile processPerform Organizational ChangesEstablish organization heartbeatDefine the backlog entities and structure
- 10. Phase 1 –Main ActionsPerform Organizational Changes
- 11. Change the evaluationprocessChange Teams To Co-Location where neededRemoveMiddle Management Merge Testing and development organizationPerform Roles and responsibilities changesProduct Manager Vs Product Owner
- 12. Two Strategic Themesfor Creating the Change CultureFlexibility & Agility LeadershipFrom Management to LeadershipTrustRespectOpennessLeadership Making an impactCulture Flexibility & Agility
- 13. Phase 1 –Main ActionsEstablish organization heartbeat13
- 14. Backlog Management ProcessReleasePlanStrategyManaging Release BacklogInitiationsOpportunity/customer TeamSolution OverviewHigh Level DesignTop Priority – Mini Release ItemsPortfolio PlanningPlan 1Plan 2Plan 3Plan 4Portf Mini Release 1Portf Mini Release 2Portf Mini Release 3Portf Mini Release 4Portfolio HeartbeatProducts IterationsScrum TeamPortf Mini Release 2Portf Mini Release 3Portf Mini Release 4Portf Mini Release 1Portfolio Integration LabReleases Development Product Integration14
- 15. Phase 1 –Main ActionsDefine the backlog entities and structure 15
- 16. Backlog EntitiesRelease VehicleProduct/ArchitectureReleaseProjectProductPortfolioMini ReleaseComponentStoryAgile GroupFeatureSprintInitiativeEpicEpic16
- 17. We were happywith the resultsBUTMore challenges waited around the corner…
- 18. Not enough visibilityto E2E process
- 19. Requirements not readyfor design, Designs not ready for development Changes run into sprint
- 20. Not enough collaborationwithin Customer teams and with Scrum teams
- 21. No focus onE2E cycle time
- 22. No sync betweenbacklog grooming and development
- 23. The solution: Lean/ Kanban for customer teams, to ensure flow of work
- 24. Step 1: ValueStream mapping
- 29. Step 2: CreateKanban board for project/product
- 30. We started thisway…
- 31. Than became morestructured
- 32. e-Kanban in TeamPlayer(In house development)
- 33. What is thebest granularity?Features?Epics?Stories?Epics/MMFs!
- 34. ScrumBanDONEREADY!E2E Flow Scrum TeamOpportunity Team34
- 36.
- 37. Step 3: Limitthe WIP and create a pull system
- 38. WIP limit guidelinesfor customer teamsSet the initial WIP limits
- 39. Analysis should bemade after 1 months and after 2 months. Only then make changes if needed
- 40. WIP limit isconstantly violated probably too tight limit
- 41. WIP limit isnever violated too loose limit, decrease it
- 42. WIP limitis sometimes violated good. Analyze the root cause for violation and solve it.Thresholds CustomizationTo ensure min’ work at each stageWhat is the average time each item should stay at each stage – to identify the ones that are not activeAnd not more then what can actually be handled
- 43. Flow/Pull IndicationsAnd youget here a notice what is the problemIf one of the parameters are not met the column is coloredIndicates an “aging” note
- 44. How to drivemore Pull?
- 45. Step 4: Continuousimprovement
- 46. Continuous improvementToyota cultureWesterncompanies culture
- 47. Continuous improvementCoach teamsto stop and observe
- 48.
- 49. Implement Root causeanalysis techniques: 5 why’s, fish bone diagram, …
- 50.
- 51. OT retrospectiveRoot causeanalysis (5 why’s)
- 52.
- 53. Complete all JUnits/TCmappingAutomate all Critical/High TCsStart Code Review processIncorporate Static code analyzer and code coverage toolUnderstand and Use Story PointsClose all Medium Defects by End of SP2Complete all outstanding NFT issuesOPS review example – “Continuous improvement spot”Example
Editor's Notes
- #3 I am going to tell you about the journey we are doing in Amdocs for the last 2.5 years
- #5 Amdocs is considered to be one of the successful companies thanks to a unique business strategy
- #6 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.
- #7 We decided to implement Agile in PBG and called it Galileo.
- #8 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)
- #9 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
- #12 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.
- #13 in order to support the business.(flexibility and agility to the market).the focus was made on Culture and leadership
- #15 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.
- #17 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)
- #18 After 1.5-2 years….
- #19 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
- #20 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
- #21 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.
- #23 Bad statistics: 35% of designs did not reach dev Waste in requirement definition
- #24 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
- #25 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.
- #26 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.
- #33 Thresholds settings-WIP limit, step time, FPs limitViolation alertsCFD, CT measurements, and more
- #35 Actually what we have in the system is ScrumBan
- #36 Kanban trainingWe are using getKanban board-game and getting excellent feedbacks
- #37 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
- #38 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
- #42 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
- #47 OT retrospective
- #50 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
- #53 Some ideas we’re considering:Lean Budget/Planning processKanban for initiativesKanban for management team work. Personal Kanban for Managers…