Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Essential SAFe® 4.0

174 views

Published on

Essential SAFe® 4.0 is a subset of big picture SAFe 4.0 framework. It is good starting point for self-learners. This slideshow cover essential aspects of SAFe framework.
It is a primer to Scaled Agile Framework.

Published in: Technology

Essential SAFe® 4.0

  1. 1. Essential SAFe® 4.0 A primer to Scaled Agile Framework Chintamani Umarani Lead Software Engineer | Certified ScrumMaster | SAFe Agilist 4.0 chintan@umarani.com
  2. 2. • What is SCRUM ? (btw…SAFe is based on Scrum-Agile)
  3. 3. • Limitation of Scrum: ( hmm… or need of SAFe?) • Only good for small, fast moving projects as it works well only with small team • Scrum lacks in program level planning • If a task is not well defined, estimating project costs and time will not be accurate • Difficult to scale to large projects with many teams and a large number of deliveries • Scrum-of-Scrums is insufficient
  4. 4. Why SAFe? • For larger organizations (5-12 scrum teams or 50-125 people), especially those with • larger and more complex systems to develop and support, SCRUM does not provide very much guidance around scaling • Without SAFe, There is disconnect between teams which are working on same project • Often there are mis-understandings and it ends with blame games • Although SAFe builds on SCRUM, It doesn’t replace it
  5. 5. What is SAFe ? The Scaled Agile Framework® (SAFe®) was designed to help enterprises deliver value continuously and more efficiently on a regular and predictable schedule, making them more Agile in the marketplace and more competitive in their industry.
  6. 6. The big picture of SAFe 4.0 Framework
  7. 7. Internal Let’s deepdivein SAFe 9
  8. 8. • Agile Teams and Release Train • ART is a long-lived, self-organizing team of Agile teams, a virtual organization (50-125 people) that plans, commits, and executes together • Each train must include real, cross- functional Agile teams, as well as people from various other disciplines
  9. 9. • Without Agile Teams and ARTs: • Teams don’t work towards a common mission. • Teams locally optimize and can’t deliver end to end value. • Dependencies rule the day. • Individuals are over-specialized; bottlenecks inhibit flow and release of value. • There is no architectural and user experience integrity 11
  10. 10. • Cadence and synchronization • Cadence provides a rhythmic pattern, the dependable heartbeat of the development process • Synchronization required to align development teams and the business to a common mission at Program Increment (PI) planning 12
  11. 11. 13 • Without cadence and synchronization • There’s no development rhythm. • You constantly fight entropy and misalignment. • It’s impossible to schedule planning, retrospectives, demos and key events. • It’s hard to adjust to changing priorities. • You can’t limit Work in Process (WIP) and are constantly overloaded
  12. 12. • Essential Team and Program Roles • Team roles • Scrum Master: Facilitating team meetings, driving Agile behavior, removing impediments • Product Owner: Maintains the team backlog, acts as the customer for team, prioritizes the work. • Development Team: Developers, testers, and various specialists, They define, build, test, and deliver software, hardware, system components or features • Program Roles • The Release Train Engineer (RTE): Acts as the chief Scrum Master • Product Management: Responsible for identifying customer needs • System Architect-Engineering: Align ARTs with a common technological and architectural vision. • Business Owners: Responsibility for customer relationships, development, solution quality, deployment, operations, Product Management, and architecture • Customer: The king 14
  13. 13. • Responsibilities for most everything is unclear. • Decision-making is fractured, late, and uncertain. • Deliverables do not meet stakeholder expectations. • Solution features and components evolve incompatibly. • Vision and requirements are unclear and hard to prioritize. • Improvements are virtually impossible to achieve 15 • Without these critical roles …
  14. 14. • Program Increment (PI) 16
  15. 15. • Program Increment (PI) Planning: • The most powerful event in SAFe which provides cadence or rhythm to ART • All team members (50~125 people) gather for two days to work together on plans, identify dependencies. • Teams come together periodically to better define and design the system that fulfills the vision, and to commit to near-term PI objectives • This event creates, fosters and sustain a sense of shared mission, responsibility, and collaboration • Responsibility for planning moves from central authority to the teams. • This event builds the social network that the ART depends on 17
  16. 16. • Example of PI planning: • There are teams in the U.S. planning at the same time with remote teams in India, using video conferencing. Leads from teams in Eastern Europe are attending the U.S. event in person, and are collaborating with their teams remotely. U.S.-based Business Owners are sitting at the table in the middle, accessible to everyone. Product Owners are with their teams in India. 18
  17. 17. • Without PI Planning … • Stakeholders, teams, and management are misaligned. • Demand doesn't match capacity, eliminating predictability and creating excess WIP. • Lack of trust between stakeholders and teams develops. • Dependencies are discovered by “running into them.” • The result is low commitment, ownership, and enthusiasm 19
  18. 18. 20 • System Demo: • Primary measurement of ART progress. • Every two weeks, the full system— the integrated work of all team • Stakeholders provide the feedback and Teams takes corrective action • At the end of each PI, a final system demo is held
  19. 19. • Without the System Demo: • Things are just “waterfalled”. • Problems and risks are discovered too late. • Teams are sprinting, but the system is not. • Chronic lack of trust develops between stakeholders and teams. • There’s no feedback about the right solution. • False progress leads to poor quality 21
  20. 20. • Inspect and Adapt: • Inspect and Adapt (I&A) workshop is a significant event held at the end of each PI • A regular time to reflect, collect data and solve problems, the I&A workshop assembles teams and stakeholders to assess the solution, and define and take action on the improvements needed to increase the velocity, quality, and reliability of the next PI • The I&A has three parts: • 1. PI system demo. Demo of all features completed by the ART • 2. Quantitative measurement: • 3. Problem-solving workshop: Retrospective for the PI 22
  21. 21. • Without Inspect and Adapt: • Problems perpetuate without systemic improvement. • There is no way to measure or establish delivery predictability. • Improvement attempts address symptoms, not root causes. • Those who could change the system are not engaged. • Morale deteriorates. 23
  22. 22. • Innovation and Planning (IP) Iteration: • When teams are working on PI objectives, Every iteration counts, and the teams are mostly “heads down,” focused on near-term delivery so there is very litter scope for innovations. • To address this, the IP iteration provides opportunity, for teams to work on activities that are difficult to fit into a continuous delivery model. • Time for innovation and exploration, a dedicated time for the scheduled PI system demo, the I&A workshop, PI planning events, backlog refinement for the next PI, and even time for continuing education. 24
  23. 23. 25 Without the IP iteration: • Lack of delivery capacity buffer impacts predictability. • Tyranny of the urgent overrules innovation. • Technical debt grows uncontrollably. • People burn out. • There’s no time for teams to plan, demo, and improve together.
  24. 24. • For further reading : SAFe: http://www.scaledagileframework.com http://www.scaledagileframework.com/introduction-to-safe http://umarani.com/how-pass-leading-safe-exam Scrum: http://umarani.com/how-to-pass-csm-test http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf http://scrumprimer.org/scrumprimer20.pdf 26
  25. 25. Internal Q & A 27
  26. 26. Internal Thank You Chintamani Umarani Lead Software Engineer | Certified ScrumMaster | SAFe Agilist 4.0 chintan@umarani.com 28

×