This document provides guidance on key principles for distributed agile teams based on SAFe and Scrum principles. It discusses three main principles: 1) Close, daily cooperation between business and developers; 2) Applying cadence and synchronizing teams; and 3) Incremental building with fast learning cycles. It recommends structures for different types of distributed teams and emphasizes synchronizing ceremonies. It provides an example schedule for an offshore team and lists common tools used by distributed teams. The overall message is that distributed agile success relies on timely feedback across stakeholders and is a journey that requires adapting processes and culture.
Modern agile & ESP proposal for TransformationRavi Tadwalkar
The document proposes adopting a Modern Agile approach using Enterprise Services Planning (ESP) for PE Operations management. Modern Agile focuses on making people and safety a priority, rapid experimentation and learning, and continuous delivery of value. ESP is a Kanban-based system that coordinates across interconnected services using cadences to improve speed, optionality and agility while maintaining control. The proposal recommends understanding current challenges, mapping current and desired future states, designing Kanban boards and experiments to iteratively achieve targets like reducing hardware onboarding time from 160+ days to 1-2 days with an empowered team. Value stream mapping is used to analyze workflows, identify waste and non-value add time with a goal of continuous improvement.
LKIN2018: leveraging Lean and Kanban to implement continuous improvementRavi Tadwalkar
Here are the key steps in the improvement plan:
1. Understand the direction and challenges facing Operations through initiatives like the Tech Refresh program. The focus is on hardware onboarding/offboarding bottlenecks.
2. Assess the current condition through value stream mapping to identify operational inefficiencies and document the "as is" state.
3. Define the next feasible target condition by documenting the desired "to-be" state value stream map.
The plan involves understanding the challenges, assessing the current process inefficiencies, and defining an improved future state to guide continuous improvements in Operations.
The document outlines a 5-step DevOps assessment and improvement process: 1) Intake and planning, 2) Discovery, 3) Roadmap development, 4) Piloting improvements, and 5) Wider rollout. It describes assessing an organization's DevOps capability maturity across people, processes, and tools. Deliverables include an assessment report, value stream map, deployment pipeline diagrams, and a 30-60-90 day continuous improvement plan. The key takeaway is that DevOps requires an open culture embracing Agile, Lean, and continuous feedback across stakeholders.
LKIN2019: Lean transformation journey of infra briefing for business agility...Ravi Tadwalkar
This document outlines a plan to implement a continuous improvement and innovation model for business agility. It involves leveraging design thinking, lean change canvases, lean and Kanban methods. The plan maps the model to strategic imperatives and team activities over 10 weeks. Key activities include establishing the continuous improvement model, prioritizing value streams, creating a Kanban board to manage experiments, developing value stream maps, and sustaining the model through skills development and innovation teams. The overall goal is to help the organization sense changes and respond accordingly to deliver value to customers.
The document outlines an agenda for a Lean-Agile leadership workshop for executives. It will begin with comparing waterfall vs Lean-Agile methodology, focusing on adopting a value-driven mindset by looking at culture first. It will then cover Agile product management, discussing topics like limiting work in progress, prioritization using journey maps and story maps, and the product owner role. Executives will also have a Q&A about Agile transformation journeys and be provided with self-learning aids.
Pecha kucha format- how can devops be implemented with lean and agileRavi Tadwalkar
Title:
-------
Case Study: Lean Manufacturing plant level continuous improvement
How can DevOps be implemented with Lean and Agile?
Description:
-----------------
How can we leverage our knowledge of Lean Manufacturing and TPS (Toyota Production System) to implement Agile & DevOps in organizations?
My topic is about "how DevOps can be implemented with Lean and Agile", by implementing Enterprise Kanban system that has this value stream:
“Portfolio Kanban (upstream “Epics”) -> Scrum / ScrumBan / Kanban “In the middle” -> Release Engineering Kanban(Downstream “Deployable Artifacts”),
Presentation History:
Agile2016, PechaKuchaLightening Talk on July 27, 2016
Reference:
---------------
Slides 21-27 in my preso:
http://www.slideshare.net/RaviTadwalkar/devops-approach-point-of-view-by-ravi-tadwalkar
DevOps Approach (Point of View by Ravi Tadwalkar)Ravi Tadwalkar
The document discusses a 5-step approach to implementing a DevOps journey: 1) Intake and Planning, 2) Discovery Phase, 3) Roadmap Phase, 4) Pilot Phase, 5) Wider Rollout. It describes each step in detail, covering activities such as defining goals and scope, conducting assessments, creating recommendations and roadmaps, training, and socializing outcomes. The goal is to help organizations improve their DevOps capability maturity over time through this phased approach.
Modern agile & ESP proposal for TransformationRavi Tadwalkar
The document proposes adopting a Modern Agile approach using Enterprise Services Planning (ESP) for PE Operations management. Modern Agile focuses on making people and safety a priority, rapid experimentation and learning, and continuous delivery of value. ESP is a Kanban-based system that coordinates across interconnected services using cadences to improve speed, optionality and agility while maintaining control. The proposal recommends understanding current challenges, mapping current and desired future states, designing Kanban boards and experiments to iteratively achieve targets like reducing hardware onboarding time from 160+ days to 1-2 days with an empowered team. Value stream mapping is used to analyze workflows, identify waste and non-value add time with a goal of continuous improvement.
LKIN2018: leveraging Lean and Kanban to implement continuous improvementRavi Tadwalkar
Here are the key steps in the improvement plan:
1. Understand the direction and challenges facing Operations through initiatives like the Tech Refresh program. The focus is on hardware onboarding/offboarding bottlenecks.
2. Assess the current condition through value stream mapping to identify operational inefficiencies and document the "as is" state.
3. Define the next feasible target condition by documenting the desired "to-be" state value stream map.
The plan involves understanding the challenges, assessing the current process inefficiencies, and defining an improved future state to guide continuous improvements in Operations.
The document outlines a 5-step DevOps assessment and improvement process: 1) Intake and planning, 2) Discovery, 3) Roadmap development, 4) Piloting improvements, and 5) Wider rollout. It describes assessing an organization's DevOps capability maturity across people, processes, and tools. Deliverables include an assessment report, value stream map, deployment pipeline diagrams, and a 30-60-90 day continuous improvement plan. The key takeaway is that DevOps requires an open culture embracing Agile, Lean, and continuous feedback across stakeholders.
LKIN2019: Lean transformation journey of infra briefing for business agility...Ravi Tadwalkar
This document outlines a plan to implement a continuous improvement and innovation model for business agility. It involves leveraging design thinking, lean change canvases, lean and Kanban methods. The plan maps the model to strategic imperatives and team activities over 10 weeks. Key activities include establishing the continuous improvement model, prioritizing value streams, creating a Kanban board to manage experiments, developing value stream maps, and sustaining the model through skills development and innovation teams. The overall goal is to help the organization sense changes and respond accordingly to deliver value to customers.
The document outlines an agenda for a Lean-Agile leadership workshop for executives. It will begin with comparing waterfall vs Lean-Agile methodology, focusing on adopting a value-driven mindset by looking at culture first. It will then cover Agile product management, discussing topics like limiting work in progress, prioritization using journey maps and story maps, and the product owner role. Executives will also have a Q&A about Agile transformation journeys and be provided with self-learning aids.
Pecha kucha format- how can devops be implemented with lean and agileRavi Tadwalkar
Title:
-------
Case Study: Lean Manufacturing plant level continuous improvement
How can DevOps be implemented with Lean and Agile?
Description:
-----------------
How can we leverage our knowledge of Lean Manufacturing and TPS (Toyota Production System) to implement Agile & DevOps in organizations?
My topic is about "how DevOps can be implemented with Lean and Agile", by implementing Enterprise Kanban system that has this value stream:
“Portfolio Kanban (upstream “Epics”) -> Scrum / ScrumBan / Kanban “In the middle” -> Release Engineering Kanban(Downstream “Deployable Artifacts”),
Presentation History:
Agile2016, PechaKuchaLightening Talk on July 27, 2016
Reference:
---------------
Slides 21-27 in my preso:
http://www.slideshare.net/RaviTadwalkar/devops-approach-point-of-view-by-ravi-tadwalkar
DevOps Approach (Point of View by Ravi Tadwalkar)Ravi Tadwalkar
The document discusses a 5-step approach to implementing a DevOps journey: 1) Intake and Planning, 2) Discovery Phase, 3) Roadmap Phase, 4) Pilot Phase, 5) Wider Rollout. It describes each step in detail, covering activities such as defining goals and scope, conducting assessments, creating recommendations and roadmaps, training, and socializing outcomes. The goal is to help organizations improve their DevOps capability maturity over time through this phased approach.
Kin2020- flow based product development- an experience reportRavi Tadwalkar
The document discusses transitioning a product development team from a mandated Scrum process to a leaner Scrumban process. It emphasizes focusing on flow-based product development and increasing collaboration through practices like mob programming and behavior driven development. The team used tools like a process evaluation framework and simulation to help decide what process changes would work best for increasing flow efficiency and productivity.
Agile lean workshop for managers & exec leadershipRavi Tadwalkar
This document summarizes an agile workshop for managers and executive leadership at Cisco. The workshop covers several topics:
- Defining the role of an agile functional manager and transitioning existing managers to this role.
- Discussing whether the concept of "servant leadership" is too idealistic and assessing different leadership styles.
- Explaining the value of having a dedicated team room to facilitate transparency, collaboration and trust within agile teams.
The workshop provides guidance to leadership on adopting an inside-out approach to cultural change, emphasizing assessing organizational culture before implementing new processes or structures. Overall, the document outlines an agenda to help management explore how to effectively lead teams using agile and lean
Embrace TQM (Total Quality Mgmt) mindset with lean thinkingRavi Tadwalkar
This document discusses embracing a Total Quality Management (TQM) mindset with Lean thinking. It provides context that improving ecosystem quality is the goal. An approach is to embrace a TQM mindset and Lean thinking to implement TQM and Lean for product and IT service teams. A case study describes how a printing, packaging, and shipping Lean manufacturing workflow at LifeTouch uses tools like PDCA loops and Kanban boards for continuous improvement tracking and Kaizen events.
The document provides an overview of the Kanban Coaching Professional (KCP) Masterclass taught by LKU (David Anderson) from April 28 - May 2, 2014 and the Lean Kanban North America (LKNA) 2014 conference from May 5-8. It discusses topics from the KCP including the Kanban method overview, core practices, advanced topics, and a case study on capacity allocation. Photos and experiences from LKNA 2014 are also included along with recommended reading and references on Kanban.
Ravi Tadwalkar as SM/DevOps/management/CoachRavi Tadwalkar
The document discusses the roles and responsibilities of a Scrum Master, DevOps Manager, and DevOps Coach. It provides examples of how DevOps adoption improved deployment processes at companies like PayPal and Western Digital. Specifically, implementing continuous integration/deployment and embedding release engineers into agile teams reduced PayPal's deployment time from 6 weeks to 9 days. For Western Digital, using a common code repository improved their firmware integration from twice a week to on-demand. The document also outlines the author's experience over 20 years in software development, management, coaching, and DevOps roles.
In Agile Development, Testing is meant to be a part of the development process, right along with coding, but many “Agile Teams” are missing this vital component and experiencing degregated quality. In this presentation, we will discuss how to integrate Agile Testing in Kanban processes by discussing the following:
• Introduction to Agile and Lean
• How testers add value to cross-functional Agile Development Teams
• How testers participate in Agile ceremonies
• How to test in an Agile Environment
• The Four Environments (Dev, Test, Stage, Production)
• The types of testing that occurs in each environmen
Resource Planning is one of the biggest headaches for medium to large organizations. Creating a detailed resource plan that is meaningful is very difficult, and keeping it up to date is almost impossible. Plans that look good are often an attractive fiction, full of unrealistic assumptions, over-allocations, and the spreading of too-few people in too many ways.
Agile Resource Planning provides a very different approach to the classic model. It produces realistic plans that are simple to maintain, and effective for planning work over time. In this webinar, Dr. Kevin Thompson will present new concepts in Agile Resource Planning, which provide a practical and easy-to-use approach to Resource Planning that can be used for Agile and classic environments.
The PPT is about scaling agile across various non-cross-functional teams and the various experiments that were done before arriving at a methodology that worked for the teams.
Agile introduction for the American Chamber of Commerce membersAndy Brandt
This document provides an overview of Agile and Scrum. It begins with introducing Agile and its core values as outlined in the Agile Manifesto. It then provides a quick introduction to Scrum, describing the basic components of Scrum including roles, artifacts, and events like Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The document discusses the goals and purpose of each Scrum component and ceremony.
Join agile coaches Bob Galen from RGCG and Michael Cooper from the QASymphony Board of Advisors as they explore key aspects of the 3-Pillars of Agile Quality & Testing framework that Bob and Mary Thorn developed. In this dynamic panel discussion Bob and Michael will tackle what it takes to be a balanced and effective tester in today’s agile world. We’ll talk about tools, techniques, attitudes, and adjustments. There will be no “one size fits all” strategies here, just real-world experience sharing stories about what works and what doesn’t.
Agile & Lean & Kanban in the Real World - A Case StudyRussell Pannone
The document discusses Lean, Agile, and Kanban principles and methods. It provides an overview of Lean Agile approaches, the Kanban method, and a case study of an infrastructure team at a footwear company applying hybrid Lean Agile and Kanban principles. The team was previously using Scrum but found it did not fit their reactive, event-driven work. They decided to experiment with Kanban to better fit their work style and provide more visibility into tasks. The goal was to see if work-in-progress limits and measuring cycle time would help improve their effectiveness.
An explanation of Agile and how it relates to frameworks like Scrum.
What is Agile: https://agile-mercurial.com/2019/01/28/what-is-agile-1-minute-explanation-video/
Blog: https://agile-mercurial.com
YouTube: https://www.youtube.com/channel/UCPM82of2YuqIR1SgLGHa1eg
Twitter: https://twitter.com/agile_mercurial
Tumblr: https://agilemercurial.tumblr.com/
First DRAFT of a DevOps presentation and posters covering the essentials for a DevOps mindset. Help improve the content by forking and contributing a pull request to https://github.com/wpschaub/DevOps-mindset-essentials/blob/master/README.md.
This document discusses best practices for using agile product development for hardware projects. It provides differences between hardware and software development such as hardware being more difficult to change after manufacturing. It recommends using scrum with a focus on technical stories for hardware. An example project at Thermo Fisher Scientific developing analytical chemistry equipment is described that successfully used scrum. Key lessons learned include the product owner also being a team member, most deliverables being behind the scenes technical work rather than user-facing, and estimation and velocity being more challenging for hardware projects.
Agile Cafe Boulder - Panelist and keynote slidesCloud Elements
Agile Cafe, 2/3 in Boulder, CO. Presentations from Adam Woods at StoneRiver, Bill Holst at Colorado Springs Utilities and keynote by Jean Tabaka at Rally Software.
Life Has Not Been That Rosy With Agile : Rahul SudameoGuild .
In my experience, Agile adoption started in some of the organizations with lot of hype and inflated expectations. And in such cases, if Agile transformation is not handled properly, it can result in multiple challenges rather than providing the expected benefits.
This practical experience sharing session would cover some such problems I faced while applying Agile in different environments. The audience practicing Agile can relate some of these challenges with their own environment as well. The attendees who are on their path to Agile transformation can learn from the lessons and mistakes shared by the speaker.
The session would cover challenges observed due to nature of the project, customer-vendor engagement model, application of processes, attitude of people rolling out agile, unrealistic expectations, conflict in roles and responsibilities. It would also highlight challenges introduced to some of the roles (like Project/QA Manager/Manual Tester etc.) in Agile environment and impact on billing / project contracts / SOW etc.
Agile project management is more about empowerment. Agile projects are not lead by individual like project manager. Agile project management is a combination of art and science both where you should be well versed with the principals of the project management. At the same time you should be practical while taking decision and understanding circumstances.
Agile & SCRUM - Deep Dive for General Assemblytheresajaustin
A swift look at the relationship between Agile & SCRUM, then a deep dive into the practicalities and basics of SCRUM. Presented at General Assembly NYC in July 2014 to the Product Management class.
This document summarizes an Agile development presentation. It discusses the limitations of traditional waterfall development models and introduces Agile development methods like Scrum and Extreme Programming. Key aspects of Agile covered include short iterative development cycles, frequent delivery of working software, daily stand-up meetings, and collaborative practices like pair programming. The document provides examples of how Agile development methods address the challenges of frequent changes and rapid delivery in a more adaptive way compared to waterfall models.
Kin2020- flow based product development- an experience reportRavi Tadwalkar
The document discusses transitioning a product development team from a mandated Scrum process to a leaner Scrumban process. It emphasizes focusing on flow-based product development and increasing collaboration through practices like mob programming and behavior driven development. The team used tools like a process evaluation framework and simulation to help decide what process changes would work best for increasing flow efficiency and productivity.
Agile lean workshop for managers & exec leadershipRavi Tadwalkar
This document summarizes an agile workshop for managers and executive leadership at Cisco. The workshop covers several topics:
- Defining the role of an agile functional manager and transitioning existing managers to this role.
- Discussing whether the concept of "servant leadership" is too idealistic and assessing different leadership styles.
- Explaining the value of having a dedicated team room to facilitate transparency, collaboration and trust within agile teams.
The workshop provides guidance to leadership on adopting an inside-out approach to cultural change, emphasizing assessing organizational culture before implementing new processes or structures. Overall, the document outlines an agenda to help management explore how to effectively lead teams using agile and lean
Embrace TQM (Total Quality Mgmt) mindset with lean thinkingRavi Tadwalkar
This document discusses embracing a Total Quality Management (TQM) mindset with Lean thinking. It provides context that improving ecosystem quality is the goal. An approach is to embrace a TQM mindset and Lean thinking to implement TQM and Lean for product and IT service teams. A case study describes how a printing, packaging, and shipping Lean manufacturing workflow at LifeTouch uses tools like PDCA loops and Kanban boards for continuous improvement tracking and Kaizen events.
The document provides an overview of the Kanban Coaching Professional (KCP) Masterclass taught by LKU (David Anderson) from April 28 - May 2, 2014 and the Lean Kanban North America (LKNA) 2014 conference from May 5-8. It discusses topics from the KCP including the Kanban method overview, core practices, advanced topics, and a case study on capacity allocation. Photos and experiences from LKNA 2014 are also included along with recommended reading and references on Kanban.
Ravi Tadwalkar as SM/DevOps/management/CoachRavi Tadwalkar
The document discusses the roles and responsibilities of a Scrum Master, DevOps Manager, and DevOps Coach. It provides examples of how DevOps adoption improved deployment processes at companies like PayPal and Western Digital. Specifically, implementing continuous integration/deployment and embedding release engineers into agile teams reduced PayPal's deployment time from 6 weeks to 9 days. For Western Digital, using a common code repository improved their firmware integration from twice a week to on-demand. The document also outlines the author's experience over 20 years in software development, management, coaching, and DevOps roles.
In Agile Development, Testing is meant to be a part of the development process, right along with coding, but many “Agile Teams” are missing this vital component and experiencing degregated quality. In this presentation, we will discuss how to integrate Agile Testing in Kanban processes by discussing the following:
• Introduction to Agile and Lean
• How testers add value to cross-functional Agile Development Teams
• How testers participate in Agile ceremonies
• How to test in an Agile Environment
• The Four Environments (Dev, Test, Stage, Production)
• The types of testing that occurs in each environmen
Resource Planning is one of the biggest headaches for medium to large organizations. Creating a detailed resource plan that is meaningful is very difficult, and keeping it up to date is almost impossible. Plans that look good are often an attractive fiction, full of unrealistic assumptions, over-allocations, and the spreading of too-few people in too many ways.
Agile Resource Planning provides a very different approach to the classic model. It produces realistic plans that are simple to maintain, and effective for planning work over time. In this webinar, Dr. Kevin Thompson will present new concepts in Agile Resource Planning, which provide a practical and easy-to-use approach to Resource Planning that can be used for Agile and classic environments.
The PPT is about scaling agile across various non-cross-functional teams and the various experiments that were done before arriving at a methodology that worked for the teams.
Agile introduction for the American Chamber of Commerce membersAndy Brandt
This document provides an overview of Agile and Scrum. It begins with introducing Agile and its core values as outlined in the Agile Manifesto. It then provides a quick introduction to Scrum, describing the basic components of Scrum including roles, artifacts, and events like Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The document discusses the goals and purpose of each Scrum component and ceremony.
Join agile coaches Bob Galen from RGCG and Michael Cooper from the QASymphony Board of Advisors as they explore key aspects of the 3-Pillars of Agile Quality & Testing framework that Bob and Mary Thorn developed. In this dynamic panel discussion Bob and Michael will tackle what it takes to be a balanced and effective tester in today’s agile world. We’ll talk about tools, techniques, attitudes, and adjustments. There will be no “one size fits all” strategies here, just real-world experience sharing stories about what works and what doesn’t.
Agile & Lean & Kanban in the Real World - A Case StudyRussell Pannone
The document discusses Lean, Agile, and Kanban principles and methods. It provides an overview of Lean Agile approaches, the Kanban method, and a case study of an infrastructure team at a footwear company applying hybrid Lean Agile and Kanban principles. The team was previously using Scrum but found it did not fit their reactive, event-driven work. They decided to experiment with Kanban to better fit their work style and provide more visibility into tasks. The goal was to see if work-in-progress limits and measuring cycle time would help improve their effectiveness.
An explanation of Agile and how it relates to frameworks like Scrum.
What is Agile: https://agile-mercurial.com/2019/01/28/what-is-agile-1-minute-explanation-video/
Blog: https://agile-mercurial.com
YouTube: https://www.youtube.com/channel/UCPM82of2YuqIR1SgLGHa1eg
Twitter: https://twitter.com/agile_mercurial
Tumblr: https://agilemercurial.tumblr.com/
First DRAFT of a DevOps presentation and posters covering the essentials for a DevOps mindset. Help improve the content by forking and contributing a pull request to https://github.com/wpschaub/DevOps-mindset-essentials/blob/master/README.md.
This document discusses best practices for using agile product development for hardware projects. It provides differences between hardware and software development such as hardware being more difficult to change after manufacturing. It recommends using scrum with a focus on technical stories for hardware. An example project at Thermo Fisher Scientific developing analytical chemistry equipment is described that successfully used scrum. Key lessons learned include the product owner also being a team member, most deliverables being behind the scenes technical work rather than user-facing, and estimation and velocity being more challenging for hardware projects.
Agile Cafe Boulder - Panelist and keynote slidesCloud Elements
Agile Cafe, 2/3 in Boulder, CO. Presentations from Adam Woods at StoneRiver, Bill Holst at Colorado Springs Utilities and keynote by Jean Tabaka at Rally Software.
Life Has Not Been That Rosy With Agile : Rahul SudameoGuild .
In my experience, Agile adoption started in some of the organizations with lot of hype and inflated expectations. And in such cases, if Agile transformation is not handled properly, it can result in multiple challenges rather than providing the expected benefits.
This practical experience sharing session would cover some such problems I faced while applying Agile in different environments. The audience practicing Agile can relate some of these challenges with their own environment as well. The attendees who are on their path to Agile transformation can learn from the lessons and mistakes shared by the speaker.
The session would cover challenges observed due to nature of the project, customer-vendor engagement model, application of processes, attitude of people rolling out agile, unrealistic expectations, conflict in roles and responsibilities. It would also highlight challenges introduced to some of the roles (like Project/QA Manager/Manual Tester etc.) in Agile environment and impact on billing / project contracts / SOW etc.
Agile project management is more about empowerment. Agile projects are not lead by individual like project manager. Agile project management is a combination of art and science both where you should be well versed with the principals of the project management. At the same time you should be practical while taking decision and understanding circumstances.
Agile & SCRUM - Deep Dive for General Assemblytheresajaustin
A swift look at the relationship between Agile & SCRUM, then a deep dive into the practicalities and basics of SCRUM. Presented at General Assembly NYC in July 2014 to the Product Management class.
This document summarizes an Agile development presentation. It discusses the limitations of traditional waterfall development models and introduces Agile development methods like Scrum and Extreme Programming. Key aspects of Agile covered include short iterative development cycles, frequent delivery of working software, daily stand-up meetings, and collaborative practices like pair programming. The document provides examples of how Agile development methods address the challenges of frequent changes and rapid delivery in a more adaptive way compared to waterfall models.
The document outlines the scrum process for an offshore development team, including an overview of scrum methodology, roles like the product owner and scrum master, artifacts like the product backlog and sprint burndown chart, and activities in the sprint planning, daily standups, and retrospectives. It provides details on tailoring scrum for offshore teams and defining roles for the project manager, development team, and business analyst to work with the onshore client.
Bas Vodde is the creator of LeSS, a lightweight (agile) framework for scaling Scrum to more than one team.
Toyota Production System and Lean Thinking have been an essential influence to LeSS. Lean Thinking is one of the ten LeSS principles. In this talk, he zoomed in a little on how and why Lean Thinking influenced LeSS and how similar thinking can help your development independent of ‘scaling framework’.
LeSS is different with other scaling frameworks in the sense that it provides a very minimalistic framework that enables empiricism on a large-scale which enables the teams and organization to inspect-adapt their implementation based on their experiences and context. LeSS is based on the idea that providing too much rules, roles, artifacts and asking the organization to tailor it down is a fundamentally flawed approach and instead scaling frameworks should be minimalistic and allowing organizations to fill them in.
More Lean presentations are available on www.lean-digital-summit.com
Scrum Scalability: Advanced Techniques for Managing Distributed Agile TeamsBelatrix Software
This document summarizes a webinar on scrum scalability techniques for distributed agile teams. The webinar will feature panelists Hubert Smits, a certified scrum trainer and scrum coach, and Juan Pablo Calvo, a certified scrummaster and project lead. The webinar will provide an overview of scrum and scaled scrum approaches, and discuss techniques like release planning, scrum of scrums, and the five levels of planning to help align distributed teams.
The document outlines the agile Scrum process using four phases: initiation, exploration, planning, and build. In the initiation phase, a kickoff meeting is held to define the scope and problem statement. In exploration, domain concepts are explored and prototypes are developed. In planning, release and sprint backlogs are created to prioritize user stories. Glossaries and coding standards are also defined. In build, daily stand-up meetings are held to update the sprint dashboard and status of work.
From Chaos to Confidence: DevOps at LeanKitJon Terry
This document outlines LeanKit's product development operating model, which aims to transition the organization from chaos to confidence. Key elements of the model include using Kanban and cadences to visualize and limit work-in-progress, organizing teams into squads and guilds for autonomous delivery, and holding regular meetings like tribal councils and architecture committees. The model emphasizes continuous delivery of value through deploying increments every 5 days, measuring outcomes, and improving collaboratively.
The document summarizes how a software company implemented Scrum and lean principles to improve coordination, manage requirements, and deliver releases on time. Some key problems previously were difficulty coordinating distributed teams of 1000 staff and delays in major releases. The company adapted Scrum, with roles like Product Owner and Scrum Master, along with XP practices like pair programming. This allowed parallel development across teams and on-time delivery of 2.6 and 3.0 releases through 10+1 sprints and daily stand-up meetings.
This document discusses Sprint Zero, which is the preparation period before real sprints begin for a new Scrum team. Sprint Zero is needed because the product owner and team need time to get acquainted, set up the development environment, establish processes like the definition of done, and clarify roles. The document provides a checklist of activities for Sprint Zero, including ensuring team training, setting up tools and infrastructure, defining the technical architecture and coding standards, and agreeing on the sprint agenda and planning process. It also lists signs of good and bad Scrum practices.
The document discusses techniques for implementing Scrum and agile practices. It recommends taking an iterative approach where requirements are gathered continuously throughout the project through early customer involvement, rather than gathering all requirements upfront. This allows for important discoveries to still be incorporated late in the project. It also shows a chart tracking story points committed versus completed over multiple sprints of a project, with completion percentages generally increasing each sprint.
Scrum teams can face challenges when performing quality assurance tasks. Some issues include multi-sited teams which impact communication, a lack of test automation which reduces test coverage, and using waterfall methods such as making all user stories available for testing at the end of a sprint. Other problems are a lack of code reviews and unit testing which can lead to defects, not capturing all bugs in bug reports which impacts metrics, and ambiguous user stories which makes testing difficult. Solutions include co-locating team members, automating tests, making stories testable earlier, and capturing all bugs in detailed reports.
The document discusses the role and responsibilities of a Scrum Master. It describes how the Scrum Master facilitates the Scrum process and ceremonies like daily stand-ups, sprint planning and retrospectives. The Scrum Master also helps resolve impediments, enables self-organization of the team and protects the team from external interference. Key responsibilities include enforcing timeboxes, maintaining artifacts and metrics, and guiding the team on Agile best practices. The document provides checklists and guidelines for Scrum Masters to effectively perform their duties.
The role of QA in software development is to analyze requirements, write test cases, and perform system/integration testing. QA is involved throughout the software development lifecycle, from requirements analysis through deployment. Key responsibilities of QA include analyzing requirements, writing test cases based on requirements, and executing tests to identify bugs. QA works closely with developers to ensure quality software is delivered.
Experiments that have worked for me in the last 7 years playing with Scrum in Agile teams.
The presentation covers 4 key pilars of Scrum:
- Roles: Product Owner, Scrum Master and Development Team.
- Scrum Events: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo and Retrospective.
- Scrum Artifacts: Product Backlog, User Stories, Definition of Done, Sprint Backlog, Sprint Dashboad.
- Reports: End of Sprint Report, New Sprint Report, Burn-up/Burn-down, Product Report.
Benzne Webinar : Running a sprint with JiraSwatiKapoor43
Scrum is one of the most widely used Agile frameworks for iterative and incremental project delivery and Jira is the most widely used tool to drive a scrum project. While we may understand Scrum very well or we are very experienced with JIRA, often we come across a scenario where we want help with either one of them. Join us in this free webinar where we will discuss how to utilize JIRA effectively to manage, monitor and drive a scrum project.
The document describes "The Mega Framework", an additional framework developed by UOL R&D to scale Scrum across multiple teams working on a large product backlog. Key aspects of the framework include using feature teams, a prioritized mega backlog, growing teams before splitting, and additional synchronization meetings like Mega Planning and Mega Stand-ups to coordinate multiple Scrum teams. The framework helped scale Scrum from 2 initial teams in 2010 to 10 teams currently working together through practices focused on transparency, commitment and teamwork.
The document discusses patterns and principles for scaling Scrum frameworks. It provides an overview of patterns in original Scrum and modern Scrum, as well as scaling patterns like the LeSS and SAFe frameworks. Key concepts discussed include the well-formed team, roles like the product owner and Scrum master, and patterns for addressing problems like distributing work across multiple teams.
Similar to Distributed agile- exec level briefing (20)
From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptxRavi Tadwalkar
This document provides context and information for a workshop on evaluating process frameworks like Scrum, Scrumban, and Kanban using a questionnaire in Excel. The workshop aims to help a struggling team determine what process could work best for them by discussing a series of questions. The document includes an example questionnaire comparing Scrum, Scrumban and Kanban on factors like planning, decomposition, estimation, responsiveness, and culture fit. It also summarizes key differences between the frameworks in areas like planning, timeboxing, and metrics.
The document outlines an agenda for a training on Agile concepts for executives. It includes introducing Agile concepts, characteristics of Agile teams, roles and responsibilities of Agile leaders, how Lean and Agile work together, and Lean/Agile leadership models. It also describes exercises used in the training, such as the Penny Game, and covers topics like Scrum framework, product backlogs, planning in Agile, and governance with dynamic budgeting.
The document provides an overview and agenda for a training course on becoming an effective agile team member, covering topics such as self-organized cross-functional teams, lean thinking, estimating and prioritizing backlogs, agile engineering principles, and expectations for scrum team members. The intended audience includes developers, testers, leaders, and others involved in product planning and delivery processes. Course prerequisites include completing an Agile 101 training.
This document provides an agenda for a training course on the scrum master role, covering topics such as comparing scrum masters to traditional project managers, facilitating scrum ceremonies like planning, daily standups and retrospectives, and coaching
Here are 3 scenarios that could be attached to the user story card:
Scenario 1: As a customer, I search for flights from New York to Los Angeles for next weekend. The results show available flights for those dates.
Scenario 2: As a customer, I select a flight from the results and am taken to a page to enter my personal details and payment information to complete the booking.
Scenario 3: As a customer, I receive a confirmation email after completing my booking with all the flight details.
Conversation
The team discusses things like:
- What dates constitute "next weekend"?
- What payment methods will be accepted?
- What information is included in the confirmation email?
Confirmation
This document outlines an agenda for an Agile 101 training session. It includes exercises to teach Lean and Agile principles using a penny game. It then covers what Agile is and isn't, the Agile manifesto and principles, an introduction to Scrum framework including artifacts and roles. Planning, daily stand-ups, sprints, and retrospectives are discussed. A Lego Scrum game simulation is described to illustrate a Scrum process over three sprints with optimization of the team.
Lean, agile and dev ops games- facilitator's guideRavi Tadwalkar
The document outlines exercises and games to teach Lean, Agile, and DevOps principles to teams. It includes:
1. A marshmallow building challenge to demonstrate teamwork.
2. A penny flipping game showing how doing work in parallel can be more efficient than sequentially.
3. A "management by walking" activity illustrating the value of empowering teams.
4. A ball passing game involving self-organization and continuous process improvement over iterations.
5. A Lego Scrum game simulating three sprints - the first using basic Scrum, the second optimizing the Scrum team, and the third emphasizing continuous delivery.
6. Discussion of using a Kanban
This document contains metrics from an organization's agile workflow over multiple years and weeks, including throughput (number of accepted cards per week), average lead time per week, and average flow efficiency percentage per week. It also includes totals for story points, issue types, and sprints across the recorded time period. A chart at the bottom shows the throughput values for each recorded week.
Example of BDD/scenario based vertical slicing (for PM/PO community)Ravi Tadwalkar
The document discusses high availability for establishing atomic communication paths. It states that if a request to establish a flow path is accomplished, all flows composing the connection will be programmed, but if the request fails, no flows will be programmed and an error will be reported via rollback. Typical failures include timeouts or operations failing, such as attempting to program a full flow table on a switch. Acceptance criteria include committing successfully programmed flows and rolling back failed requests to maintain integrity and atomicity.
Obstacles encountered by teams are logged on obstacle boards at three levels - team, management, and executive. At the team level, the Scrum Master tries to resolve obstacles and logs them on a physical board. Unresolved obstacles are escalated to the management level board where managers work to find solutions. Obstacles that cannot be resolved by management are escalated to the executive level board where executives are responsible for resolving or dismissing them.
This document discusses how roles and responsibilities change in Agile/Scrum frameworks compared to traditional organizations. It outlines several key Agile roles including Product Owner, Scrum Master, and Scrum Team Members. It also discusses how requirements, design, testing, and tracking emerge incrementally rather than being fully planned upfront. Cultural shifts involve moving from big requirements/design upfront to emergent approaches. The roles of Architect, User Experience Lead, Internal Coach/Mentor, Agile Program Manager, and Functional Manager are also described.
This document contains the results of an agile team assessment survey completed by three respondents. The survey contains 15 questions assessing various aspects of agile practices across 5 categories: PO ownership/backlog quality, engineering best practices, delivery of value/velocity, lead times, and team behavior.
The responses indicate the team is generally performing well across categories, with most areas scoring in the 3-4 range. Areas identified as opportunities for improvement include product backlog quality, which 2 of 3 respondents rated a 2, and regression testing during sprints, where 1 respondent rated a 2. Overall, the assessment places the team's maturity in the norming to performing range.
This document summarizes an agile leadership assessment of an individual. The assessment scored the individual a 0 out of 100 in several key areas of agile leadership, including setting clear expectations, goal setting, coaching employees, involvement in development, and attitude. All scores were 0%, indicating the individual needs to improve in all areas assessed by developing agile leadership skills. No strengths were identified. The assessment suggests the individual needs to work on and improve all leadership skills measured.
The team conducted a Lean Kanban self-assessment to evaluate their performance in several areas including visualizing work, making policies explicit, limiting work in progress, managing flow, improving processes, implementing feedback loops, and observing effects. Across the different areas evaluated, the team scored between 60-65% indicating they are occasionally to often demonstrating good Lean Kanban practices in each area but still have room for improvement.
The document provides an agenda and guidance for facilitating a multi-day release planning event involving breakout sessions at both the track and team levels. Key points include:
- The event will use breakout rooms for teams to decompose features into user stories, size stories, identify dependencies, and populate a release plan across 8 sprints.
- Guidance and "cheat sheets" are provided on techniques for feature decomposition, story sizing, and identifying risks. Sample user stories are to be pre-loaded.
- Each day involves breakout sessions, with time for leadership reviews and adjustments. On day 3 teams will present plans to track leads and participate in a confidence vote.
- In breakouts,
The document contains statistical data on lead times, including dates, lead times, frequencies of lead times, averages, medians, modes, maximums and minimums. It also includes charts on the distribution and variability of lead times over time. The data focuses on analyzing lead time metrics and performance for process improvement purposes.
Designing and Sustaining Large-Scale Value-Centered Agile Ecosystems (powered...Alexey Krivitsky
Is Agile dead? It depends on what you mean by 'Agile'. If you mean that the organizations are not getting the promised benefits because they were focusing too much on the team-level agile "ways of working" instead of systemic global improvements -- then we are in agreement. It is a misunderstanding of Agility that led us down a dead-end. At Org Topologies, we see bright sparks -- the signs of the 'second wave of Agile' as we call it. The emphasis is shifting towards both in-team and inter-team collaboration. Away from false dichotomies. Both: team autonomy and shared broad product ownership are required to sustain true result-oriented organizational agility. Org Topologies is a package offering a visual language plus thinking tools required to communicate org development direction and can be used to help design and then sustain org change aiming at higher organizational archetypes.
Originally presented at XP2024 Bolzano
While agile has entered the post-mainstream age, possibly losing its mojo along the way, the rise of remote working is dealing a more severe blow than its industrialization.
In this talk we'll have a look to the cumulative effect of the constraints of a remote working environment and of the common countermeasures.
Impact of Effective Performance Appraisal Systems on Employee Motivation and ...Dr. Nazrul Islam
Healthy economic development requires properly managing the banking industry of any
country. Along with state-owned banks, private banks play a critical role in the country's economy.
Managers in all types of banks now confront the same challenge: how to get the utmost output from
their employees. Therefore, Performance appraisal appears to be inevitable since it set the
standard for comparing actual performance to established objectives and recommending practical
solutions that help the organization achieve sustainable growth. Therefore, the purpose of this
research is to determine the effect of performance appraisal on employee motivation and retention.
A team is a group of individuals, all working together for a common purpose. This Ppt derives a detail information on team building process and ats type with effective example by Tuckmans Model. it also describes about team issues and effective team work. Unclear Roles and Responsibilities of teams as well as individuals.
Ganpati Kumar Choudhary Indian Ethos PPT.pptx, The Dilemma of Green Energy Corporation
Green Energy Corporation, a leading renewable energy company, faces a dilemma: balancing profitability and sustainability. Pressure to scale rapidly has led to ethical concerns, as the company's commitment to sustainable practices is tested by the need to satisfy shareholders and maintain a competitive edge.
12 steps to transform your organization into the agile org you deservePierre E. NEIS
During an organizational transformation, the shift is from the previous state to an improved one. In the realm of agility, I emphasize the significance of identifying polarities. This approach helps establish a clear understanding of your objectives. I have outlined 12 incremental actions to delineate your organizational strategy.
A presentation on mastering key management concepts across projects, products, programs, and portfolios. Whether you're an aspiring manager or looking to enhance your skills, this session will provide you with the knowledge and tools to succeed in various management roles. Learn about the distinct lifecycles, methodologies, and essential skillsets needed to thrive in today's dynamic business environment.
Colby Hobson: Residential Construction Leader Building a Solid Reputation Thr...dsnow9802
Colby Hobson stands out as a dynamic leader in the residential construction industry. With a solid reputation built on his exceptional communication and presentation skills, Colby has proven himself to be an excellent team player, fostering a collaborative and efficient work environment.
2. Distributed Teams – Key Principles
Among SAFe and Scrum principles, there are
three key principles that Distributed Teams
focus on:
1. Close, daily cooperation between business
people and developers
2. Principle: Apply cadence and synchronize
teams
3. Build incrementally with fast, integrated
learning cycles
Adapt and apply SAFe
practices to distributed
teams
3. Principle: Close, daily cooperation between business people
and developers
Co-located Distributed
Team
Partially-
dispersed
Distributed Team
Fully-dispersed
Distributed Team
Recommended Distributed
Team Structure
• Co-located Product Owner,
Technical Lead, Scrum
Master, and team
• Optionally, use Lead
Developer as interface
between Distributed Team
and on-site ART
Alternate Partially-dispersed
Distributed Team Structure
• Co-located Product Owner,
Technical Lead, Scrum
Master, and partial team
• Some members may
reside onshore
Not recommended
4. Principle: Apply cadence, synchronize teams
Distributed Team operated in
the same cadence as ART
Synchronize onshore/offshore
Team and ART ceremonies
Common Program and Team
Backlogs
1. Pre-PI Planning
2. PI Planning
1. Distributed Scrum Team Ceremonies
2. Scrum of Scrums (SoS) & Program Increment level
Ceremonies
1. Common Program Backlog of features
2. Team Backlog of user stories
3. Team PI Objectives that align and rollup to Program PI
Objectives
5. Pre-PI Planning process encompasses the below key steps:
T-6 Week T-5 Week T-4 Week T-3 Week T-2 Week T-1 Week
Goals/Objectives for PI, Capabilities to
Achieve PI Goal and Feature refinement
• Acceptance criteria
• Product Management review
T = PI
Planning
Product Management
input
• Product requirements
• Product Management
review • Multiple grooming sessions
• User story maturity rating
User Story Build-out & Refinement by Scrum Teams
Milestone:
product plan
reviews
with key Leads
Draft a PI Plan
• PI Capacity
• Story Allocation
to sprints
Offshore Team only
6. Time
Meeting
Participant
s
Expectation
Tel Aviv
El
Segundo
(PDT)
Tuesday 9am-
5pm
Monday
PI Planning Day 1 Tel Aviv Scrum
Teams
1. Review Features (Business and Enablers)
2. Review user stories, functional and non-functional
acceptance criteria
3. Conduct User Story Maturity Rating
4. Create Dependencies objects in Agile Craft
5. Record assumptions
6. Record risks and mitigation plan
7. Asks
Tuesday 5pm-
6pm
Tuesday
7am-8am
PI Planning Day 1 Sync Dev Leads, RTE,
Scrum Masters and
Pos
Communicate:
1. Features (Business and Enablers)
2. User stories, functional and non-functional
acceptance criteria
3. Dependencies
4. Assumptions
5. Risks and mitigation plan
6. Asks
Wednesday
9am-5pm
Wednesday
8am – 2pm
PI Planning Day 2 Tel Aviv Scrum
Teams
1. Document velocity for sprints 1-5
2. Plan features and stories for sprints 1-5
3. Record Team PI Objectives
4. Record assumptions
5. Record risks and mitigation plan
6. Asks
Wednesday
5pm-6pm
Wednesday
7am-8am
PI Planning Day 2 Sync Dev Leads, RTE,
Scrum Masters and
Pos
Communicate:
1. Present velocity for sprints 1-5
2. Present features and stories for sprints 1-5
3. Present Team PI Objectives
4. Present assumptions
5. Present risks and mitigation plan
6. Asks
Thursday
Midnight – 1AM
Wednesday
2pm – 3pm
PI Planning Day 2
Readout
Dev Leads, RTE,
Scrum Masters and
POs
Communicates:
1. Present changes to team PI Objectives
2. Present changes to PI Scope (features and stories)
3. Confirm Assumptions
4. Confirm Risks and mitigation plan
5. Asks
El Segundo PI Planning Days: Tuesday and Wednesday every 10 weeks
PI Planning for Distributed
Team
• In lieu of face-to-face PI Planning,
Distributed Team prepares PI Plan
two-days prior to onsite PI Planning
event.
• Set clear expectation, meeting time
and list of participants for these
“Distributed Team PI Planning” days.
• Setup “PI Planning Day X Sync”
meetings to align outcomes from
previous ART PI Planning day.
Sample PI Planning for Tel Aviv Team
7. Scrum Ceremonies: Plan and publish your Distributed/Onsite Scrum Ceremonies and SoS
Monday Tuesday Wednesday Thursday Friday
(T-5d) Planning Part I: Grooming
session with the team and PO on
user stories maturity ranked
(T-1d) Final prioritized list of user
stories identified and ready in
JIRA with maturity ranked and
estimated
Day 1 (T)
Start of Sprint
• S: Planning Part II – Capacity
Planning
• S: Set up Jira stories and
estimation
Day 2 (T+1d)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
• P: Dev/QA Post Scrum
Day 3 (T+2d)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
• S: Final Test Cases Id
• S: Scrum of Scrums (RTE,
Proxy RTE, Scrum Masters)
(7:30AM)
Day 4 (T+3d)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
• S: Mid Sprint Review
Day 5 (T+4d)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
• S: Scrum of Scrums (RTE,
Proxy RTE, Scrum Masters)
(7:30AM)
Day 6 (T+5d)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
• Backlog Refinement
(Recorded story review, pre-
estimation, slotting)
Day 7 (T+6d)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
• 60% of user stories delivered
to test team
• Recorded Tech Review for
upcoming stories.
Day 8 (T+7d)
• S: Scrum of Scrums (RTE,
Proxy RTE, Scrum Masters)
(7:30AM)
• S: (by 10:30AM PDT)
Documented Daily Scrums
(onshore and offshore)
Day 9 (T+8d)
S: (by 10:30AM PDT) Documented
Daily Scrums (onshore and
offshore)
• User Stories Complete
• Final sprint review with PO
and architects
Day 10 (T+9d)
• S: Scrum of Scrums (RTE,
Proxy RTE, Scrum Masters)
(7:30AM)
• S: Retrospective
• S: Sprint Review/Demo
• S: Recorded Sprint
Review/Demo
S = Full onshore and offshore Together
P = Partial onshore and offshore team together
> Offset teams by one day
8. Time
Titans
(Vietnam)
Mirosoft-2
(Tel Aviv)
Microsoft-3
(New Jersey)
Android 3
(Tel Aviv)
Aviato (El
Segundo +
Tel Aviv)
Miracle
Workers
(Tel Aviv)
Roku 1
(Tampa)
Roku 2
(Tampa)El
Segund
o (PDT)
Tampa/
NJ
(EDT)
Tel
Aviv
Vietnam
7:30 -- 18:30 -- -- -- -- -- SU -- -- --
7:00 10:00 18:00 20:00
SOS SOS SOS SOS SOS SOS SOS SOS
7:30 10:30 18:30 20:30
Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) Retro (T)
8:00 11:00 19:00 21:00
Demo
(T10)
Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10)
SU: Daily Standup
SOS: Scrum of Scrums
Retro: Retrospective
Demo: (Recorded)
Note: This slide covers meetings attended by teams in different locations.
Scrum Ceremonies: Plan and publish time of meetings that accommodate everyone
9. Principle: Build incrementally with fast, integrated learning cycles
Distributed Team(s) operate in
the same eco-system as any other
team.
They use common set of tools
across all teams
They Build and Test incrementally
ALM: Jira, AgileCraft
Collaboration: HipChat, Confluence
Code Quality/ Unit Test: Junit, SonarQube
Test Automation: LISA, Jmeter, Selenium
Build Tools and Repo : Maven, Nexus
Test management: Qmetry
CI/CD Orchestration: Jenkins
Monitoring and Log: AppDynamics, Splunk
Security: Fortify
NOTE : Tools are very specific to this case study
10. • Distributed Agile Teams’ success is all about giving & getting feedback
across stakeholders in the ART value stream – in timely manner!
• Distributed Agile doesn't come in one box.. It’s a journey with goals!
• Distributed Agile is more than tooling .. It involves improvising our ways of
working, process, and culture!
10
Summary
Animation/ Interactivity Notes:
Voice Over Script:
Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including:
Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes
Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort)
Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer
Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts
Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits.
A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating).
A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so.
B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team.
C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.
Animation/ Interactivity Notes:
Voice Over Script:
Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including:
Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes
Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort)
Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer
Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts
Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits.
A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating).
A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so.
B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team.
C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.
Animation/ Interactivity Notes:
Voice Over Script:
Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including:
Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes
Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort)
Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer
Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts
Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits.
A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating).
A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so.
B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team.
C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.
In order to ensure the PI planning event is productive for all teams, DFW has implemented a Pre-PI planning process that starts 6 weeks before the Planned PI event.
The process of Pre-PI planning at DFW starts with establishing Goals/Objectives for the PI with supporting features and relevant acceptance criteria. This is typically aligned upon by product management and architectural leadership as based on product objectives there is typically engineering groundwork that needs to happen first to enable those goals. This is what is called “Architecture” and “Enabler” features in the timeline which are specified concurrently to the above business goals.
Since there are a lot of suppliers involved with the DFW architecture, supplier input is needed ahead of time with specifying what is needed from them from a PI perspective. This typically happens 5 weeks before the PI event.
Once the capabilities have been refined and agreed upon by management, these are shared with all the Scrum teams and RTEs for allocation of work on respective trains. Based upon these requirements Scrum teams do an initial SWAG of the features sizes ensuring that they can be accomplished within a PI and then stack rank them from a priority and logical sequence perspective.
While the previous activity is happening the PO/TPO/Architect for the scrum teams starts to build out all the user stories with detailed acceptance criteria to support required Features for the PI. This activity lasts for 3 weeks and runs through to the PI planning event. After the first week, the suppliers (both internal and external) need to start to review their plans with affected Scrum teams so that both sides know what to expect for the upcoming 10 week increment. This activity culminates with a supplier plan review and readout to key leads on the trains before the PI planning event.
Note for the above user story build out and refinement activity by Scrum teams, this activity may involve multiple grooming sessions with all members of the Scrum teams and giving feedback to the PO/TPO/Architect on immature stories via a rating process and helping with gaps in acceptance criteria and/or proper sequence of activities.
Once the above activities are complete the trains are now ready for the PI planning event.
Animation/ Interactivity Notes:
Voice Over Script:
Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including:
Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes
Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort)
Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer
Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts
Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits.
A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating).
A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so.
B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team.
C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.