Your SlideShare is downloading. ×
0
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Scaling Amdocs PBG from team scrum to a multi-program portfolio using lean and kanban - Shirly Paster-Benor
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

2,233

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,233
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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…
  • Transcript

    • 1. Scaling Scrum using<br />Lean/Kanban @ Amdocs<br />September, 2010<br />Shirly Paster-Benor<br />
    • 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 />
    • 7. Agile as Planned organizational Change<br />Balance<br />Balance<br />Balance<br />Balance<br />Balance<br />
    • 8. From Team Agility to Enterprise Agility<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 />
    • 13. Phase 1 – Main Actions<br />Establish organization heartbeat<br />13<br />
    • 14. Backlog Management Process<br />Release Plan<br />Strategy<br />Managing Release Backlog<br />Initiations<br />Opportunity/customer Team<br />Solution Overview<br />High Level Design<br />Top Priority – Mini Release Items<br />Portfolio Planning<br />Plan 1<br />Plan 2<br />Plan 3<br />Plan 4<br />Portf Mini Release 1<br />Portf Mini Release 2<br />Portf Mini Release 3<br />Portf Mini Release 4<br />Portfolio Heartbeat<br />Products Iterations<br />Scrum Team<br />Portf Mini Release 2<br />Portf Mini Release 3<br />Portf Mini Release 4<br />Portf Mini Release 1<br />Portfolio Integration Lab<br />Releases Development Product Integration<br />14<br />
    • 15. Phase 1 – Main Actions<br />Define the backlog entities and structure <br />15<br />
    • 16. Backlog Entities<br />Release Vehicle<br />Product/Architecture<br />Release<br />Project<br />Product<br />Portfolio<br />Mini Release<br />Component<br />Story<br />Agile Group<br />Feature<br />Sprint<br />Initiative<br />Epic<br />Epic<br />16<br />
    • 17. We were happy with the results<br />BUT<br />More challenges waited around the corner…<br />
    • 18. Not enough visibility to E2E process<br />
    • 19. Requirements not ready for design, Designs not ready for development  Changes run into sprint<br />
    • 20. Not enough collaboration within Customer teams and with Scrum teams<br />
    • 21. No focus on E2E cycle time<br />
    • 22. No sync between backlog grooming and development<br />
    • 23. The solution: <br />Lean / Kanban for customer teams, to ensure flow of work<br />
    • 24. Step 1: Value Stream mapping<br />
    • 25.
    • 26.
    • 27.
    • 28.
    • 29. Step 2: Create Kanban board for project/product<br />
    • 30. We started this way…<br />
    • 31. Than became more structured<br />
    • 32. e-Kanban in Team Player<br />(In house development)<br />
    • 33. What is the best granularity?<br />Features?<br />Epics?<br />Stories?<br />Epics/MMFs!<br />
    • 34. ScrumBan<br />DONE<br />READY!<br />E2E Flow  <br />Scrum Team<br />Opportunity Team<br />34<br />
    • 35.
    • 36. Customer (opportunity) team<br />36<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 />
    • 44. How to drive more Pull?<br />
    • 45. Step 4: Continuous improvement<br />
    • 46. Continuous improvement<br />Toyota culture<br />Western companies culture<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 />
    • 56. Feature Point<br />
    • 57. EVM (Earned Value Management)<br />
    • 58. Roadmap/vision<br />
    • 59. Thank You!<br />shirlyp@amdocs.com<br />

    ×