Jump to content

User:Toddwill/sandbox1: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Toddwill (talk | contribs)
305 edits
No edit summary
Toddwill (talk | contribs)
305 edits
No edit summary
Line 14: Line 14:


==Summary==
==Summary==
'''''Agile Project Management with Scrum ''''', by [[Ken Schwaber]], describes the process of managing a [[Scrum (development) | Scrum]] software development project. It uses a mixture of definitions and case studies to educate a would-be [[Scrum (management) |Scrum]] manager ([[aka]] ScrumMaster<FONT SIZE="-1"><SUP>TM</SUP></FONT>) on scrum, the major players in a scrum project and the ScrumMaster's role. The case studies exhibited are both success and failure cases to provide learning capabilities in both directions.
'''''Agile Project Management with Scrum,''''' by [[Ken Schwaber]], describes the process of managing a [[Scrum (development) | Scrum]] software development project. It uses a mixture of definitions and case studies to educate a would-be [[Scrum (management) |Scrum]] manager ([[aka]] ScrumMaster<FONT SIZE="-1"><SUP>TM</SUP></FONT>) on scrum, the major players in a scrum project and the ScrumMaster's role. The case studies exhibited are both success and failure cases to provide learning capabilities in both directions.


The book presumes very little knowledge of scrum and agile processes. The appendix supplies a variety of background data that might be needed by the novice.
The book presumes very little knowledge of scrum and agile processes. The appendix supplies a variety of background data that might be needed by the novice.
Line 22: Line 22:
==Analysis==
==Analysis==


Schwaber defines the concept of ''[[empirical]] [[process control]]'' and uses this as the foundation for scrum. His clam is that in the "real world" of software development most projects that build or improve a product are breaking new ground and cannot use ''defined process control'', as might be used in truly repetitive projects. Empirical process control relies on actual observed data to affect the project and change its execution. The iterative nature of scrum (see Figure 1) provides adjustments to the process every cycle (30 days) allowing it to adapt to the current situation.
Schwaber defines the concept of ''[[empirical]] [[process control]]'' and uses this as the foundation for justification of the scrum process. His claim is that in the "real world" of software development most projects that build or improve a product are breaking new ground and cannot use ''defined process control'', as might be used in truly repetitive projects. Empirical process control relies on actual observed data to affect the project and change its execution. The iterative nature of scrum (see Figure 1) provides adjustments to the process every cycle (30 days) allowing it to adapt to the current situation.


[[Image:ScrumFlow.jpg|frame|center|Figure 1. Scrum Project Flow]]
[[Image:ScrumFlow.jpg|thumb|600px|center|Figure 1 Scrum Project Flow]]


As with other [[Agile Project Management (book) | agile]] processes, [[timebox | timeboxing]] is important to minimize many sources of waste:
As with other [[Agile Project Management (book) | agile]] processes, [[timebox | timeboxing]] is important to minimize many sources of waste:
Line 33: Line 33:


The heart of scrum is iterative incremental development and delivery. Figure 1 summarizes the flow of a scrum process.
The heart of scrum is iterative incremental development and delivery. Figure 1 summarizes the flow of a scrum process.
# A product backlog is created.
# A Product Backlog is created.
# An eight hour meeting is held to define the work to be done. The first four hours is for the Product Owner to define the highest priority features and the second four hours is for the Team to commit to a work plan for the Sprint.
# An eight hour meeting is held to define the work to be done. The first four hours is for the Product Owner to define the highest priority features and the second four hours is for the Team to commit to a work plan for the Sprint.
# All work is done in 30-day increments. Each day there is a Scrum daily meeting (15-minutes) where the following question are addressed within the Team:
# All work is done in 30-day increments. Each day there is a Scrum daily meeting (15-minutes) where the following questions are addressed within the Team:
##What was completed yesterday.
##What was completed yesterday?
##What is planned for today.
##What is planned for today?
##What is in the way of completing the work.
##What is in the way of completing the work?
#At the end of the Sprint there is a four hour meeting with the stakeholders where '''shippable ''' product is demonstrated.
#At the end of the Sprint there is a four hour meeting with the stakeholders where '''shippable ''' product is demonstrated.
#If the stakeholders want to deploy the product, a deployment sprint is executed.
#If the stakeholders want to deploy the product, a deployment sprint is executed.
#If more iterations are needed and funded, then the Product owner presents the updated Product Backlog and the process starts over.
#If more iterations are needed and funded, then the Product Owner presents the updated Product Backlog and the process starts over.


Scrum projects to not have a manager as with traditional [[Project management | projects]]. Management is done by a group of three set of people &mdash; [[#ScrumMaster | ScrumMaster]], [[#Product Owner | Product_Owner]] and [[#The_Team | The Team]].
Scrum projects to not have a manager as with traditional [[Project management | projects]]. Management is done by a group of three set of people &mdash; [[#ScrumMaster | ScrumMaster]], [[#Product Owner | Product Owner]] and [[#The_Team | The Team]].


===ScrumMaster===
===ScrumMaster===
Line 52: Line 52:
*Teach the concepts of scrum,
*Teach the concepts of scrum,
*Shield the team from outside disturbances,
*Shield the team from outside disturbances,
*Remove obstacles
*Remove obstacles,
*Mold scrum into the company culture
*Mold scrum into the company culture


The ScrumMaster must be dedicated to the project and continually observe the Team and their progress to determine signs where the scrum rules are not being followed. Through case studies, Schwaber provides examples of common failures of ScrumMasters (including his own) to educate the reader on the process, hence providing a list of what a ScrumMaster is not.
The ScrumMaster must be dedicated to the project and continually observe the Team and their progress to determine signs where the scrum rules are not being followed. Through case studies, Schwaber provides examples of common failures of ScrumMasters (including his own) to educate the reader on the process, hence providing a list of what a ScrumMaster is not.
A ScrumMaster does not:
A ScrumMaster does not:
*Assign work to the team.
*Assign work to the team,
*Run the daily scrum.
*Run the daily scrum,
*Manage task done by the Team
*Manage task done by the Team,
*Change priorities of the Team (inside or outside the Sprint)
*Change priorities of the Team (inside or outside the Sprint).


===Product Owner===
===Product Owner===
Line 75: Line 75:
Along with the ScrumMaster, the Team has the greatest change in responsibilities over traditional project management. Tasks that the Team must do that may be new to them are estimations, self-management and self-organization. These tasks, often left to the Project Manager, are daily task for the team using scrum.
Along with the ScrumMaster, the Team has the greatest change in responsibilities over traditional project management. Tasks that the Team must do that may be new to them are estimations, self-management and self-organization. These tasks, often left to the Project Manager, are daily task for the team using scrum.


In the sprint planning meeting the team will be provided a list of prioritized features that they can work on. They will select the highest priority features that they feel they can build and complete ("complete" means fully tested and functional code that can be shipped to the customer) the customer. This will create a list called the Sprint Backlog. This list may change over the course of the sprint adding item that are required to complete the agreed to list. No new features may be added. Each feature will have a estimate of the hours to complete. Hours-to-complete will be updated daily.
In the sprint planning meeting, the team is be provided a list of prioritized features that they can work on. They will select the highest priority features that they feel they can build and complete ("complete" means fully tested and functional code that can be shipped to the customer). This will create a list called the Sprint Backlog. This list may change over the course of the sprint adding items that are required to complete the agreed upon list. No new features may be added. Each feature will have a estimate of the hours to complete. Hours-to-complete will be updated daily.


Daily the team will meet for a timeboxed 15-minute meeting and each team member will answer three questions to the rest of the team:
Daily the team will meet for a timeboxed 15-minute meeting and each team member will answer three questions to the rest of the team:
Line 82: Line 82:
#What impediments need assistance in being solved?
#What impediments need assistance in being solved?


Although the questions are directed at the team, the last question needs to be addressed by the ScrumMaster, if for no other reason than to ensure it gets answered in a timely manner. If the issue is external to the group, it is the ScrumMasters responsibility to resolve it.
Although the questions are directed at the team, the last question needs to be addressed by the ScrumMaster, if for no other reason than to ensure it gets answered in a timely manner. If the issue is external to the group, it is the ScrumMaster's responsibility to resolve it.


The key functions of the Team are:
The key functions of the Team are:
Line 93: Line 93:


===Reporting/Visibility===
===Reporting/Visibility===
Reporting on Scrum projects is inherently different than traditional projects. The primary point is that Scrum projects work on features not tasks. There are basic reports are used and the ScrumMaster can mold them to the organization where they are being deployed. These reports are:
Reporting on Scrum projects is inherently different than traditional projects. The primary point is that Scrum projects work on features not tasks. There are basic reports that are used and the ScrumMaster can mold them to the organization where they are being deployed. These reports are:
# Product Backlog - What is intended to be in the product. This is a dynamic list so there are subsets of this report:
# Product Backlog: What is intended to be in the product. This is a dynamic list so there are subsets of this report:
## Previous Product Backlog - The back log at the start of the previous sprint
## Previous Product Backlog: The backlog at the start of the previous sprint
## Current Product Backlog - The back log at the start of the current sprint
## Current Product Backlog: The backlog at the start of the current sprint
## Changes in Product Backlog - the difference between current and previous backlog
## Changes in Product Backlog: the difference between current and previous backlog
# Sprint Backlog - What the team has committed to do in this sprint (updated daily for hours-to-complete)
# Sprint Backlog: What the team has committed to do in this sprint (updated daily for hours-to-complete)
# Feature burndown - A report to show features that have been completed.
# Feature Burndown: A report to show features that have been completed.
# Sprint review - Although not a report, this demonstration of shippable functionality provides the ''fait accompli'' to show the work is complete.
# Sprint Review: Although not a report, this demonstration of shippable functionality provides the ''fait accompli'' to show the work is complete.


===Project Planning===
===Project Planning===
Schwaber describes the task required to plan and set expectations of a scrum project. He covers:
Schwaber describes the tasks required to plan and set expectations of a scrum project. He covers:
*What the funding party should expect.
*What the funding party should expect,
*What progress will be seen in each sprint
*What progress will be seen in each sprint,
*What the value of Scrum is and why stakeholders can expect good delivery
*What the value of Scrum is and why stakeholders can expect successful delivery,
*What is meant by "Done", since an iterative process implies open ended
*What is meant by "Done", since an iterative process implies open ended,
*How a collaborative process works
*How a collaborative process works,
*The meaning of estimates and expectations
*The meaning of estimates and expectations.


===Scaling Scrum===
===Scaling Scrum===
Line 254: Line 254:
==External References==
==External References==
http://www.controlchaos.com/ Schwaber's scrum website
http://www.controlchaos.com/ Schwaber's scrum website

http://www.scrumalliance.org/ Scrum Alliance (trademark holders of "Certified ScrumMaster" and "ScrumMaster")
http://www.scrumalliance.org/ Scrum Alliance (trademark holders of "Certified ScrumMaster" and "ScrumMaster")



<!--
<!--

Revision as of 21:36, 13 July 2006

Agile Project Management with Scrum
File:APMScrum(Thumb).jpg
AuthorKen Schwaber
LanguageEnglish
GenreBusiness, Project Management, Scrum (management)
PublisherMicrosoft Press
Publication date
January 2004
Publication placeUnited States
Media typePrint (Paperback)
Pages163
ISBNISBN 073561993X Parameter error in {{ISBNT}}: invalid character

Summary

Agile Project Management with Scrum, by Ken Schwaber, describes the process of managing a Scrum software development project. It uses a mixture of definitions and case studies to educate a would-be Scrum manager (aka ScrumMasterTM) on scrum, the major players in a scrum project and the ScrumMaster's role. The case studies exhibited are both success and failure cases to provide learning capabilities in both directions.

The book presumes very little knowledge of scrum and agile processes. The appendix supplies a variety of background data that might be needed by the novice.

The book is relatively short and easy to read.

Analysis

Schwaber defines the concept of empirical process control and uses this as the foundation for justification of the scrum process. His claim is that in the "real world" of software development most projects that build or improve a product are breaking new ground and cannot use defined process control, as might be used in truly repetitive projects. Empirical process control relies on actual observed data to affect the project and change its execution. The iterative nature of scrum (see Figure 1) provides adjustments to the process every cycle (30 days) allowing it to adapt to the current situation.

Figure 1 Scrum Project Flow

As with other agile processes, timeboxing is important to minimize many sources of waste:

  1. Dwelling on features that are not top priority.
  2. Minimizing excess documentation.
  3. Creating deployable product — increasing Return on Investment ( ROI)
  4. Discussions in large groups where one-on-one interaction is needed.

The heart of scrum is iterative incremental development and delivery. Figure 1 summarizes the flow of a scrum process.

  1. A Product Backlog is created.
  2. An eight hour meeting is held to define the work to be done. The first four hours is for the Product Owner to define the highest priority features and the second four hours is for the Team to commit to a work plan for the Sprint.
  3. All work is done in 30-day increments. Each day there is a Scrum daily meeting (15-minutes) where the following questions are addressed within the Team:
    1. What was completed yesterday?
    2. What is planned for today?
    3. What is in the way of completing the work?
  4. At the end of the Sprint there is a four hour meeting with the stakeholders where shippable product is demonstrated.
  5. If the stakeholders want to deploy the product, a deployment sprint is executed.
  6. If more iterations are needed and funded, then the Product Owner presents the updated Product Backlog and the process starts over.

Scrum projects to not have a manager as with traditional projects. Management is done by a group of three set of people — ScrumMaster, Product Owner and The Team.

ScrumMaster

The ScrumMaster is somewhat analogous to a Project Manager in traditional projects, but Schwaber is quick to note this is only an analogy. There are significant differences. The primary difference and key that makes scrum work is that the ScrumMaster does not manage the team — the team is self-managed. The ScrumMaster provides leadership to the project.

The key functions of the ScrumMaster are:

  • Enforce the scrum rules,
  • Teach the concepts of scrum,
  • Shield the team from outside disturbances,
  • Remove obstacles,
  • Mold scrum into the company culture

The ScrumMaster must be dedicated to the project and continually observe the Team and their progress to determine signs where the scrum rules are not being followed. Through case studies, Schwaber provides examples of common failures of ScrumMasters (including his own) to educate the reader on the process, hence providing a list of what a ScrumMaster is not. A ScrumMaster does not:

  • Assign work to the team,
  • Run the daily scrum,
  • Manage task done by the Team,
  • Change priorities of the Team (inside or outside the Sprint).

Product Owner

The Product Owner (analogous to a Product Manager) manages the product and works with the stakeholders and the end user to define the final product and set priorities for feature development.

The key functions of the Product Owner are:

  • Represent all stakeholders,
  • Provide funding,
  • Define requirements,
  • Set priorities,
  • Determine return on investment.

The Team

Along with the ScrumMaster, the Team has the greatest change in responsibilities over traditional project management. Tasks that the Team must do that may be new to them are estimations, self-management and self-organization. These tasks, often left to the Project Manager, are daily task for the team using scrum.

In the sprint planning meeting, the team is be provided a list of prioritized features that they can work on. They will select the highest priority features that they feel they can build and complete ("complete" means fully tested and functional code that can be shipped to the customer). This will create a list called the Sprint Backlog. This list may change over the course of the sprint adding items that are required to complete the agreed upon list. No new features may be added. Each feature will have a estimate of the hours to complete. Hours-to-complete will be updated daily.

Daily the team will meet for a timeboxed 15-minute meeting and each team member will answer three questions to the rest of the team:

  1. What was accomplished since yesterday's meeting?
  2. What is planned to be done today?
  3. What impediments need assistance in being solved?

Although the questions are directed at the team, the last question needs to be addressed by the ScrumMaster, if for no other reason than to ensure it gets answered in a timely manner. If the issue is external to the group, it is the ScrumMaster's responsibility to resolve it.

The key functions of the Team are:

  • Responsible for building the functionality of the product,
  • Self-organized their work to achieve Sprint results,
  • Self-managed their tasks,
  • Perform cross-functional duties,
  • Present shippable product at scrum review,
  • Run the daily scrum meeting.

Reporting/Visibility

Reporting on Scrum projects is inherently different than traditional projects. The primary point is that Scrum projects work on features not tasks. There are basic reports that are used and the ScrumMaster can mold them to the organization where they are being deployed. These reports are:

  1. Product Backlog: What is intended to be in the product. This is a dynamic list so there are subsets of this report:
    1. Previous Product Backlog: The backlog at the start of the previous sprint
    2. Current Product Backlog: The backlog at the start of the current sprint
    3. Changes in Product Backlog: the difference between current and previous backlog
  2. Sprint Backlog: What the team has committed to do in this sprint (updated daily for hours-to-complete)
  3. Feature Burndown: A report to show features that have been completed.
  4. Sprint Review: Although not a report, this demonstration of shippable functionality provides the fait accompli to show the work is complete.

Project Planning

Schwaber describes the tasks required to plan and set expectations of a scrum project. He covers:

  • What the funding party should expect,
  • What progress will be seen in each sprint,
  • What the value of Scrum is and why stakeholders can expect successful delivery,
  • What is meant by "Done", since an iterative process implies open ended,
  • How a collaborative process works,
  • The meaning of estimates and expectations.

Scaling Scrum

When scaling Scrum to larger projects Schwaber provides a few guidelines:

  • Attempt to keep the team size to eight.
  • Do not engage all the teams until the infrastructure is built. This may require the first few sprints being done by only one or two teams and only non-functional requirements being built.
  • Divide the work into teams that logically represent the work and minimize the need for multiple assignments of people.
  • Create a daily scrum meeting of representatives of each scrum, held after the daily scrum.

Appendices

The appendix contains invaluable material for someone new to Scrum. The "Rules" enumerates the rules for each major activity in the Project — Sprint Planning Meeting, Daily Scrum Meeting, Sprint, Sprint Review Meeting and Sprint Retrospective Meeting.

Other appendices provide definitions and applicability to scrum in specific project situations.

Complete Table of Contents

  • Forward: Mike Cohn
  • Forward: Mary Poppendieck
  • Acknowledgements
  • Introduction
  1. Backdrop: The Science Of Scrum
    Empirical Process Control
    Complex Software development
    The Skeleton and Heart of Scrum
    Scrum Roles
    Scrum Flow
    Scrum Artifacts
    Product Backlog
    Sprint Backlog
    Increment of Potentially Shippable Product Functionality
  2. New Management Responsibilities
    The ScrumMaster at MetaEco
    The Situation at MetaEco
    The ScrumMaster in action
    The ScrumMaster's Value
    The Product Owner at MegaEnergy
    The Situation at MegaEnergy
    The Product Owner in action
    The Product Owner's Value
    The Team at Service1st
    The Situation at Service1st
    The Team in action
    The Team's Value
  3. The ScrumMaster
    The Untrained ScrumMaster at Trey Research
    What was Wrong
    Lessons Learned
    The Untrained ScrumMaster at Litware
    What was Wrong
    Lessons Learned
    Overzealous at Contoso.com
    Being Right Isn't Everything
    Lessons Learned
    Wolves at MegaFund
    Wolves Strike
    Lessons Learned
  4. Bringing Order to Chaos
    The situation at Service1st
    Application of Scrum
    Lessons Learned
    The situation at Tree Business Publishing
    Application of Scrum
    Lessons Learned
    The situation at Lapsec
    Application of Scrum
    Lessons Learned
  5. The Product Owner
    Customer and Team Collaboration
    Getting Service1st Management Back in Action
    Sprint Review Meeting
    Lessons Learned
    Fixing the Problem of XFlow at MegaFund
    Addressing the Problem
    Lessons Learned
    Company Goals at TechCore
    How Scrum Helped TechCore
    Lessons Learned
    Company Goals at MegaBank Funds Transfer System
    How Scrum helped FTS
    Lessons Learned
  6. Planning the Scrum Project
    Managing Cash at MegaBank
    The Two-day Sprint Planning
    Lessons Learned
    Certified ScrumMasters Take on Return on Investment (ROI)
    MLBTix
    How the Teams Responded To This Exercise
    Lessons Learned
  7. Project Reporting—Keeping Everything Visible
    New Project Reporting as the MegaEnergy Title Project
    Solving the Problem
    Lessons Learned
    Getting More Information at MegaBank
    Solving the Problem
    Lessons Learned
    Not Everything is Visible at Service1st
    The Reality
    Lessons Learned
  8. The Team
    Team Formation at Service 1st
    Learning Who is Boss: The Transition
    Learning to Engineer Better: The Transition
    Learning to Self-Organize: The Transition
    Estimating Workload: The Transition
    Learning to Have Fun While Working: The Transition
    Giving the Team a Chance at WebNewSite
    Background
    Lessons Learned
  9. Scaling Projects Using Scrum
    Scaling at MegaFund
    Approach
    Lessons Learned
    Scrum Scaling
    Scaling at Medcinsoft
    Approach
    Bug Fixing
    Lessons Learned
  • Appendices
  1. Rules
    Sprint Planning Meeting
    Daily Scrum Meeting
    Sprint
    Sprint Review Meeting
    Sprint Retrospective Meeting
  2. Definitions
  3. Resources
  4. Fixed-Price, Fixed Date Contracts
    How to Gain Competitive Advantage
    How to Ignore Competitive Advantage
  5. Capability Maturity Model (CMM)
    CMM at MegaFund
    SEI, CMM, and Scrum
  • Index

Other Books

External References

http://www.controlchaos.com/ Schwaber's scrum website

http://www.scrumalliance.org/ Scrum Alliance (trademark holders of "Certified ScrumMaster" and "ScrumMaster")


Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=User:Toddwill/sandbox1&oldid=63672964"