1 / 49

Cisco CCATG China Agile Coaching Final Report

Cisco CCATG China Agile Coaching Final Report. UP er f orm. Agenda. Coaching Summary Coaching Results and Feedback Main Findings Recommendations. Coaching Summary. 1. Coaching Priorities & Objectives. Scaling Product Backlog How to write good User Stories

seamus
Download Presentation

Cisco CCATG China Agile Coaching Final Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CiscoCCATG ChinaAgile Coaching Final Report UPerform

  2. Agenda • Coaching Summary • Coaching Results and Feedback • Main Findings • Recommendations

  3. Coaching Summary 1

  4. Coaching Priorities & Objectives • Scaling Product Backlog • How to write good User Stories • Splitting large Epic User Stories to small Implementable User Stories • Backlog Refinement activity to ensure Sprint readiness • Release Planning • How team precisely estimate effort/velocity to make realistic commitments • Acceptance Test Driven Development • How Scrum team work closely with PO to write good Acceptance Criteria

  5. Coaching Plan & Execution • On-site Team Coaching (89 man-days) # of Coaches onsite • On-site Customized Workshop (7 man-days) • Total effort = 96man-days (83 man-days in SoW )

  6. Team Coaching Coverage

  7. Coaching Resultsand Feedback 2

  8. Team Evaluation Forms

  9. What Teams Are Happy With • How to write good User Stories (feature and technical) • User Story splitting techniques and approaches • Why Backlog Refinement activity is must-to-have and how to execute • How to write good Acceptance Criteria • Relative effort estimation • Team velocity estimation and Release Planning techniques • Sprint Planning activity and output • Daily Scrum, Sprint Review and Retrospective activities

  10. Other Benefits regarding People & Culture • Big visible boards – most effective Agile tools • Improved team moral through effective retrospective • Established internal coaches communities in 3 sites • Better communication between team members (e.g., Dev and QA) • Daily Brown Bag sessions to share knowledge & experience • Helped the teams to identify issues and problems

  11. What Teams Are Still Struggling With • Collaboration gap with PO/EM in US • Backlog Refinement – very hard to get US involvement because of the “extra” effort US team have to pay • User Stories – very hard to split Epics since they are often tasks entered by US teams • Time consuming Scrum Meetings – language and communication skills need to be improved on the China side • Release Planning (Agile Commit) • US managers are used to the current time estimates, progress is tracked by hours so team has to turn points to hours • Cannot estimate velocity without relative estimation • Getting User Stories to “Done” • Rally is not easy to be customized to fit Cisco Agile context

  12. Main Findings 3

  13. Team Level Findings

  14. Agile Delivery Process • Lack of visibility to product/program roadmap • User stories are still too large • Tasks instead of user stories • Lack of requirement details, hard to write AC • Hard to do relative estimates • Lack of DoR (Definition of Ready) • Backlog Refinement activity and DOR is not widely adopted in US • Good Scrum format, but some are small waterfall inside

  15. Requirement & Product Backlog • Lack of commitments against DoD: undone User stories are accepted • Technical “User Stories” cannot lead to real feature delivery • Multiple Sprints to deliver 1 user story • Separated Dev Stories and QA Stories • Long bug lists

  16. Tools & Engineering Practices • Rally (or other tools) is only used in team level, need to be extended to Program and Portfolio level to establish transparency and visibility • No target environment to deploy after each Sprint • For back-end projects, high test coverage doesn’t lead to high quality – not all corner cases can be identified without a client • TA coverage is still not high enough • Use WebEx too much for in-office communication

  17. Team & Culture • PPO role does not have enough authority to drive Backlog refinement • Some PPOs are playing the technical leader roles, focus on tasks more than on requirements • EMs are playing the “pig” role – hands-on “managing” the team • All-green reports • PPO and manager assign tasks to individuals • Scrum teams with more than 20 people • Highly specialized team members • Skipping Daily Scrum & Retrospective

  18. Program/SoS Level Findings

  19. Agile Program Management • Very high complication and complexity • Product Decomposition: Technical/component driven • Program Management: Function/Resource manager driven • Reticulation relationship between components and teams • Ad-hoc Program Management, lack of program management maturity • Weak Scrum of Scrum guidance and governance • Management silos between different sites in one program • Lack of transparency, communication silos between different end-points • Ad-hoc Risk/Issue/Dependency management

  20. Scaling Product Backlog • Lack of Product Roadmap and Roadmap visibility • Lack of one single view of different levels of Product Backlogs • Unclear ownership for Product Backlog • Teams/Programs/Releases have different priorities

  21. Delivery & Release Management • Long release cycles and feedback loop • Lack of the capability of deliver on cadence • Ad-hoc Sprint delivery approaches (Sprint schedule, Sprint approach, etc) • Complex dependencies between components – late integration leads to late release • No program level CI/CD • Deployment (Build + Deployment + Automated Regression Testing) takes too long

  22. Team and culture • Department walls between Product Management, Engineering and Cloud Service • Unclear R&R definition for critical Agile/Scrum roles • Unclear roles and responsibilities for management layer • “Component” Ownership leads to the resistance of sharing code • Collaboration gaps among different sites • Collaboration gaps cross components

  23. Product/Program/Component Relationship

  24. Product/Program/Component Relationship

  25. Product/Program/Component Relationship

  26. Recommendations 4

  27. Organization Level Scaled Scrum Framework Ownership Realignment Team Optimization Break Department Silos Establish Agile Program Management Layer New role: Agile Program Manager & PMO Agile release process: develop on cadence, release on demand Engineering practices and tools Program/SoS Level Team Level Code Check-in Process Continuous Code Review + Formal Code Review Process Backlog refinement + DoR + DoD 1 – 2 weeks Sprints

  28. Organizational Recommendations:Scaled Scrum Framework

  29. Scaled Scrum Framework Portfolio Vision & Planning Feature Epics Product Management Portfolio Backlog PORTFOLIO Engineering Architecture Epics Agile Release with Cadence Target Quarterly Release AC Program Backlog Release Planning & Product Roadmap Feature Feature Feature Feature PROGRAM Arch Arch Iteratively Incremental Delivery Feature and Component Teams Team A Team Backlog TEAM Team B Team C Monthly Delivery

  30. Example WebEx Conferencing WebEx 11 Portfolio Backlog PORTFOLIO Train WebEx 11 Orion Mobility WebEx 11: End to End Quarterly Release MISSING WebEx 11 Pages Pebble Beach Program Backlog Release Planning & Product Roadmap Whitney Integration Feature Feature Feature Feature PROGRAM Eureka Integration Arch Arch …… Iteratively Incremental Delivery Feature and Component Teams WebEx 11 Pages Team Backlog TEAM Pebble Beach Whitney Monthly Delivery

  31. Streamline: Scaling to Program Level • Agile Program Management groups committing to continuously value delivery (quarterly release to destination, e.g., Early Field Trial) • Continuously align to a common mission within delivery Scrum teams which committing to deliver fully tested solutions every 4 – 6 weeks • Common Sprint lengths and normalized velocity, same start and end dates • Transparent visibility to Program Backlog, Feature Burn Up and delivery status

  32. Develop on Cadence. Deliver on Demand Major Release to EFT Major Release to EFT Major Release to EFT Urgent Update Customer Update Deliver on Demand Develop on Cadence

  33. Agile Program Management Group • Director level involvement • Perspectives from Product Management, Engineering and Cloud Service teams • Shared mission on Program Delivery Cadence • Agile PMO – review status for all programs • Transparency and visibility – Program Dash Board

  34. Agile PMO Review Meeting in Numbers • 0 Most Important: VP level leadership • 1 weekly meeting – happens every week • 1 hour time-boxed – keep it short and focused • 2 focuses –Program status, and RID (Risk/Issue/Dependency) • 3 key metrics – Schedule, Quality, Productivity

  35. Organizational Recommendations:Ownership Realignment

  36. Ownership Alignmentin Organization Matrix Report Line Product Portfolio Management SVP/VP Portfolio Backlog Agile Program Management Group Director Vision & Roadmap (Product Management, Engineering (US + CHN) & Cloud Service) Product Alignment PM/EM US Chief PO Program Backlog EM CHN Area PO Team Backlog Scrum team Virtual Technical Group Across teams

  37. Chief Product Owner & Area Product Owner PRODUCT TEAM VPPRODUCT MGMT STAKEHOLDERS SVP OWNS A PRODUCT PORTFOLIO DIRECTORPRODUCT MGMT PM (CPO) DIRECTOR PRODUCT MGMT PM VPENGINEERING SCRUM TEAMS EM (CPO) ENG DIRECTOR US EM ENG DIRECTOR US APO APO APO DIRECTOR CHINA Scrum Team (Dev+QA) Scrum Team (Dev+QA) Scrum Team (Dev+QA) Scrum Team (Dev+QA) Scrum Team (Dev+QA)

  38. Organizational Recommendations:Team Optimization

  39. Team Optimization • People Managers could have more team members – decrease People Manager ratio • Grow more Individual Contributors to take Area PO role • People managers own talents (technical growth, people development, innovation, etc.) Scrum Team (Dev/QA) Scrum Team (Dev/QA) Scrum Team (Dev/QA) Scrum Team (Dev/QA) APO as IC APO as IC SITE DIRECTOR Technical Management & Talent Development HR & Workforce External Vendors People Manager People Manager People Manager

  40. Program/SoS Level Recommendations:Agile Program Management

  41. Break Department Silos • Make Product Management, Engineering and Cloud Service people one same team • Make individuals from different locations one same team

  42. Agile Program Manager Role • A cross functional, cross location role committing to Program delivery • Authorized to work with different functions to ensure collaboration • Program level facilitator for Program planning and tracking • Maintain program level visibility and transparency • Process governance • Risk/Issue/Dependency management • Blocker remover and escalation accelerator

  43. Agile Release Process in Program Level • Define measurement within one program • Use User Story Cycle Time as the maturity measurement • Agile dashboard with GREEN/YELLOW/RED lights(Quality, Schedule, Productivity) • Normalize relative estimation against effort and velocity • Establish Agile release planning process on program level • Consistent Sprint delivery cadence • Product Roadmap and Release Map

  44. Engineering Practice and Tools • Create engineering internal DoD environment with continuous deployment • Invest more on testing automation (architecture, framework and tools) • Integrated Dev & QA team model • Reduce the # of dedicated testers, increase quality assurance engineers • Encourage team to practice Test Driven Work • Decrease the ratio between Developers and QAs

  45. Team Level Recommendations

  46. Team and Culture • Clarify R&R • Make it mandatory that engineering teams use their own products • Create new career paths for Product Owners and ScrumMasters • One Agile community cross location to promote cross-site Agile sharing • Hire more people with solid English language and communication skills

  47. Engineering Practices and Tools • Code check-in Process to ensure sufficient testing before code check-in • Continuous Code Review and Formal Code Review Process • Educate the traditional developers that quality is their responsibility

  48. Q & A

More Related