Downloaded 1,007 times
More Related Content
Similar to Introduction to scaled agile framework
Introduction to scaled agile framework
- 1. Introduction to ScaledAgile Framework
- 2. Why Scaling Agile? ▸To some, “scaling agile” means going from a few agile teams to multiple, or even hundreds of, agile development teams. ▸Some unique challenges that come up whenever you have an organization where more than 3 or 4 agile teams need to work together in a coordinated fashion. ▸Need new approaches that harnesses the power of Agile and Lean and applies to the needs of the largest software enterprises
- 3. Scaling factors facedby Agile teams www.disciplinedagileconsortium.org
- 4. Disciplined Agile Delivery 4 2models – Iteration based and Flow Based Uses non Scrum terminology • Iteration instead of Sprint • Work item list – instead of a Product backlog Supports robust set of roles – Team Lead, Architect, PO, Stakeholder Teams are Enterprise aware Governance “built in”
- 5. Large Scale Scrum(LeSS) Two Agile Scaling Frameworks •LeSS: Up to eight teams (of eight people each). •LeSS Huge: Up to a few thousand people on one product. Principles : Queuing Theory Empirical Process control Lean thinking Systems thinking Continuous Improvement Whole Product Focus
- 6. Scaling Agile@Spotify Squad –Scrum team Tribe – Collection of Squads Chapter – Small family of people having similar skills, having same competency area Guilds – Community of Practice- share knowledge tools and practices
- 7. ScaledAgileFramework.com Synchronizes alignment, collaboration and delivery forlarge numbers of teams CORE VALUES 1. Program Execution 2. Alignment 3. Code Quality 4. Transparency Scaled Agile Framework
- 8. Scaling Methods andApproaches Version one 9th Annual State of Agile Survey
- 10. SAFe – TeamLevel ▸ Valuable, fully-tested software increments every two weeks ▸ Empowered, self-organizing, self-managing cross-functional teams ▸ Teams operate under program vision, architecture and user experience guidance ▸ Scrum project management and XP-inspired technical practices ▸ Value delivery via User Stories
- 11. SAFe – ProgramLevel ▸ Self-organizing, self-managing team-of-agile-teams ▸ Working, system increments every two weeks ▸ Aligned to a common mission via a single backlog ▸ Common sprint lengths and estimating ▸ Face-to-face release planning cadence for collaboration, alignment, synchronization, and assessment ▸ Value Delivery via Features and Benefits
- 12. Agile Release Train ▸Long lived self organizing team of 5-12 Agile teams (50-125 individuals) that delivers solutions ▸ Program Increment is a fixed time box (default 10 weeks) ▸ Aligned to a common mission via a single Program backlog ▸ Produces valuable and evaluate-able system level solutions frequently
- 13. Key Program roles ▸Release Train Engineer – Chief Scrum master for the train ▸ Product Management – owns, defines and prioritizes the product backlog ▸ System Architect – provides architectural guidance and technical enablement to the team ▸ System team – provides process and tools to integrate and evaluate assets early and often ▸ Business Owners – Key stakeholders of the Agile Release Train
- 14. Release Planning ▸ 2days every 8-12 weeks ▸ Every one attends in person, if at all possible ▸ Each team comes out with PI objectives which are brief summaries in business terms what each team intends to deliver at the end of the PI ▸ There is a Program Board which lists out all the features, the milestones, the dependencies, and anticipated delivery dates of all the teams in a PI
- 15. Program Board -Sample
- 16. SAFe - Portfolio ▸Centralized strategy, decentralized execution ▸ Lean-Agile budgeting empowers decision makers ▸ Kanban systems provide portfolio visibility and WIP limits ▸ Enterprise architecture is a first class citizen ▸ Objective metrics support governance and kaizen ▸ Value description via Business and Architectural Epics
- 18.
- 19. Goal: Speed, Quality,Value The Goal Sustainably shortest lead time Best quality and value to people and society Most customer delight, lowest cost, high morale, safety All we are doing is looking at the timeline, from the where the customer gives us an order to where we collect the cash. And we are reducing the time line by reducing the non-value added wastes. —Taiichi Ohno We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds. —Mary Poppendieck Most software problems will exhibit themselves as a delay. —Al Shalloway
- 20. Respect for People Your customer is whoever consumes your work Don’t trouble them Don't overload them Don't make them wait Don't impose wishful thinking Don't force people to do wasteful work Equip your teams with problem- solving tools Form long-term relationships based on trust People Develop individuals and teams; they build products Empower teams to continuously improve Build partnerships based on trust and mutual respect
- 21. Kaizen Become Relentless In: Reflection Continuous improvement as an enterprise value A constant sense of danger Small steady, improvements Consider data carefully, implement change rapidly Reflect at milestones to identify and improve shortcomings Use tools like retrospectives, root cause analysis, and value stream mapping Protect the knowledge base by developing stable personnel and careful succession systems
- 22. Product Development Flow DonReinertsen Principles of Product Development Flow 1. Take an economic view 2. Actively manage queues 3. Understand and exploit variability 4. Reduce batch sizes 5. Apply WIP constraints 6. Control flow under uncertainty: cadence and synchronization 7. Get feedback as fast as possible 8. Decentralize control
- 23.
Editor's Notes
- #5 This lifecycle presents a more detailed view of what we call the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle: It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls sprints). It uses non-Scrum terminology. Although the lifecycle is Scrum-based we chose to use non-branded terminology in DAD, in the case of this diagram the term iteration instead of sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead. It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle. There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and when you take this greater scope into account you begin to realize you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements. For more on this, read Agile Best Practice: Prioritized Requirements. In includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet. Such milestones are an important aspect of agile governance. We call this the basic/agile lifecycle because it’s likely where you’re going to start with DAD. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.