Data driven coaching - Agile 2016 (troy magennis)Troy Magennis
Team data and dashboards can be misused and cause more pain than results. Having the team run blind to its historical data though is often worse, with solely opinions and gut-feel driving process change. Helping your teams see and understand a holistic balance of their data will give your coaching advice context and encourage team constant improvement through experiments and reflection.
Coaching dashboards are about balancing trade-offs. Trading something your team is great at for something they want (or need) to improve. Having the team complete the feedback loop and confirm than an experiment had the intended impact, will process improvement be continuous and sustainable.
This presentation shows how to expose data to teams in order for them to retrospect productively, determine if a process experiment is panning out as expected, and to vigorously explore process change opportunities. Recent research shows strong relationships of certain metrics to process and practices, and this session demonstrates how these metrics have and can be tied to timely coaching advice.
The real-world dashboards demonstrated in this session show most common problems and how to avoid them with before and after shots and quotes from the teams impacted by them.
In this session you will –
- Learn how you can not only gather data, but use it to improve the process, with examples!
- Learn how your can tie data insights to coaching advice (data driven coaching)
- Learn how you can detect, predict and avoid data gaming and dashboard misuse
- Learn from my mistakes, and mistakes I’ve seen others with real examples of Agile coaching dashboards (good and bad)
This document is an introduction to Agile for AXA Emerging Markets EMEA-LATAM. It discusses why Agile is being adopted, including benefits like faster time to market and flexibility. Key Agile principles are outlined, such as customer collaboration, responding to change, and valuing individuals. The document also covers Agile frameworks like Scrum and Kanban that will be implemented. Overall it provides a high-level overview of Agile concepts and sets the stage for more detailed explanations in subsequent chapters.
A Scrum Master facilitates the Scrum process, creates rhythm and sets expectations for projects and team members. They facilitate daily stand-ups and meetings, enhance communication, and act as an approachable coach through 1:1 meetings and active listening. Scrum Masters also train teams, products, and the organization on Agile practices.
It is the team who does all the work. Team is self-organising. Team decides and plans. So what is the role of scrum master? Is it a full time role? How is it different from a project manager? Can a project lead or manager be a scrum master? It is probably the least understood and the most abused role in scrum. Let's explore these points in details further on April 10, 3:00 PM.
3 Roles in Scrum
Role of scrum master
Challenges of a scrum master
Skills, Knowledge & mindset required
Full time or part time?
Future career path of scrum master
Benefits:
Uncover the true role of a scrum master which is that of a facilitator, protector, negotiator and a coach.
Understand the true meaning of coaching.
Learn how scrum master can coach the team.
Understand the skills, knowledge and mindset required as a scrum master.
Perform better as a scrum master by getting introduced to some magical techniques and fad words like gamestorming, innovation games and visual thinking to facilitate collaborative decision making.
Learn points which you can use to make people understand the vital role a scrum master plays.
Appreciate the difference between project manager and a scrum master.
Learn who can be a good scrum master.
Attend the webinar and separate yourself from the crazy herd of people blindly accepting or discarding the role of scrum master!!
The document discusses agile retrospectives and provides guidance on facilitating effective retrospectives. It outlines a 5-step format for retrospectives: 1) set the stage, 2) gather data, 3) generate insights, 4) decide what to do, and 5) close the retrospective. The facilitator's role is to make sure everyone contributes and a plan is created without solving problems for the team. The Scrum Master reflects the team's behavior back to help them improve. Team members should focus on the content, discuss openly, and make decisions. Retrospectives help teams continuously improve and change their definition of done, working agreements, and generate action items.
This document contains 6 case studies describing organizations undergoing agile or lean transformations. The case studies outline challenges the organizations face and questions an agile coach might address to help with the transformation. The case studies cover companies in various industries including automotive, databases, banking, healthcare, and restaurants. Kanban and lean principles applied in a healthcare setting are also detailed. The document provides context to help an agile coach develop engagement strategies and initial action plans to assist the organizations.
The document provides a template for conducting a Sprint Review, Retrospective, and Planning meeting. It includes sections for demoing completed work, reviewing work accepted in the previous Sprint, discussing key performance metrics and action items from the prior Retrospective, setting the Sprint goal, and estimating work for the upcoming Sprint.
What does a Scrum Master do all day if a Daily Scrum is only 15 minutes? This talk - “A Day in the Life of a Scrum Master” - will explore the role beyond simple facilitation of the Sprint Ceremonies. Attendees learn four different areas of focus for a balanced approach to the role.
Data driven coaching - Agile 2016 (troy magennis)Troy Magennis
Team data and dashboards can be misused and cause more pain than results. Having the team run blind to its historical data though is often worse, with solely opinions and gut-feel driving process change. Helping your teams see and understand a holistic balance of their data will give your coaching advice context and encourage team constant improvement through experiments and reflection.
Coaching dashboards are about balancing trade-offs. Trading something your team is great at for something they want (or need) to improve. Having the team complete the feedback loop and confirm than an experiment had the intended impact, will process improvement be continuous and sustainable.
This presentation shows how to expose data to teams in order for them to retrospect productively, determine if a process experiment is panning out as expected, and to vigorously explore process change opportunities. Recent research shows strong relationships of certain metrics to process and practices, and this session demonstrates how these metrics have and can be tied to timely coaching advice.
The real-world dashboards demonstrated in this session show most common problems and how to avoid them with before and after shots and quotes from the teams impacted by them.
In this session you will –
- Learn how you can not only gather data, but use it to improve the process, with examples!
- Learn how your can tie data insights to coaching advice (data driven coaching)
- Learn how you can detect, predict and avoid data gaming and dashboard misuse
- Learn from my mistakes, and mistakes I’ve seen others with real examples of Agile coaching dashboards (good and bad)
This document is an introduction to Agile for AXA Emerging Markets EMEA-LATAM. It discusses why Agile is being adopted, including benefits like faster time to market and flexibility. Key Agile principles are outlined, such as customer collaboration, responding to change, and valuing individuals. The document also covers Agile frameworks like Scrum and Kanban that will be implemented. Overall it provides a high-level overview of Agile concepts and sets the stage for more detailed explanations in subsequent chapters.
A Scrum Master facilitates the Scrum process, creates rhythm and sets expectations for projects and team members. They facilitate daily stand-ups and meetings, enhance communication, and act as an approachable coach through 1:1 meetings and active listening. Scrum Masters also train teams, products, and the organization on Agile practices.
It is the team who does all the work. Team is self-organising. Team decides and plans. So what is the role of scrum master? Is it a full time role? How is it different from a project manager? Can a project lead or manager be a scrum master? It is probably the least understood and the most abused role in scrum. Let's explore these points in details further on April 10, 3:00 PM.
3 Roles in Scrum
Role of scrum master
Challenges of a scrum master
Skills, Knowledge & mindset required
Full time or part time?
Future career path of scrum master
Benefits:
Uncover the true role of a scrum master which is that of a facilitator, protector, negotiator and a coach.
Understand the true meaning of coaching.
Learn how scrum master can coach the team.
Understand the skills, knowledge and mindset required as a scrum master.
Perform better as a scrum master by getting introduced to some magical techniques and fad words like gamestorming, innovation games and visual thinking to facilitate collaborative decision making.
Learn points which you can use to make people understand the vital role a scrum master plays.
Appreciate the difference between project manager and a scrum master.
Learn who can be a good scrum master.
Attend the webinar and separate yourself from the crazy herd of people blindly accepting or discarding the role of scrum master!!
The document discusses agile retrospectives and provides guidance on facilitating effective retrospectives. It outlines a 5-step format for retrospectives: 1) set the stage, 2) gather data, 3) generate insights, 4) decide what to do, and 5) close the retrospective. The facilitator's role is to make sure everyone contributes and a plan is created without solving problems for the team. The Scrum Master reflects the team's behavior back to help them improve. Team members should focus on the content, discuss openly, and make decisions. Retrospectives help teams continuously improve and change their definition of done, working agreements, and generate action items.
This document contains 6 case studies describing organizations undergoing agile or lean transformations. The case studies outline challenges the organizations face and questions an agile coach might address to help with the transformation. The case studies cover companies in various industries including automotive, databases, banking, healthcare, and restaurants. Kanban and lean principles applied in a healthcare setting are also detailed. The document provides context to help an agile coach develop engagement strategies and initial action plans to assist the organizations.
The document provides a template for conducting a Sprint Review, Retrospective, and Planning meeting. It includes sections for demoing completed work, reviewing work accepted in the previous Sprint, discussing key performance metrics and action items from the prior Retrospective, setting the Sprint goal, and estimating work for the upcoming Sprint.
What does a Scrum Master do all day if a Daily Scrum is only 15 minutes? This talk - “A Day in the Life of a Scrum Master” - will explore the role beyond simple facilitation of the Sprint Ceremonies. Attendees learn four different areas of focus for a balanced approach to the role.
The document discusses goals for adopting agile practices like predictability, quality, early ROI, lower costs, and innovation. It then covers considerations for transformation based on organization size, dependencies between teams, and resistance to change. Finally, it outlines key elements of transformation including backlogs, teams, and working tested software and discusses governance structures with portfolio, program, and delivery teams.
This document summarizes a presentation on introducing Kanban. It discusses Kanban principles like visualizing workflow, establishing work in process limits, establishing fast feedback loops, and using an evolutionary approach to continuous improvement. The presentation emphasizes that Kanban is not just for individual teams, but should be applied at multiple "flight levels" including operational, end-to-end coordination, and strategic portfolio management levels.
The document provides an overview of the Scrum agile framework for software development. It defines Scrum, outlines its history and components, and describes key aspects like roles, artifacts, and the sprint process. Scrum uses short development iterations called sprints to incrementally develop working software, with daily stand-ups and sprint planning and review meetings. Roles include the product owner, scrum master, and self-organizing cross-functional team. Artifacts include the product and sprint backlogs and burn down charts. The document also discusses scaling Scrum for large projects.
« Il était une fois la vie d’un Product Owner (PO) » est un retour d’expérience de 9 mois, une immersion dans la peau d’un Product Owner qui découvre son rôle et qui doit livrer son premier produit.
Entre les visionnaires, les utilisateurs, l’équipe de développement et les investisseurs, il évolue dans un environnement exigeant, sans filet. De l’initiation à la maturité, ce Product Owner va vivre des échecs, des réussites et construire pas à pas son produit en utilisant des techniques d’expression de besoins dans le seul et unique but de valider ses hypothèses.
Entre fiction et réalité, « Il était une fois la vie d’un Product Owner » est une illustration concrète et fantastique du quotidien et de l’apprentissage d’un Product Owner fraîchement débarqué qui va gérer son produit en mode startup.
Cette session illustre par des exemples concrets la réalité de ce rôle où rien n’est simple ni écrit d'avance avec des focus particuliers sur :
• L’évolution d’une approche déterministe de la gestion de produit vers la mise en place d’hypothèses et de mesures associées,
• L’articulation des outils actuellement à disposition des Product Owner : de la vision à la production en passant par les User stories, les exigences non-fonctionnelles, Kanban pour les Product Owner, l’impact mapping et le Lean Startup,
• L’apprentissage des erreurs commises, leurs analyses et des idées pour les éviter : UX, communication, gestion du backlog,
• La remise en question de la stratégie du Product Owner par son travail avec les parties prenantes
• Maintenir un équilibre fragile entre une approche analytique de l’expression de besoins et un contexte émergent inhérent à l’environnement startup.
Cette session s’adresse particulièrement à tous les Product Owner et les responsables produit qui souhaitent développer et enrichir leur gestion de produit agile.
This document describes one team's transition from Scrum to Kanban or "Scrumban". It outlines their typical Scrum process, including daily standups and weekly planning and retrospectives. It then discusses how they experimented with different work in progress limits on their Kanban board and the problems they encountered, such as bottlenecks. Finally, it notes how their process evolved more naturally over time with continuous improvement and that they retained stakeholder demos and retrospectives as needed rather than having fixed weekly meetings.
Here are the slides from the Kanban Coaching Exchange talk from Daidree Tofano. In this talk she talks about coaching leaders. Please see the you tube channel if you wish to watch the video.
Scrum is an agile framework for managing product development. It defines three roles - Scrum Master, Product Owner, and Development Team - and three artifacts - Product Backlog, Sprint Backlog, and Product Increment. It also includes five ceremonies - Product Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Scrum was first defined in 1986 and evolved through the 1990s, with Ken Schwaber and Jeff Sutherland formalizing the method in 2001 in their book Agile Software Development with Scrum.
Scrumban - applying agile and lean practices for daily uncertainty by Vidas V...Vidas Vasiliauskas
In this presentation I have talked about scrumban - a mix of routines and techniques for daily use in dynamic environment. Like in startups, product manufacture, support or similar cases.
This document provides an introduction to Agile Scrum methodology. It defines Agile and Scrum, outlines the history and principles of Scrum, and describes the core components and processes in Scrum including roles, ceremonies, artifacts, and sprints. The document explains that Scrum is an iterative Agile framework used for managing complex projects, with self-organizing cross-functional teams working in short sprints to deliver working software increments based on prioritized backlogs.
Scrum is certainly not a foolproof framework as it does have its own set
of limitations; which is the reason why it may not be the best fit for
every team or product. There are other Agile and Lean approaches too,
like Kanban or XP.
Therefore, what is crucial is for us to comprehend that these current
shifts call for a dynamic and progressive outlook from developers and managers. The need of the hour is to utilize the benefits that a Scrum Master brings to the table, in terms of opening up team communication and problem solving techniques.
This document discusses definitions of done at the sprint and release levels in Scrum. It provides examples of what could be included in a definition of done at the sprint level, such as code being complete, passing unit tests, and product owner acceptance. It distinguishes acceptance criteria, which ensures the right functionality is built, from the definition of done, which ensures quality. The document concludes by providing instructions for an exercise where a team discusses and creates their own definition of done, capturing deliverables needed at each level.
- Scrum is an agile framework for managing product development, with roles of Product Owner, Scrum Master, and Development Team.
- Key rituals include Sprint Planning, Daily Stand-ups, Sprint Review and Retrospective.
- The Product Owner prioritizes features in the Product Backlog to maximize business value, while the Development Team works in sprints to deliver increments of functionality. The Scrum Master facilitates the process and removes impediments.
Scrum 101 Learning Objectives:
1. Waterfall project methodology basics - what is waterfall and where did it come from?
2. Agile umbrella practices and frameworks - what is agile? what isn't agile? Where does Scrum fit in?
3. Scrum empirical theory - emperical vs. theoretical
4. Parts of the Scrum framework - roles, events / ceremonies, artifacts and rules
5. Features of cultures that use Scrum
Scrum is an agile framework for managing product development. It involves short development iterations called sprints (typically 2-4 weeks) where self-organizing cross-functional teams work to deliver a potentially shippable product increment. Key aspects of scrum include product backlogs to define features, sprint planning meetings, daily stand-up meetings, sprint reviews, and retrospectives. Scrum aims to improve transparency, inspection, and adaptation and enables rapid delivery of valuable software through an empirical process that promotes continuous improvement.
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.
This document provides an overview of numerous agile concepts, frameworks, and practices. It includes concepts related to lean, scrum, kanban, design thinking, and scaled agile frameworks. The document also discusses challenges organizations may face in implementing agile and how an agile delivery partner can help address common issues through various agile services.
This document provides an overview of Scrum training. It introduces the trainer, Deniz Gungor, and their background. It then outlines the agenda, which will cover Scrum fundamentals, a Scrum simulation game, and the Scrum framework. Key aspects of Scrum are defined, including self-organizing Scrum teams, iterative delivery, the Product Owner, Scrum Master, Development Team, events like the Daily Scrum and Sprint Review, and artifacts like the Product Backlog and Sprint Backlog. The training will help participants understand and apply the Scrum framework to projects.
A Multi-Team, Full-Cycle, Product-Oriented Scrum (Agile game) Simulation with LEGO Bricks. Based on the lego4scrum.com.
Lego4Scrum is teaching game is used by the Scrum trainers community worldwide including various certification classes, in-house trainings, formal business programs and team workshops.
This document discusses the concept of "READY" in agile development. It defines READY as having clear goals and criteria, understanding how to complete the work, having the ability to complete it in the sprint, and managing risks and dependencies. Work that is not READY causes problems like missed deadlines and unclear acceptance criteria. The document recommends using READY as a quality gate to prevent unprepared work from being committed to sprints. It provides examples of how to structure product backlogs and incrementally prepare stories to become READY. The results section notes low adoption rates for READY compared to definitions of done.
Metrics at Every (Flight) Level [2020 Agile Kanban Istanbul FlowConf]Matthew Philip
Slides as presented on Dec 8, 2020 at FlowConf organized by Agile Kanban Istanbul. https://www.flowconf.com/
Organizational change often stalls out at departmental boundaries, whether that is IT or another division. How do we help organizations connect vertically and horizontally to realize the outcomes that they have when undertaking large-scale change efforts?
Join this session to learn from a case study of a bank that combined flight levels and metrics to bridge their departmental boundaries and recognize gains not only in software delivery effectiveness but unifying higher-level strategy.
This document discusses achieving "ready-ready" stories by having more than a sprint's worth of stories prepared in advance. It recommends having a chief product owner approve stories that meet INVEST criteria and can be estimated quickly. Stories should be tested, have API/UI mockups approved, and be achievable within a sprint. Analyzing defects can help improve the ready-ready process by addressing issues like communication, knowledge, or availability. Presenting the ready-ready process to the organization should provide direction, gain support, and outline key performance indicators to help achieve goals. Starting small experiments is encouraged to test the approach.
Black Magic of the Advanced Scrum MasterGil Nahmias
The document discusses tactics for Scrum Masters to establish trust and leadership. It provides tips for getting stakeholders to like and trust the Scrum Master such as smiling, remembering details, getting feedback, and establishing trust first. It also covers handling resistance, motivating teams, and establishing mastery, autonomy and purpose. The document warns against unethical tactics like applying time pressure or psychological manipulation.
The document discusses goals for adopting agile practices like predictability, quality, early ROI, lower costs, and innovation. It then covers considerations for transformation based on organization size, dependencies between teams, and resistance to change. Finally, it outlines key elements of transformation including backlogs, teams, and working tested software and discusses governance structures with portfolio, program, and delivery teams.
This document summarizes a presentation on introducing Kanban. It discusses Kanban principles like visualizing workflow, establishing work in process limits, establishing fast feedback loops, and using an evolutionary approach to continuous improvement. The presentation emphasizes that Kanban is not just for individual teams, but should be applied at multiple "flight levels" including operational, end-to-end coordination, and strategic portfolio management levels.
The document provides an overview of the Scrum agile framework for software development. It defines Scrum, outlines its history and components, and describes key aspects like roles, artifacts, and the sprint process. Scrum uses short development iterations called sprints to incrementally develop working software, with daily stand-ups and sprint planning and review meetings. Roles include the product owner, scrum master, and self-organizing cross-functional team. Artifacts include the product and sprint backlogs and burn down charts. The document also discusses scaling Scrum for large projects.
« Il était une fois la vie d’un Product Owner (PO) » est un retour d’expérience de 9 mois, une immersion dans la peau d’un Product Owner qui découvre son rôle et qui doit livrer son premier produit.
Entre les visionnaires, les utilisateurs, l’équipe de développement et les investisseurs, il évolue dans un environnement exigeant, sans filet. De l’initiation à la maturité, ce Product Owner va vivre des échecs, des réussites et construire pas à pas son produit en utilisant des techniques d’expression de besoins dans le seul et unique but de valider ses hypothèses.
Entre fiction et réalité, « Il était une fois la vie d’un Product Owner » est une illustration concrète et fantastique du quotidien et de l’apprentissage d’un Product Owner fraîchement débarqué qui va gérer son produit en mode startup.
Cette session illustre par des exemples concrets la réalité de ce rôle où rien n’est simple ni écrit d'avance avec des focus particuliers sur :
• L’évolution d’une approche déterministe de la gestion de produit vers la mise en place d’hypothèses et de mesures associées,
• L’articulation des outils actuellement à disposition des Product Owner : de la vision à la production en passant par les User stories, les exigences non-fonctionnelles, Kanban pour les Product Owner, l’impact mapping et le Lean Startup,
• L’apprentissage des erreurs commises, leurs analyses et des idées pour les éviter : UX, communication, gestion du backlog,
• La remise en question de la stratégie du Product Owner par son travail avec les parties prenantes
• Maintenir un équilibre fragile entre une approche analytique de l’expression de besoins et un contexte émergent inhérent à l’environnement startup.
Cette session s’adresse particulièrement à tous les Product Owner et les responsables produit qui souhaitent développer et enrichir leur gestion de produit agile.
This document describes one team's transition from Scrum to Kanban or "Scrumban". It outlines their typical Scrum process, including daily standups and weekly planning and retrospectives. It then discusses how they experimented with different work in progress limits on their Kanban board and the problems they encountered, such as bottlenecks. Finally, it notes how their process evolved more naturally over time with continuous improvement and that they retained stakeholder demos and retrospectives as needed rather than having fixed weekly meetings.
Here are the slides from the Kanban Coaching Exchange talk from Daidree Tofano. In this talk she talks about coaching leaders. Please see the you tube channel if you wish to watch the video.
Scrum is an agile framework for managing product development. It defines three roles - Scrum Master, Product Owner, and Development Team - and three artifacts - Product Backlog, Sprint Backlog, and Product Increment. It also includes five ceremonies - Product Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Scrum was first defined in 1986 and evolved through the 1990s, with Ken Schwaber and Jeff Sutherland formalizing the method in 2001 in their book Agile Software Development with Scrum.
Scrumban - applying agile and lean practices for daily uncertainty by Vidas V...Vidas Vasiliauskas
In this presentation I have talked about scrumban - a mix of routines and techniques for daily use in dynamic environment. Like in startups, product manufacture, support or similar cases.
This document provides an introduction to Agile Scrum methodology. It defines Agile and Scrum, outlines the history and principles of Scrum, and describes the core components and processes in Scrum including roles, ceremonies, artifacts, and sprints. The document explains that Scrum is an iterative Agile framework used for managing complex projects, with self-organizing cross-functional teams working in short sprints to deliver working software increments based on prioritized backlogs.
Scrum is certainly not a foolproof framework as it does have its own set
of limitations; which is the reason why it may not be the best fit for
every team or product. There are other Agile and Lean approaches too,
like Kanban or XP.
Therefore, what is crucial is for us to comprehend that these current
shifts call for a dynamic and progressive outlook from developers and managers. The need of the hour is to utilize the benefits that a Scrum Master brings to the table, in terms of opening up team communication and problem solving techniques.
This document discusses definitions of done at the sprint and release levels in Scrum. It provides examples of what could be included in a definition of done at the sprint level, such as code being complete, passing unit tests, and product owner acceptance. It distinguishes acceptance criteria, which ensures the right functionality is built, from the definition of done, which ensures quality. The document concludes by providing instructions for an exercise where a team discusses and creates their own definition of done, capturing deliverables needed at each level.
- Scrum is an agile framework for managing product development, with roles of Product Owner, Scrum Master, and Development Team.
- Key rituals include Sprint Planning, Daily Stand-ups, Sprint Review and Retrospective.
- The Product Owner prioritizes features in the Product Backlog to maximize business value, while the Development Team works in sprints to deliver increments of functionality. The Scrum Master facilitates the process and removes impediments.
Scrum 101 Learning Objectives:
1. Waterfall project methodology basics - what is waterfall and where did it come from?
2. Agile umbrella practices and frameworks - what is agile? what isn't agile? Where does Scrum fit in?
3. Scrum empirical theory - emperical vs. theoretical
4. Parts of the Scrum framework - roles, events / ceremonies, artifacts and rules
5. Features of cultures that use Scrum
Scrum is an agile framework for managing product development. It involves short development iterations called sprints (typically 2-4 weeks) where self-organizing cross-functional teams work to deliver a potentially shippable product increment. Key aspects of scrum include product backlogs to define features, sprint planning meetings, daily stand-up meetings, sprint reviews, and retrospectives. Scrum aims to improve transparency, inspection, and adaptation and enables rapid delivery of valuable software through an empirical process that promotes continuous improvement.
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.
This document provides an overview of numerous agile concepts, frameworks, and practices. It includes concepts related to lean, scrum, kanban, design thinking, and scaled agile frameworks. The document also discusses challenges organizations may face in implementing agile and how an agile delivery partner can help address common issues through various agile services.
This document provides an overview of Scrum training. It introduces the trainer, Deniz Gungor, and their background. It then outlines the agenda, which will cover Scrum fundamentals, a Scrum simulation game, and the Scrum framework. Key aspects of Scrum are defined, including self-organizing Scrum teams, iterative delivery, the Product Owner, Scrum Master, Development Team, events like the Daily Scrum and Sprint Review, and artifacts like the Product Backlog and Sprint Backlog. The training will help participants understand and apply the Scrum framework to projects.
A Multi-Team, Full-Cycle, Product-Oriented Scrum (Agile game) Simulation with LEGO Bricks. Based on the lego4scrum.com.
Lego4Scrum is teaching game is used by the Scrum trainers community worldwide including various certification classes, in-house trainings, formal business programs and team workshops.
This document discusses the concept of "READY" in agile development. It defines READY as having clear goals and criteria, understanding how to complete the work, having the ability to complete it in the sprint, and managing risks and dependencies. Work that is not READY causes problems like missed deadlines and unclear acceptance criteria. The document recommends using READY as a quality gate to prevent unprepared work from being committed to sprints. It provides examples of how to structure product backlogs and incrementally prepare stories to become READY. The results section notes low adoption rates for READY compared to definitions of done.
Metrics at Every (Flight) Level [2020 Agile Kanban Istanbul FlowConf]Matthew Philip
Slides as presented on Dec 8, 2020 at FlowConf organized by Agile Kanban Istanbul. https://www.flowconf.com/
Organizational change often stalls out at departmental boundaries, whether that is IT or another division. How do we help organizations connect vertically and horizontally to realize the outcomes that they have when undertaking large-scale change efforts?
Join this session to learn from a case study of a bank that combined flight levels and metrics to bridge their departmental boundaries and recognize gains not only in software delivery effectiveness but unifying higher-level strategy.
This document discusses achieving "ready-ready" stories by having more than a sprint's worth of stories prepared in advance. It recommends having a chief product owner approve stories that meet INVEST criteria and can be estimated quickly. Stories should be tested, have API/UI mockups approved, and be achievable within a sprint. Analyzing defects can help improve the ready-ready process by addressing issues like communication, knowledge, or availability. Presenting the ready-ready process to the organization should provide direction, gain support, and outline key performance indicators to help achieve goals. Starting small experiments is encouraged to test the approach.
Black Magic of the Advanced Scrum MasterGil Nahmias
The document discusses tactics for Scrum Masters to establish trust and leadership. It provides tips for getting stakeholders to like and trust the Scrum Master such as smiling, remembering details, getting feedback, and establishing trust first. It also covers handling resistance, motivating teams, and establishing mastery, autonomy and purpose. The document warns against unethical tactics like applying time pressure or psychological manipulation.
LKNA 2014 Risk and Impediment Analysis and Analytics - Troy MagennisTroy Magennis
Software risk impact is more predictable than you might think. This session discusses similarities of uncertainty in various industries and relates this back to how we can measure and analyze impediments and risk for agile software teams.
Forecasting using data workshop slides for the Deliver conference in Winnipeg October 2016. This session introduces practical exercises for probabilistic forecasting. http://www.prdcdeliver.com
Risk Management and Reliable Forecasting using Un-reliable Data (magennis) - ...Troy Magennis
To meet expectations and optimize flow, managing risk is an important part of Kanban. Anticipating and adapting to things that "go wrong" and the uncertainty they cause is topic of this session. We look at techniques for quantifying what risks should be considered important to deal with.
Although discouraging, forecasting size, effort, staff and cost is sometimes necessary. Of course we have to do as little of this as possible, but when we do, we have to do it well with the data we have available. Forecasting is made difficult by un-reliable information as inputs to our process – the amount of work is uncertain, the historical data we are basing our forecasts on is biased and tainted, the situation seems hopeless. But it isn't. Good decisions can be made on imperfect data, and this session discusses how. This session shows immediately usable and simple techniques to capture, analyze, cleanse and assess data, and then use that data for reliable forecasting.
Second and hopefully draft of LKCE 2014 talk.
The document discusses various code quality metrics that can be used to understand software quality, including defects density, unit test density, code and test coverage, cyclomatic complexity, fan-in and fan-out, and WTFs per minute. While metrics can help identify issues, they cannot determine the precise cause. Metrics should be used carefully to avoid incentivizing behaviors like hiding bugs. Maintaining pride in craftsmanship is important for quality.
High Performance Teams: The 4 KPIs of SuccessQELIedu
This document discusses the keys to developing high performance teams. It identifies 4 key performance indicators (KPIs) of success: 1) having a common vision and clear actions, 2) clear accountability and performance reporting, 3) leveraging diversity and leading by example, and 4) awareness and support of individual work/life goals. A case study shows that implementing a 3-phase high performance team program focused on these KPIs led to improved job demands, satisfaction, engagement, and a six month ROI of $254,951.50 for a team. Developing high performance teams can help organizations thrive through innovation, savings, and growth rather than just survive challenges.
The Scrum checklist is an informal tool to help teams get started with Scrum or assess their current implementation. It outlines various Scrum practices and categorizes them as core, recommended, or optional. The checklist is not meant to be used prescriptively but can help teams identify areas for improvement by discussing which practices they do or do not follow and why. It is intended as a guide rather than a rulebook and emphasizes that teams can experiment and tailor practices to their needs.
The Scrum checklist is an informal tool to help teams get started with Scrum or assess their current implementation. It outlines various Scrum practices and indicates which are core, recommended, or optional. The checklist is not meant to be used rigidly, but rather as a guide for teams to discuss what they are currently doing and identify areas for potential improvement. It is not an official certification of a team's Scrum implementation.
This document summarizes how a scrum team conducts various scrum activities including sprint demos, retrospectives, and slack time between sprints. It provides details on:
- Conducting sprint demos and insisting they include a demo at the end of each sprint for feedback.
- Organizing sprint retrospectives to identify what went well, opportunities for improvement, and action items for the next sprint.
- The importance of slack time between sprints for rest and learning, such as dedicating lab days for skills development.
How To Do A Retrospective + (Step-by-Step Playbook and Example)Philip Chesney
How To Do A Retrospective + (Step-by-Step Playbook and Example) Learn how to do a retrospective with a step-by-step guide and a practical example. Be prepared for your next retro!
How to do a retrospective video: https://youtu.be/RD60Js82D7Q
The document discusses time management and provides tips for using time efficiently. It tells the story of a king who constantly asks his attendant questions about a gathering by the river, while the prime minister is able to gather more comprehensive information in a single meeting. This illustrates how planning and prioritization allows some to achieve more in the same amount of time as others. The document then provides strategies for improving time management, such as setting goals, prioritizing tasks, understanding expectations, and conducting self-analyses to strengthen weaknesses and minimize threats.
The document discusses time management and provides tips for using time efficiently. It tells the story of a king who constantly asks his attendant questions about a gathering by the river, while the prime minister is able to gather more comprehensive information in a single meeting. This illustrates how planning and prioritization allows some to achieve more in the same amount of time as others. The document then provides strategies for improving time management, such as setting goals, prioritizing tasks, understanding expectations, and continuously working to overcome weaknesses.
9 ways to get started with Agile in public servicesJosephBadman1
Agile is simple to understand, but lots of people we work with sometimes find it difficult to get started.
Here are some practices you can try to help you get started on your Agile journey. They range from simple things you can do as an individual, to more ambitious approaches that will involve your wider team.
Let us know how you get on at comms@basis.co.uk or on Twitter @WeAreBasis or @Dyn_Drwg for Joe.
The document discusses time management and productivity. It tells a story about a king who constantly asks his attendant questions about a gathering by the river, while the prime minister is able to gather much more useful information in a single meeting. This illustrates how being organized and prioritizing tasks can allow one to achieve more in the same amount of time. It then provides tips for improving time management, such as making to-do lists, setting goals, being proactive, prioritizing tasks, understanding others, and improving oneself through regular self-reflection.
The document discusses the evolution of agile practices at a company called Caelum over many years. It describes how they experimented with different methods like Scrum, Kanban and others. Over time they realized some practices like sprints and metrics were not working well for their teams. They adapted an approach focused on continuous flow and adapting practices based on team retrospectives and feedback rather than rigidly following a specific method.
What is Agile Scrum? How can it be used for project management? How can it improve communication and effectiveness? This is a presentation used in a medium sized London start-up eCommerce business.
AGILE: THE AGILE GUIDE TO THE ENTERPRISE Jason Suttie
This is RMB story of how we adopted Agile at Rand Merchant Bank.
A romance novel for knowledge workers, if you are thinking about adopting Agile in your organization this is for you, practical experience of what worked and what didn't.
Agile Africa: August 2015
Credits: Candice Nolan
Creative & Visual: Deidre Wolmarans Consulting
- Agile is a more successful approach to product development that focuses on adaptability, iterative delivery, and customer satisfaction. Scrum is the most commonly used Agile framework.
- The key goals of Agile and Scrum are to deliver more quickly and frequently while improving quality, visibility, accountability and learning. This is achieved through self-organizing cross-functional teams, minimizing work-in-process, and rapidly addressing impediments.
- Adopting Agile requires a mindset shift and executive support for teams to learn through failures and receive subtle guidance rather than rigid control from management.
How to Ship in 8 Weeks or Less (via Cross-Functional Teams)QuekelsBaro
Get you clued up on what the development methodology Shape Up looks like in practice and sneak-peak into what we do at Process Street as our EPD team shares their secrets.
How One Article Changed the Way we Create our Product RoadmapNick Peasant
The deck was presented to the whole Old St Labs team on how we are going to start to change the way we build out our product roadmap and how we can leverage the knowledge in the company and our users.
A big thank you to @tconrad for his article here - http://bit.ly/1JiUFep that inspired the whole presentation. We used all of his thoughts and made them work in our current process.
1. The document discusses improving team presentations at Big Sprint Days by focusing on showcasing lessons learned and work, rather than just presenting status updates. It suggests sharing specific tactics or ideas that others can apply, like how a team improved cross-functionality or crafted good sprint goals.
2. The document also addresses challenges with current Big Sprint Day presentations like them being unstructured with no feedback. It notes presentations should be timeboxed and focus on 2-3 key takeaways that are useful for others.
3. The document emphasizes that presenters should consider what others can learn from their presentation and experiences, not just provide status updates, in order to make the presentations more valuable.
The document discusses how companies often make mistakes in their agile transformations by asking managers to take on the additional role of Scrum Master. This is problematic for several reasons: managers still have their existing responsibilities, they lack impartiality as coaches since they evaluate their direct reports, and their presence inhibits honest feedback in retrospectives. A better approach is to hire dedicated Scrum Masters and give managers freedom from tasks now handled by self-organizing teams and Product Owners, allowing them to focus on coaching and empowering teams.
Organisations and usually pretty bed when it comes to self diagnose their own problem and even worse when choosing a solution for the badly diagnosed problem.
Understanding the basic of complexity and system thinking can help a lot, providing foundations for a different mindset and a surprising solutions toolkit.
Temple of Asclepius in Thrace. Excavation resultsKrassimira Luka
The temple and the sanctuary around were dedicated to Asklepios Zmidrenus. This name has been known since 1875 when an inscription dedicated to him was discovered in Rome. The inscription is dated in 227 AD and was left by soldiers originating from the city of Philippopolis (modern Plovdiv).
Gender and Mental Health - Counselling and Family Therapy Applications and In...PsychoTech Services
A proprietary approach developed by bringing together the best of learning theories from Psychology, design principles from the world of visualization, and pedagogical methods from over a decade of training experience, that enables you to: Learn better, faster!
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...PECB
Denis is a dynamic and results-driven Chief Information Officer (CIO) with a distinguished career spanning information systems analysis and technical project management. With a proven track record of spearheading the design and delivery of cutting-edge Information Management solutions, he has consistently elevated business operations, streamlined reporting functions, and maximized process efficiency.
Certified as an ISO/IEC 27001: Information Security Management Systems (ISMS) Lead Implementer, Data Protection Officer, and Cyber Risks Analyst, Denis brings a heightened focus on data security, privacy, and cyber resilience to every endeavor.
His expertise extends across a diverse spectrum of reporting, database, and web development applications, underpinned by an exceptional grasp of data storage and virtualization technologies. His proficiency in application testing, database administration, and data cleansing ensures seamless execution of complex projects.
What sets Denis apart is his comprehensive understanding of Business and Systems Analysis technologies, honed through involvement in all phases of the Software Development Lifecycle (SDLC). From meticulous requirements gathering to precise analysis, innovative design, rigorous development, thorough testing, and successful implementation, he has consistently delivered exceptional results.
Throughout his career, he has taken on multifaceted roles, from leading technical project management teams to owning solutions that drive operational excellence. His conscientious and proactive approach is unwavering, whether he is working independently or collaboratively within a team. His ability to connect with colleagues on a personal level underscores his commitment to fostering a harmonious and productive workplace environment.
Date: May 29, 2024
Tags: Information Security, ISO/IEC 27001, ISO/IEC 42001, Artificial Intelligence, GDPR
-------------------------------------------------------------------------------
Find out more about ISO training and certification services
Training: ISO/IEC 27001 Information Security Management System - EN | PECB
ISO/IEC 42001 Artificial Intelligence Management System - EN | PECB
General Data Protection Regulation (GDPR) - Training Courses - EN | PECB
Webinars: https://pecb.com/webinars
Article: https://pecb.com/article
-------------------------------------------------------------------------------
For more information about PECB:
Website: https://pecb.com/
LinkedIn: https://www.linkedin.com/company/pecb/
Facebook: https://www.facebook.com/PECBInternational/
Slideshare: http://www.slideshare.net/PECBCERTIFICATION
2. How many times have you heard this… We need these 5 features done by the end of July But we can only finish 3 by July... Try harder! Do Overtime! Please prioritize for us Manager Team It already is. All is must. Ok we will do our best...
3. Back home… I’ve convinced them to do more! Yay! This project is so failing... Manager Team
4. What do you think is going to happen, ultimately?
11. different ending – using visibility We need these 5 features done by the end of July After estimating, it seems like 3 first features will probably get done. 4th feature – maybe and last one will probably not get done by July. But we need all of them! Deliver all the features! Manager Team Well we can SAY we will deliver. That won’t change reality. However we promise to let you know once our prediction changes. Ok. keep me in the loop.
12. Different ending – smaller bites We need these 5 features done by the end of July As it is, seems too big. Can you chop them into smaller pieces? How is that going to help? This way we can identify sub-stories we can live without, or ones to give some other team with more capacity. Manager Team Can you start working before breaking down? In the coming 2 weeks – yes. Not later. Enough time to get ready on your end?
13. Different ending – there is more money than time We need these 5 features done by the end of July Looks like a lot of work. Help? I can extend the team Too late to add people now (see: Brooks’s Law). But we can use manpower in other ways Manager Team I’m all ears The new guys can help by taking easy and managerial tasks off our load so we can focus on the special things only we can do.
16. And we need a faster build serverManager Team I can filter noise and talk to the product. Build server is out of reach now. What can you do with that?