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
Agile Training: Roles and ExpectationsMike Wienold
The document provides an overview of roles and expectations in Agile training at Itron. It discusses the key roles of the Scrum Master, Product Owner, and Development Team. The Scrum Master facilitates meetings and removes impediments for the team. The Product Owner represents customers, prioritizes work, and accepts completed items. The cross-functional Development Team delivers working software each sprint and manages its own work. It also reviews the Agile process, sprint activities like planning and retrospectives, and expectations for each role.
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 discusses the agile tools available in Visual Studio 2010. It provides an overview of Visual Studio 2010's capabilities for managing the entire software development lifecycle using agile methodologies like Scrum. Key features highlighted include improved support for agile processes like Scrum through templates and work item tracking, reporting and planning tools, and tight integration across the development lifecycle from requirements through deployment. The document argues that Visual Studio 2010's agile tools can help teams overcome complexity, improve quality, increase transparency, facilitate collaboration, and reduce risk through a lightweight and customizable approach.
Scrum Master Role and Responsibilities in Agile Environment - AMECSE 2014 Ahmed Hammad
This presentation tried to cover ScrumMaster roles and responsibilities in Agile environments. It is presented in Software Innovation for Sustainable Economy conference See: http://2014.amecse-conferences.org/
The document discusses various agile roles including Scrum Master, Product Owner, and team members. It describes how roles differ in agile/self-organizing teams compared to traditional methods. Key roles like project manager, analyst, developer, and tester focus less on documentation and more on collaboration, automated testing, and visual project management through tools like Kanban boards.
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.
The document discusses roles in agile teams compared to classic teams. In agile teams, roles are more collaborative and team-oriented, focusing on delivering value quickly rather than specific job functions. The product owner generates acceptance tests, developers use test-driven development and behavior-driven development, and quality assurance works with analysts to define scenarios. The most important thing is the team attitude of helping each other deliver value as quickly as possible.
Agile Training: Roles and ExpectationsMike Wienold
The document provides an overview of roles and expectations in Agile training at Itron. It discusses the key roles of the Scrum Master, Product Owner, and Development Team. The Scrum Master facilitates meetings and removes impediments for the team. The Product Owner represents customers, prioritizes work, and accepts completed items. The cross-functional Development Team delivers working software each sprint and manages its own work. It also reviews the Agile process, sprint activities like planning and retrospectives, and expectations for each role.
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 discusses the agile tools available in Visual Studio 2010. It provides an overview of Visual Studio 2010's capabilities for managing the entire software development lifecycle using agile methodologies like Scrum. Key features highlighted include improved support for agile processes like Scrum through templates and work item tracking, reporting and planning tools, and tight integration across the development lifecycle from requirements through deployment. The document argues that Visual Studio 2010's agile tools can help teams overcome complexity, improve quality, increase transparency, facilitate collaboration, and reduce risk through a lightweight and customizable approach.
Scrum Master Role and Responsibilities in Agile Environment - AMECSE 2014 Ahmed Hammad
This presentation tried to cover ScrumMaster roles and responsibilities in Agile environments. It is presented in Software Innovation for Sustainable Economy conference See: http://2014.amecse-conferences.org/
The document discusses various agile roles including Scrum Master, Product Owner, and team members. It describes how roles differ in agile/self-organizing teams compared to traditional methods. Key roles like project manager, analyst, developer, and tester focus less on documentation and more on collaboration, automated testing, and visual project management through tools like Kanban boards.
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.
The document discusses roles in agile teams compared to classic teams. In agile teams, roles are more collaborative and team-oriented, focusing on delivering value quickly rather than specific job functions. The product owner generates acceptance tests, developers use test-driven development and behavior-driven development, and quality assurance works with analysts to define scenarios. The most important thing is the team attitude of helping each other deliver value as quickly as possible.
This document discusses the role of managers in an agile environment. It begins by outlining some assumptions, such as the reader's familiarity with agile processes and interest in learning what managers need to know. It then explores different types of managers like product and project managers. The document also covers common reporting structures, organizational impacts of agile, and career paths. It provides guidance on agile leadership at the team level and concludes by discussing management responsibilities in an agile world.
How to survive the zombie scrum apocalypse Mia Horrigan
A couple of years ago Christiaan Verwijs and Johannes Schartau coined the term ‘Zombie-Scrum’. What's it all about?
Well, at first sight Zombie Scrum seems to be normal Scrum. But it lacks a beating heart. The Scrum teams do all the Scrum events but a potential releasable increment is rarely the result of a Sprint. Zombie Scrum teams have a very unambitious definition of what ‘done’ means, and no drive to extend it. They see themselves as a cog in the wheel, unable and unwilling to change anything and have a real impact: I’m only here to code! Zombie Scrum teams show no response to a failed or successful Sprint and also don’t have any intention to improve their situation. Actually nobody cares about this team. The stakeholders have forgotten the existence of this team long time ago.
Zombie Scrum is Scrum, but without the beating heart of working software and its on the rise. This workshop will help you understand how to recognise the symptoms and cuases of Zombie Scrum and what you can do to get started to combat and treat Zombie-Scrum. Knowing what causes Zombie Scrum might help prevent a further outbreak and prevent the apocalypse
Agile transformation with Scrum. Where to start
1. Agile vs Waterfall
2. What is Scrum
3. Scrum team
4. Scrum artefacts (with activities for easier learning)
5. Scrum events
6. Is Scrum enough?
How to build rubust org structure for Agile at scaleYuriy Kudin
Are you going to implement Agile/Lean methodologies in your organization, but you don’t have a clue where to start? Does it make sense to begin with Agile training? Or, it would be better to start with implementation of application lifecycle management tools (ALM), or, it would be enough just to hire right people with agile expertise?
Based on our experience, with more than 100 clients, we clearly see that in most of the cases real agile transformation is kicking off from organizational structure change. This is exactly what we would like to share with you.
We will talk about typical issues in organization structure that we have seen when helping our clients to transform. We will also outline what potential problems might cause those issues. Furthermore, we will share successful patterns of building robust organizational structures for different types of the companies: starting from small and scaling it up to enterprise (100+ employees).
As an outcome, participants will get an overview on how to build robust organizational structure as a foundation for successful Agile/Lean implementation.
“Scrum Master” & “Agile Project Manager”: A Tale of Two Different Roles by Manohar Prasad, CSP®-SM, CSP®-PO, CSM®, CSPO®, PSM I®, Agile Coach
“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”
“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
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 document outlines the 6 core roles in Scrum: ScrumMaster, Product Owner, Team, Customer, Manager, and End User. It describes each role and how they work together. The ScrumMaster protects the team and removes impediments. The Product Owner defines the product vision and backlog. The Team delivers working software each sprint. The Customer requests the product and provides feedback. The Manager establishes organizational structure. The End User provides requirements and feedback.
This document provides an overview of Agile and Scrum methodologies. It describes the iterative incremental model and compares it to the waterfall model. The key aspects of Agile include iterative development, early delivery of working software, collaboration between business and developers, self-organizing teams, and face-to-face communication. Scrum is then introduced as a framework for implementing Agile. The core Scrum roles, events, artifacts, user stories, estimation techniques, and burn down charts are defined and explained at a high level.
- The client wants to build a new website and has a $100k budget and 12 month deadline
- The team will use an Agile methodology called Scrum to manage the project incrementally using short sprints
- Scrum uses cross-functional teams, prioritized backlogs, daily stand-ups, sprints, reviews and retrospectives to iteratively deliver working software
- Key roles include the Product Owner who prioritizes features, the Development Team who build the increments, and the ScrumMaster who facilitates the process
Executive agility to be able to respond effectively in chaosZXM Webinar - Mia Horrigan
Now more than ever, the ability to respond to change over 'following a plan' couldn't ring truer. Hindsight is 20/20 but none of us could have predicted the unprecedented effect that the Corona Virus has wrought upon every aspect of our lives. Now we are working from home, readjusting to a new 'norm', but all the while living in a state of chaos whilst still 'keeping the lights on' in the space of not months or years but in weeks, days and even hours.
Organisations have already had to rapidly change the products or services they 'traditionally' brought to market and reinvent themselves at lightning speed to not just stay relevant but to actually survive.
The document summarizes the origins and principles of Lean manufacturing as derived from Toyota's production system. It describes a 1990 study showing Japanese automakers had 50% higher productivity and quality with 40% faster development times using Lean principles. Lean focuses on eliminating waste to optimize value delivery. The core ideas are only producing what is needed when it is needed, stopping work to fix problems, and empowering employees.
This document provides an introduction to agile frameworks like Scrum, XP, Lean, and Kanban. It discusses agile principles like valuing individuals, collaboration, and responding to change. It describes Scrum roles, events, and tools like user stories, burn-down charts, and daily stand-ups. XP's emphasis on testing is covered. Lean principles like eliminating waste and building quality in are explained. Kanban concepts like pull systems and work-in-progress limits are also summarized. The document concludes with recommendations for certifications and further reading on agile methods.
This document provides an overview of Lean, Agile and Scrum concepts and practices. It discusses Lean principles and how they were developed at Toyota to eliminate waste. It also covers the Agile manifesto and why Agile works by allowing for change and autonomy. The Scrum framework is summarized, including the roles of Product Owner, Scrum Master and Development Team. Key Scrum ceremonies like Sprint Planning, Review and Retrospective are outlined. Common Scrum artifacts such as the Product Backlog, Sprint Backlog and user stories are defined.
Scrum is an agile framework for managing complex projects. It emphasizes transparency, inspection, and adaptation. Key aspects of Scrum include short sprints with fixed durations, daily stand-ups, sprint planning and reviews, and retrospectives. The product owner prioritizes features in the backlog and the cross-functional team works to complete them in sprints. Applying Scrum principles like frequent delivery, transparency, and process improvement can help manage uncertainty, deliver value faster, improve quality, and eliminate waste.
Scrum is an agile framework that emphasizes incremental deliveries, quality, continuous improvement, and discovering potential. It consists of sprints, roles like the product owner, scrum master, and cross-functional team. Sprint reviews provide visibility, feedback, and an opportunity for demos. Retrospectives are meetings at the end of each sprint to learn and improve for the next sprint through structured activities like gathering data, generating insights, and deciding on actions. They aim to continuously improve the development process.
Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.
Scrum is an efficient framework within which you can develop software with teamwork. It is based on agile principles.
This presentation will help you understand agile development in general and Scrum in specific. You will get familiar with its associated terminology along with appropriate examples.
This simple and crisp quick reference card is for Agile and Scrum basics. It is a simple way to glance through all the concepts and use it as a tool for revision, even before an interview.
The document provides an introduction to Agile development using Scrum. It discusses traditional software project failures and limitations of the Waterfall model. Scrum is then introduced as a framework that uses short Sprints, daily stand-up meetings, sprint reviews and retrospectives. Key Scrum roles include the Product Owner, Scrum Master and self-organizing cross-functional Team.
This document discusses the role of managers in an agile environment. It begins by outlining some assumptions, such as the reader's familiarity with agile processes and interest in learning what managers need to know. It then explores different types of managers like product and project managers. The document also covers common reporting structures, organizational impacts of agile, and career paths. It provides guidance on agile leadership at the team level and concludes by discussing management responsibilities in an agile world.
How to survive the zombie scrum apocalypse Mia Horrigan
A couple of years ago Christiaan Verwijs and Johannes Schartau coined the term ‘Zombie-Scrum’. What's it all about?
Well, at first sight Zombie Scrum seems to be normal Scrum. But it lacks a beating heart. The Scrum teams do all the Scrum events but a potential releasable increment is rarely the result of a Sprint. Zombie Scrum teams have a very unambitious definition of what ‘done’ means, and no drive to extend it. They see themselves as a cog in the wheel, unable and unwilling to change anything and have a real impact: I’m only here to code! Zombie Scrum teams show no response to a failed or successful Sprint and also don’t have any intention to improve their situation. Actually nobody cares about this team. The stakeholders have forgotten the existence of this team long time ago.
Zombie Scrum is Scrum, but without the beating heart of working software and its on the rise. This workshop will help you understand how to recognise the symptoms and cuases of Zombie Scrum and what you can do to get started to combat and treat Zombie-Scrum. Knowing what causes Zombie Scrum might help prevent a further outbreak and prevent the apocalypse
Agile transformation with Scrum. Where to start
1. Agile vs Waterfall
2. What is Scrum
3. Scrum team
4. Scrum artefacts (with activities for easier learning)
5. Scrum events
6. Is Scrum enough?
How to build rubust org structure for Agile at scaleYuriy Kudin
Are you going to implement Agile/Lean methodologies in your organization, but you don’t have a clue where to start? Does it make sense to begin with Agile training? Or, it would be better to start with implementation of application lifecycle management tools (ALM), or, it would be enough just to hire right people with agile expertise?
Based on our experience, with more than 100 clients, we clearly see that in most of the cases real agile transformation is kicking off from organizational structure change. This is exactly what we would like to share with you.
We will talk about typical issues in organization structure that we have seen when helping our clients to transform. We will also outline what potential problems might cause those issues. Furthermore, we will share successful patterns of building robust organizational structures for different types of the companies: starting from small and scaling it up to enterprise (100+ employees).
As an outcome, participants will get an overview on how to build robust organizational structure as a foundation for successful Agile/Lean implementation.
“Scrum Master” & “Agile Project Manager”: A Tale of Two Different Roles by Manohar Prasad, CSP®-SM, CSP®-PO, CSM®, CSPO®, PSM I®, Agile Coach
“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”
“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
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 document outlines the 6 core roles in Scrum: ScrumMaster, Product Owner, Team, Customer, Manager, and End User. It describes each role and how they work together. The ScrumMaster protects the team and removes impediments. The Product Owner defines the product vision and backlog. The Team delivers working software each sprint. The Customer requests the product and provides feedback. The Manager establishes organizational structure. The End User provides requirements and feedback.
This document provides an overview of Agile and Scrum methodologies. It describes the iterative incremental model and compares it to the waterfall model. The key aspects of Agile include iterative development, early delivery of working software, collaboration between business and developers, self-organizing teams, and face-to-face communication. Scrum is then introduced as a framework for implementing Agile. The core Scrum roles, events, artifacts, user stories, estimation techniques, and burn down charts are defined and explained at a high level.
- The client wants to build a new website and has a $100k budget and 12 month deadline
- The team will use an Agile methodology called Scrum to manage the project incrementally using short sprints
- Scrum uses cross-functional teams, prioritized backlogs, daily stand-ups, sprints, reviews and retrospectives to iteratively deliver working software
- Key roles include the Product Owner who prioritizes features, the Development Team who build the increments, and the ScrumMaster who facilitates the process
Executive agility to be able to respond effectively in chaosZXM Webinar - Mia Horrigan
Now more than ever, the ability to respond to change over 'following a plan' couldn't ring truer. Hindsight is 20/20 but none of us could have predicted the unprecedented effect that the Corona Virus has wrought upon every aspect of our lives. Now we are working from home, readjusting to a new 'norm', but all the while living in a state of chaos whilst still 'keeping the lights on' in the space of not months or years but in weeks, days and even hours.
Organisations have already had to rapidly change the products or services they 'traditionally' brought to market and reinvent themselves at lightning speed to not just stay relevant but to actually survive.
The document summarizes the origins and principles of Lean manufacturing as derived from Toyota's production system. It describes a 1990 study showing Japanese automakers had 50% higher productivity and quality with 40% faster development times using Lean principles. Lean focuses on eliminating waste to optimize value delivery. The core ideas are only producing what is needed when it is needed, stopping work to fix problems, and empowering employees.
This document provides an introduction to agile frameworks like Scrum, XP, Lean, and Kanban. It discusses agile principles like valuing individuals, collaboration, and responding to change. It describes Scrum roles, events, and tools like user stories, burn-down charts, and daily stand-ups. XP's emphasis on testing is covered. Lean principles like eliminating waste and building quality in are explained. Kanban concepts like pull systems and work-in-progress limits are also summarized. The document concludes with recommendations for certifications and further reading on agile methods.
This document provides an overview of Lean, Agile and Scrum concepts and practices. It discusses Lean principles and how they were developed at Toyota to eliminate waste. It also covers the Agile manifesto and why Agile works by allowing for change and autonomy. The Scrum framework is summarized, including the roles of Product Owner, Scrum Master and Development Team. Key Scrum ceremonies like Sprint Planning, Review and Retrospective are outlined. Common Scrum artifacts such as the Product Backlog, Sprint Backlog and user stories are defined.
Scrum is an agile framework for managing complex projects. It emphasizes transparency, inspection, and adaptation. Key aspects of Scrum include short sprints with fixed durations, daily stand-ups, sprint planning and reviews, and retrospectives. The product owner prioritizes features in the backlog and the cross-functional team works to complete them in sprints. Applying Scrum principles like frequent delivery, transparency, and process improvement can help manage uncertainty, deliver value faster, improve quality, and eliminate waste.
Scrum is an agile framework that emphasizes incremental deliveries, quality, continuous improvement, and discovering potential. It consists of sprints, roles like the product owner, scrum master, and cross-functional team. Sprint reviews provide visibility, feedback, and an opportunity for demos. Retrospectives are meetings at the end of each sprint to learn and improve for the next sprint through structured activities like gathering data, generating insights, and deciding on actions. They aim to continuously improve the development process.
Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.
Scrum is an efficient framework within which you can develop software with teamwork. It is based on agile principles.
This presentation will help you understand agile development in general and Scrum in specific. You will get familiar with its associated terminology along with appropriate examples.
This simple and crisp quick reference card is for Agile and Scrum basics. It is a simple way to glance through all the concepts and use it as a tool for revision, even before an interview.
The document provides an introduction to Agile development using Scrum. It discusses traditional software project failures and limitations of the Waterfall model. Scrum is then introduced as a framework that uses short Sprints, daily stand-up meetings, sprint reviews and retrospectives. Key Scrum roles include the Product Owner, Scrum Master and self-organizing cross-functional Team.
Scrum is an agile framework that uses short development cycles called sprints to iteratively develop software. A scrum team consists of a product owner, scrum master, and cross-functional team. The team works through a prioritized backlog during a sprint planning meeting to determine the sprint backlog. Daily stand-ups are held to track progress. At the end of a sprint, a review is conducted to demo completed work before retrospecting on improvements for the next sprint.
Scrum is an agile framework for managing projects that emphasizes collaboration, adaptation to change, and iterative delivery. It uses sprints, daily stand-ups, backlogs and artifacts like burn-down charts. Key roles include the Product Owner, Scrum Master and cross-functional team. Scrum aims to deliver working software frequently through an empirical process that adapts to change rather than a fixed plan.
The document provides an introduction to Agile methodology and Scrum framework. It discusses the limitations of traditional waterfall approaches and how Agile and Scrum address those limitations through iterative development with frequent delivery and ability to adapt to changing requirements. The key aspects of Scrum like sprints, daily stand-ups, sprint planning, review and retrospective are explained to give an overview of how Scrum works in practice.
Scrum is an agile framework that focuses on iterative development through short cycles called sprints. There are three main roles: the product owner prioritizes features and communicates with stakeholders, the development team implements the features, and the scrum master facilitates the process and removes impediments. Key aspects of scrum include daily stand-up meetings to track progress, prioritized backlogs to plan sprints, and retrospectives after each sprint to improve. The goal is to frequently deliver working software and adapt quickly to changes.
The document provides an overview of the Agile Scrum methodology. It describes that Agile is an iterative process involving constant collaboration with stakeholders. Scrum is an Agile framework that breaks work into sprints with daily stand-ups. Key Scrum roles include the Product Owner who manages the backlog, the Scrum Master who removes impediments, and the Development Team who delivers increments each sprint. Artifacts include the Product and Sprint Backlogs, the Definition of Done, and the increment delivered at the end of each sprint.
Scrum is an agile framework for managing complex product development that has been used since the 1990s. It is lightweight, simple, and difficult to master. The core Scrum roles are the Product Owner, Development Team, and Scrum Master. The Product Owner manages the product backlog and maximizes ROI. The Development Team is self-organizing and cross-functional. The Scrum Master removes impediments and ensures adherence to Scrum practices. Key Scrum events include Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.
This document provides an overview of Scrum, an agile framework for managing product development. It discusses the Scrum roles of Product Owner, Team, and Scrum Master. The key Scrum ceremonies are planning, daily stand-ups, sprint reviews, and retrospectives. Scrum uses short iterations called sprints to incrementally deliver working software. The document recommends starting with a short initial sprint length and identifying the Product Owner, Scrum Master, and cross-functional Team.
This presentation provides a quick guide to getting started with the Scrum framework. It's based on the 2020 Scrum Guide (https://scrumguides.org/scrum-guide.html). It can be used to introduce Scrum to new teams as well as experienced practitioners that need to refresh their understanding of the framework as part of the continuous improvement process. It also provides additional resources and references.
The document provides an overview of the Agile-Scrum project development methodology. Some key points include:
- Scrum uses short development cycles called sprints to deliver working software frequently in an iterative manner.
- Self-organizing cross-functional teams work to deliver business value through working software at the end of each sprint.
- Daily stand-up meetings are held for teams to synchronize their work. Sprint planning and reviews ensure alignment with stakeholders.
- Key Scrum roles include the Product Owner who prioritizes backlog items, the Scrum Master who facilitates the process, and the Development Team.
- Sprints use a product backlog, sprint backlog and burn-down charts to track
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.
This presentation provides a quick guide to getting started with the Scrum framework. It's based on the 2020 Scrum Guide (https://scrumguides.org/scrum-guide.html). It can be used to introduce Scrum to new teams as well as experienced practitioners that need to refresh their understanding of the framework as part of the continuous improvement process. It also provides additional resources and references. This deck can be used by SMs or Agile Coaches to team Scrum Framework to teams.
This document provides an overview of key agile and Scrum concepts for exam preparation. It defines agile methods and contrasts them with waterfall approaches. Scrum is introduced as an agile process that focuses on rapid delivery of working software in short iterations called sprints. The document outlines Scrum roles like Product Owner, Scrum Master, and team. It describes the Scrum processes of initiating, planning, implementing, reviewing, and releasing software. Key terms are defined for each Scrum event, artifact, and role. The document recommends reviewing videos, taking a mock exam, and scheduling the proctored certification exam.
Software Development Guide To Accelerate PerformanceZaid Shabbir
Scrum is the most widely used framework across all software and business industries. By following complete scrum framework you can improve the quality product deliver in more adaptive way.
Slides contents content guidelines related to scrum framework and how some one become a certified scrum master. Slides elaborate scrum framework by using user friendly diagrams and bulleted points. After grasping the slides any one can easily pass certified scrum examination.
I am sure you will enjoy the contents and its really helpful to become a certified scrum practitioner.
Scrum is an agile framework that focuses on rapid delivery of working software in short cycles called sprints. It involves self-organizing cross-functional teams, prioritized backlogs and artifacts like product backlogs, sprint backlogs and increments. Key roles include the product owner who prioritizes features, the development team who work on delivering features and the scrum master who facilitates the process. Ceremonies like sprint planning, daily standups, sprint reviews and retrospectives help ensure transparency and process improvement.
Scrum is an agile framework that uses short cycles called sprints to incrementally develop products. It consists of roles like the product owner and scrum master, events like the sprint planning meeting and daily standup, and artifacts like the product backlog and sprint backlog. The scrum team works to complete items from the product backlog during a sprint, tracks progress using tools like burn down charts, and inspects and adapts each sprint through the sprint retrospective.
Scrum is an agile framework for managing product development. It uses fixed-length iterations called sprints to structure work. Key roles include the Product Owner who prioritizes work, the Development Team who does the work, and the Scrum Master who facilitates the process. Rituals like daily stand-ups, sprint planning and retrospectives provide structure and opportunities to inspect and adapt the process sprint over sprint. The goal is to deliver working software frequently in a transparent and collaborative manner.
Scrum is an agile development method that focuses on managing tasks within a team environment. It advocates for small, self-organizing teams of 7-9 members empowered to manage their own work. Key Scrum roles include the Scrum Master who removes obstacles, Product Owner who prioritizes a backlog of requirements, and the Scrum Team who completes the work. The team works in sprints or cycles to deliver functionality by selecting items from the backlog, estimating tasks, daily stand-ups, and sprint reviews where progress is demonstrated.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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,
Accident detection system project report.pdfKamal Acharya
The Rapid growth of technology and infrastructure has made our lives easier. The
advent of technology has also increased the traffic hazards and the road accidents take place
frequently which causes huge loss of life and property because of the poor emergency facilities.
Many lives could have been saved if emergency service could get accident information and
reach in time. Our project will provide an optimum solution to this draw back. A piezo electric
sensor can be used as a crash or rollover detector of the vehicle during and after a crash. With
signals from a piezo electric sensor, a severe accident can be recognized. According to this
project when a vehicle meets with an accident immediately piezo electric sensor will detect the
signal or if a car rolls over. Then with the help of GSM module and GPS module, the location
will be sent to the emergency contact. Then after conforming the location necessary action will
be taken. If the person meets with a small accident or if there is no serious threat to anyone’s
life, then the alert message can be terminated by the driver by a switch provided in order to
avoid wasting the valuable time of the medical rescue team.
Null Bangalore | Pentesters Approach to AWS IAMDivyanshu
#Abstract:
- Learn more about the real-world methods for auditing AWS IAM (Identity and Access Management) as a pentester. So let us proceed with a brief discussion of IAM as well as some typical misconfigurations and their potential exploits in order to reinforce the understanding of IAM security best practices.
- Gain actionable insights into AWS IAM policies and roles, using hands on approach.
#Prerequisites:
- Basic understanding of AWS services and architecture
- Familiarity with cloud security concepts
- Experience using the AWS Management Console or AWS CLI.
- For hands on lab create account on [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
# Scenario Covered:
- Basics of IAM in AWS
- Implementing IAM Policies with Least Privilege to Manage S3 Bucket
- Objective: Create an S3 bucket with least privilege IAM policy and validate access.
- Steps:
- Create S3 bucket.
- Attach least privilege policy to IAM user.
- Validate access.
- Exploiting IAM PassRole Misconfiguration
-Allows a user to pass a specific IAM role to an AWS service (ec2), typically used for service access delegation. Then exploit PassRole Misconfiguration granting unauthorized access to sensitive resources.
- Objective: Demonstrate how a PassRole misconfiguration can grant unauthorized access.
- Steps:
- Allow user to pass IAM role to EC2.
- Exploit misconfiguration for unauthorized access.
- Access sensitive resources.
- Exploiting IAM AssumeRole Misconfiguration with Overly Permissive Role
- An overly permissive IAM role configuration can lead to privilege escalation by creating a role with administrative privileges and allow a user to assume this role.
- Objective: Show how overly permissive IAM roles can lead to privilege escalation.
- Steps:
- Create role with administrative privileges.
- Allow user to assume the role.
- Perform administrative actions.
- Differentiation between PassRole vs AssumeRole
Try at [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
Supermarket Management System Project Report.pdfKamal Acharya
Supermarket management is a stand-alone J2EE using Eclipse Juno program.
This project contains all the necessary required information about maintaining
the supermarket billing system.
The core idea of this project to minimize the paper work and centralize the
data. Here all the communication is taken in secure manner. That is, in this
application the information will be stored in client itself. For further security the
data base is stored in the back-end oracle and so no intruders can access it.
Applications of artificial Intelligence in Mechanical Engineering.pdfAtif Razi
Historically, mechanical engineering has relied heavily on human expertise and empirical methods to solve complex problems. With the introduction of computer-aided design (CAD) and finite element analysis (FEA), the field took its first steps towards digitization. These tools allowed engineers to simulate and analyze mechanical systems with greater accuracy and efficiency. However, the sheer volume of data generated by modern engineering systems and the increasing complexity of these systems have necessitated more advanced analytical tools, paving the way for AI.
AI offers the capability to process vast amounts of data, identify patterns, and make predictions with a level of speed and accuracy unattainable by traditional methods. This has profound implications for mechanical engineering, enabling more efficient design processes, predictive maintenance strategies, and optimized manufacturing operations. AI-driven tools can learn from historical data, adapt to new information, and continuously improve their performance, making them invaluable in tackling the multifaceted challenges of modern mechanical engineering.
Prediction of Electrical Energy Efficiency Using Information on Consumer's Ac...PriyankaKilaniya
Energy efficiency has been important since the latter part of the last century. The main object of this survey is to determine the energy efficiency knowledge among consumers. Two separate districts in Bangladesh are selected to conduct the survey on households and showrooms about the energy and seller also. The survey uses the data to find some regression equations from which it is easy to predict energy efficiency knowledge. The data is analyzed and calculated based on five important criteria. The initial target was to find some factors that help predict a person's energy efficiency knowledge. From the survey, it is found that the energy efficiency awareness among the people of our country is very low. Relationships between household energy use behaviors are estimated using a unique dataset of about 40 households and 20 showrooms in Bangladesh's Chapainawabganj and Bagerhat districts. Knowledge of energy consumption and energy efficiency technology options is found to be associated with household use of energy conservation practices. Household characteristics also influence household energy use behavior. Younger household cohorts are more likely to adopt energy-efficient technologies and energy conservation practices and place primary importance on energy saving for environmental reasons. Education also influences attitudes toward energy conservation in Bangladesh. Low-education households indicate they primarily save electricity for the environment while high-education households indicate they are motivated by environmental concerns.
AI in customer support Use cases solutions development and implementation.pdfmahaffeycheryld
AI in customer support will integrate with emerging technologies such as augmented reality (AR) and virtual reality (VR) to enhance service delivery. AR-enabled smart glasses or VR environments will provide immersive support experiences, allowing customers to visualize solutions, receive step-by-step guidance, and interact with virtual support agents in real-time. These technologies will bridge the gap between physical and digital experiences, offering innovative ways to resolve issues, demonstrate products, and deliver personalized training and support.
https://www.leewayhertz.com/ai-in-customer-support/#How-does-AI-work-in-customer-support
Height and depth gauge linear metrology.pdfq30122000
Height gauges may also be used to measure the height of an object by using the underside of the scriber as the datum. The datum may be permanently fixed or the height gauge may have provision to adjust the scale, this is done by sliding the scale vertically along the body of the height gauge by turning a fine feed screw at the top of the gauge; then with the scriber set to the same level as the base, the scale can be matched to it. This adjustment allows different scribers or probes to be used, as well as adjusting for any errors in a damaged or resharpened probe.
3. 3
Course Requirements
Description
• In this course, we will discuss the skills necessary to facilitate agile teams, so that the team members
transition from a sequential work style to a swarming work style.
• Self-organized cross-functional teams are the cornerstone of agile development.
Prerequisite
• Prior to taking this training, you should have completed the following:
• Agile 101 Training
Intended Audience
• Potential Scrum Masters
• Any leadership role involved in Product/Service Planning & Delivery process
• e.g. Technical Leader, QA Leader, Technical Managers, QA Managers, Project Managers, Program Managers
4. 4
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
Coaching Team- Small Team Dynamicsd
1
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh
5. 5
Video #0: Scrum Master Role
Power of Scrum: a funny Scrum Master Movie
with
Jeff Sutherland, co-creator of Scrum Process Framework
6. 6
What are Lean Principles? And How do we implement them in Agile
Lean Principles Implementation in Agile
Eliminate waste Retrospectives, Feedback loops at every iteration
Amplify learning Retrospectives, Feedback loops at every iteration
Decide as late as possible Iteration Planning every 2 weeks
Deliver as fast as possible Short Iterations
Empower the team Servant Leadership, Team Collaboration
Build integrity in Build Quality In: Continuous Testing & integration
See the whole Cross functional teams, breaking down Silos
Principles
Values
Process
Practices
(kata)
8. 8
In Summary: Scrum is most common Agile Framework
• Each sprint has a fixed duration “time-box”
• Each sprint delivers working, fully tested code
• Only the team can do a pull from backlog
• Team cannot plan to exceed their capacity
• Team sync up on sprint goals during daily standup
• Core team size cannot be dynamic
• Team stays together for extended duration Scrum is lightweight yet, like rugby, needs rules to ensure
correct flow.
It is the responsibility of the Scrum Master to ensure
adherence to the agreed rules.
Scrum Values
Commitment, courage, focus, openness and respect
9. 9
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh
10. 10
SCRUM - Team
SERVICE OWNER
A person responsible for
maximizing the value of the
Service and the work of the
Scrum Team (Service Backlog
and determination of
priorities)
SCRUM TEAM
Professionals who do the work for
delivering a potentially releasable
Increment of “Done“ software at the
end of each Sprint. The software is
coded and tested. Self-organizing,
cross-functional
SCRUM MASTER
A person ensuring that Scrum is understood
and enacted. Expert in the Scrum Process and
monitors the Scrum Team progress
PRODUCT OWNER
A person responsible for
ensuring Product adoption of
the Service and maximizing
the value of the Product
(Product-specific Backlog and
determination of priorities)
SUPPORTING SMEs
Professionals who work on the
enabling elements of a Service
and/or Product Adoption
SERVICE ANALYST
A person who defines Service
Level Requirements, Use Cases
and User Stories.
Supports UAT.
BUSINESS ANALYST
A person who defines Product
Adoption Level Requirements,
Use Cases and User Stories.
Supports UAT.
AGILE COACH
A person leading and coaching the
organization in its Agile and Scrum
adoption.
PROGRAM MANAGER
(SERVICE AND PRODUCT)
A person who manages and resolve
Interdependencies and aligns
enabling activities to support team.
Also involved in monitoring and
tracking of velocity and other health
indicators
11. 11
Scrum Master Role
Scrum
Advocate
Servant
Leader
Coach
Problem
Solver
Protector
Process
Owner
Responsible
for making sure
that team lives by
values & principles of
Scrum process
Leads team by serving the best interests of team, not one-self
Does anything
to help team
become high
performing
Creating balance
with team’s key
stakeholder:
product/service
owner
Protects team from over-commitment & complacency
Helping
team do the
best work it
possibly can
• 1 Person!
• Accountable for guiding,
coaching, teaching and
assisting team
• Creates and maintains an
environment favorable to
applying Scrum process
• This involves:
• Bulldozing (removing)
any impediments to
team’s progress
• facilitating meetings,
and working with
product/service owner
12. 12
Agile vs. Traditional Responsibilities- Scrum Master vs. Project Manager
Mindset changes needed- Shift from directive leadership to servant leadership
Coordinating team activities & contributions
Deadlines
Driving towards outcomes
Knowing the answer
Coaching teams to collaborate
Objectives
Being invested in overall performance
Asking the teams for the answer
to
to
to
to
Directing Aiding self-organizationto
Fixing problems Helpto
13. 13
A Day in Life of Scrum Master
•Engage Product/Service Owner so that
s/he is available to provide clarifications
•Ensure Product/Service Owner is not
micromanaging team
•Schedule frequent demos as early as
possible, for course corrections
•Facilitate Product/Service Backlog
Refinement sessions to prepare for next
sprint planning
•Help Product/Service Owner refines
Epic/user stories for future requirementsSprint Planning
During Sprint
Daily Scrum
Sprint Demo Retrospective
14. 14
Facilitating Product/Service Owner and Team Decisions: Which Stories to Prioritize for a Sprint
Sprint 1 Backlog
• Each story is selected by importance
• The sum of the stories should not exceed team velocity
• The team decides how many stories to include
• Commitment is achieved once stories have consensus around estimates
Backlog for future sprints
16. 16
Scrum Master Facilitates Scrum Ceremonies
• Ensure that:
• Meeting happens on Sprint day 1
• Meeting is time boxed, for example:
2 weeks Sprint should have 4 hours of Sprint Planning
• Product/Service Owner has prioritized work
• Team is engaged and committed to current Sprint
• Team understands work prioritized for the Sprint
• Team considers total team capacity and dependencies
(technical and external) while providing commitment
• All team members jointly agree & arrive at consensus
• All team members commit (“fist of 5”) to Sprint goal
Sprint Planning Example of Agenda for Sprint Planning:
1:00 PM – 5:00 PM
• 1:00 – 1:30 PM
Product/Service Owner states Sprint goal,
summarizes backlog, talks about demo place, date
& time
• 1:30 – 3:00 PM
Team (re)sizes user stories, breaking down work.
Team defines story acceptance criteria as needed.
• 3:00 – 4:00 PM
Team selects stories for the sprint. Scrum Master
does capacity calculations as a reality check.
• 4:00 – 5:00 PM
1-by-1, team breaks down stories into tasks.
Team decides place & time for Daily Scrum.
18. 18
Scrum Master Facilitates Scrum Ceremonies (Continued)
• Ensure that:
• Daily Standup time is fixed
• Entire team attends the Daily Standup
• Every one is attentive during Daily Standup
• Daily Standup is focused on the 3 standard questions
• No additional discussion happens
• Daily Standup is complete in 15 minutes
• Team does not deviate from the purpose of the Daily Standup
• Reinforce if team is deviating
Daily Stand-up
19. 19
Facilitating Daily Standup aka Daily Scrum (continued)
• Scrum Master should ensure that the Agile Team reviews Sprint Burn down chart
during Daily Scrum and discuss re-planning, as required:
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
Trend line
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
-200
-100
0
100
200
300
400
500
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
Trend line
Trend line
21. 21
Scrum Master Facilitates Scrum Ceremonies (Continued)
• Ensure that:
• Sprint review happens at regular credence at the end of the Sprint
• Time boxing Sprint review session, e.g.:
2 weeks Sprint can have 2 hours of Sprint Demo
• Team has met with “Definition of Done” for all completed stories
• Product/Service Owner accepts or rejects stories based on story acceptance
criteria
• Rejected stories are moved back to Product/Service Backlog and re-
prioritized
• Make note of any course correction on implementation
• Also new stories are created for any additional feedback/changes
Sprint Demo
23. 23
Scrum Master Facilitates Scrum Ceremonies (Continued)
• Ensure that:
• Teams are doing retrospective at the end of every Sprint
• Team looks back and considers how the work was done during Sprint, how well it
was developed and delivered, and also is there way for further improvement
• During Sprint, make your own observations about how team is working. Unless it
is very critical, don’t provide any immediate feedback during Sprint. But discuss
these observations during retrospective
• Team uses Sprint retrospective to identify further improvements to become high
performance team
• Action items are tracked and closed (i.e. do not repeat in subsequent sprints)
Sprint Retrospective
25. 25
Coaching Team- Small Team Dynamics
Enabling Team to
set Clear and
Realistic Goals
Encourage team
to build Cross-
Functional
Capabilities
Motivate team to
adopt
Engineering
Practices as Team
matures
Drive Team towards
“High Performance”
through focus on
Continuous
Improvements
Ensure
Transparency
through Open
Communication
within the Team
Enabling Team to
be Self-Organized
Elevate the “One
Team“ Spirit
through various
Team building
Activities
26. 26
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh
27. 27
User Story Map: Begin With End In Mind
• Release Planning
starts with User Story
Mapping
• Align stories as per
user activity (2nd line)–
helps with grouping
the features (1st line)
toward the activity
• High value items at
the top and low value
items at the bottom
• Stories
(Product/Service
Backlog) categorized
by Releases
(Release Backlog)
• Incrementally realize
the Product Goals
optionality
necessary
less
optional
more
optional
Release 1
Release 2
Release 3
28. 28
User Story map Exercise
• Identify an Epic from your current engagement (1 per group)
• Create a user story map for 1 or 2 personas, similar to one below: What stories can we tell?
29. 29
User Stories creation
“As a <role>, I want <goal>, so that <benefit>”
User stories provide a different communication strategy than
traditional requirements, telling us WHO wants WHAT and WHY:
30. 30
I N V E S T
Independent Negotiable Valuable Estimable Small Testable
- Make
stories as
independent
as possible
from each
other
- Start with a
brief
description
- Details
emerge in
discussion &
negotiations
- Users and
customers
perceive
value in the
deliverables
- Domain and
technical
knowledge
allow the
team to
provide
estimates
- A team can
finish one
story in a few
days, and
several in
every sprint
- Acceptance
(testing)
criteria and
technique are
specified
clearly
Summary: Invest in Writing Good User stories
31. 31
Life Cycle of a User Story
Product/Service Owner PO + ARCH + LEAD PO + QA + LEAD PO + Team
Product/Service Owner
writes epics that are
negotiable and has
relevant business value
Architect and Team Lead
negotiate with PO/ SO to
create vertical slices of
epics to shape small and
independent stories
QA ensures stories are
testable and estimable
with scenarios for each
user story
Additional story split along
scenarios and acceptance
criteria may occur
Team receives well
packaged user stories
Team negotiates user
stories with the
Product/Service Owner
Team sizes story for
understanding and
provides estimate
Negotiable
Valuable
Independent
Small
Estimable
Testable
33. 33
Exercise #2: Decompose Epic into User Stories from Story Map (Template)
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
Participate in user story grooming session to write 5 user stories from your Story Map
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:
34. 34
Exercise #2: Decompose Epic “Send Money Using Mobile Devices” (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
35. 35
Exercise #2: Refining User Stories with BDD template (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Apple as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Square as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. GIVEN PayPal as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
36. 36
Team-Based Estimation: Overview
Can we Estimate Size of cars?
Pretend you and your team are looking out a
window at a parking lot and are tasked with
estimating the size of the cars.
Relative Easier than Absolute
•Toyota Corolla in the foreground is a small car
•The Ford Excursion is neither small nor large,
yet looks smaller to team based on distance
Team Eliminates any Bias
Team can discuss and eliminate the bias that the
distance causes to come up with a more correct
way by doing relative sizing of the two vehicles.
Ford Excursion
Toyota Corolla
37. 37
Why Team-Based Estimation: With Sizing Board
• Increases accuracy by including all perspectives
• Builds a shared understanding of what needs to be
done and what items may potentially affect completion
• Creates shared commitment to achieving the sprint
goals and will give everyone – from analyst to developer
to tester – a vision for how complex the work will be
• Use modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20)
to size user stories
• Always triangulate with other stories, e.g. an 8 point
story should take 4 times longer than a 2 point story
• Avoid Outliers- ensure that stories have similar sizes,
e.g. stories having sizes 3,5,8 instead of sizes 1,5,13
• This increases predictability, reduces variability
38. 38
Sprint Backlog Estimation (Using “Planning Poker”)
Each estimator gets a
deck of cards
Product/Service
Owner reads a
story
Estimators
privately select
cards
Cards are turned
over
Discuss
Differences
Re-estimate
Each estimator is given a
deck of cards with the
values listed above.
For each backlog item to
be estimated,
Product/Service Owner
reads description.
Each estimator privately
selects a card
representing their
estimate.
All cards are
simultaneously turned
over so that everyone
can see each estimate.
High and low estimators
explain their differences..
Re-estimate until
estimates converge. Use
timer if process takes too
long.
Adapted from Mike Cohn. Agile Estimating and Planning, 2005.
Using “Planning Poker” in a Sprint Planning Session combines expert opinion, analogy, and
disaggregation for quick but reliable estimates
39. 39
Exercise #3: Planning Poker for User Stories (Template)
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
Participate in Planning Poker session to size user stories from story map. Use Sizing Board.
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
As A:
I want:
So That:
40. 40
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Teams Participated in Planning Poker session and used Sizing Board for sizes like these:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
Exercise #3: Planning Poker for Epic “Send Money Using Mobile Devices” (Example)
3 5 8
41. 41
Backlog Management - Priority Drives the Planning
Iteration / Sprint
Release
Priority
High
Low
Roadmap
Value
Risk
Cost
Knowledge
42. 42
How to Prioritize Stories: MoSCoW Principle as an option
MoSCoW
– Prioritizes stories in four categories
Must Have - Stories that must be included in the project delivery time-box for the project success
Should Have - Stories not critical but should be included if at all possible
Could Have - Less critical but nice to have stories
Won’t Have - Least critical and lowest payback items
• Appropriate mix of stories in each category can be implemented for a release/sprint
• Example 50% can be Must have, 30% Should have, 15% Could have and 5% Wont have
43. 43
How to Prioritize Stories: Risk Analysis as the other option
High Risk
Low Value
High Risk
High Value
Low Risk
Low Value
Low Risk
High Value
Value
Risk
Low
High
High
Avoid Do first
Do Last Do second
Value
Risk
Low
High
High
To optimally prioritize feature it is important to consider both risk and value
Business Dimensions
The desirability of the story to a broad base of users or customers
The desirability of the story to a small number of important users or
customers
The cohesiveness and ordering of the stories in order to deliver the
release end-goals
Business seeks for advice from the technical team but if there is
disagreement, Business might still push for the feature
Technical Dimensions
Technical Complexity
Technical Feasibility
The technical risk that the story cannot be completed as
desired
The impact the story will have on other stories if
deferred (consider high risk story first)
44. 44
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh
45. 45
Metrics
• Burndown
• Team Velocity
• # of Stories planned vs accepted
• Unit test coverage
• Open defects
Team Metrics
46. 46
Burndown Chart
Visible indicator of progress, allows the
team to self-correct
Helps you measure how much work is
left to do vs how much time is left
Automatically generated by Jira by
team members updating their tasks
Ideal Sprint Work
Actual Sprint Work
completed
47. 47
Team Capacity
Determining the team’s capacity is critical to a successful planning session and should be the first
activity in the planning meeting. Plan for 80% allocation for dedicated team members.
Team Member PTO/Holiday Allocation
(Max 80%)
(in days)
Michael 0 80% 10 x .8 = 8
Randy 3 80% 7 x .8 = 5.6
Tito 0 80% 10 x .8 = 8
Jermaine 0 80% 10 x .8 = 8
Janet 2 40% 8 x .4 = 3.2
Peter 1 25% 9 x .25 = 2.25
35 days (Total Team Capacity)
Assume 10 day sprints
48. 48
Team Velocity
Velocity is the average number of story points completed by a team in an iteration, and is used to
understand team limits while defining the amount of scope that can be committed to in a sprint.
Exercise:
Assume the following team data:
Sprint 1: 35 story points
Sprint 2: 38 story points
Sprint 3: 42 story points
Sprint 4: 40 story points
What is team’s average velocity (based on trend line)?
If team has 210 story points worth of pending work,
how many sprints will be needed to complete work?
49. 49
Stories planned vs. accepted
Used to show how
well a team is
implementing
story-level
acceptance criteria
0
1
2
3
4
5
6
7
8
Sprint 1 Sprint 2 Sprint 3
Stories Planned vs Accepted
Stories Planned Stories Accepted
50. 50
Unit test code coverage
Visible indicator of code risk that helps a team
measure and characterize potential bugs in the code
Helps track improvements in unit test coverage
52. 52
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Tasks (Sequence#, name, estimate, day#)
1. Implement payment gateway I/F (4h, d2)
2. Create Wireframe for UI (2h, d3)
3. Implement UI for transaction (1h, d4)
4. End-To-End Test for Vertical Slice (3h, d5)
5. …
6. …
Exercise #2: Burndown Chart for Epic “Send Money Using Mobile Devices” (Template)
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Tasks (Sequence#, name, estimate, day#)
1. Implement payment gateway I/F (4h, d2)
2. Create Wireframe for UI (2h, d3)
3. Implement UI for transaction (1h, d4)
4. End-To-End Test for Vertical Slice (3h, d5)
5. …
6. …
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Tasks (Sequence#, name, estimate, day#)
1. Implement payment gateway I/F (4h, d2)
2. Create Wireframe for UI (2h, d3)
3. Implement UI for transaction (1h, d4)
4. End-To-End Test for Vertical Slice (3h, d5)
5. …
6. …
Participate in creating burndown chart using task related data for these user stories:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
3 5 8
53. 53
Instructions: Compare and Contrast Traditional vs. Agile
1. Designate someone to be Scrum Master
2. Sequence of prioritized tasks will affect the burn down.
3. Scrum Master facilitates plotting of tasks burning down on the chart
4. Scrum Master and Team discuss the chart and analyze the variations
e.g. hockey stick burndown and so on
Exercise #2: Burndown Chart for Epic “Send Money Using Mobile Devices” (Instructions)
54. 54
Exercise #2: Burndown Chart for Epic “Send Money Using Mobile Devices” (Example)
Your burndown charts may look somewhat like this:
Actual Sprint Work
Planned Sprint Work
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
-200
-100
0
100
200
300
400
500
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
55. 55
How to Track progress using Big Visible Information Radiators?
Scrum Boards & Charts
• Allow to view Product
Progress over time
• Track against
Release/Project Scope
line
• Charts updated at the
end of every sprint
• Allows team to make
course correction if
significant deviation
from Ideal trend line
57. 57
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh
58. 58
Removing Impediments/Obstacles: Overview
• Types of Impediments/Obstacles
• Physical (e.g. server/access for dev/stage env)
• Organizational (People-ware within teams/management)
• Skill (e.g. not enough x in y)
• Example of Levels of impediments/obstacles
Management
• Team level (scrum master)
• Management Level
• Portfolio (Exec Level)
• Obstacle card is like an index card
• Front side:
• Name
• Owner
• Due Date
• Problem Statement
• Vision
• Back side:
• Detailed Log (actions/status)
59. 59
Removing Improvements: Obstacle Moves across (For Example) 3 Levels
• Team-level:
• Scrum Master tries to resolve obstacle with help of team.
• Obstacle is logged on an obstacle board.
• Management-level:
• When the team cannot resolve it, or when it is org-level escalation, SM gets
manager involved.
• For business escalation, Product/Service Owner gets manager involved.
• It shows up on management-level obstacle board.
• Exec-level:
• When manager cannot resolve the obstacle, it shows up on exec-level obstacle
board.
• This board is similar to the team level, except that last column mentions “resolved”,
as it cannot be placed “on hold” at exec level.
• Owner can resolve/dismiss obstacle at regular interval.
60. 60
Removing Impediments/Obstacles: Example of Governance
• Team-level:
• Scrum Master will ensure that each
obstacle is logged on an obstacle
board.
• This can be physical board in team
area or team room, marked with “Do
Not Remove” sign.
• Management-level:
• For org-level escalation, functional
manager will use online obstacle board
(virtual Kanban board)
• For business escalation, PO/manager
will use similar obstacle board.
• Management-level online obstacle
boards:
• This level obstacle board can be a Kanban
board with the following value stream:
• Entire middle-management should have
access to this board.
• Exec-level:
• Exec-level obstacle board
can be physical board
outside exec room.
Alternately execs can
access management level
virtual board for escalations
of obstacle(s) in-progress.
61. 61
Exercise #3:
Top 3 obstacles that your teams generally encounter. Decide which level of escalation those belong to.
In your experience so far, what are the top 3 obstacles a Scrum Master can
help remove, so that the scrum team stays productive?
What are some of the escalation paths available to this Scrum Master?
62. 62
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh
63. 63
Pitfalls in Scrum Master Role
Scrum Master as Project Manager
• Tendency to go back
to traditional ‘Command and
Control’ management especially
when in Crisis
• Conducting Daily Standup as
status update meetings
• Allocating tasks during Sprint
planning meeting
Scrum Master as Decision Maker
• Making project decisions instead
facilitating Agile Team to make
appropriate decisions
• Providing Sprint commitment in
Sprint planning meeting
Scrum Master as Communication Channel
• Act as “Single Point of Contact” for any
communication with Product/Service
Owner or other stakeholders
Assuming Delivery Ownership
• Projecting as leader of Agile
Team and assuming product
delivery ownership instead of
facilitating Agile Team to take
ownership of their commitments
Scrum Master
Pitfalls to Avoid
X
X
X
X
64. 64
7 Servant Leadership Traits
Primary Source: Mike Cohn “"Leader of the Band: Six Attributes of the Good Scrum Master"
Empowering
& Developing
Others
Serving
Others
Vulnerability
& Humility
Open,
Participatory
Leadership
Visionary
Leadership
Courageous
Leadership
(integrity &
authenticity)
Inspiring
Leadership
65. 65
10 Principles of Servant Leadership
Primary Source: Mike Cohn “"Leader of the Band: Six Attributes of the Good Scrum Master"
Persuasion – (building consensus)
Awareness – (of self and of others)
Healing – (search for wholeness of self &others)
Empathy – (understanding)
Listening – (to self and others)1
2
3
4
5
Building Community – (benevolent,
humane, philanthropic, to benefit others)
Commitment to Growth – (personal,
professional, spiritual of self and others)
Stewardship – (holding institution in trust
for the good of society)
Conceptualization – (dreams and of day-
to-day operations)
Foresight – (ability to learn from past & see
future )6
7
8
9
10
66. 66
Exercise #4:
Apply your knowledge about being Scrum Master to solve the following situation you will encounter a lot.
Scenario:
Faced with pressure from stakeholders, the Program Manager tells the Scrum
Master to tell the teams how much work they need to complete in the next
sprint.
What is the best way to deal with this scenario?
The Wrong Way to do Agile: Specifications
The Wrong Way to do Agile: Planning
How to: Improve Sprint Backlog Refinement/Grooming
Without Lean Thinking, you really can’t be Agile!
Lean Thinking provide a compass for good decision making
Peeling the onion:
Lean -> Thinking/Principles
Agile -> Mindset/Values
Scrum -> Process/Framework
XP -> Engineering Practices
The Wrong Way to do Agile: Specifications
The Wrong Way to do Agile: Planning
How to: Improve Sprint Backlog Refinement/Grooming
The Wrong Way to do Agile: Team
The Wrong Way to do Agile: Standups
Dodgy Daily Standup
Hitler at Sprint Review
The Wrong Way to do Agile: Retrospectives
Paste those sized stories on the sizing board.
Based on data about tasks, their actuals in hours taken to complete, and date completed; create a burndown chart that you can monitor as a Scrum Master.
Based on data about tasks, their actuals in hours taken to complete, and date completed; create a burndown chart that you can monitor as a Scrum Master.
Name: Team commitments are inconsistent
Problem Statement:
Teams are missing their sprint/release commitments whenever a team member is unexpectedly absent.
The “XYZ1” team is behind schedule due to a team member being on jury duty and none of the other team members have the required know-how to fill in for him. Missing the next milestone will impact the “ABC” program and delay the retirement of the “Acme” software, costing PayPal $100,000 per month.
Due to a car accident, the “XYZ2” team lost one team member for two weeks last month. The whole team was blocked for an entire Sprint because the person out on sick leave was the only one who knew how to develop in Java.
Vision:
Team members should be cross-trained so that they can step in when another team member is unavailable or to aid others in the team when necessary.
Owner: Mike Smith
Due Date: 6/06/2014
Steps Taken to Resolve and Status:
[5/1/2014] Mike Smith - did a 5 whys root cause analysis.
Team members cannot cover for each other
Why? Because people are not cross-trained
Why? Because of lack of budget
Why? Because cross-training is not valued
Why? Because functional managers have not been coached
Why? Because DT does not have a coach
[5/2/2014] Mike Smith - Spoke to managers of teams. Suggested “pair programming” for people to learn on the job.
[5/30/2014] Mike Smith - Despite following up weekly over the course of two weeks nothing has been done yet.