Software in 30 Days

How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust

Ken Schwaber, Jeff Sutherland

• Publisher: Wiley
• Year: 2012
• ISBN:
  9781118240908
• Edition: 1
• Topic: Business
• Subtopic: Business General
• Index: Business

A radical approach to getting IT projects done faster and cheaper than anyone thinks possible

Software in 30 Days summarizes the Agile and Scrum software development method, which allows creation of game-changing software, in just 30 days. Projects that use it are three times more successful than those that don't. Software in 30 Days is for the business manager, the entrepreneur, the product development manager, or IT manager who wants to develop software better and faster than they now believe possible. Learn how this unorthodox process works, how to get started, and how to succeed. Control risk, manage projects, and have your people succeed with simple but profound shifts in the thinking.

The authors explain powerful concepts such as the art of the possible, bottom-up intelligence, and why it's good to fail early—all with no risk greater than thirty days.

• The productivity gain vs traditional "waterfall" methods has been over 100% on many projects
• Author Ken Schwaber is a co-founder of the Agile software movement, and co-creator, with Jeff Sutherland, of the "Scrum" technique for building software in 30 days
• Coauthor Jeff Sutherland was cosigner of the Agile Manifesto, which marked the start of the Agile movement

Software in 30 Days is a must-read for all managers and business owners who use software in their organizations or in their products and want to stop the cycle of slow, expensive software development. Programmers will want to buy copies for their managers and their customers so they will know how to collaborate to get the best work possible.

Appendix 1: Terminology

Baseline	A line that is a base for measurement. In a burndown chart, it reflects the point in time when no requirements work remains to be done to complete the release.
Burndown chart	A chart that tracks the amount of requirements work remaining on a release across time, where time is measured in Sprints.
Daily Scrum meeting	The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains: What has been accomplished since the last meeting? What will be done before the next meeting? What obstacles are in the way?
Development Team	The Development Team consists of professionals who do the work of delivering a potentially releasable increment of “Done” product at the end of each Sprint. Only members of the Development Team create the increments.
Emergence	The way complex systems and patterns arise out of a multiplicity of relatively simple interactions. Emergence is central to the theories of integrative levels and of complex systems.
Empirical	Denotes information gained by means of observation or experimentation.
Forecast	A prediction based on experience of how much requirements effort in the Product Backlog can be transformed into an increment. This is not a guarantee.
Function point	A unit of measurement to express the amount of business functionality an information system provides to a user. The cost (in dollars or hours) of a single unit is calculated from past projects.
Increment	The increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new increment must be “done,” which means it must be in useable condition and meet the Scrum Team's definition of “done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
Iteration	Iteration is the act of repeating a series of steps or processes, usually with the aim of approaching a desired goal or result. Each repetition of the process is also called an iteration, and the results of one iteration are used as the starting point for the next.
Iterative incremental, process	A way of developing a system or product through a sequence of iterations, each of which generates a complete increment of functionality that builds on all previous increments. Iterations continue until a goal is reached or value is optimized.
PRN	As necessary (from the Latin pro re nata, which means “take when needed”).
Product Backlog	The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Product Owner	The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
Productivity	The number of units of business functionality that are developed for a specified amount of money (e.g., per $100,000 invested). Productivity is also called velocity.
Quality	The number of defects is counted starting on the day that the unit of functionality is given to the Product Owner and ending after three months of customer usage of the functionality.
Requirements	A singular documented physical and functional need that a particular product or service must be or perform. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user.
Scrum	An iterative, incremental process that employs empirical process control. Scrum is one of several agile processes.
Scrum Master	The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
Scrum Team	The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross functional.
Self-organization	The process where a structure or pattern appears in a system without a central authority or external element imposing it through planning.
Software developer	A person concerned with facets of the software development process. This person's work includes researching, designing, developing, and testing software.
Sprint	The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done,” useable, and potentially releasable product increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprint Backlog	The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team, which determines what functionality will be in the next increment and the work needed to deliver that functionality. The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.
Sprint Goal	The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
Sprint Planning Meeting	The work to be performed in the Sprint i...

Table of contents

• Cover
• Title Page
• Copyright
• Dedication
• About the Authors
• Acknowledgments
• Introduction
• Section I: Why Every Business in the World Can Produce Software in 30 Days
• Section II: How to Produce Software in 30 Days
• Appendix 1: Terminology
• Appendix 2: The Scrum Guide
• Appendix 3: A Playbook for Achieving Enterprise Agility
• Index