chapter 1 modernizing project management copyrighted …

CHAPTER 1 Modernizing Project Management 7

1.indd 7 Trimsize:7.375in×9.25in August7,20207:15AM

Chapter 1 Modernizing Project Management

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 fl exibility, team input, and delivering well-tested products that refl ect cus-tomer needs.

In this chapter, you fi nd out why agile processes emerged as an approach to soft-ware development project management in the mid-1990s and why agile method-ologies 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.

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

COPYRIG

HTED M

ATERIAL

8 PART 1 Understanding Agility


Project Management Needed a MakeoverA 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 managementProjects 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 pro-gramming 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 com-puters 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 Devel-opment 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 over-looked 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 quoComputer 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 capa-bilities 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.

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 una-ble 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

» Everythingtheyneed

» Everythingtheythinktheymayneed

» Everythingtheywant

» Everythingtheythinktheymaywant

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

FIGURE 1-1: Actualuseof

requestedsoftwarefeatures.

© Copyright 2017 Standish Group



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 three decades, people working on projects have recognized the growing problems with traditional project management and have been working to create a better model.

Introducing Agile Project ManagementThe 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.

SOFTWARE PROJECT SUCCESS AND FAILUREStagnationintraditionalprojectmanagementapproachesiscatchingupwiththesoft-wareindustry.In2015,asoftwarestatisticalcompanycalledtheStandishGroupdidastudyonthesuccessandfailureratesof10,000projectsintheUS. Theresultsofthestudyshowedthat

• 29 percent of traditional projects failed outright.Theprojectswerecancelledbeforetheyfinishedanddidnotresultinanyproductreleases.Theseprojectsdeliverednovaluewhatsoever.

• 60 percent of traditional projects were challenged.Theprojectswerecompletedbut hadgapsbetweenexpectedandactualcost,time,quality,oracombinationof theseelements.Theaveragedifferencebetweentheexpectedandactualproj-ect results —lookingattime,cost,andfeaturesnotdelivered —waswellover100 percent.

• 11 percent of projects succeeded.Theprojectswerecompletedanddeliveredtheexpectedproductintheoriginallyexpectedtimeandbudget.

OfthehundredsofbillionsofdollarsspentonproductdevelopmentintheUSalone,billionsofdollarswerewastedonprojectsthatneverdeployedasinglepieceoffunctionality.



FIGURE

1-2:

Agileproject

man

agem

ent

timeline.



In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article called “The New New Product Development Game” in the Harvard Business Review. Takeuchi and Nonaka’s article described a rapid, flexible development strategy to meet fast-paced product demands. This article first paired the term scrum with product development. (Scrum referred to a player formation in rugby.) Scrum eventually became one of the most popular agile frameworks for delivering value to customers.

In 2001, a group of software and project experts got together to talk about what their successful projects had in common. This group created the Manifesto for Agile Software Development (commonly referred to as the Agile Manifesto), a statement of values for successful software development:

ManifestoforAgileSoftwareDevelopment*

Weareuncoveringbetterwaysofdevelopingsoftwarebydoingitandhelpingothersdoit.Throughthisworkwehavecometovalue:

Individuals and interactionsoverprocessesandtoolsWorking softwareovercomprehensivedocumentationCustomer collaborationovercontractnegotiationResponding to changeoverfollowingaplan

Thatis,whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore.* Agile Manifesto Copyright © 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

This declaration may be freely copied in any form, but only in its entirety through this notice.

These experts also created 12 principles behind the Agile Manifesto that help support the values in the Agile Manifesto. We list the Agile Principles and describe the Agile Manifesto in more detail in Chapter 2.

Agile, in product development terms, is a descriptor for approaches that focus on people, communications, the product, and flexibility. If you’re looking for the agile methodology, you won’t find it. However, all agile methodologies (for exam-ple, Crystal), frameworks (for example, scrum), techniques (for example, user story requirements), and tools (for example, relative estimating) have one thing in common: adherence to the Agile Manifesto and the 12 Agile Principles.

Martin Fowler, one of the co-authors of the Agile Manifesto, writes that many different words were discussed for naming their movement. They considered lightweight methods, adaptive, and many others until landing on agile as the best descriptor of the adaptiveness and responsiveness to change they were seeking.



Other synonyms are resilient, nimble, and healthy. When you think of agile, think healthy. Healthy organizations and teams are agile, resilient, nimble, and responsive.

How agile projects workAgile approaches are based on an empirical control method — a process of making decisions based on the realities observed in the project. In the context of software development methodologies, an empirical approach can be effective in both new product development and enhancement and upgrade projects. By using frequent and firsthand inspection of the work to date, you can make immediate adjust-ments, if necessary. Empirical control requires

» Unfettered transparency:Everyoneinvolvedinanagileprojectknowswhatisgoingonandhowtheprojectisprogressing.

» Frequent inspection:Thepeoplewhoareinvestedintheproductandprocessthemostregularlyevaluatetheproductandprocess.

» Immediate adaptation:Adjustmentsaremadequicklytominimizeprob-lems;ifaninspectionshowsthatsomethingshouldchange,itischangedimmediately.

To accommodate frequent inspection and immediate adaptation, agile projects work in iterations (smaller segments of the overall project). An agile product development effort involves the same type of work as in a traditional waterfall project: You create requirements and designs, develop product features, document what was done and why, and continuously integrate new features. You test the product, fix any problems, and deploy the product for use. However, instead of completing these steps for all product features at once, as in a waterfall project, you break the project into iterations, also called sprints.

Figure 1-3 shows the difference between a linear waterfall project and an agile project.

Mixing traditional project management methods with agile approaches is like saying, “I have a Tesla Model S. However, I’m using a wagon wheel on the front left side. How can I make my car as fast and efficient as the other Teslas?” The answer, of course, is you can’t. If you fully commit to an agile approach, you will have a better chance of project success.



FIGURE

1-3:

Waterfall

versusagile

project.



Agile Project Management Is Becoming Agile Product Management

Traditional projects, by definition, are organized into temporary, build-only team efforts designed to accomplish specific benefits projected in a business case. Proj-ect initiation, which is when we know the least, is when budgets, schedules, and expectations are set. When projects end, the teams are disbanded and unfamiliar operational teams are left to support the customer and product. If more work is required, new team members are allocated to a new project and must refamiliarize themselves with the product architecture. Projects typically end once deliverables are released into production, leaving others to support and evaluate the effect on business.

Today, products are considered long-term, value-creating assets requiring permanent teams who iteratively elaborate, design, develop, test, integrate, document, and even support products until business outcomes are achieved. A high-performing team continuously inspects and adapts until the customer’s problems are solved, and the team retains this hard-earned knowledge. The team and customer collaborate to create value over following written specifications.

More and more we see a project-driven approach as a constraint to delivering customer value early and often. Taking an agile approach to product development limits you not to time or money but to value. Organizations most effectively deliver value when they use the following formula to determine when it’s time to shift priorities:

AC +OC>V,thatis,actualcost+opportunitycost>value

When the actual cost of working on a product’s additional requirements plus the opportunity cost of not working on a different investment opportunity exceed the expected value of delivering those remaining product requirements, the team shifts to developing the more valuable investment opportunity.

Differences between managing a project versus developing a productThree primary differences exist between managing a project and developing a product:



» Productsbenefitmostfromstable,long-lived,andevenpermanentteams.

» Productscanbenotonlyshort-termassetsbutalsolong-termassets.Activeproductsareneverreallyfinishedbecausetheyrequiremaintenanceandimprovements.

» Productsarepartofaportfoliodesignedtomaximizevalueoverfollowingspecifications.

Permanent team over temporary teamLong-lived products are best developed and maintained by long-lived and even permanent teams. The longer a team works together iteratively building an emer-gent architecture and expanding its capability and high performance, the better the team understands the customer and the more predictable the team becomes. Project-focused teams come together for a specific amount of time and then move on to something new. Lessons learned at the end of a project may not even apply to the next project because the context of people, technologies, and customers will most likely be different. Stable permanent teams enable transparency, inspection, and adaptation (empirical process control).

Permanent doesn’t mean that agile product teams don’t change and career aspirations are inhibited. However, team personnel changes are an exception rather than the rule. People — especially people who become more valuable because of their expanding capability — are presented with career-enhancing opportunities. Ideally, permanent team members behave more like a family than as a temporary, one-project-only group.

Products as long-term assets rather than project deliverablesProduct development is risky. Uncertainty abounds at every corner. But uncer-tainty is what makes agile product development ideal! Traditional projects are tasked with accomplishing specific system deliverables within a fixed time frame, but agile product development iteratively reduces uncertainty by building useable, fully functional product increments, gathering and implementing feedback throughout development. The product becomes a customer-aligned, problem-solving asset. Active products are never finished because maintenance must be performed and improvements can be made.

Investments in time, money, and people, particularly with today’s capital expen-diture strategies, change products into depreciable assets that improve bottom-line results for not only revenue but also cost savings. Treating product



development as an asset creator rather than a cost expenditure changes the per-spective of everyone involved. Continuous delivery of customer value through agile product development increases the likelihood of additional funding.

Capital expenditures, commonly known as CapEx, are funds used by a company to acquire, upgrade, and maintain physical assets such as property, buildings, indus-trial plants, technology, and equipment. CapEx is often used to undertake new projects or investments by the firm.

Pursuing value over specificationsEarly failure is a key tenant of agility. Agile teams are obsessed with taking risks to create customer value. Like scientists, they create a hypothesis, test it in the real world, evaluate the results, and then adjust the hypothesis and test it again. They repeat this process again and again, aligning the product more closely to the cus-tomer’s needs with each iteration. Teams trade reams of documented specifications for real-world feedback from the customer. With agile product development, func-tionality priorities are set by the people most familiar with the problem to be solved.

Why agile product development works betterThroughout this book, you see how product development with an agile approach works better than with a traditional approach. Agile approaches can produce more successful products. The Standish Group study, mentioned in the sidebar “Soft-ware project success and failure,” found that while 29 percent of traditional proj-ects failed outright, that number dropped to only 9 percent with agile techniques. The decrease in failure for agile product development is a result of agile teams making immediate adaptations based on frequent inspections of progress and customer satisfaction.

Here are some key areas where agile product development approaches are supe-rior to traditional project management methods:

» Project success rates:InChapter 17,youfindouthowtheriskofcata-strophicprojectfailurefallstoalmostnothingwithagileproductdevelop-ment.Agileapproachesofprioritizingbybusinessvalueandriskensureearlysuccessorfailure.Agileapproachestotestingthroughouttheproductdevelopmenthelpensurethatyoufindproblemsearly,notafterspendingalargeamountoftimeandmoney.



» Scope creep:InChapters 9, 10,and 14,youseehowagileapproachesaccommodatechangesthroughoutproductdevelopment,minimizingscopecreep.Followingagileprinciples,youcanaddnewrequirementsatthebeginningofeachsprintwithoutdisruptingdevelopmentflow.Byfullydevelopingprioritizedfeaturesfirst,youpreventscopecreepfromthreaten-ingcriticalfunctionality.

» Inspection and adaptation:InChapters 12and 16,youfinddetailsofhowregularinspectionsandadaptationworkthroughoutagileproductdevelop-ment.Agileteams —armedwithfrequentfeedbackfromcompletedevelop-mentcyclesandworking,shippablefunctionality —canimprovetheirprocessesandtheirproductswitheachsprint.

Throughout many chapters in this book, you discover how business agility can help you gain control of product outcomes. Testing early and often, adjusting pri-orities as needed, using better communication techniques, and regularly demon-strating and releasing product functionality allow you to fine-tune your control over a wide variety of factors.

chapter 1 modernizing project management copyrighted …

Documents