Short introduction to Project Management and Scrum.
Meetup SET Software Engineering Thailand:
http://www.meetup.com/Software-Engineering-Thailand/events/223939279/
The document discusses reasons why research projects fail and introduces an approach called Scrum to help address those failures. Scrum is a set of guidelines for organizing work into sprints of 2-4 weeks, with planning meetings at the start of each sprint to define objectives, daily stand-up meetings to track progress, and retrospective meetings after each sprint to improve. By breaking work into short sprints with frequent re-planning, Scrum aims to help research objectives stay clear and prevent wasted time as objectives change over the course of a project.
KYIV PM CLUB 25.01 Anna Lavrova - Once upon a time in ITLviv Startup Club
Anna Lavrova - Certified Scrum Master, Engineering Manager at Betbull, former Project Manager and Queen of Scrum at Ciklum
Topic: Once upon a time in IT
The document outlines the agile Scrum process using four phases: initiation, exploration, planning, and build. In the initiation phase, a kickoff meeting is held to define the scope and problem statement. In exploration, domain concepts are explored and prototypes are developed. In planning, release and sprint backlogs are created to prioritize user stories. Glossaries and coding standards are also defined. In build, daily stand-up meetings are held to update the sprint dashboard and status of work.
STX Next - Scrum Development Process OverviewSTX Next
An overview of Software Development Process at STX Next presenting basic SCRUM ceremonies and workflows. To learn more about STX Next visit https://stxnext.com
The document discusses reasons why research projects fail and introduces an approach called Scrum to help address those failures. Scrum is a set of guidelines for organizing work into sprints of 2-4 weeks, with planning meetings at the start of each sprint to define objectives, daily stand-up meetings to track progress, and retrospective meetings after each sprint to improve. By breaking work into short sprints with frequent re-planning, Scrum aims to help research objectives stay clear and prevent wasted time as objectives change over the course of a project.
KYIV PM CLUB 25.01 Anna Lavrova - Once upon a time in ITLviv Startup Club
Anna Lavrova - Certified Scrum Master, Engineering Manager at Betbull, former Project Manager and Queen of Scrum at Ciklum
Topic: Once upon a time in IT
The document outlines the agile Scrum process using four phases: initiation, exploration, planning, and build. In the initiation phase, a kickoff meeting is held to define the scope and problem statement. In exploration, domain concepts are explored and prototypes are developed. In planning, release and sprint backlogs are created to prioritize user stories. Glossaries and coding standards are also defined. In build, daily stand-up meetings are held to update the sprint dashboard and status of work.
STX Next - Scrum Development Process OverviewSTX Next
An overview of Software Development Process at STX Next presenting basic SCRUM ceremonies and workflows. To learn more about STX Next visit https://stxnext.com
This document outlines the step-by-step process for release planning. It involves bringing together the product owner, delivery team, and stakeholders to define the release theme, schedule, and backlog items. Key steps include sharing the vision and roadmap, discussing velocity and availability, mapping stories to iterations, reviewing dependencies and assumptions, and committing to the release plan and schedule. The output is an agreed upon release plan with its backlog items and timeline. Release planning in DevOps and SAFe frameworks follows a similar process but with shorter iterations in DevOps and programs/trains in SAFe.
Scrum planning poker, principles of the gameSid Dane
Planning poker is a consensus-based technique for estimating effort or relative size of development tasks. It involves the following key principles:
1. Accept uncertainty in software projects and use relative story point estimates rather than precise hours to account for intangible factors.
2. Estimates are derived through group discussion where estimators must justify their cards, leading to more accurate estimates that factor in an average of individual views.
3. The document outlines seven principles for effective planning poker, including keeping estimates at a granular level, focusing only on the current sprint without long-term planning, using a question mark card when more information is needed, and being willing to finalize estimates when consensus is reached.
This is a short introduction to the practice of Sprint Planning in Scrum. It would be useful for people new to Scrum or Agile. For more, comment or write to read my blog : http://agilediary.wordpress.com/
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
“It's better to be roughly right, than precisely wrong!”
~ John Maynard Keyenes
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
PROBLEMS WITH TIME-BASED ESTIMATES
-Teams spend too much time trying to get it right
-Lack of confidence/experience can lead to people being either optimistic or pessimistic
-Timeline you are estimating may be too far in the future
-Due to long timeline, there are too many risks, unknowns, changes or dependencies!
WHY USE RELATIVE ESTIMATION?
-Allows a quick comparison of stories in the backlog
-Allows you to select a predictable volume of work to do in a sprint
-Uses a simple arbitrary scale
-Allows PO to make trade-offs and take on the most valuable stories next
ESTIMATION TIPS
-Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
-The team estimates the story, not management nor the customer.
-Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
-Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
-Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
-Only pull into your sprint, stories that are refined and estimated.
-Break down stories that are large, into smaller slivers of value to optimize your flow.
-Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Planning Poker is a technique used to estimate effort for tasks in Agile software development. It involves each team member privately selecting a planning poker card representing their estimate for a task. The cards have Fibonacci numbers written on them. The cards are then revealed and discussed if estimates differ, until consensus is reached. Once estimates are established, the team's velocity (amount of work completed per sprint) can be used to predict future release dates. Planning Poker works well because it leverages the wisdom of crowds and averages individual estimates for more accurate results.
This document summarizes key aspects of product backlogs in Scrum projects. It discusses the importance of the product backlog, characteristics of a good backlog, and grooming activities. It also addresses questions around which and how many backlogs should exist for different project structures involving multiple teams or products. Specifically:
1. The product backlog is a prioritized list of desired functionality that provides a shared understanding of what to build. It consists of product backlog items like user stories.
2. A good backlog is detailed appropriately, emergent, estimated, and prioritized. Grooming involves refining, estimating, and prioritizing items through collaboration.
3. Backlog structures can be
Nguyen Vu Hung - Software Project Management with Jira AgileVu Hung Nguyen
Biography:
Nguyen Vu Hung is the CLO of Septeni Technology, a development center of Tokyo based Septeni Group that focuses on developing and operating, mostly, web-based online advertisement systems. He has numerous years of IT and software development, project/product management in both Japan and Vietnam. Considering himself as a FOSS and Agile evangelist and being a Agile lover and an CLO, he is also interested in not-so-related domains such as human resource management and (organization) (re)structuring. Hung is interested in: – Agile/Scrum and the alikes – Open Source – Project Management
Software project management with Jira Agile:
In this workshop, I will share hand-on experience on how using Jira Agile to manage project in Agile/Scrum ways. The workshop will guide you:
– How to create and manage your product backlog, sprints backlog using Confluence
– How to manage sprint backlog using Confluence, link it with JIRA
– How to manage daily tasks and stories in JIRA
– Using Scrum board, Epic
– Make Sprint report, Velocity chart
– Using Planning and Estimating
Goal of this session:
Master Scrum Artifacts using JIRA
References:
http://agiletourvietnam.org/speakers/
http://agiletourvietnam.org/speaker/nguyen-vu-hung/
http://agiletourvietnam.org/session/software-project-management-with-jira-agile/
This document provides an overview of agile, including:
- A brief history of agile originating from the Agile Manifesto in 2001 as an alternative to traditional waterfall approaches.
- The core principles of agile focus on valuing individuals and interactions, working software, customer collaboration, and responding to change.
- Common agile frameworks include Scrum, Kanban, and features iterative and incremental development approaches contrasted with traditional waterfall.
- While agile originated for software development, it is now widely used beyond just software and across many industries and organization types.
The document provides an overview of roles, artifacts, meetings, and processes in Scrum. The Scrum team is cross-functional and self-organizing. Artifacts include the Product Backlog, Sprint Backlog, and Burndown Chart. Meetings include Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The Product Owner prioritizes the Product Backlog and Scrum Master facilitates the team.
Estimating user stories is central to the Agile planning process. An estimate is a measure of the relative size, in terms of effort, of a story. These estimates help answer questions such as:
• How many stories can we fit into the release?
• How many stories will be completed in the next iteration?
• What are the impacts of adding, removing and changing stories?
What you’ll learn in this presentation:
• How estimates are used on Agile projects.
• How to define estimates.
• The basics of planning poker to help estimate.
The document discusses the different levels of planning in Agile development: release planning, iteration planning, and task planning. It provides details on each level, including who is involved, how to define a release plan, estimating velocity, common problems and solutions, and examples. The key aspects covered are the differences between releases and iterations, estimating at each level, and breaking down stories into tasks.
The Role of a BA on a Scrum Team IIBA Presentation 2010scrummasternz
What is your role as a BA on a Scrum team? How do you fit in? This presentation was given to the IIBA conference in NZ in 2010 by Stephen Reed. Stephen had worked extensively as a BA and moved into using Scrum with multiple teams at a large Insurance company. This experience led to a lot of questions around what the BA should be doing on a Scrum team. This presentation goes some way to listing what worked in the teams Stephen was involved in. The BA role does not change and all the skills of a great BA are necessary still on a great Software Development team, just more focused on being a team member and utilising those skills for the Scrum process of getting working software to the customer with more focus and clarity for the user.
Personally designed (content + graphics design), officially accredited AgilePgM® (Agile Programme Management) Foundation courseware.
AgilePgM® is a Registered Trade Mark of Dynamic Systems Development Method Limited.
Trademarks are properties of the holders, who are not affiliated with courseware author.
Increase productivity and improve the predictability of software projects. Interest in the Scrum Agile process framework is exploding as companies discover that Scrum enables them to manage software projects with greater reliability and improve responsiveness to customers. This class introduces the skills that project managers and team leaders need to perform the basic steps of a Scrum process for software development.
-Learn how Scrum practices relate to project management fundamentals
-Learn the essentials of Scrum as a software development process
-Learn the three Scrum roles, three Scrum meetings, and three Scrum artifacts
-Project Managers and team leads learn basic planning, tracking, and management skills
-Product Managers learn how to develop and prioritize requirements
-Team members learn how to estimate and break down work
Understanding the Agile Release and Sprint Planning Process John Derrico
The document discusses Agile planning processes. Release planning occurs before each release and involves the product owner, Scrum team, and stakeholders prioritizing features and setting release dates. Sprint planning occurs before each sprint and involves the Scrum team and product owner selecting stories for the sprint from the prioritized backlog, estimating work, and establishing a plan. The document provides details on participants, timing, objectives, inputs, and outputs for both release and sprint planning meetings in Agile. It also notes that estimations may be inaccurate initially but will improve over time as teams gain experience.
Personally designed, Professional Scrum Master (PSM-I) courseware.
Trademarks are properties of the holders, who are not affiliated with courseware author.
The ultimate presentation about Scrum, the world's leading project management framework for agile software development.
http://www.noop.nl
http://www.jurgenappelo.com
This document discusses common ways that teams implement Scrum but fail to fully realize its benefits, which it calls "ScrumButs". It provides examples of ScrumButs such as having daily standup meetings only weekly, using Scrum just because management requires it rather than for its values, and having separate testing/integration teams. The document urges teams to inspect why they use certain practices and adapt to better align with Scrum's principles of self-organization, lean thinking, and continuous improvement. It argues Scrum requires reflecting on its values and not just following practices mechanically.
This document outlines the step-by-step process for release planning. It involves bringing together the product owner, delivery team, and stakeholders to define the release theme, schedule, and backlog items. Key steps include sharing the vision and roadmap, discussing velocity and availability, mapping stories to iterations, reviewing dependencies and assumptions, and committing to the release plan and schedule. The output is an agreed upon release plan with its backlog items and timeline. Release planning in DevOps and SAFe frameworks follows a similar process but with shorter iterations in DevOps and programs/trains in SAFe.
Scrum planning poker, principles of the gameSid Dane
Planning poker is a consensus-based technique for estimating effort or relative size of development tasks. It involves the following key principles:
1. Accept uncertainty in software projects and use relative story point estimates rather than precise hours to account for intangible factors.
2. Estimates are derived through group discussion where estimators must justify their cards, leading to more accurate estimates that factor in an average of individual views.
3. The document outlines seven principles for effective planning poker, including keeping estimates at a granular level, focusing only on the current sprint without long-term planning, using a question mark card when more information is needed, and being willing to finalize estimates when consensus is reached.
This is a short introduction to the practice of Sprint Planning in Scrum. It would be useful for people new to Scrum or Agile. For more, comment or write to read my blog : http://agilediary.wordpress.com/
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
“It's better to be roughly right, than precisely wrong!”
~ John Maynard Keyenes
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
PROBLEMS WITH TIME-BASED ESTIMATES
-Teams spend too much time trying to get it right
-Lack of confidence/experience can lead to people being either optimistic or pessimistic
-Timeline you are estimating may be too far in the future
-Due to long timeline, there are too many risks, unknowns, changes or dependencies!
WHY USE RELATIVE ESTIMATION?
-Allows a quick comparison of stories in the backlog
-Allows you to select a predictable volume of work to do in a sprint
-Uses a simple arbitrary scale
-Allows PO to make trade-offs and take on the most valuable stories next
ESTIMATION TIPS
-Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
-The team estimates the story, not management nor the customer.
-Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
-Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
-Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
-Only pull into your sprint, stories that are refined and estimated.
-Break down stories that are large, into smaller slivers of value to optimize your flow.
-Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Planning Poker is a technique used to estimate effort for tasks in Agile software development. It involves each team member privately selecting a planning poker card representing their estimate for a task. The cards have Fibonacci numbers written on them. The cards are then revealed and discussed if estimates differ, until consensus is reached. Once estimates are established, the team's velocity (amount of work completed per sprint) can be used to predict future release dates. Planning Poker works well because it leverages the wisdom of crowds and averages individual estimates for more accurate results.
This document summarizes key aspects of product backlogs in Scrum projects. It discusses the importance of the product backlog, characteristics of a good backlog, and grooming activities. It also addresses questions around which and how many backlogs should exist for different project structures involving multiple teams or products. Specifically:
1. The product backlog is a prioritized list of desired functionality that provides a shared understanding of what to build. It consists of product backlog items like user stories.
2. A good backlog is detailed appropriately, emergent, estimated, and prioritized. Grooming involves refining, estimating, and prioritizing items through collaboration.
3. Backlog structures can be
Nguyen Vu Hung - Software Project Management with Jira AgileVu Hung Nguyen
Biography:
Nguyen Vu Hung is the CLO of Septeni Technology, a development center of Tokyo based Septeni Group that focuses on developing and operating, mostly, web-based online advertisement systems. He has numerous years of IT and software development, project/product management in both Japan and Vietnam. Considering himself as a FOSS and Agile evangelist and being a Agile lover and an CLO, he is also interested in not-so-related domains such as human resource management and (organization) (re)structuring. Hung is interested in: – Agile/Scrum and the alikes – Open Source – Project Management
Software project management with Jira Agile:
In this workshop, I will share hand-on experience on how using Jira Agile to manage project in Agile/Scrum ways. The workshop will guide you:
– How to create and manage your product backlog, sprints backlog using Confluence
– How to manage sprint backlog using Confluence, link it with JIRA
– How to manage daily tasks and stories in JIRA
– Using Scrum board, Epic
– Make Sprint report, Velocity chart
– Using Planning and Estimating
Goal of this session:
Master Scrum Artifacts using JIRA
References:
http://agiletourvietnam.org/speakers/
http://agiletourvietnam.org/speaker/nguyen-vu-hung/
http://agiletourvietnam.org/session/software-project-management-with-jira-agile/
This document provides an overview of agile, including:
- A brief history of agile originating from the Agile Manifesto in 2001 as an alternative to traditional waterfall approaches.
- The core principles of agile focus on valuing individuals and interactions, working software, customer collaboration, and responding to change.
- Common agile frameworks include Scrum, Kanban, and features iterative and incremental development approaches contrasted with traditional waterfall.
- While agile originated for software development, it is now widely used beyond just software and across many industries and organization types.
The document provides an overview of roles, artifacts, meetings, and processes in Scrum. The Scrum team is cross-functional and self-organizing. Artifacts include the Product Backlog, Sprint Backlog, and Burndown Chart. Meetings include Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The Product Owner prioritizes the Product Backlog and Scrum Master facilitates the team.
Estimating user stories is central to the Agile planning process. An estimate is a measure of the relative size, in terms of effort, of a story. These estimates help answer questions such as:
• How many stories can we fit into the release?
• How many stories will be completed in the next iteration?
• What are the impacts of adding, removing and changing stories?
What you’ll learn in this presentation:
• How estimates are used on Agile projects.
• How to define estimates.
• The basics of planning poker to help estimate.
The document discusses the different levels of planning in Agile development: release planning, iteration planning, and task planning. It provides details on each level, including who is involved, how to define a release plan, estimating velocity, common problems and solutions, and examples. The key aspects covered are the differences between releases and iterations, estimating at each level, and breaking down stories into tasks.
The Role of a BA on a Scrum Team IIBA Presentation 2010scrummasternz
What is your role as a BA on a Scrum team? How do you fit in? This presentation was given to the IIBA conference in NZ in 2010 by Stephen Reed. Stephen had worked extensively as a BA and moved into using Scrum with multiple teams at a large Insurance company. This experience led to a lot of questions around what the BA should be doing on a Scrum team. This presentation goes some way to listing what worked in the teams Stephen was involved in. The BA role does not change and all the skills of a great BA are necessary still on a great Software Development team, just more focused on being a team member and utilising those skills for the Scrum process of getting working software to the customer with more focus and clarity for the user.
Personally designed (content + graphics design), officially accredited AgilePgM® (Agile Programme Management) Foundation courseware.
AgilePgM® is a Registered Trade Mark of Dynamic Systems Development Method Limited.
Trademarks are properties of the holders, who are not affiliated with courseware author.
Increase productivity and improve the predictability of software projects. Interest in the Scrum Agile process framework is exploding as companies discover that Scrum enables them to manage software projects with greater reliability and improve responsiveness to customers. This class introduces the skills that project managers and team leaders need to perform the basic steps of a Scrum process for software development.
-Learn how Scrum practices relate to project management fundamentals
-Learn the essentials of Scrum as a software development process
-Learn the three Scrum roles, three Scrum meetings, and three Scrum artifacts
-Project Managers and team leads learn basic planning, tracking, and management skills
-Product Managers learn how to develop and prioritize requirements
-Team members learn how to estimate and break down work
Understanding the Agile Release and Sprint Planning Process John Derrico
The document discusses Agile planning processes. Release planning occurs before each release and involves the product owner, Scrum team, and stakeholders prioritizing features and setting release dates. Sprint planning occurs before each sprint and involves the Scrum team and product owner selecting stories for the sprint from the prioritized backlog, estimating work, and establishing a plan. The document provides details on participants, timing, objectives, inputs, and outputs for both release and sprint planning meetings in Agile. It also notes that estimations may be inaccurate initially but will improve over time as teams gain experience.
Personally designed, Professional Scrum Master (PSM-I) courseware.
Trademarks are properties of the holders, who are not affiliated with courseware author.
The ultimate presentation about Scrum, the world's leading project management framework for agile software development.
http://www.noop.nl
http://www.jurgenappelo.com
This document discusses common ways that teams implement Scrum but fail to fully realize its benefits, which it calls "ScrumButs". It provides examples of ScrumButs such as having daily standup meetings only weekly, using Scrum just because management requires it rather than for its values, and having separate testing/integration teams. The document urges teams to inspect why they use certain practices and adapt to better align with Scrum's principles of self-organization, lean thinking, and continuous improvement. It argues Scrum requires reflecting on its values and not just following practices mechanically.
The document discusses key concepts and practices in agile project management including scrum, kanban, lean product development, user stories, retrospectives, and more. It provides definitions and explanations of agile terms and methods. The document also lists several books related to agile project management that could provide further information on these topics.
This document provides an overview of Scrum, including its key roles, events, artifacts, and principles. Scrum is a framework for managing complex projects that require frequent collaboration and feedback. It uses short "sprints" to incrementally develop work into a potentially shippable product increment. The core Scrum roles are the Product Owner, who manages priorities and requirements, the Development Team, who do the work, and the Scrum Master, who facilitates the process. Events include Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective. Artifacts include the Product Backlog and Sprint Backlog. The goal is to continuously improve through transparency, inspection, and adaptation each sprint.
The document discusses whether agile will kill project management. It presents some key differences between traditional project management and agile approaches. While agile prioritizes adapting to change over stickling to a predefined plan, it does not eliminate project management but rather changes it. Agile still uses practices like planning at different levels from programs to sprints, but allows for more flexibility in scope to keep costs and time fixed. The document argues project managers still have an important role in agile, but with less command-and-control and more of a focus on leading and facilitating teams.
Is there a role for Project Managers and Business Analysts in Agile?allan kelly
The document discusses the roles of business analysts and project managers in agile development. It argues that business analysts can serve as product owners and help gather requirements between sprints. Project management as traditionally defined does not fit with agile, as agile focuses on ongoing development rather than finite projects. The role of managers in agile is to manage workflows, metrics, and people rather than projects, ensuring flow and eliminating non-beneficial work. Trust in employees and a theory y management style are important for agile.
Slides Chris Butler recently used in his discussion w/ mentees of The Product Mentor.
Synopsis: How do you know you (or someone you are managing) are a great product manager? How do you continuously push the quality of product work higher in your organization? How do you identify what is 'great' product work anyways? This talk will give methods to help product managers grow and be great. It will be helpful for people that are product manager managers today, those who want to be managers, and any product manager that wants to take their skills up a level.
The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…Better Decisions. Better Products. Better Product People.
Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.
http://TheProductMentor.com
This document provides an overview and agenda for a training on Scrum basics. It begins with an introduction section and then covers the fundamentals of Scrum over multiple sections. It includes details on roles like Product Owner and Scrum Master. There is a section on the Scrum process that outlines the sprint planning, daily standup, demo, and retrospective meetings. Other areas covered include prioritizing the product backlog, velocity, estimation techniques, and tips for running an effective retrospective. The training will conclude with a question and answer session.
The document describes an agile workout consisting of three exercises to demonstrate agile principles. The first exercise shows that individuals are more efficient completing one task at a time rather than multitasking. The second exercise demonstrates that reducing batch sizes decreases overall completion time. The third exercise finds that self-organizing teams perform better than manager-led teams at solving problems. The exercises are intended to help internalize agile concepts such as eliminating waste, rapid delivery, and self-organizing teams.
From different ways of working (or the same) to working in a Scrum team. What is so different? Is it better? Does it bring value to delivered software? What are the benefits found for the developer in the Scrum team, and what was missing in the previous experience? What are the challenges? What is the most important to be agile? What if the team is distributed? What about people? What was the biggest surprise for author?
This talk brings author’s experience in joining a Scrum team after several years of working in any other way (or maybe it was really the same way). Author brings his experience by challenging segments of software development through different ways of working.
The author brings his own view of different components of development, from technical and organizational to social.
In the technical part he analyzes version control and way of using it, technologies, CI/CD, while in organizational segment analyzes issue tracking, tasks progress tracking, meetings, etc.
The author also brings own experience regarding the social component, such as collaboration in the team and out of the team, people in the team, their mindset, collaboration with the customer, management’s impact to the team, level of trust, and Scrum process over all.
Agile Network India | Challenges with scrum, can Kanban be an alternative | O...AgileNetwork
This document discusses challenges with the Scrum framework and whether Kanban can be an alternative. It provides an overview of Scrum and Kanban, including their approaches to change management. Scrum uses a revolutionary approach, while Kanban takes an evolutionary one. Kanban aims for continuous flow without fixed sprints and focuses on limiting work in progress. The document suggests Kanban may be a better option than Scrum for organizations facing resistance to change or that cannot meet all of Scrum's requirements.
The team is not enough: a leap to become an Agile CoachCaio Cestari
Presented at Elabor8 Lunch 'n Learn Melbourne - March, 2017. Describes how I applied Lyssa's and Michael's framework to my own Agile Coach career, and how is a leap to become an Agile Coach
This document provides an introduction to Agile and Scrum. It discusses the principles of Agile, including the Agile Manifesto. Scrum is presented as an Agile framework consisting of roles, ceremonies, and artifacts. The roles of Product Owner, Scrum Master, and Engineering Team are defined. Ceremonies like Sprint Planning, Daily Scrum, Sprint Review and Retrospective are explained. Artifacts such as Product Backlog, Sprint Backlog and Burn Down Chart are also summarized. User stories, estimation techniques, and definitions of done are covered as part of requirements and planning in Scrum.
ESCE Marketing of the 21st century
Methodologies and patterns for structural innovation
How to mix Design Thinking, Lean Startup and Agile methods to respond to complex markets in an innovative and fun way
Class 1 : Agile methods
Class 2 : explore and define
Class 3 : create and prototype
Anti-patterns for not-so-smart processes: Avoiding the BPM and SOA pitfalls. A short presentation to focus your project on success - featuring the "magic progress fairy"
AGILE! Who cares - Tell me what to do @ADC2014Suman Guha
"AGILE! Who cares - Tell Me What To Do. " I presented this at Agile Day Conference 2014 in Pune, India http://www.agiledayconference.com/conference-in-pune
I bet you have encountered this title in your role (e.g. Agile Coach or Mentor) when helping teams in transitioning to Agile. So I did encounter this too and in one such discussion, Chris (Principal Architect) asked me to share my thoughts on handling a Scrum team who simply wanted to be “told what to do”. On the surface, this doesn't seem like such a bad thing. In fact, I’ll bet these folks are bright, capable and work very hard. So if there is an issue with this in agile teams, what is it? And why would it be a problem? Hence this session is about "Transitioning to Agile".
Titas Lapinskas - Technical Team Leader in AgileAgile Lietuva
This document discusses the role of a technical team leader in agile projects. It describes when Scrum works well for projects, such as those with stable teams developing codebases over many years. It also discusses when Scrum may not be suitable, like for short-term projects with fixed costs, schedules, and scopes. The technical team leader acts as a group player, specialist, and manager, providing technical leadership. Their responsibilities include infrastructure setup, prototyping, documentation, and code reviews when needed. The goal is to help the team grow their skills over time and avoid failures by preventing issues before they occur.
The document provides information about an Agile consultant named Anuj M Ojha. It includes details of his certifications and experience in Agile coaching and training over 13 years. It also lists some of the organizations he has worked with to help them implement Agile practices and deliver value through continuous improvement.
Carrer goals.pptx and their importance in real lifeartemacademy2
Career goals serve as a roadmap for individuals, guiding them toward achieving long-term professional aspirations and personal fulfillment. Establishing clear career goals enables professionals to focus their efforts on developing specific skills, gaining relevant experience, and making strategic decisions that align with their desired career trajectory. By setting both short-term and long-term objectives, individuals can systematically track their progress, make necessary adjustments, and stay motivated. Short-term goals often include acquiring new qualifications, mastering particular competencies, or securing a specific role, while long-term goals might encompass reaching executive positions, becoming industry experts, or launching entrepreneurial ventures.
Moreover, having well-defined career goals fosters a sense of purpose and direction, enhancing job satisfaction and overall productivity. It encourages continuous learning and adaptation, as professionals remain attuned to industry trends and evolving job market demands. Career goals also facilitate better time management and resource allocation, as individuals prioritize tasks and opportunities that advance their professional growth. In addition, articulating career goals can aid in networking and mentorship, as it allows individuals to communicate their aspirations clearly to potential mentors, colleagues, and employers, thereby opening doors to valuable guidance and support. Ultimately, career goals are integral to personal and professional development, driving individuals toward sustained success and fulfillment in their chosen fields.
Suzanne Lagerweij - Influence Without Power - Why Empathy is Your Best Friend...Suzanne Lagerweij
This is a workshop about communication and collaboration. We will experience how we can analyze the reasons for resistance to change (exercise 1) and practice how to improve our conversation style and be more in control and effective in the way we communicate (exercise 2).
This session will use Dave Gray’s Empathy Mapping, Argyris’ Ladder of Inference and The Four Rs from Agile Conversations (Squirrel and Fredrick).
Abstract:
Let’s talk about powerful conversations! We all know how to lead a constructive conversation, right? Then why is it so difficult to have those conversations with people at work, especially those in powerful positions that show resistance to change?
Learning to control and direct conversations takes understanding and practice.
We can combine our innate empathy with our analytical skills to gain a deeper understanding of complex situations at work. Join this session to learn how to prepare for difficult conversations and how to improve our agile conversations in order to be more influential without power. We will use Dave Gray’s Empathy Mapping, Argyris’ Ladder of Inference and The Four Rs from Agile Conversations (Squirrel and Fredrick).
In the session you will experience how preparing and reflecting on your conversation can help you be more influential at work. You will learn how to communicate more effectively with the people needed to achieve positive change. You will leave with a self-revised version of a difficult conversation and a practical model to use when you get back to work.
Come learn more on how to become a real influencer!
This presentation, created by Syed Faiz ul Hassan, explores the profound influence of media on public perception and behavior. It delves into the evolution of media from oral traditions to modern digital and social media platforms. Key topics include the role of media in information propagation, socialization, crisis awareness, globalization, and education. The presentation also examines media influence through agenda setting, propaganda, and manipulative techniques used by advertisers and marketers. Furthermore, it highlights the impact of surveillance enabled by media technologies on personal behavior and preferences. Through this comprehensive overview, the presentation aims to shed light on how media shapes collective consciousness and public opinion.
This presentation by Professor Alex Robson, Deputy Chair of Australia’s Productivity Commission, was made during the discussion “Competition and Regulation in Professions and Occupations” held at the 77th meeting of the OECD Working Party No. 2 on Competition and Regulation on 10 June 2024. More papers and presentations on the topic can be found at oe.cd/crps.
This presentation was uploaded with the author’s consent.
XP 2024 presentation: A New Look to Leadershipsamililja
Presentation slides from XP2024 conference, Bolzano IT. The slides describe a new view to leadership and combines it with anthro-complexity (aka cynefin).
This presentation by OECD, OECD Secretariat, was made during the discussion “Competition and Regulation in Professions and Occupations” held at the 77th meeting of the OECD Working Party No. 2 on Competition and Regulation on 10 June 2024. More papers and presentations on the topic can be found at oe.cd/crps.
This presentation was uploaded with the author’s consent.
Collapsing Narratives: Exploring Non-Linearity • a micro report by Rosie WellsRosie Wells
Insight: In a landscape where traditional narrative structures are giving way to fragmented and non-linear forms of storytelling, there lies immense potential for creativity and exploration.
'Collapsing Narratives: Exploring Non-Linearity' is a micro report from Rosie Wells.
Rosie Wells is an Arts & Cultural Strategist uniquely positioned at the intersection of grassroots and mainstream storytelling.
Their work is focused on developing meaningful and lasting connections that can drive social change.
Please download this presentation to enjoy the hyperlinks!
Mastering the Concepts Tested in the Databricks Certified Data Engineer Assoc...SkillCertProExams
• For a full set of 760+ questions. Go to
https://skillcertpro.com/product/databricks-certified-data-engineer-associate-exam-questions/
• SkillCertPro offers detailed explanations to each question which helps to understand the concepts better.
• It is recommended to score above 85% in SkillCertPro exams before attempting a real exam.
• SkillCertPro updates exam questions every 2 weeks.
• You will get life time access and life time free updates
• SkillCertPro assures 100% pass guarantee in first attempt.
1. Scrum as an Agile Project & Requirements
Management Framework
July 22, 2015
Roland Petrasch
2. Scrum as an Agile Project & Requirements
Management Framework
● Agenda
● Project Management
● Classical Project Management and Scrum
● Project Management: Power Structure
● Scrum: To do, or not to do ...
● Scrum Process: How it begins
Karl talks about „Scrum and BPM“
}20 min.
Goals:
Shake you up with nice colors,
initiate the Scrum discussion,
prepare for Karl's talk
3. Project Management
● Project (Management): It's (not only) about time ...
... but too late still means: you failed
4. Project Management
● Project management (even with Scrum)
● Is a task that lasts from set-up until finishing
● Consists of
– Planing (planned tasks, resources, cost))
– Monitoring (comparison: planned / actual values)
– Control (measures to stay on track)
● Aspects: accounting, leadership, collaboration,
knowledge, structuring, socializing ...
I've read the textbook
Questions: „When did our project started
and when will it end? What are the goals?
Where are the requirements?“
No start, no end, no goals?
No project!
5. Classical Project Management and Scrum
● Classic Project Management and Scrum:
Same same or different? Or: Same same, but different ...
Development
Team
Team
Project
Manager
Scrum
Master
Requirements
Engineer
Product
Owner
SRS
Product
Backlog
Project
Plan
Burndown
Chart
Sure, it's about Project Management
But: VERY BIG differences
6. Classical Project Management and Scrum
● So what are the main differences?
● Scrum means a different power structure (not top-down)
● Team is a (relatively) autonomous entity (resource planning)
● Responsibility is shared (Product Owner, Team, Scrum Master)
● Strong “connection” to software product (deliverables) →
Integrated requirements management
● Agile Manifesto (agilemanifesto.org), e.g.
Individuals and interactions over processes and tools
Scrum (→ abr. of scrummage)
used in Rugby;
meaning: disorderly struggle
Anyone who has never made a
mistake has never tried anything new.
Albert Einstein
7. Classical Project Management and Scrum
● Sport, e.g. soccer
● Team (not the coach) plays
90 min. (autonomy)
● Single player has
responsibility, but team wins
or loses
● Coach gives orders ...
but not every single minute
● Strategy / tactics clear
before (!) the game starts,
but can change on-demand
and spontaneously
Player 18:
step aside!
Player 19:
kick now!
Player 17:
jump to the left!
8. Classical Project Management and Scrum
● Classical Project Management
● Project Manager:
– authority to give directives
– responsible for the team
– plan, monitor, control
● Team member
– responsible for own work
– follow the plan
– execute directives
9. Project Management: Power Structure
● Classical organizational structure
● Pyramids or hierarchies
(with a leader / manager and
people who support him/her and obey)
● Leadership →
the right to command and enforce,
administration of resources (responsibility):
plan, monitor, control
● Team member → only responsible
for own work, a resource with assigned
tasks and a workload (PM view)
PM
Team members
10. Project Management: Power Structure
● Agile means different power structure(s)
● Team is (more) autonomous (→ committee)
● Self-managing / -organizing (Scrum Master is responsible for
process) → Lean management
● Team member: responsible for work of all team members
● Product Owner has to negotiate with the team, can't give
orders
Team
Product Owner
11. Project Management: Power Structure
● Consequences for middle and upper management
● Lack of project manager = less control over single team
member (“Who is doing what, where and when?”)
● Planning is not “top-down” → negotiation with team
● Team is “creating” its own development process
● Management loses power
● Question:
– Really no need for leader / manager for team?
– Does it work under all conditions?
12. Scrum: To do, or not to do ...
● Really no need for leader / manager for team?
● Wrong question
● One word to leadership and management
● Leadership: "ability to create a solid vision of a better future
for those people he/she is leading" [Buckingham, 2005]
● Management: "ability to match people’s tasks with their
skills" [Buckingham, 2005]
● Scrum projects need leadership
... not (many) managers
13. Scrum: To do, or not to do ...
● Does it work under all conditions?
● No.
● Some aspects
– Mixture between experienced and young professionals
– Awareness of team responsibility,
no obedient little workers or hackers
– Ability to communicate often, openly and constructively
– Willingness to improve (own) behavior and processes
– Need for proper requirements understood
– Start with a real project: real start, real end, real users,
real goals, real requirements
14. Scrum: To do, or not to do ...
● Scrum is a framework: modifications, extensions,
combintations ... are welcome
● Scrum has many colors – go and find your color combination
15. Scrum Project: How it begins
● Where to start?
● Product Backlog Items are requirements,
but where do they come from? Product Owner knows it ...
Product
Backlog
Sprint
Backlog
Sprint
(Iteration)
Product
Requirements
Output
Intput
?
Requirements are specified during the project, but ...
16. Scrum Process: How it begins
● BPM and Software Development
● Sometimes it's a good idea
– to analyze or optimize processes first and (maybe)
– then develop or introduce software (if necessary)
Product
Backlog
Business Process (Re-)Engineering
Project
Product
Business
Needs or
Process
Backlog
Business
Processes,
Data Model
Software Engineering / Development
Project
17. On the right path
To be continued:
Karl Schindler talks about „Scrum for Business
Process Reengineering Projects“