Transitioning to Scrum is not easy, and for many, distributed teams are the most difficult to manage. In trying to make Scrum work with a geographically dispersed team, increasing efficiency requires adjustments to processes and effective communication and collaboration.
This webinar will provide guidance for proper planning and managing, in order to get your distributed teams working smoothly throughout the scrum processes. Dr. Kevin Thompson, cPrime’s Agile Practice Lead, will address key issues such as:
• How to have scrum meetings for distributed teams (daily scrum, sprint planning, sprint review, retrospective)
• How to cope with time-zone differences
• How to cope with language differences
• Best practices for collaborating in a distributed team
• Best practices for tools that mitigate distributed team impact
An overview of the Agile Manifesto and the principles and practices that define Agile software development. A comparison of Agile Development methodologies and an organisational culture that supports them
An overview of the Agile Manifesto and the principles and practices that define Agile software development. A comparison of Agile Development methodologies and an organisational culture that supports them
Discover 12 principles for Agile Development created by @liquidconcept.
Liquid Concept is a swiss interactive communications agency. We share the values of our international clients: quality, user-friendliness, clarity and attention to detail
Executive Presentation on Agile Project Management by Boardroom Metrics Inc.Boardroom Metrics
This presentation was delivered to a group of senior executives with little or no understanding of Agile methodologies. It was an eye-opening experience!
If interested, please reach out to our firm to discuss how we can help your organization: 1.416.994.6552 or info@boardroommetrics.com
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
Module 1. Born to fail
- Why projects are failing
- Waterfall & traditional software development
Module 2. Agile
Module 3. Scrum
Module 4. Writing high quality software with Agile
- XP
- How Google Write Software
Module 5. Do's and dont's
- How Scrum might fail
- Myths and realities
Module 6. How to kick off Scrum
Kanban was originally created as a scheduling system to help manufacturing organizations determine what to produce, when to produce it, and how much to produce. Although this may not sound like software development, these lean principles can be successfully applied to development teams to improve the delivery of value through better visibility and limits on work in process.
This webinar will provide an overview of the Kanban method, including the history and motivation, the core principles and practices, and how these apply to efficiency and process improvement in software development. We’ll also describe how Team Foundation Server can be used as a foundation for your work visualization and work flow management. Come join us for this free Webinar!
Introduction to Agile Project Management and ScrumVoximate
Brief introduction to Agile Project Management and Scrum covering user stories, story points, use of Fibonacci sequence values for story points, release planning, sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts. Explains the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic. Summarizes the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work). Discusses values and best practices in Agile/Extreme Programming ("XP") values. Explains daily standup meeting in which people share what they did yesterday, what they're doing today, and any blocking issues they're encountering. Summarizes common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch. Summaries problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers.
Ik gebruik deze checklist zelf als Scrum coach. De mindmap bevat een samenvatting van alle waarden rondom Scrum.
Door op deze waarden te letten, naast het eenvoudig kijken naar de "mechanica" van Scrum, ontstaat er een veel betere Scrum implementatie. Zo wordt Scrum "naar de geest" toegepast.
Business Case for Agile - Time for ROI CheckTathagat Varma
When we talk of agility, we often refer to number of user stories or story points delivered, or burn down charts or velocity, etc. I call them 'lower-order agility' and howsomuch interesting they are, they make no sense to the 'higher-order agility' at business level. Why is that outrageous claims of performance, productivity and quality improvements at lower-order agility don't translate to commensurate higher-order agility? In this talk, I explore some of these issues. I also propose some ideas on how the whole notion of portfolio planning should be seen in the context of higher-order agility.
I delivered this talk on 19 July 2012 at the launch of Agile Leadership Network, Bangalore chapter, hosed by Valtech at their office.
Discover 12 principles for Agile Development created by @liquidconcept.
Liquid Concept is a swiss interactive communications agency. We share the values of our international clients: quality, user-friendliness, clarity and attention to detail
Executive Presentation on Agile Project Management by Boardroom Metrics Inc.Boardroom Metrics
This presentation was delivered to a group of senior executives with little or no understanding of Agile methodologies. It was an eye-opening experience!
If interested, please reach out to our firm to discuss how we can help your organization: 1.416.994.6552 or info@boardroommetrics.com
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
Module 1. Born to fail
- Why projects are failing
- Waterfall & traditional software development
Module 2. Agile
Module 3. Scrum
Module 4. Writing high quality software with Agile
- XP
- How Google Write Software
Module 5. Do's and dont's
- How Scrum might fail
- Myths and realities
Module 6. How to kick off Scrum
Kanban was originally created as a scheduling system to help manufacturing organizations determine what to produce, when to produce it, and how much to produce. Although this may not sound like software development, these lean principles can be successfully applied to development teams to improve the delivery of value through better visibility and limits on work in process.
This webinar will provide an overview of the Kanban method, including the history and motivation, the core principles and practices, and how these apply to efficiency and process improvement in software development. We’ll also describe how Team Foundation Server can be used as a foundation for your work visualization and work flow management. Come join us for this free Webinar!
Introduction to Agile Project Management and ScrumVoximate
Brief introduction to Agile Project Management and Scrum covering user stories, story points, use of Fibonacci sequence values for story points, release planning, sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts. Explains the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic. Summarizes the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work). Discusses values and best practices in Agile/Extreme Programming ("XP") values. Explains daily standup meeting in which people share what they did yesterday, what they're doing today, and any blocking issues they're encountering. Summarizes common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch. Summaries problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers.
Ik gebruik deze checklist zelf als Scrum coach. De mindmap bevat een samenvatting van alle waarden rondom Scrum.
Door op deze waarden te letten, naast het eenvoudig kijken naar de "mechanica" van Scrum, ontstaat er een veel betere Scrum implementatie. Zo wordt Scrum "naar de geest" toegepast.
Business Case for Agile - Time for ROI CheckTathagat Varma
When we talk of agility, we often refer to number of user stories or story points delivered, or burn down charts or velocity, etc. I call them 'lower-order agility' and howsomuch interesting they are, they make no sense to the 'higher-order agility' at business level. Why is that outrageous claims of performance, productivity and quality improvements at lower-order agility don't translate to commensurate higher-order agility? In this talk, I explore some of these issues. I also propose some ideas on how the whole notion of portfolio planning should be seen in the context of higher-order agility.
I delivered this talk on 19 July 2012 at the launch of Agile Leadership Network, Bangalore chapter, hosed by Valtech at their office.
This is a template for a slide deck I use to guide/facilitate my Scrum Teams through Sprint Review (Demo and Retrospective) and Sprint Planning sessions.
Agile Project Management with Kanban (4 Nov 2015)Mai Quay
Agile Project Management with Lean & Kanban, given at Lean Kanban Singapore on 3 November 2015 and the Institute of Systems Science of the National University of Singapore on 4 November 2015
Our social lives lend themselves to efficient collection of information, shares and broadcast irrelevances. A modernity driven by a real time marinade of electronic information.
I suggest that we live in anticipation of the arrival of information. Work and social divergences have become accelerated, which has created nostalgia for previous unhurried social situations... In short a new social sensibility.
Final report for the EPSRC Research Cluster, 2009. Details 'community' awareness of user-generated content, social media, location-aware social sorting and introduces construct of the Productive Consumer.
A research *snap-shot* of our new paper 'Talking about Escape'. We introduce how escape is talked about in everyday contexts and interaction – where we overhear individual’s widespread and routine discussion of escape and escaping.
Overview of agile values
This presentation shows some core concepts that make agile software development different.
This will help your team familiar with agile concepts and start boosting your team performance.
From Waterfall to Agile - from predictive to adaptive methodsBjörn Jónsson
In this introduction into Agile methods, the background and environment of Software Development is discussed. Results of the 1995 Chaos report are mentioned, as well as interests in adaptive "lightweight" methods. Agile methods are explained in general and Scrum method taken as a concrete sample.
Agile development poses several challenges to effectively testing software. Many myths have become "common wisdom" about how testing is much more difficult, even impossible, in an agile environment. Aricent's software testing experts look at 7 of these myths, and based on their years of experience debunk them.
Agile Certification Professional (PMI-ACP) Certification is the most coveted agile certification for project managers offered by the reputed PMI Institute. PMI-ACP certification is globally acknowledged and is valid across industries. Prepare for PMP exam with Simplilearn and make us a part of your success story. Simplilearn brings to you online PMI-ACP exam prep course that gives you the liberty to study at your pace and from your own place. This PMI-ACP presentation provides you a complete overview of basics of agile certification. Each slide covers PMI-ACP topics based on PMI-ACP exam syllabus and is prepared by our certified agile practitioners who have years of experience in agile environment. Get an understanding of PMI-ACP framework, agile methodologies, agile principles and its implementations in various projects. Cited examples and practice questions based on agile course and industry specific subjects provide better insights on each topic improving your confidence and knowledge towards attaining the agile certification goal.
cPrime's latest Agile Meetup discussion will center around methods for how to monitor and validate the performance of agile.
Many firms that have been doing agile can not determine how or if it has had an impact on the company. Agile expert, Jeff Howey will discuss ways to evaluate agile performance. Join our webinar to learn how to identify the benefits of agile and uncover the differences between companies that exhibit "agile-like" behavior and highly functioning teams.
Join us for a highly interactive and customized Agile Webinar that will uncover the most prominent, common and troubling roadblocks experienced by organizations trying to adopt agile and will offer solutions to overcome these obstructions!
Broadcasted: June 15th, 2012 by Jeff Howey, cPrime Agile Coach
To view this live webinar visit: http://cprime.eleapcourses.com/
For more information on Agile & cPrime visit: www.cprime.com
What have you heard about Agile? Trying to decide if Scrum or Kanban is a better approach for your particular team? Are you asking yourself if functions outside of Application Development, such as Marketing, Ux Design, Infrastructure, benefit from Agile techniques? Do you want to know some basic, but powerful, concepts to approaching your release cycle? Do you have complex dependencies or fit in a non-agile PMO environment but want to be agile?
If you answered yes to any of these questions, join us for a webinar walking through these key concepts:
· Agile is not just a framework for software development, it is a way of thinking that can span the business
· Agile gives a more clearly understood measure of progress than traditional Status Reports or Project Plans
· Agile can be done within structured, well-defined PMO processes
· Agile improves the ability to manage Customer and Stakeholder Expectations
We will also discuss some high-level similarities and differences between Scrum and Kanban along with recommendations to incorporate both into your overall strategy, even when your enterprise-at-large needs to continue some projects using a traditional plan-driven approach.
Watch the recorded version of this Webinar here:
Curious about Continuous Integration? Tune in!
Continuous Integration (CI), which is a big part of continuous delivery, is the concept of continuously building and testing software using an automated process. We have learned that utilizing CI could help us catch bugs earlier, enable better visibility, reduce repetitive processes, enable the development team to produce deployable products at a moment's notice, and reduce risk overall.
These slides will identify the various levels of continuous integration and delivery with regards to a release maturity of the development team or parent organization.
Advocates of agile development claim that agile software projects succeed more often than plan-driven projects. Unfortunately, attempts to validate this claim statistically are problematic, because "success" is not defined consistently across studies. This paper addresses the question through a mathematical analysis of these projects. We model agile and plan-driven software projects with identical requirements, and show how they are affected by the same set of unanticipated problems. We find that that the agile project provides clear benefits for return-on-investment and risk reduction, compared to the plan-driven project, when uncertainty is high. When uncertainty is low, plan-driven projects are more cost-effective.
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
More from cPrime | Project Management | Agile | Consulting | Staffing | Training (10)
Introduction to AI for Nonprofits with Tapp NetworkTechSoup
Dive into the world of AI! Experts Jon Hill and Tareq Monaur will guide you through AI's role in enhancing nonprofit websites and basic marketing strategies, making it easy to understand and apply.
Model Attribute Check Company Auto PropertyCeline George
In Odoo, the multi-company feature allows you to manage multiple companies within a single Odoo database instance. Each company can have its own configurations while still sharing common resources such as products, customers, and suppliers.
Macroeconomics- Movie Location
This will be used as part of your Personal Professional Portfolio once graded.
Objective:
Prepare a presentation or a paper using research, basic comparative analysis, data organization and application of economic information. You will make an informed assessment of an economic climate outside of the United States to accomplish an entertainment industry objective.
June 3, 2024 Anti-Semitism Letter Sent to MIT President Kornbluth and MIT Cor...Levi Shapiro
Letter from the Congress of the United States regarding Anti-Semitism sent June 3rd to MIT President Sally Kornbluth, MIT Corp Chair, Mark Gorenberg
Dear Dr. Kornbluth and Mr. Gorenberg,
The US House of Representatives is deeply concerned by ongoing and pervasive acts of antisemitic
harassment and intimidation at the Massachusetts Institute of Technology (MIT). Failing to act decisively to ensure a safe learning environment for all students would be a grave dereliction of your responsibilities as President of MIT and Chair of the MIT Corporation.
This Congress will not stand idly by and allow an environment hostile to Jewish students to persist. The House believes that your institution is in violation of Title VI of the Civil Rights Act, and the inability or
unwillingness to rectify this violation through action requires accountability.
Postsecondary education is a unique opportunity for students to learn and have their ideas and beliefs challenged. However, universities receiving hundreds of millions of federal funds annually have denied
students that opportunity and have been hijacked to become venues for the promotion of terrorism, antisemitic harassment and intimidation, unlawful encampments, and in some cases, assaults and riots.
The House of Representatives will not countenance the use of federal funds to indoctrinate students into hateful, antisemitic, anti-American supporters of terrorism. Investigations into campus antisemitism by the Committee on Education and the Workforce and the Committee on Ways and Means have been expanded into a Congress-wide probe across all relevant jurisdictions to address this national crisis. The undersigned Committees will conduct oversight into the use of federal funds at MIT and its learning environment under authorities granted to each Committee.
• The Committee on Education and the Workforce has been investigating your institution since December 7, 2023. The Committee has broad jurisdiction over postsecondary education, including its compliance with Title VI of the Civil Rights Act, campus safety concerns over disruptions to the learning environment, and the awarding of federal student aid under the Higher Education Act.
• The Committee on Oversight and Accountability is investigating the sources of funding and other support flowing to groups espousing pro-Hamas propaganda and engaged in antisemitic harassment and intimidation of students. The Committee on Oversight and Accountability is the principal oversight committee of the US House of Representatives and has broad authority to investigate “any matter” at “any time” under House Rule X.
• The Committee on Ways and Means has been investigating several universities since November 15, 2023, when the Committee held a hearing entitled From Ivory Towers to Dark Corners: Investigating the Nexus Between Antisemitism, Tax-Exempt Universities, and Terror Financing. The Committee followed the hearing with letters to those institutions on January 10, 202
The Roman Empire A Historical Colossus.pdfkaushalkr1407
The Roman Empire, a vast and enduring power, stands as one of history's most remarkable civilizations, leaving an indelible imprint on the world. It emerged from the Roman Republic, transitioning into an imperial powerhouse under the leadership of Augustus Caesar in 27 BCE. This transformation marked the beginning of an era defined by unprecedented territorial expansion, architectural marvels, and profound cultural influence.
The empire's roots lie in the city of Rome, founded, according to legend, by Romulus in 753 BCE. Over centuries, Rome evolved from a small settlement to a formidable republic, characterized by a complex political system with elected officials and checks on power. However, internal strife, class conflicts, and military ambitions paved the way for the end of the Republic. Julius Caesar’s dictatorship and subsequent assassination in 44 BCE created a power vacuum, leading to a civil war. Octavian, later Augustus, emerged victorious, heralding the Roman Empire’s birth.
Under Augustus, the empire experienced the Pax Romana, a 200-year period of relative peace and stability. Augustus reformed the military, established efficient administrative systems, and initiated grand construction projects. The empire's borders expanded, encompassing territories from Britain to Egypt and from Spain to the Euphrates. Roman legions, renowned for their discipline and engineering prowess, secured and maintained these vast territories, building roads, fortifications, and cities that facilitated control and integration.
The Roman Empire’s society was hierarchical, with a rigid class system. At the top were the patricians, wealthy elites who held significant political power. Below them were the plebeians, free citizens with limited political influence, and the vast numbers of slaves who formed the backbone of the economy. The family unit was central, governed by the paterfamilias, the male head who held absolute authority.
Culturally, the Romans were eclectic, absorbing and adapting elements from the civilizations they encountered, particularly the Greeks. Roman art, literature, and philosophy reflected this synthesis, creating a rich cultural tapestry. Latin, the Roman language, became the lingua franca of the Western world, influencing numerous modern languages.
Roman architecture and engineering achievements were monumental. They perfected the arch, vault, and dome, constructing enduring structures like the Colosseum, Pantheon, and aqueducts. These engineering marvels not only showcased Roman ingenuity but also served practical purposes, from public entertainment to water supply.
Honest Reviews of Tim Han LMA Course Program.pptxtimhan337
Personal development courses are widely available today, with each one promising life-changing outcomes. Tim Han’s Life Mastery Achievers (LMA) Course has drawn a lot of interest. In addition to offering my frank assessment of Success Insider’s LMA Course, this piece examines the course’s effects via a variety of Tim Han LMA course reviews and Success Insider comments.
Unit 8 - Information and Communication Technology (Paper I).pdfThiyagu K
This slides describes the basic concepts of ICT, basics of Email, Emerging Technology and Digital Initiatives in Education. This presentations aligns with the UGC Paper I syllabus.
Biological screening of herbal drugs: Introduction and Need for
Phyto-Pharmacological Screening, New Strategies for evaluating
Natural Products, In vitro evaluation techniques for Antioxidants, Antimicrobial and Anticancer drugs. In vivo evaluation techniques
for Anti-inflammatory, Antiulcer, Anticancer, Wound healing, Antidiabetic, Hepatoprotective, Cardio protective, Diuretics and
Antifertility, Toxicity studies as per OECD guidelines
1. Managing Distributed Teams
Instructor: Kevin Thompson, Ph.D., PMP, ACP, CSP
4100 E. Third Ave, Suite 205, Foster City, CA 94404 | 650-931-1651 | www.cprime.com
The leader in training and consulting for project management and agile development
2. What is an Agile Process?
In principle:
Any process that adheres to the principles
of the Agile Manifesto
“We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.”
Manifesto for Agile Software Development, www.agilemanifesto.org
The concepts arose in software project management, BUT…
Change “software” to “products” or “deliverables” to apply more generally
Copyright 2011, cPrime Inc.
2
3. Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10.Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Copyright 2011, cPrime Inc.
3
4. Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10.Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Copyright 2011, cPrime Inc.
4
5. Adaptive Spectrum Drives Process Selection
All processes have their “sweet spots”
Based on scope, effort uncertainty
PREDICTIVE REACTIVE
Predictive Predictive Adaptive Reactive
Processes Plan-Driven Scrum Kanban
Waterfall XP
• Emphasize
SDLC CBPM The Agile Zone
Efficiency
• Perform poorly Adaptive processes Reactive processes
when
uncertainty • Emphasize adaptability to • Don’t require planning
is high rapid change • Handle unpredictable work
• Enable detailed planning well
Copyright 2011, cPrime Inc.
5
6. Feedback Loops are Critical for
Agile Processes
Copyright 2011, cPrime Inc.
6
7. What Processes are Agile?
In practice, these: In practice, not these:
• Scrum • Waterfall
• Extreme Programming (XP) • Software Development
• Kanban Lifecycle (SDLC)
• Commitment-Based Project • Rational Unified Process
Management (CBPM) (RUP)
• Others • Information Technology
DSDM, FDD, Crystal Infrastructure Library (ITIL)
Is PMBOK Agile?
Could be: It’s a collection of practices (tools & techniques),
not a process definition
Not necessarily: Contains no explicitly agile content (up
through V4)
Copyright 2011, cPrime Inc.
7
8. Three Views of How Work Gets Done
• Plan-Driven
• Often phase-oriented, delivers results at the end
SDLC, Waterfall, RUP, PERT, Critical Chain, Prince2
• Agile with Planning
• Planning and execution are epicyclic, repeated at different
scales for nested time horizons
Scrum, XP, CBPM
• Agile without Planning
• Processes unpredictable requests efficiently, for types of work
where planning is not possible or required
Kanban
8
Copyright 2011, cPrime Inc.
9. Linear Plan-Driven: Project Lifecycle
Initiating Closing
Processes Processes
define, deliver,
authorize Planning & Executing review, shut
initial scope Processes alternate to down
completion
Copyright 2011, cPrime Inc.
9
10. Agile with Planning: Project Lifecycle
Inception Termination
phase phase shuts
prepares for down
start of Scrum
process Implementation phase plans,
executes, and delivers for multiple
time scales
Copyright 2011, cPrime Inc.
10
11. Unplanned Agile Project: Kanban Lifecycle
Work items arrive in a
steady stream, are
prioritized daily
Kanban
(Signboard):
Literally, a signal
indicating that an
action should be
performed
Copyright 2011, cPrime Inc.
11
12. Agile Essentials
Adaptability
• Expects the
unexpected and
adjusts gracefully
• “Inspect and
Adapt”
Collaboration
• Team members
self-organize
Members define,
allocate tasks
Continuous Improvement
• Self improvement through reflection, learning from past experience
• Stable Team membership increases domain knowledge and
productivity over time
12
Copyright 2011, cPrime Inc.
13. Scrum: Our Reference Process
Scrum
• Arose in software engineering
• Not tied to any subject domain
• Planning is iterative
• Execution is iterative
Copyright 2011, cPrime Inc.
13
14. Select Process: Scrum Summary
Product Owner provides ranked requirements, as short
narrative descriptions (“Stories”), or bug-fix requests. Set
of unscheduled requirements is the “Product Backlog.”
Each requirement is a Product Backlog Item (PBI).
Small Teams (3—9 people) work in short “Sprints” (2—4
weeks) to implement stories in rank order.
• Requirements frozen when Sprint starts—no change requests allowed!
Teams self-organize to best apply member skill sets (coding,
test development, testing, etc.).
• ScrumMaster does not assign tasks
• SM focuses on planning, tracking, mentoring, and issue resolution
Schedule rules: Don’t extend Sprint to finish incomplete
Stories
14
Copyright 2011, cPrime Inc.
15. The Defining Characteristics of Scrum
• Three roles Three artifacts
• Team • Product Backlog
• ScrumMaster • Sprint Backlog
• Product Owner • Burndown chart
Five Time Boxes
• Sprint
• Sprint Planning
• Daily Scrum Meeting
• Sprint Review (Demo) Meeting
• Retrospective Meeting
Copyright 2011, cPrime Inc. 15
16. The Time Boxes of Scrum
Sprint Planning Meeting: < 8 hrs
Plan work to be done in Sprint
Sprint:
2—4 weeks Daily Stand-Up Meeting: 15 min
Review status and issues
Implement
requirements
in rank order Sprint Review Meeting: 1 hour
Product Owner reviews deliverables
Retrospective Meeting: 1 hour
Learn from experience
Copyright 2011, cPrime Inc. 16
18. Sprint (Each Day’s Major Activities)
Purpose: Implement PBIs in Sprint Backlog
• ScrumMaster monitors work, facilitates issue resolution
• Team members swarm to implement PBIs in rank order
• Ask Product Owner to clarify requirements
• Ask ScrumMaster to resolve issues the Team cannot resolve
• Team members update status of each task
• On starting, finishing, revising “to-do” effort, …
• Team members don’t start PBIs they can’t finish in Sprint
• Maintain discipline of finishing what is started!
18
Copyright 2011, cPrime Inc.
19. Sprint Planning Meeting
Purpose: Assign PBIs to Sprint Backlog
• ScrumMaster facilitates, enforces selected time box
• E.g., 1 hour, if Team has reviewed PBIs carefully in advance
Agenda
• For each Product Backlog Item (PBI), in rank order
1. ScrumMaster reads PBI to Team
2. Team discusses, asks Product Owner to clarify details
3. ScrumMaster facilitates & records Planning Poker estimation
4. ScrumMaster adds PBI to Sprint Backlog
5. Planning is finished when Sprint Backlog is filled to capacity
After:
• Team creates Task Breakdowns for Sprint Backlog items
Revise scope of Sprint Backlog based on Task estimates
19
Copyright 2011, cPrime Inc.
20. Daily Scrum Meeting
Purpose: Promote common understanding of Sprint status,
and identify issues to be resolved
• ScrumMaster facilitates, enforces 15-minute time box
• Team members, ScrumMaster, Product Owner attend
Agenda
1. ScrumMaster shows burndown chart, describes progress
2. Each Team member describes
What I’ve done since the last Daily Stand-Up meeting
What I plan to do before the next Daily Stand-Up meeting
What issues I’m facing that I need help to resolve
In meeting:
• Decide who will collaborate to resolve each issue after the
meeting (“sidebar discussions”)
20
Copyright 2011, cPrime Inc.
21. Sprint Review Meeting
• Purpose: Confirm acceptability of implementations
• ScrumMaster facilitates, enforces selected time box
Agenda
1. Team demonstrates finished PBIs to the Product Owner
• Team members decide who will do the demonstrations.
One person does all; round-robin style; etc.
2. Product Owner provides final decision on whether
implementations are acceptable for release
• If not, then they are not released
Should be rare, since PO monitors & evaluates throughout Sprint.
After:
• Product Owner writes Stories for changes to implementations
21
Copyright 2011, cPrime Inc.
22. Retrospective Meeting
Purpose: Learn from experience, and improve
• ScrumMaster facilitates, records, enforces time box
• Say, 60 minutes total: 30 for recording, 30 for discussion
Agenda
1. Review status of work items from previous Retrospective
2. Team members, Product Owner, ScrumMaster answer
What went well, that we should do again?
What needs improvement?
What specific improvements should we make?
3. Specify follow-up actions
1. Prioritize improvements
2. Select top few to address
3. Select owners to drive improvements
22
Copyright 2011, cPrime Inc.
23. Agile Collaboration by Swarming
How many people can work
on Story #1?
They swarm on #1.
How many people can work
on Story #2?
They swarm on #2.
How many people can …
Copyright 2011, cPrime Inc.
23
24. Agile Manifesto Principles Affected by Geographic
Distribution
Business people and developers must work together
daily throughout the project.
The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
Copyright 2011, cPrime Inc. 24
25. Why Co-Location is Preferred
• Members work together easily throughout day
• Proximity encourages interaction
• Information propagates rapidly
• Communication is Osmotic
• Members absorb information from questions, answers in
background
• Members can chime in if they have something to contribute
• Agile projects favor in-person communication over
documentation
• Co-location encourages and enables good communication
• Distribution impairs it, requires more documentation
25
Copyright 2011, cPrime Inc.
26. Distributed Teams: Best Case
• Scrum Teams are
distributed
• Scrum Team members
are co-located per Team
• Compared to total co-
location
• Intra-Team communication
is the same
• Cross-Team
communication somewhat
more difficult, but not hard
• Cross-Team work synced
via “Scrum of Scrums”
meetings
26
Copyright 2011, cPrime Inc.
27. How to Implement Cross-Team Requirements
• Synchronize with “Scrum of Scrums” meetings
• Purpose: Identify & address cross-Team issues
• Frequency: As needed (daily, weekly,… )
• Participants:
• One from each team
Team Member, ScrumMaster
• Facilitator
• Agenda:
• Each person describes
What my Team is doing that may affect other Teams
What issues my Team needs help to resolve
• Resolve issues in meeting, if possible
• Identify follow-up actions and owners Diagram by Clinton Keith,
www.gamasutra.com
Copyright 2011, cPrime Inc.
27
28. Distributed Teams: Other Cases
• Members of Scrum
Team are
distributed
• Compared to co-
location
• Communication
latency increases
with
fragmentation,
time-zone
separation
• Productivity
decreases
• Non-overlapping
time zones make
collaboration
28
Copyright 2011, cPrime Inc.
difficult
29. Best Practices for Meetings
Working Sprint Daily Sprint Retro- Comment
Time Planning Stand-Up Review spective
Full overlap All attend All attend All attend All attend Co-located
Full overlap All attend All attend All attend All attend Distributed
Partial All attend All attend All attend All attend
overlap
Adjacent All attend All attend All attend All attend
Far apart All attend Sub-groups, Rotate Sub-groups, One SM
SMPs meet. demo to PO SMPs meet. proxy (SMP)
SMPs, SM among sub- SMPs, SM per sub-
provide all groups provide all group
findings to findings to
full Team. full Team.
Full Team Sub-group
meets twice nearest to
/ week PO demos
Copyright 2011, cPrime Inc. 29
30. Distributed Agile Case Study: S Corp.
• Three Teams
• ScrumMaster in CA
• Product Owner in PA
• 1/3 Team members in
CA
• 1/3 Team members on
East Coast
• 1/3 Team members in Shanghai, China
• Adaptations
• One proxy for ScrumMaster in Shanghai
• 15 min Daily Stand-Ups Twice-weekly 30-60 minute
meeting/Team
• Sprint Planning meetings One for US, one for Shanghai
• Sprint Retrospectives One for US, one for Shanghai
• ScrumMaster in all meetings
30
Copyright 2011, cPrime Inc.
31. Distributed Agile Case Study: Z Corp.
• SixTeams
• ScrumMaster in CA
• 3 Product Owners in CA
• 1/6 Team members in
CA
• 5/6 Team members in
Beijing, China
• Adaptations
• One proxy for ScrumMaster in Beijing
• Six 15 min Daily Stand-Ups Sun-Thur, 8-10 PM PST
• Sprint Planning meetings One per Team, staggered so POs
can attend all, with POs facilitating
• Task Breakdowns Drafted in Beijing, reviewed in CA
• Sprint Retrospectives One for all in CA, one for all in Beijing
• ScrumMaster in all meetings
31
Copyright 2011, cPrime Inc.
32. Case Study: Xebia Corp (Jeff Sutherland)
• Three Distributed Teams
• Across The Netherlands
& India (3 hrs separation)
• One Product Owner
• Three ScrumMasters
• Adaptations
• Start small, then grow
• Start co-located team, members from all locations
• Later seed distributed teams with experienced members
• All Scrum meetings Video-conferenced via Skype, except for…
• Sprint Review meeting Held in The Netherlands
32
Copyright 2011, cPrime Inc.
33. Best Practices for Engaging & Aligning People
1. Start small and co-located
• Members come from all locations
• Work together for 3 Sprints
2. Spread the wealth
• Seed new Teams in other locations with seasoned members
3. Understand cultural differences
• ScrumMasters provide safe environment, encouragement to
enable people from hierarchical cultures to adjust to Agile
culture of egalitarian collaboration
4. Build personal relationships face to face
• Encourage travel to other offices
• Socialize with the visitors
5. Use video in all meetings
33
Copyright 2011, cPrime Inc.
34. Closing Thoughts
• Distributed Agile projects are not desirable
• Distributed Agile projects are possible
• Technology and common sense adaptations reduce but
do not eliminate pain
34
Copyright 2011, cPrime Inc.
35. The Most Important Thing to Remember
The process exists to help the people succeed
“Build projects around motivated individuals. Give them
the environment and support they need, and trust them to
get the job done.”
Individuals
Processes
Interactions Tools
35
Copyright 2011, cPrime Inc.
Editor's Notes
** Notebook Question 1Describe balance between left side (soft skills) and right side (hard skills). The Manifesto says the left takes precedence, but we need both.Going all the way to the left works for the “three people in a garage startup company,” which has zero to one customers, but leads to chaos and gridlock when we try to scale up.Going all the way to the leads to cumbersome, slow-moving, documentation-heavy projects that take a very long time to deliver the wrong thing.
Highlighted principles are impacted by geographic distribution.
Highlighted principles are impacted by geographic distribution.
** Notebook Question 7This slide shows typical feedback loops for a Scrum process, involving internal people who work together to make things, and external people (stakeholders, customers) who want things made. The terminology is from Scrum, but the concepts are common to Agile processes in general.Internal PeopleIn a Scrum process, the Product Owner writes requirements, the Team members implement requirements and test the implementation.External PeopleStakeholders and customers want things made.Feedback LoopsTop Level: Work is done in iterations, not in a long, continuous process. Every few iterations, the Product Owner meets with Customers and Stakeholders to show what has been accomplished and what is planned, and get feedback regarding how well the completed or planned work aligns with their needs. Middle Level: Requirements specifications are called Stories, and are implemented and tested by the Team members. At the end of each Iteration, the Team members demonstrate completed Stories to the Product Owner, for approval or decision that re-work is required.Bottom Level: In real time, as needed, Team members call on the Product Owner for guidance about requirements, to ensure that deliverables will meet the Product Owner’s expectations.
** Notebook Question 8-10
SDLC: Software Development Lifecycle. An “umbrella terms” for plan-driven approaches to software projects.Waterfall: The classic phase-oriented model described by Winston Royce in 1970. For software projects.RUP: Rational Unified Process. A comprehensive framework for building iterative phase-oriented SDLCs.PERT: Dependency-oriented planning. For any kind of project.Critical Chain: Resource-oriented planning. For any kind of project.Prince2: A process framework that addresses process stages at a relatively high level. It leaves a lot of freedom for customization at the tactical level. For any kind of project.Scrum and XP are discussed in detail in following slides.CBPM (Commitment Based Project Management) is an agile process optimized for hardware projects, and used in microelectronic component design.Kanban is discussed in detail in following slides.
This is the classic PMI view of how a process works for a project. Process Groups may or may not represent sequential phases. They may, in the simplest case, but in complex projects may overlap, alternate, or both.
Epicyclic:Consisting of nested cycles. Scrum, XP, and CBPM are epicyclic. These processes are used for environments where uncertainty about requirements and effort is high, and especially when useful production capabilities can be delivered incrementally.Summarize different phases and cycles.Inception: Includes startup work that must be done before the specified process can start. Inception occurs when starting a new product or service from scratch. It is not a part of the (iterative) work of creating multiple releases of a product over time. Vision: Define concept for product.Roadmap: Long term plan, for one to a few years. Includes major milestones at a summary level, and spans multiple Releases or Projects.Release or Project:A medium-term (weeks to months) span of time, at the end of which results are delivered to customers. Includes fine- to medium-grainedy specifications of product functionality.Iteration: A short term (1-6 weeks) period spent developing functionality, for which all requirements are fine-grained and directly implementable in this span of time without further decomposition.Day: A single day may have any activities, as required, and involves fluid and dynamic collaboration among Team members to get work done.Termination: This refers to all activities associated with shutting down a Project. It is the same thing as the PMI Closing Process Group.====Note: Inception and Termination are rare occurrences in agile / Scrum projects, because the default mode of working is to continue adding capabilities and deliverables to an existing set, not to start and finish distinct projects frequently.
Kanban omits planning, and focuses on prioritization, tracking, and optimizing throughput. It is commonly employed in production support, Information Technology departments, hospital Emergency Rooms (as “triage”), and in any environment where work items are not known in advance.Kanban originated in manufacturing, and was adapted for software development. “Kanban” is a Japanese word meaning “signboard,” and in manufacturing refers to a signal indicating that some action should be performed. The use of signals to request action is consistent with the “pull” nature of projects or processes in which Kanban is generally employed.A Kanban project has no phases associated with starting or ending a project. All work is handled the same way, as tasks that flow through states.
Adaptability: “Inspect and Adapt” is a Scrum motto. It means that we do not rely on or invent process solutions to all problems. Instead, we use process solutions when they make sense, but emphasize looking at where we are right now, and identifying the best way to proceed.Collaboration: Teams should have all skills needed to implement work, from customer-facing aspects on down. Team members self-organize by owning the responsibility to (A) define tasks needed to implement requirements, and (B) deciding which Team members will do which tasks, in what order, and how, with the goal of minimizing implementation time.Continuous Improvement: For teams to become highly productive, they need stable membership over time, and a commitment to improvement. Stable teams will gradually gain or lose members, but will not be formed or disbanded frequently. Teams may be disbanded for good reasons, but resource managers should plan for Teams to last at least six months, and preferably longer.Teams learn how to improve all the time, informally, but the formal mechanism for continuous improvement is the Retrospective meeting (which is discussed later), which occurs at the end of every iteration. The Retrospective meeting captures information about what did or didn’t work well in the last iteration. Then Team members select top items requiring improvement, and decide who will work on them. The next Retrospective meeting will start with a review of how the last set of improvements worked out (or didn’t), before capturing more information about the most recent iteration.
Most agile processes include planning, but not all. The most popular agile process is Scrum, which is an iterative process that divides the calendar into short iterations called Sprints. In each Sprint, a Team starts and finishes implementation and testing of several small requirements. Scrum is not tied to any industry, and can be used for any project for which its characteristics are well-suited.Scrum is used in environments where plan-driven processes are inappropriate, because they have high uncertainty around requirements and effort which make plan-driven schedules unreliable. Instead of defining scope and estimating schedule, Scrum defines schedule (such as a Sprint) and estimates the scope that fits into it. Scrum optimizes risk mitigation (through completing work quickly) over efficiency.A Scrum process does not have planning and execution phases. Planning (for future Sprints) is done in parallel with implementation work (in the present Sprint).
** Notebook Question 6
Key Points:Activities recur at fixed intervals on the calendar, e.g. every two weeks for a two week Sprint. So if a Sprint Planning meeting occurs next Monday morning at 8 AM, there will be another Sprint Planning meeting every two weeks after that, also at 8 AM on Mondays.The purpose of the Sprint is to implement Backlog Items, but some time must be allocated to the various activities, leaving less time for work. The sample schedule shows that overhead due to meetings takes up 11 hours, leaving 29 hours to implement Backlog Items.
ScrumMaster ResponsibilitiesThe ScrumMaster has well-defined responsibilities for facilitating meetings and estimating Team velocity, but also exercises soft skills a lot. He talks to Team members informally, reviews status information throughout the day, and generally maintains situational awareness that the more focused Team members generally don’t have. He looks for issues that are not being addressed, and brings them to the attention of Team members who can address them. He keeps an eye out for Team members who are having problems, and helps them work through the problems. He is the escalation path for any problem Team members can’t handle on their own, whether task-related or personal.[Instructor should give examples from personal experience.]Example: “The dog ate my laptop.” Action: ScrumMaster does what is needed to get Team member a new laptop.Example: “I don’t know how to do X.”Action: ScrumMaster says, “Joe in IT knows how to do X. Let’s go talk to him and see if he can help.”Example: ScrumMaster is sitting at his desk when a Team member comes by. Team member says, “The second floor is being re-modeled, so everyone there is on our floor, and we’re doubling up in our cubicles. Marcie, from Marketing, is in my cube. She chews bubble gum all day long, and pops her bubbles. I can’t get any work done, because the popping is driving me crazy, and I can’t think.”Action:ScrumMaster does whatever is needed to solve the problem. This could include talking to Marcie, talking to her manager, seeing if it is possible to move people around so the problem goes away, etc.Product Owner ResponsibilitiesThe Product Owner must be available for discussions about requirements, and to review work-in-progress when Team members have something to show. From the Team’s perspective, the Product Owner is the final authority for all requirements-related questions. However, the Product Owner may consult with customers and stakeholders to resolve questions, as needed.Team member ResponsibilitiesTeam members are responsible for estimating Stories, creating Task Breakdowns and Task Estimates, getting the work done, updating task status in the tracking system, and collaborating with the Product Owner in real-time (or close to it) for clarification of requirements.
** Notebook Question 7-8
** Notebook Question 9-10
** Notebook Question 11
** Notebook Question 12In practice, each item is often a “Story,” which is used as a generic term for any requirement to be implemented via Scrum, XP, or Kanban. The goal is to finish each item as quickly as possible, to minimize risk of non-completion (risk mitigation is more important than efficiency). We do this by maximizing resources applied to each Story, via Swarming.
** Notebook Question 15
We don’t need to go through the slide in detail, especially as the Scrum meetings have not been described yet. We do want to point out that the importance of having everyone present varies across different meetings. Sometimes everyone must be present, even when this is inconvenient (e.g., Sprint Planning). Sometimes it is acceptable to have sub-groups have separate meetings (e.g., Daily Stand-Up) or even have just one sub-group hold the meeting (e.g., Sprint Review).