Abbildung von: Agile Project Management For Dummies - For Dummies

Agile Project Management For Dummies

For Dummies (Verlag)
2. Auflage
Erschienen am 21. August 2017
432 Seiten
ePUB mit Adobe-DRM
978-1-119-40573-3 (ISBN)
20,99 €inkl. 7% MwSt.
für ePUB mit Adobe-DRM
E-Book Einzellizenz
Als Download verfügbar
Flex your project management muscle
Agile project management is a fast and flexible approach to managing all projects, not just software development. By learning the principles and techniques in this book, you'll be able to create a product roadmap, schedule projects, and prepare for product launches with the ease of Agile software developers. You'll discover how to manage scope, time, and cost, as well as team dynamics, quality, and risk of every project.
As mobile and web technologies continue to evolve rapidly, there is added pressure to develop and implement software projects in weeks instead of months--and Agile Project Management For Dummies can help you do just that. Providing a simple, step-by-step guide to Agile project management approaches, tools, and techniques, it shows product and project managers how to complete and implement projects more quickly than ever.
* Complete projects in weeks instead of months
* Reduce risk and leverage core benefits for projects
* Turn Agile theory into practice for all industries
* Effectively create an Agile environment
Get ready to grasp and apply Agile principles for faster, more accurate development.
Mark C. Layton, aka "Mr. Agile¯(TM)," is a veteran of more than 25 years in the project and program management field. He is a Certified Scrum Trainer, a PMP, and an MBA. He holds multiple scrum scaling certifications and is the founder of Platinum Edge, LLC. Steven J. Ostermiller is a coach, mentor, and trainer empowering leaders and teams to become more agile. He holds CSP and PMP designations.
  • Intro
  • Title Page
  • Copyright Page
  • Table of Contents
  • Introduction
  • About This Book
  • Foolish Assumptions
  • Icons Used in This Book
  • Beyond the Book
  • Where to Go from Here
  • Part 1 Understanding Agile
  • Chapter 1 Modernizing Project Management
  • Project Management Needed a Makeover
  • The origins of modern project management
  • The problem with the status quo
  • Introducing Agile Project Management
  • How agile projects work
  • Why agile projects work better
  • Chapter 2 Applying the Agile Manifesto and Principles
  • Understanding the Agile Manifesto
  • Outlining the Four Values of the Agile Manifesto
  • Value 1: Individuals and interactions over processes and tools
  • Value 2: Working software over comprehensive documentation
  • Value 3: Customer collaboration over contract negotiation
  • Value 4: Responding to change over following a plan
  • Defining the 12 Agile Principles
  • Agile principles of customer satisfaction
  • Agile principles of quality
  • Agile principles of teamwork
  • Agile principles of project management
  • Adding the Platinum Principles
  • Resisting formality
  • Thinking and acting as a team
  • Visualizing rather than writing
  • Changes as a Result of Agile Values
  • The Agile Litmus Test
  • Chapter 3 Why Being Agile Works Better
  • Evaluating Agile Benefits
  • How Agile Approaches Beat Historical Approaches
  • Greater flexibility and stability
  • Reduced nonproductive tasks
  • Higher quality, delivered faster
  • Improved team performance
  • Tighter project control
  • Faster and less costly failure
  • Why People Like Being Agile
  • Executives
  • Product development and customers
  • Management
  • Development teams
  • Part 2 Being Agile
  • Chapter 4 Agile Approaches
  • Diving under the Umbrella of Agile Approaches
  • Reviewing the Big Three: Lean, Scrum, and Extreme Programming
  • An overview of lean
  • An overview of scrum
  • An overview of extreme programming
  • Putting It All Together
  • Chapter 5 Agile Environments in Action
  • Creating the Physical Environment
  • Collocating the team
  • Setting up a dedicated area
  • Removing distractions
  • Going mobile
  • Low-Tech Communicating
  • High-Tech Communicating
  • Choosing Tools
  • The purpose of the tool
  • Organizational and compatibility constraints
  • Chapter 6 Agile Behaviors in Action
  • Establishing Agile Roles
  • Product owner
  • Development team member
  • Scrum master
  • Stakeholders
  • Agile mentor
  • Establishing New Values
  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect
  • Changing Team Philosophy
  • Dedicated team
  • Cross-functionality
  • Self-organization
  • Self-management
  • Size-limited teams
  • Ownership
  • Part 3 Agile Planning and Execution
  • Chapter 7 Defining the Product Vision and Product Roadmap
  • Agile Planning
  • Progressive elaboration
  • Inspect and adapt
  • Defining the Product Vision
  • Step 1: Developing the product objective
  • Step 2: Creating a draft vision statement
  • Step 3: Validating and revising the vision statement
  • Step 4: Finalizing the vision statement
  • Creating a Product Roadmap
  • Step 1: Identifying stakeholders
  • Step 2: Establishing product requirements
  • Step 3: Arranging product features
  • Step 4: Estimating efforts and ordering requirements
  • Step 5: Determining high-level time frames
  • Saving your work
  • Completing the Product Backlog
  • Chapter 8 Planning Releases and Sprints
  • Refining Requirements and Estimates
  • What is a user story?
  • Steps to create a user story
  • Breaking down requirements
  • Estimation poker
  • Affinity estimating
  • Release Planning
  • Sprint Planning
  • The sprint backlog
  • The sprint planning meeting
  • Chapter 9 Working throughout the Day
  • Planning Your Day: The Daily Scrum
  • Tracking Progress
  • The sprint backlog
  • The task board
  • Agile Roles in the Sprint
  • Creating Shippable Functionality
  • Elaborating
  • Developing
  • Verifying
  • Identifying roadblocks
  • The End of the Day
  • Chapter 10 Showcasing Work, Inspecting, and Adapting
  • The Sprint Review
  • Preparing to demonstrate
  • The sprint review meeting
  • Collecting feedback in the sprint review meeting
  • The Sprint Retrospective
  • Planning for sprint retrospectives
  • The sprint retrospective meeting
  • Inspecting and adapting
  • Chapter 11 Preparing for Release
  • Preparing the Product for Deployment: The Release Sprint
  • Preparing for Operational Support
  • Preparing the Organization for Product Deployment
  • Preparing the Marketplace for Product Deployment
  • Part 4 Agile Management
  • Chapter 12 Managing Scope and Procurement
  • What's Different about Agile Scope Management?
  • Managing Agile Scope
  • Understanding scope throughout the project
  • Introducing scope changes
  • Managing scope changes
  • Using agile artifacts for scope management
  • What's Different about Agile Procurement?
  • Managing Agile Procurement
  • Determining need and selecting a vendor
  • Understanding cost approaches and contracts for services
  • Organizational considerations for procurement
  • Working with a vendor
  • Closing a contract
  • Chapter 13 Managing Time and Cost
  • What's Different about Agile Time Management?
  • Managing Agile Schedules
  • Introducing velocity
  • Monitoring and adjusting velocity
  • Managing scope changes from a time perspective
  • Managing time by using multiple teams
  • Using agile artifacts for time management
  • What's Different about Agile Cost Management?
  • Managing Agile Budgets
  • Creating an initial budget
  • Creating a self-funding project
  • Using velocity to determine long-range costs
  • Using agile artifacts for cost management
  • Chapter 14 Managing Team Dynamics and Communication
  • What's Different about Agile Team Dynamics?
  • Managing Agile Team Dynamics
  • Becoming self-managing and self-organizing
  • Supporting the team: The servant-leader
  • Working with a dedicated team
  • Working with a cross-functional team
  • Reinforcing openness
  • Limiting development team size
  • Managing projects with dislocated teams
  • What's Different about Agile Communication?
  • Managing Agile Communication
  • Understanding agile communication methods
  • Status and progress reporting
  • Chapter 15 Managing Quality and Risk
  • What's Different about Agile Quality?
  • Managing Agile Quality
  • Quality and the sprint
  • Proactive quality
  • Quality through regular inspecting and adapting
  • Automated testing
  • What's Different about Agile Risk Management?
  • Managing Agile Risk
  • Reducing risk inherently
  • Identifying, prioritizing, and responding to risks early
  • Part 5 Ensuring Agile Success
  • Chapter 16 Building a Foundation
  • Organizational and Individual Commitment
  • Organizational commitment
  • Individual commitment
  • Getting commitment
  • Can you make the transition?
  • Timing the transition
  • Choosing the Right Pilot Team Members
  • The agile champion
  • The agile transition team
  • The product owner
  • The development team
  • The scrum master
  • The project stakeholders
  • The agile mentor
  • Creating an Environment That Enables Agility
  • Support Agility Initially and Over Time
  • Chapter 17 Scaling across Agile Teams
  • Multi-Team Agile Projects
  • Making Work Digestible through Vertical Slicing
  • Scrum of scrums
  • Aligning through Roles with Scrum at Scale
  • Scaling the scrum master
  • Scaling the product owner
  • Synchronizing in one hour a day
  • Multi-Team Coordination with LeSS
  • LeSS, the smaller framework
  • LeSS Huge framework
  • Sprint review bazaar
  • Observers at the daily scrum
  • Component communities and mentors
  • Multi-team meetings
  • Travelers
  • Reducing Dependencies with Nexus
  • Nexus role - Nexus integration team
  • Nexus artifacts
  • Nexus events
  • Joint Program Planning with SAFe
  • Understanding the four SAFe levels
  • Joint program increment planning
  • Clarity for managers
  • Modular Structures with Enterprise Scrum
  • ES scrum elements generalizations
  • ES key activities
  • Chapter 18 Being a Change Agent
  • Becoming Agile Requires Change
  • Why Change Doesn't Happen on Its Own
  • Strategic Approaches to Implementing and Managing Change
  • Lewin
  • ADKAR's five steps to change
  • Kotter's eight steps for leading change
  • Platinum Edge's Change Roadmap
  • Step 1: Conduct an implementation strategy with success metrics
  • Step 2: Build awareness and excitement
  • Step 3: Form a transformation team and identify a pilot project
  • Step 4: Build an environment for success
  • Step 5: Train sufficiently and recruit as needed
  • Step 6: Kick off the pilot with active coaching
  • Step 7: Execute the Roadmap to Value
  • Step 8: Gather feedback and improve
  • Step 9: Mature and solidify improvements
  • Step 10: Progressively expand within the organization
  • Avoiding Pitfalls
  • Signs Your Changes Are Slipping
  • Part 5 The Part of Tens
  • Chapter 19 Ten Key Benefits of Agile Project Management
  • Better Product Quality
  • Higher Customer Satisfaction
  • Reduced Risk
  • Increased Collaboration and Ownership
  • More Relevant Metrics
  • Improved Performance Visibility
  • Increased Project Control
  • Improved Project Predictability
  • Customized Team Structures
  • Higher Team Morale
  • Chapter 20 Ten Key Factors for Project Success
  • Dedicated Team Members
  • Collocation
  • Automated Testing
  • Enforced Definition of Done
  • Clear Product Vision and Roadmap
  • Product Owner Empowerment
  • Developer Versatility
  • Scrum Master Clout
  • Management Support for Learning
  • Transition Support
  • Chapter 21 Ten Metrics for Agile Organizations
  • Return on Investment
  • New requests in ROI budgets
  • Capital redeployment
  • Satisfaction Surveys
  • Defects in Production
  • Sprint Goal Success Rates
  • Time to Market
  • Lead and Cycle Times
  • Cost of Change
  • Team Member Turnover
  • Skill Versatility
  • Manager-to-Creator Ratio
  • Chapter 22 Ten Valuable Resources for Agile Professionals
  • Agile Project Management For Dummies Online Cheat Sheet
  • Scrum For Dummies
  • The Scrum Alliance
  • The Agile Alliance
  • The Project Management Institute Agile Community
  • International Consortium for Agile (ICAgile)
  • InfoQ
  • Lean Enterprise Institute
  • Extreme Programming
  • Platinum Edge
  • Index
  • EULA

Chapter 1

Modernizing Project Management


Understanding why project management needs to change

Finding out about agile project management

Agile project management is a style of project management that focuses on early delivery of business value, continuous improvement of the project's product and processes, scope flexibility, team input, and delivering well-tested products that reflect customer needs.

In this chapter, you find out why agile processes emerged as an approach to software development project management in the mid-1990s and why agile methodologies have caught the attention of project managers, customers who invest in the development of new software, and executives whose companies fund software development departments. This chapter also explains the advantages of agile methodologies over long-standing approaches to project management.

Project Management Needed a Makeover

A project is a planned program of work that requires a definitive amount of time, effort, and planning to complete. Projects have goals and objectives and often must be completed in some fixed period of time and within a certain budget.

Because you are reading this book, it's likely that you are either a project manager or someone who initiates projects, works on projects, or is affected by projects in some way.

Agile approaches are a response to the need to modernize project management. To understand how agile approaches are revolutionizing projects, it helps to know a little about the history and purpose of project management and the issues that projects face today.

The origins of modern project management

Projects have been around since ancient times. From the Great Wall of China to the Mayan pyramids at Tikal, from the invention of the printing press to the invention of the Internet, people have accomplished endeavors big and small in projects.

As a formal discipline, project management as we know it has only been around since the middle of the twentieth century. Around the time of World War II, researchers around the world were making major advances in building and programming computers, mostly for the United States military. To complete those projects, they started creating formal project management processes. The first processes were based on step-by-step manufacturing models the United States military used during World War II.

People in the computing field adopted these step-based manufacturing processes because early computer-related projects relied heavily on hardware, with computers that filled up entire rooms. Software, by contrast, was a smaller part of computer projects. In the 1940s and 1950s, computers might have thousands of physical vacuum tubes but fewer than 30 lines of programming code. The 1940s manufacturing process used on these initial computers is the foundation of the project management methodology known as waterfall.

In 1970, a computer scientist named Winston Royce wrote "Managing the Development of Large Software Systems," an article for the IEEE that described the phases in the waterfall methodology. The term waterfall was coined later, but the phases, even if they are sometimes titled differently, are essentially the same as originally defined by Royce:

  • 1. Requirements
  •  2. Design
  •   3. Development
  •    4. Integration
  •     5. Testing
  •      6. Deployment

On waterfall projects, you move to the next phase only when the prior one is complete - hence, the name waterfall.

Pure waterfall project management - completing each step in full before moving to the next step - is actually a misinterpretation of Royce's suggestions. Royce identified that this approach was inherently risky and recommended developing and testing within iterations to create products - suggestions that were overlooked by many organizations that adopted the waterfall methodology.


Unfortunately, the stagnation in traditional project management approaches is catching up with the software industry. In 2015, a software statistical company called the Standish Group did a study on the success and failure rates of 10,000 projects in the US. The results of the study showed that

  • 29 percent of traditional projects failed outright. The projects were cancelled before they finished and did not result in any product releases. These projects delivered no value whatsoever.
  • 60 percent of traditional projects were challenged. The projects were completed, but they had gaps between expected and actual cost, time, quality, or a combination of these elements. The average difference between the expected and actual project results - looking at time, cost, and features not delivered - was well over 100 percent.
  • 11 percent of projects succeeded. The projects were completed and delivered the expected product in the originally expected time and budget.

Of the hundreds of billions of dollars spent on application development projects in the US alone, billions of dollars were wasted on projects that never deployed a single piece of functionality.

The waterfall methodology was the most common project management approach in software development until it was surpassed by improved approaches based on agile techniques around 2008.

The problem with the status quo

Computer technology has, of course, changed a great deal since the last century. Many people have a computer on their wrist with more power, memory, and capabilities than the largest, most expensive machine that existed when people first started using waterfall methodologies.

At the same time, the people using computers have changed as well. Instead of creating behemoth machines with minimal programs for a few researchers and the military, people create hardware and software for the general public. In many countries, almost everyone uses a computer, directly or indirectly, every day. Software runs our cars, our appliances, our homes; it provides our daily information and daily entertainment. Even young children use computers - a 2-year-old is almost more adept with the iPhone than her parents. The demand for newer, better software products is constant.

Somehow, during all this growth of technology, processes were not left behind. Software developers are still using project management methodologies from the 1950s, and all these approaches were derived from manufacturing processes meant for the hardware-heavy computers of the mid-twentieth century.

Today, traditional projects that do succeed often suffer from one problem: scope bloat, the introduction of unnecessary product features in a project.

Think about the software products you use every day. For example, the word-processing program we're typing on right now has many features and tools. Even though we write with this program every day, we use only some of the features all the time. We use other elements less frequently. And we have never used quite a few tools - and come to think of it, we don't know anyone else who has used them, either. The features that few people use are the result of scope bloat.

Scope bloat appears in all kinds of software, from complex enterprise applications to websites that everyone uses. Figure 1-1 shows data from a Standish Group study that illustrates just how common scope bloat is. In the figure, you can see that 64 percent of requested features are rarely or never used.

Copyright 2011 Standish Group

FIGURE 1-1: Actual use of requested software features.

The numbers in Figure 1-1 illustrate an enormous waste of time and money. That waste is a direct result of traditional project management processes that are unable to accommodate change. Project managers and stakeholders know that change is not welcome mid-project, so their best chance of getting a potentially desirable feature is at the start of a project. Therefore, they ask for

  • Everything they need
  • Everything they think they may need
  • Everything they want
  • Everything they think they may want

The result is the bloat in features that results in the statistics in Figure 1-1.

The problems associated with using outdated management and development approaches are not trivial. These problems waste billions of dollars a year. The billions of dollars lost in project failure in 2015 (see the sidebar, "Software project success and failure") could equate to millions of jobs around the world.

Over the past two decades, people working on projects have recognized the growing problems with traditional project management and have been working to create a better model: agile project management.

Introducing Agile Project Management

The seeds for agile techniques have been around for a long time. In fact, agile values, principles, and practices are simply a codification of common sense. Figure 1-2 shows a quick history of agile project management, dating to the 1930s with Walter Sherwart's Plan-Do-Study-Act (PDSA) approach to project quality.

FIGURE 1-2: Agile project management timeline.

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article...

Dateiformat: ePUB
Kopierschutz: Adobe-DRM (Digital Rights Management)


  • Computer (Windows; MacOS X; Linux): Installieren Sie bereits vor dem Download die kostenlose Software Adobe Digital Editions (siehe E-Book Hilfe).
  • Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions oder die App PocketBook (siehe E-Book Hilfe).
  • E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet – also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an.
Mit Adobe-DRM wird hier ein „harter” Kopierschutz verwendet. Wenn die notwendigen Voraussetzungen nicht vorliegen, können Sie das E-Book leider nicht öffnen. Daher müssen Sie bereits vor dem Download Ihre Lese-Hardware vorbereiten.

Bitte beachten Sie: Wir empfehlen Ihnen unbedingt nach Installation der Lese-Software diese mit Ihrer persönlichen Adobe-ID zu autorisieren!

Weitere Informationen finden Sie in unserer  E-Book Hilfe.