Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor

Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • 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
  • OT retrospective
  • 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…


  • 1. Scaling Scrum using
    Lean/Kanban @ Amdocs
    September, 2010
    Shirly Paster-Benor
  • 2. Agenda
    Amdocs and PBG challenges Agile in PBG Phase 1 – Scrum for development teams Phase 2 – scaling to Lean& Kanban Roadmap and vision
    “…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 customers
    global employees
    customers in over
    50 countries
  • 5. PBG Division – Product Business Group
    1500 developers and testers6 locations35 stand alone products5 lines of businessMore than 100 components1 portfolio
  • 6. Galileo
    Agile&LeanImplementation in Amdocs Product Business Group (PBG)
  • 7. Agile as Planned organizational Change
  • 8. From Team Agility to Enterprise Agility
  • 9. Phase 1 – Main Actions
    Establish overall end to end agile process
    Perform Organizational Changes
    Establish organization heartbeat
    Define the backlog entities and structure
  • 10. Phase 1 – Main Actions
    Perform Organizational Changes
  • 11. Change the evaluation process
    Change Teams To Co-Location where needed
    Middle Management
    Merge Testing and development organization
    Perform Roles and responsibilities changes
    Product Manager Vs Product Owner
  • 12. Two Strategic Themes for Creating the Change
    Flexibility & Agility
    LeadershipFrom Management to Leadership
    Making an impact
    Flexibility & Agility
  • 13. Phase 1 – Main Actions
    Establish organization heartbeat
  • 14. Backlog Management Process
    Release Plan
    Managing Release Backlog
    Opportunity/customer Team
    Solution Overview
    High Level Design
    Top Priority – Mini Release Items
    Portfolio Planning
    Plan 1
    Plan 2
    Plan 3
    Plan 4
    Portf Mini Release 1
    Portf Mini Release 2
    Portf Mini Release 3
    Portf Mini Release 4
    Portfolio Heartbeat
    Products Iterations
    Scrum Team
    Portf Mini Release 2
    Portf Mini Release 3
    Portf Mini Release 4
    Portf Mini Release 1
    Portfolio Integration Lab
    Releases Development Product Integration
  • 15. Phase 1 – Main Actions
    Define the backlog entities and structure
  • 16. Backlog Entities
    Release Vehicle
    Mini Release
    Agile Group
  • 17. We were happy with the results
    More challenges waited around the corner…
  • 18. Not enough visibility to E2E process
  • 19. Requirements not ready for design, Designs not ready for development  Changes run into sprint
  • 20. Not enough collaboration within Customer teams and with Scrum teams
  • 21. No focus on E2E cycle time
  • 22. No sync between backlog grooming and development
  • 23. The solution:
    Lean / Kanban for customer teams, to ensure flow of work
  • 24. Step 1: Value Stream mapping
  • 25.
  • 26.
  • 27.
  • 28.
  • 29. Step 2: Create Kanban board for project/product
  • 30. We started this way…
  • 31. Than became more structured
  • 32. e-Kanban in Team Player
    (In house development)
  • 33. What is the best granularity?
  • 34. ScrumBan
    E2E Flow  
    Scrum Team
    Opportunity Team
  • 35.
  • 36. Customer (opportunity) team
  • 37. Step 3: Limit the WIP and create a pull system
  • 38. WIP limit guidelines for customer teams
    • 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.
  • Thresholds Customization
    To ensure min’ work at each stage
    What is the average time each item should stay at each stage – to identify the ones that are not active
    And not more then what can actually be handled
  • 43. Flow/Pull Indications
    And you get here a notice what is the problem
    If one of the parameters are not met the column is colored
    Indicates an “aging” note
  • 44. How to drive more Pull?
  • 45. Step 4: Continuous improvement
  • 46. Continuous improvement
    Toyota culture
    Western companies culture
  • 47. Continuous improvement
    • 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
  • Root cause analysis (5 why’s)
  • 52. OT retrospective
  • 53. Complete all JUnits/TC mapping
    Automate all Critical/High TCs
    Start Code Review process
    Incorporate Static code analyzer and code coverage tool
    Understand and Use Story Points
    Close all Medium Defects by End of SP2
    Complete all outstanding NFT issues
    OPS review example – “Continuous improvement spot”
  • 54. Some more components
    • Feature Points
    • 55. EVM for project management
  • The need for sizing Features
    Feature Points provide planning/tracking as long as Feature size varies
  • 56. Feature Point
  • 57. EVM (Earned Value Management)
  • 58. Roadmap/vision
  • 59. Thank You!