Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
•Descargar como PPTX, PDF•
0 recomendaciones•1,918 vistas
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
Similar a Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor (20)
Más de AGILEMinds
Más de AGILEMinds (20)
Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
- 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
- 3. CUSTOMER EXPERIENCE SYSTEMS INNOVATION “…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 17,000+ 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 Balance Balance Balance Balance Balance
- 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 Remove 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 Culture Flexibility & Agility LeadershipFrom Management to Leadership Trust Respect Openness Leadership Making an impact Culture Flexibility & Agility
- 13. Phase 1 – Main Actions Establish organization heartbeat 13
- 14. Backlog Management Process Release Plan Strategy Managing Release Backlog Initiations 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 14
- 15. Phase 1 – Main Actions Define the backlog entities and structure 15
- 16. Backlog Entities Release Vehicle Product/Architecture Release Project Product Portfolio Mini Release Component Story Agile Group Feature Sprint Initiative Epic Epic 16
- 17. We were happy with the results BUT 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
- 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? Features? Epics? Stories? Epics/MMFs!
- 34. ScrumBan DONE READY! E2E Flow Scrum Team Opportunity Team 34
- 36. Customer (opportunity) team 36
- 37. Step 3: Limit the WIP and create a pull system
- 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
- 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
- 49. Implement Root cause analysis techniques: 5 why’s, fish bone diagram, …
- 50. OPS review
- 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” Example
- 56. Feature Point
- 57. EVM (Earned Value Management)
- 58. Roadmap/vision
Notas del editor
- 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…