Agile Project Management For Dummies

Mark C. Layton, Steven J. Ostermiller, Dean J. Kynaston

• Publisher: For Dummies
• Year: 2020
• ISBN:
  9781119677055
• Edition: 3
• Topic: Business
• Subtopic: Project Management
• Index: Business

This updated edition shows you how to use the agile project management framework for success!

Learn how to apply agile concepts to your projects. This fully updated book covers changes to agile approaches and new information related to the methods of managing an agile project.

A gile Project Management For Dummies, 3rd Edition gives product developers and other project leaders the tools they need for a successful project. This book's principles and techniques will guide you in creating a product roadmap, self-correcting iterations of deployable products, and preparing for a product launch. Agile approaches are critical for achieving fast and flexible product development. It's also a useful tool for managing a range of business projects.

Written by one of the original agile technique thought-leaders, this book guides you and your teams in discovering why agile techniques work and how to create an effective agile environment. Users will gain the knowledge to improve various areas of project management.

• Define your product's vision and features
• Learn the steps for putting agile techniques into action
• Manage the project's scope and procurement
• Plan your team's sprints and releases
• Simplify reporting related to the project

A gile Project Management For Dummies can help you to better manage the scope of your project as well as its time demands and costs. You'll also be prepared to skillfully handle team dynamics, quality challenges, and risks.

Part 1

Understanding Agility

IN THIS PART …

Understand why project management has modernized due to the flaws and weaknesses in historical approaches to project management.

Find out why agile methods are becoming more product-focused than project-focused, and become acquainted with the foundation of agile product development: the Agile Manifesto and the 12 Agile Principles.

Discover the advantages that your products, projects, teams, customers, and organization can gain from adopting agile techniques.

Understand the importance of placing the customer’s needs first and why agile techniques help to make the customer central to every decision, functionality, and problem.

Chapter 1

Modernizing Project Management

IN THIS CHAPTER

Understanding why project management needs to change

Seeing how agile project management is becoming agile product management

Finding out about agile product development

Agile is a descriptor of a mindset approach to project management that focuses on early delivery of business value, continuous improvement of the product being created and the processes used to create the product, 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 products and services, and executives whose companies fund product development. While business agility is popular in software product development, agile values, principles, and techniques apply in a multitude of industries and applications — not just software. This chapter also explains the advantages of agile approaches over long-standing project management methodologies.

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're reading this book, you're likely 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 product development, 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 been around only 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.

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 tablet or smartphone, 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 —2-year-olds are almost more adept with the iPhone than their parents. The demand for newer, better 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. 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 80 percent of requested features are infrequently or never used.

© Copyright 2017 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.

SOFTWARE PROJECT SUCCESS AND FAILURE

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 we...