is the best approach ✘ › Provide basic LeSS Overview for the purpose of understanding terms used and content of this session ✓ › Underlying reasoning behind LeSS principles ✘
a particular Agile methodology Trust No Trust = Not Agile Believe in transparency, overcommunicate, and open-minded Collaboration Open-minded to suggestions from others and learn from experience Responding to change Flexible to change Being able to respond fast to changes in market
request takes longer to deliver Collaboration More burden: Service Planners for detail specs, Developers code base dependency grew, QA needed more time to test Responding to change 4-6 weeks per release Requirement at most may miss current sprint and wait 2 months
Sprint Release at end of Month 1 Potential Shippable per Sprint + Use 2nd Sprint as buffer Release every 2 Sprint 1 Potential Shippable per Sprint Release every 2 Sprint 1 Potential Shippable per Sprint Release every Sprint Transition (2W Sprint) Transition (2W Sprint) Goal Before (4W Sprint)
and priority. Members from all 4 teams pick tickets from the top, and quickly trade with other team to maximize productivity. Sprint Planning 1 ( Overall Planning ) Each team takes the selected tickets and begin planning independent from other teams. Base on estimation and story break down, quickly negotiate with service planners Sprint Planning 2 ( Single Team Planning )
manager assistance › Cross team / function collaboration improvement › Any good lessons learned worth sharing with other team Team Representatives Scrum Masters Product Owner Managers
Cross-team More responsible teams Gradual rollout, Feature toggle, Automation coverage, QA regression shortened Planning/PBR Task breakdown, Estimation, ticket exchange, align PBR/Planning teams Scrum/Kanban? Split into leading team for V2 architecture revamp