Agile Project Management Vol. 7, No. 10 The Lean-Agile PMO · The Lean-Agile PMO: Using Lean...

The Lean-Agile PMO:Using Lean Thinking to AccelerateAgile Project Delivery

by Sanjiv Augustine and Roland Cuellar

Corporate project portfolios are routinely challenged in many

organizations. Executives will often see projects that are late

and overbudget, deliver poor value, and have less-than-satisfied

business sponsors and end users. In this Executive Report, we offer

suggestions on how to combine Agile project delivery at the

project level with Lean thinking at the portfolio level in order to

significantly increase project throughput, financial investment

performance, and business sponsor satisfaction.

Agile ProjectManagement

Vol. 7, No. 10

http://www.cutter.com

About Cutter ConsortiumCutter Consortium is a unique IT advisory firm, comprising a group of more than 150 internationally recognized experts who have come together to offer content,consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, ground-breaking work in organizations worldwide, helping companies deal with issues inthe core areas of software development and agile project management, enterprisearchitecture, business technology trends and strategies, enterprise risk management,business intelligence, metrics, and sourcing.

Cutter delivers what no other IT research firm can: We give you Access to theExperts. You get practitioners’ points of view, derived from hands-on experience withthe same critical issues you are facing, not the perspective of a desk-bound analystwho can only make predictions and observations on what’s happening in themarketplace. With Cutter Consortium, you get the best practices and lessons learnedfrom the world’s leading experts, experts who are implementing these techniques at companies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats includingprint and online advisory services and journals, mentoring, workshops, training,and consulting. And by customizing our information products and training/consultingservices, you get the solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for allenterprises, or all departments within one enterprise, or even all projects within adepartment. Cutter believes that the complexity of the business technology issuesconfronting corporations today demands multiple detailed perspectives from which acompany can view its opportunities and risks in order to make the right strategic andtactical decisions. The simplistic pronouncements other analyst firms make do nottake into account the unique situation of each organization. This is another reason topresent the several sides to each issue: to enable clients to determine the course ofaction that best fits their unique situation.

For more information, contact Cutter Consortium at +1 781 648 8700 [email protected].

Cutter Business Technology Council

Access to the

Experts

Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Lou Mazzucchelli Ed YourdonRob Austin

mailto:[email protected]


by Sanjiv Augustine and Roland Cuellar

The Lean-Agile PMO:Using Lean Thinking to Accelerate Agile Project DeliveryAGILE PROJECT MANAGEMENTADVISORY SERVICEExecutive Report, Vol. 7, No. 10

Talk to an executive in a Fortune500 company, and you will likelyencounter frustration with theorganization’s ability to reliablydeliver projects in execution ofits strategic objectives. Talk tomanagers tasked by the executivewith managing the organization’sproject portfolio, and it won’ttake long for you to figure outhow difficult their project portfoliomanagement (PPM) job is. Mostmidsized-to-large organizationshave a project portfolio situationthat looks something like thesample illustrated in Table 1.

If this PPM picture looks familiar,should portfolio managers resignthemselves to this fate, or cansomething definitive be doneto improve this situation? Whatabout the program managementoffices (PMOs)? Are PMOs helping

with these issues and the deliveryof the project portfolio as a whole?

ARE PMOs HELPING WITHPORTFOLIO MANAGEMENT?

Speak with managers in the PMO,and they will confess their lack ofempowerment to attack the mostdifficult PPM problems. Typically,PMOs are set up to focus on theimprovement of project manage-ment practices across the organi-zation. PMOs tend to see theirpurpose as providing training andmentoring to project teams or aug-menting their capabilities to helpindividual projects inculcate proj-ect management best practices.

So the typical PMO focus onproject management practicesdoesn’t really align directlywith the portfolio managementfunction of the organization. How

can managers in the PMO beempowered to use their talents toincrease the delivery of businessvalue and to improve businesscustomer and team satisfaction atthe same time? The answer lies inthe establishment of a Lean-AgilePMO that is directly tasked withmanaging the project portfolio todeliver business value across theorganization (see sidebar “What IsLean Thinking?” on page 3).

CAN AGILE HELP THE PMO WITH PPM?

There is evidence of the growingadoption of Agile practices at theproject level and the businessvalue they deliver. ForresterResearch reports that 14% ofNorth American and Europeanearly adopter enterprises areusing Agile, and a second waveof adoption involving another 19%


VOL. 7, NO. 10 www.cutter.com

22 AGILE PROJECT MANAGEMENT ADVISORY SERVICE

The Agile Project Management Advisory Service Executive Report is published by the Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA. Client Services: Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America, +1 800 888 1816; E-mail: [email protected]; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: [email protected] Editor: Cindy Swain, E-mail: [email protected]. ISSN: 1536-2981. ©2006 by Cutter Consortium. All rights reserved. Unauthorized repro-duction in any form, including photocopying, faxing, image scanning, and downloading electronic copies, is against the law. Reprints make anexcellent training tool. For more information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or [email protected].

Resulting IssuesPPM Goal Conventional

PPM Practice

Deliver

faster

to market

Meet

diverse

business

partners’

needs

Meet

changing

business

objectives

Allocate

resources

effectively

Create

innovative

solutions

Track and

monitor

portfolio

performance

Kick off more and more projects to deliver “concurrently” on strategic objectives.

Get as many projects from as many business centers started.

Try and anticipate all potential changes at the beginning of the yearly cycle.

Make sure people and resources are 100% utilized.

Deal with innovation as an afterthought.

Create estimates at project kickoff, measure spottily, or not at all at project end.

• Several hundred incomplete projects in the project portfolio. • Projects are sometimes prioritized within each business unit, but there is no sense of which projects take priority strategically across the organization as a whole.• At least 30% of small and midsized projects in the portfolio are delivered late, nearly 100% of large projects are behind schedule, and at least 15% of projects are seriously “sick.” • The portfolio as a whole seems sluggish and its time to market has become a serious issue competitively.

• Functional executives regularly push their pet projects, trapping portfolio management officers in the unenviable position of having to mediate between functional divisions or, alternatively, simply accepting all projects into the already loaded portfolio.• Competition for resources and projects exists within and across business units.• Projects are not prioritized in alignment with business strategy.

• Business customer satisfaction is low despite many projects actually being delivered to specified requirements.• Customer demand invariably changes midcycle, causing planning and resource allocation nightmares. • More projects mean more people and resources and scrambling to keep up. • Difficulty predicting demand to appropriately allocate people and resources.

• Project team members are allocated to, and working on, anywhere from three to seven projects simultaneously. • Highly skilled team members are stretched the most because they are repeatedly called on to get things done on multiple projects simultaneously. • Project team morale is especially low on ailing projects.

• External customers are not clearly identified resulting in solutions that may not meet their needs.• There is no “room” or budget for innovation in the portfolio resulting in commodity products.

• There is no accurate measurement of the true capacity of the organization to deliver (the right) projects in execution of the organization’s strategy. • Reporting to executive management is poor, or executive management is simply not involved in managing the project portfolio.

Table 1 — Typical Project Portfolio in a Large Organization


is underway with corporate ITenterprises leading the masses[4]. And a recent survey by theAgile lifecycle product companyVersionOne indicates that 60%of organizations adopting Agilemethods realize a greater than 25%acceleration in time to market [7].However, since Agile practicesfocus primarily at the project level,they do not directly address themore painful challenges of PPM.These include too many projects inthe pipeline, multiple “sick” proj-ects, overallocated resources, andoverburdened team members.

Our experiences directly deliver-ing and helping to deliver Agileprojects over the past seven yearsindicate that, in order to resolvemany of the typical PPM issuesand effectively manage the projectportfolio, Agile practices at theproject level must be comple-mented by the application of Leanprinciples at the portfolio level.The pioneering work done byMary and Tom Poppendieck in thearea of Lean software develop-ment over several decades cor-roborates our experience [2].

Put another way, we advocatethat the primary work of the PMOshould be to help executivesmaximize long-term growth andfinancial performance. A Lean-Agile PMO can best accomplishthis work by redefining its rolefrom managing project-level bestpractices to that of managingthe project portfolio using Leanprinciples and Agile practices.Primarily, this will require a

change in the focus for boththe PMO and PPM: moving fromoptimizing separate technologiesand assets at the project level tooptimizing the flow of productsthrough the entire value stream.

In this Executive Report, we pre-sent a roadmap for establishinga Lean-Agile PMO: first, by analyz-ing the effects of Agile projects onan organization and defining theLean-Agile PMO, and then by pro-viding guidance for setting up theLean-Agile PMO and managingthe Lean-Agile project portfolio.

THE EFFECTS OF AGILE PROJECTS ON ORGANIZATIONS

Independent surveys and experi-ence reports from practitioners ina variety of industries indicate thatAgile methods are delivering valueto the organizations that adoptthem. What’s not as clear arethe challenges faced at the proj-ect portfolio level when Agile

methods are successful at theproject level. To deal with PPMissues and to effectively manageportfolios with a significant num-ber of Agile projects, we need tounderstand the effect of Agileprojects on the organization. Table2 provides a summary of the posi-tive and negative effects of Agileprojects on adopting organiza-tions, and a discussion follows.

The Effect of Agile onBusiness Value Delivery

With traditional delivery methods,such as the waterfall softwaredevelopment lifecycle, there islittle or no opportunity for earlyand incremental delivery withina project. Agile projects by naturecan deliver financially meaningfulinterim results early and often,impacting the decision-makingprocess and the operations ofthe PMO in several ways. Firstof all, the portfolio manager will— possibly for the first time — be

©2006 CUTTER CONSORTIUM VOL. 7, NO. 10

EXECUTIVE REPORT 33

WHAT IS LEAN THINKING?

Lean thinking is a the term popularized over a decade ago by Jim Womack andDan Jones in their book of the same name (Simon & Schuster, 1996) and refers tothe five core principles behind the Toyota Production System (TPS):

1. Specify value by product.

2. Identify the value stream for each product.

3. Make value flow without interruptions.

4. Let the customer pull value from the producer.

5. Pursue perfection.

TPS and its supporting Lean culture, first set in place at Toyota after World War II,continues to drive Toyota’s incredible financial success even today. According toWomack and Jones’s Lean Enterprise Institute, Lean thinking changes the focus ofmanagement from optimizing separate technologies and assets to optimizing theflow of the product through the entire value stream.



able to measure actual projectperformance on several levels,while the project is still in execu-tion mode. For example, withinterim Agile deliveries, the man-ager can more accurately assess:

Schedule performance. Agileprojects give a much clearerindication of actual perfor-mance than traditional proj-ects, since Agile projects areorganized and tracked at thelevel of functional deliverablesinstead of at an activity level.In a traditional project, progressis measured in terms of mile-stone completion percentagesor in terms of earned value. Soon a typical project, we mightsay, “We are 80% completewith the design phase and arehence on track to meet ourschedule.” We have all seenprojects that completed thedesign phase on time but fellapart during construction ortesting long after substantial

money had been spent andcareer defining commitmentswere made.

Budget performance. Are thefinancial burn rate, the projectvelocity, and the remaininghigh-priority scope still compat-ible with the project budget?With Agile, managers canextrapolate the feature-levelburndown charts to get fairlyaccurate insight into whetheror not the available budget willsupport the development of theremaining features. Also, giventhe incremental nature of Agiledevelopment, business cus-tomers will be able to makebetter feature tradeoffs oncethe budget begins to get tight.Using Agile, business cus-tomers are in a position tochoose which of the remainingfeatures will bring the mostvalue to the organization for theremaining expenditure.

Risk management. Whenteams start to tackle the high-priority scope items early in theproject, they run up againstproject risks earlier. They dis-cover the technical issues anduncover serious requirementsmisunderstandings sooner andare compelled to deal withintegration issues earlier. Agilebrings risk forward, and thisgenerates highly valuable infor-mation for the managementteam much sooner in thedevelopment cycle. Waterfallprojects are simply too back-loaded in terms of informationgeneration for the managementteam to make well-informeddecisions on how to best exer-cise their options midcourse.Using Agile, the PMO can nowhave meaningful reviews ofinterim project performanceand can make more informeddecisions that will ultimatelybenefit the organization.

Business value

delivery

• Schedule performance• Budget performance• Risk management• Flexibility through options• Early financial returns

• Increased resource contention

• Misaligned measurement, reporting, and auditing

Business customer

satisfaction

• Project throughput• Flexibility and control• Reliable delivery

• Need for regular tradeoffs• Clearer accountability for business value definition• Higher visibility

• Clearer accountability• Higher utilization on non-Agile projects

Potential Positive EffectsCategory Potential Negative Effects

Project team

satisfaction

• Clear value to the organization• Participation in high-performance teams• Culture shift

Table 2 — Effects of Agile Projects


Flexibility through options.Toward the end of an Agileproject, only lower-prioritywork should remain. Therefore,it is conceivable that anotherproject in the portfolio man-ager’s project queue hasrequirements that are of highervalue to the business thanthe remaining requirementson a current in-flight project.Therefore, the portfolio man-ager could be in a position tomake the following decision:“Let’s get to a stopping pointsoon on project X and take thebenefits that have been deliv-ered so far. We will then focusthe team on another projectthat has come up that is morecritical to the business than theremaining scope on project X.”This decision is extremelydifficult to make in a waterfallenvironment, since stopping aproject early usually means analmost entirely wasted projecteffort. It also allows the PMO tosubstantially increase the valuedelivered to the organizationby always refocusing the teams

on the highest priority projectsin an environment of ever-changing priorities.

Early financial returns. At themetrics level, Agile can put theportfolio manager in a positionof greatly increasing financialperformance. Many organiza-tions use net present value(NPV) as a metric for projectfinancial performance. Thereare many reasons for usingNPV. One of the strongest isthat NPV takes into account thetime value of money. NPV rec-ognizes that a dollar of cashflow today is worth more thana dollar of cash flow nextmonth. (In comparison, ROIdoes not consider the timing ofcash flows and, therefore, thecost of capital into account.Consequently, ROI tends toovervalue projects.) Agile hasthe capability to deliver mean-ingful business value early; asa result, NPV combined withAgile is a powerful financialcombination. In fact, we oncesaw a real Agile project for a

Fortune 500 firm that generated80% of the project businessvalue after the first iteration.The effect of early delivery is asubstantial lift to financial per-formance as measured by NPV.The following is an examplethat illustrates how.

Consider a simple project thatis using Agile. Since it is usingAgile, it has a fixed team andthus a fixed burn rate. In this case,the burn rate for the team is US$100,000 a month. The systemwill be delivered after five months,and once it is delivered, it willsave the company $200,000 amonth due to efficiency gainsfor users. Internally, the companycharges its IT projects a 15% hur-dle rate or internal cost of cash.

Now imagine two delivery models.In the first, one delivery is madewaterfall-style at the end of theproject, and we calculate a one-year NPV based upon the cashflows. The NPV is illustrated inTable 3.


EXECUTIVE REPORT 55

Annual Hurdle Rate

Monthly Rate

Month

Cash Out

Cash In

Net Cash

NPV

15%

1.25%

1

-100

0

-100

$771

2

-100

0

-100

3

-100

0

-100

4

-100

0

-100

5

-100

0

-100

6

0

200

200

7

0

200

200

8

0

200

200

9

0

200

200

10

0

200

200

11

0

200

200

12

0

200

200

*All cash flows are in thousands (US dollars).

Table 3 — Project NPV with Waterfall Delivery

Annual Hurdle Rate

Monthly Rate

Month

Cash Out

Cash In

Net Cash

NPV

15%

1.25%

1

-100

0

-100

$771

2

-100

0

-100

3

-100

0

-100

4

-100

0

-100

5

-100

0

-100

6

0

200

200

7

0

200

200

8

0

200

200

9

0

200

200

10

0

200

200

11

0

200

200

12

0

200

200

Annual Hurdle Rate

Monthly Rate

Month

Cash Out

Cash In

Net Cash

NPV

15%

1.25%

1

-100

0

-100

$

2

-100

0

-100

3

-100

25

-75

4

-100

50

-50

5

-100

75

-25

6

0

200

200

7

0

200

200

8

0

200

200

9

0

200

200

10

0

200

200

Note that the project spends$100,000 every month for fivemonths. Then it gains back$200,000 a month for the com-pany every month thereafter forthe remainder of the year. Thisproject has a positive NPV, so itis a financially sound project.

Now look at what happenswhen we use the power of Agileto deliver incremental value.Suppose that there are a few fea-tures that would generate somemodest marginal cost savingssooner if we could deliver themsooner. Table 4 shows what hap-pens if we can find a few featuresthat might generate as little as$25,000 a month in savings afterjust three months of development.The team delivers a feature inmonth three that saves somedepartments $25,000 a month.In month four, the team deliversanother $25,000 in savings, andagain in month five.

After three months of develop-ment, this team releases a fewfeatures that start to save some-one in the company some money.Even this modest early additionalpositive cash flow in monthsthree, four, and five will yieldan 18% improvement in NPV.Multiply this 18% across manyprojects, and the financial perfor-mance that IT is bringing to thebusiness will be substantial.Not too many businesspeoplewould scoff at an 18% improve-ment in investment performance.Agile’s ability to generate real andmeasurable financial performanceimprovements should be a strongmotivator for middle and seniormanagers to further adopt the useof Agile. Oh, and don’t forget: theusers who are able to start usingparts of the system early to helpthem do their jobs are going to bevery happy.

So far we have focused primarilyon the positive effects of Agileupon business value delivery.These positive impacts are realand profound in many organiza-tions; hence, the growing adoptionof Agile methods. However, Agileproject delivery can certainly havesome potentially profound con-tentious impacts upon the organi-zation as well. These impacts willneed to be anticipated and man-aged if Agile is to succeed toany level of scale. The negativeimpacts of Agile may include:

Increased resource contention. We alwaysrecommend that Agile coreteam members be allowedto devote 100% of their timeand energy to a single project.But extended team members,such as database administra-tors (DBAs), subject matterexperts (SMEs), and otherspecialists, will often need



Annual Hurdle Rate

Monthly Rate

Month

Cash Out

Cash In

Net Cash

NPV

NPV Increase

15%

1.25%

1

-100

0

-100

$913

18%

2

-100

0

-100

3

-100

25

-75

4

-100

50

-50

5

-100

75

-25

6

0

200

200

7

0

200

200

8

0

200

200

9

0

200

200

10

0

200

200

11

0

200

200

12

0

200

200


Table 4 — Project NPV with Agile Delivery


to support more than oneproject. Furthermore, in a typi-cal portfolio, not all projectswill be Agile. Such a portfoliomix of Agile and non-Agileprojects can lead to seriousresource contention for theshared resources. Since theAgile projects are “off-bounds,”1

resource managers used toallocating people to multipleprojects can end up increasingthe utilization of people onnon-Agile projects. Thisincreased contention forresources and people leadsto a number of problems.Not only does it decrease thethroughput2 of the non-Agileprojects, it lowers the produc-tivity of the individuals workingon those projects. Also, whenshared specialists are support-ing other non-Agile projects,this will often slow the Agileteam down since the Agileteam may get blocked waitingfor the specialist to performsome function.

Misaligned measurement,reporting, and auditing.Most organizations have met-rics and governance proce-dures that are tuned to a yearlycycle and for waterfall deliver-ies. For instance, business plan-ning and budgeting is typicallydone once a year in most orga-nizations. This creates the needfor detailed up-front budgetestimates that will likely notbe updated until the next

budgeting cycle. How willthe incremental funding anddelivery of projects fit into thiscycle? Both are likely to bemisaligned with incrementalAgile delivery, unless they areadapted to accommodatethem. Finally, PMOs may haveaudit checkpoints that requirea full requirements reviewand signoff prior to design ora detailed design review priorto coding. Such phase gatesare in obvious conflict withAgile, and if the audit andmeasurement checkpointsare not adjusted, there will bemuch conflict between theaudit teams and the Agiledelivery teams.

The Effect of Agile on BusinessCustomer Satisfaction

Perhaps the most significantimpact of Agile projects is theeffect they have on businesscustomer satisfaction. Is thebusiness sponsor satisfied withthe functionality delivered, theperformance of the team, thesuitability of the product, and thecontinued alignment of the proj-ect against strategic goals? Frombusiness sponsors to productowners, Agile methods have theability to put the business in thedriver’s seat in the journey todeliver business value.

Some of the positive effectsfrom business customers’perspectives are:

Project throughput. To busi-ness customers in large organi-zations, it sometimes feels likegetting even the simplest thingdone is a major achievement.Ask a business customer aboutwhat they’d most like to seeimproved about project deliv-ery, and they are likely to say,“The faster the better.” Movingprojects faster through the port-folio pipeline and completedon a regular basis is one of thebiggest benefits of Agile. Asmentioned previously, earlierdelivery usually means earlierfinancial returns. Earlier finan-cial performance combinedwith on-time delivery canresult in very satisfied businesscustomers.

Flexibility and control. Beingable to control projects betterby chunking and regularlyprioritizing project releases inresponse to changing businessconditions is a powerful toolfor business customers. Forinstance — probably for thefirst time — business sponsorsare able to see actual interimversions of the product and cantherefore make well-informeddecisions about the continuedfunding of the project. This isalmost impossible in a tradi-tional environment where,halfway through the project,all the funding manager has isa design document and somehalf-working code.


EXECUTIVE REPORT 77

1Since Agile team members are typically dedicated to a single project, they are not usually available to multitask on multiple projects.2In project portfolio management, throughput is the rate at which projects net money for the business.

Reliable delivery. Havingprojects delivered on a regulariterative schedule creates con-fidence in the reliability of proj-ect delivery among businesscustomers. Creating a cadenceof regular, reliable project deliv-eries helps iron out the issuesof integration, testing, deploy-ment into production, and soon, which ensures smoothdelivery to business customersand end users.

Some of the potentially negativeeffects from business customers’perspectives include:

Need for regular tradeoffs.In many organizations, businesscustomers are used to havingmany projects being worked onat the same time, giving themthe illusion that they are gettingthings done. In reality, manycompromises in scope, quality,and so on are made along theway just to get something deliv-ered to market and becauseof overutilization of resources,all projects in the portfolio getdelayed. Agile projects requirethat business sponsors and cus-tomers make regular tradeoffsup front and also along theway. Making these tradeoffscan be very painful. Forinstance, a questionably func-tioning project that has beensucking up all the resourcesmay have to be cancelleddespite being a pet project of apowerful business executive.

Clearer accountability forbusiness value definition.

With rights come responsibili-ties. Business customers getpowerful rights to decide onprojects based on their busi-ness value. But there’s no freelunch here. Project sponsorswill need to clearly define busi-ness value and take responsi-bility for delivering it. If projectsare delivered to their specifica-tions and desired timeline, andthe projects do not deliver busi-ness value in line with strategicobjectives, business customersare responsible and account-able. The unequivocal natureof these rights and responsibili-ties place clear accountabilityfor the definition of businessvalue on business sponsorsand customers. While somebusiness customers maythrive in this environment —enjoying the gratification ofrapid turnaround on theirvalue-generating ideas —other business customersmay not make the transitionto Agile successfully.

Higher visibility. Because ofquicker incremental deliveryschedule of each project, andpotentially faster delivery on allAgile projects in the portfolio,success and failures are bothmuch more visible. Word aboutdelivery, good or bad, gets outfaster. This ends up puttingmore responsibility for effec-tively defining, managing, anddelivering projects on bothbusiness customers anddelivery teams.

The Effect of Agile on Project Team Satisfaction

Historically, Agile methodologieswere somewhat unique in thatthey were adopted and popular-ized by project team membersbefore they were adopted bymanagement. To date, our experi-ence indicates that although exec-utives and project managers areincreasingly embracing Agilemethods, some middle managersstill have trouble embracing them.That said, when Agile methodsare implemented correctly, theycan improve the experience ofproject team members and man-agers all around.

Some of the positive effects fromteam members’ perspectives are:

Clear value to the organi-zation. From developers to busi-ness analysts and testers, exceptfor a few bad apples, most teammembers are interested indoing a good job and contribut-ing value to their organizations.Most people want to havemeaning in their lives, and theywant their job contribution todeliver some of this personalmeaning. Perhaps that is whyeach of us can clearly remem-ber the projects on which wedirectly contributed value to ourorganizations. Agile projectsclearly link the contribution ofteam members to businessvalue and hence to value con-tributed to the organization.Having business customersdirectly involved in the projectmakes this feedback occur




more often and rapidly. Teammembers’ contributions areappreciated by business cus-tomers at every stage, leavingno room for doubt about indi-vidual contributions.

Participation in high-performance teams. Just aswe can all remember the proj-ects on which we added signifi-cant value, we can all alsoremember the projects inwhich we were part of high-performance teams. The col-laborative basis, business valuefocus, and tight delivery sched-ules of Agile methods lendthemselves admirably towardhelping create an environmentin which skilled performers cangel into these powerful teams,delivering significant businessvalue in positive environments.

Culture shift. Years of bureau-cratic practices built up withwaterfall methods, onerouscompliance requirements,and silo organizations havecreated an atmosphere inindustry where waste andmediocre delivery is not onlypermissible but almostexpected. Agile methods canraise the bar in rejecting thiscultural norm. In the Agile cul-ture, waste and mediocrity arenot permissible. Agile projectteams strive continually todeliver business value and tofoster environments and cul-tures that support this goal. Forindividuals who enjoy operat-ing in this environment, Agileprojects and the culture they

foster can be nothing short ofexhilarating.

Some of the negative effects fromteam members’ perspectives are:

Clearer accountability. Iterativedelivery with short iterations(one to four weeks in mostAgile projects) creates the needto constantly deliver somethingof business value. Since busi-ness customers work in closecoordination with projectteams, there is a constant pres-sure to deliver value. Withinteams, because team sizes aresmall, there is much clearer visi-bility into who is actually doingwhat. Communication mecha-nisms, like the daily standupmeeting where each teammember reports progress, havethe effect of making individualteam members much moreaccountable. Floating alongwithout contributing to the teameffort becomes very visible andcan bring on the disfavor of theentire team. Not everyone ispleased with this change inenvironment. There are defi-nitely some people who areused to negotiating the politicsand dynamics of organizations,especially large ones, to findways to float without pullingtheir weight. These individualsare very likely to dislike theaccountability that Agile meth-ods place on project teams andindividuals within them.

Higher utilization on non-Agile projects. As men-tioned previously, since the

people allocated to Agile proj-ects are off-bounds, ingrainedbehavior among resource man-agers can end up increasingthe utilization of people onnon-Agile projects. Instead ofworking on three to four proj-ects at a time, individuals work-ing on non-Agile projects mayend up being tasked with workfrom five to six projects. Notonly does this create the con-tention for resources previouslymentioned, it can also createresentment among individualsworking on non-Agile projects.Since team members on Agileprojects get to work on oneproject at a time, they will beperceived as receiving prefer-ential treatment in the form ofa lighter project workload.

Agile projects have a variety ofpotentially positive and/or nega-tive effects on business valuedelivery, business customer satis-faction, and team satisfaction.Keeping the analysis of thesepotential effects and the PPMissues laid out earlier in mind,let’s now turn our attention tohow we can apply Lean thinkingand Agile projects to the creationof the Lean-Agile PMO. Such aPMO that is organized aroundLean principles will be able tobetter garner the positive returnsthat Agile development offers,while simultaneously puttingitself in a better position to dealwith the inevitable issues thatwill arise when moving to Agile.In the remaining sections, we willdefine the Lean-Agile PMO in


EXECUTIVE REPORT 99

terms of its organization structureand its operating principles anddiscuss how to setup the Lean-Agile PMO to manage the Lean-Agile project portfolio.

DEFINING THE LEAN-AGILE PMO

To define the Lean-Agile PMO, wecover two of its basic aspects: itsorganizational structure and itsoperating principles. We definethe organizational structure of theLean-Agile PMO as well as itsposition in relation to executivemanagement and Agile projectteams. Its operating principlesdraw heavily on Lean thinkingas they apply to PPM.

Organizational Structure

When organizing the Lean-AgilePMO, we should be careful not toconvey the common practice oftaking the organization’s best proj-ect managers and insulating themfrom in-the-trenches work bysequestering them in the PMO.We also need to ensure that weavoid a structure that will orient

us toward traditional top-down,command-and-control manage-ment and cause stress betweenthe Lean-Agile PMO and Agileteams it will be chartered to sup-port. So in essence, we need tocreate an organizational structurethat is:

Intimately linked to the execu-tives who determine strategicobjectives, yet autonomousenough to avoid autocraticmanagement

Intimately linked to and collab-orative with Agile project teamsthat deliver on the strategicobjectives, yet directed enoughthat it avoids getting boggeddown in consensus-style deci-sion making for everything

Self-organizing so that it can beadaptive to change and meetthe complexities of managinglarge project portfolios with sig-nificant levels of complexity

Figure 1 illustrates how thesegoals can be achieved through a

flexible organizational structurefor the Lean-Agile PMO.

The salient points of this organiza-tional structure are:

Linking-pin representatives.The Lean-Agile PMO isconnected via “linking-pin” rep-resentatives to the higher-levelsteering committee and to theproject teams [6]. For instance,it includes at least two man-agers of Agile project teams.It also includes at least twoexecutives, preferably one eachfrom the delivery and businesssides of the organization.

Elected representatives.Key roles like the ScrumMaster(Scrum’s version of a projectmanager) for the Lean-AgilePMO, representatives fromproject teams other thanproject managers, andrepresentatives to the steeringcommittee are elected fromlower to higher levels: projectteams elect representatives tothe PMO, and the PMO electsits own representatives to thesteering committee [3].

Agile management. The Lean-Agile PMO is set up to use stan-dard Agile practices. It has itsown ScrumMaster who leads itin short iterations for delivery. Ituses standard Scrum practicesand artifacts, such as a priori-tized long-term backlog that iscreated and updated in regularrelease planning meetings, aprioritized short-term backlogthat is created and updated inregular sprint planning/review



Figure 1 — The Lean-Agile PMO organizational structure.


meetings, daily standup meet-ings, and regular tracking andmonitoring.

Having a combination of linking-pin representatives who areassigned top-down and electedrepresentatives who are electedbottom-up to straddle manage-ment levels can help ensure thatthe Lean-Agile PMO’s hierarchy isnot autocratic. Committing theLean-Agile PMO itself to usingAgile practices can help ensurethat it stays self-organizing andadaptive to change. Next, we’llcover operating principles for theLean-Agile PMO.

Operating Principles

Lean-thinking advocates reducingwaste to optimize the flow of busi-ness value across the organizationto the business customer (seesidebar “Reducing PPM Waste inLean Fashion”). Waste is definedas anything that does not addbusiness value. This focus is verydifferent from the traditional PPMfocus on asset utilization andother forms of “local” optimiza-tion. Lean thinking advocates“managing the whole” and opti-mizing globally across the valuestream. When we get our projectsflowing through the organizationfaster, we start to deliver com-pleted projects sooner, whichmeans that we start to satisfy cus-tomers sooner, and thus generatecash flows sooner.

To reduce waste and make proj-ects flow through the projectportfolio as fast as possible, the

Lean-Agile PMO needs a set ofoperating principles. We havefound the following three operat-ing principles — based on Leanthinking and Agile methods — tobe most effective in managingproject portfolios:

1. Align continuously.

2. Manage project throughput.

3. Manage system constraints.

Now, let’s look at each of theseprinciples in some detail before

we learn how to apply themthrough the Lean-Agile PMO.

1. Align Continuously

Besides loading the portfolio withtoo many projects, one of the eas-iest mistakes for portfolio man-agers to make is to fall out ofalignment with the organization’sstrategy. It is all too easy to missthe “strategy alignment” forest forthe “operational management”trees. Allocating resources toprojects, soliciting the status of


EXECUTIVE REPORT 1111

REDUCING PPM WASTE IN LEAN FASHION

Lean strives to eliminate all forms of waste — anything for which customers willnot pay or that does not contribute directly to the creation of business value.Here’s how Lean thinking can be applied to reduce PPM waste:

Overproduction. This exists when there are too many projects in flight at onceand too many requirements to develop at once. Developing requirementsfaster than we can write code. Developing code faster than we can test it.Do not start projects at a faster rate than they complete. Do not write require-ments at a faster rate than they can be developed.

Inventory. Software projects have expensive inventory, too. Requirementsdocuments, design documents, test plans, software code are all examples of“work in process” inventory that are invisible but are extremely expensive.Reign in document production and maximize product delivery. Completequickly to reduce tied up “working capital.”

Transportation and motion. Moving parts around consumes resources andtakes time. In the software world, eliminate handoffs of large documentsacross organizations. Handoffs are slow and error-prone. Use multiskilled Agileteams to enhance communications, eliminate handoffs, and reduce errors.

Processing time. Make value flow faster. Reduce processing time by prioritiz-ing projects and prioritizing requirements. Have fewer parallel projects andfewer parallel requirements. Focus on delivering early value at both the port-folio and project levels.

Idle time. Keep projects from idling in the portfolio going nowhere. Makeprojects flow by getting them the resources they need and reducing con-tention for shared resources.

Bad quality. Eliminate defects at the source. Do not pass defects down tothe next organization. On Agile projects, eliminate defects as early as possiblethrough early feedback, early testing, and integrated teams.

individual projects, and trackingand monitoring the financialhealth of the portfolio are allimportant operational aspectsof the portfolio manager’s job.However, all of these will notdeliver true value unless the port-folio itself is aligned to the strate-gic objectives of the organization.As business conditions change,the project portfolio will requireconstant steering to keep italigned with strategy. How canthe Lean-Agile PMO ensure thatalignment with the strategy is adynamic occurrence and not justa once-a-year exercise?

The simplest way to accomplishthis is to adopt the Agile practiceof prioritization by business value.Agile prioritization techniqueslike release and iteration planningcan easily be translated from theproject to the portfolio level. So,in place of building a productbacklog of high-level user storiesthat are delivered on an individualproject, the Lean-Agile PMO can

build a backlog of high-levelobjectives that are deliveredthrough multiple projects in theportfolio. Business executives andmanagers will be responsible forcreating and constantly reprioritiz-ing this project backlog on anongoing basis to ensure a matchwith the strategic objectives of theorganization.

2. Manage Project Throughput

Imagine, if you will, a crowdedhighway at rush hour in a majorcity. Traffic is bumper to bumper,and nobody is getting anywherequickly, as illustrated in Figure 2.The highway, however, is beingefficiently utilized; almost everysquare foot of this very expensiveresource has a car on it.

Given this highly efficient utiliza-tion, why are we not able to movefaster? The reason is that utiliza-tion and throughput are often neg-atively correlated, as illustrated inthe figure. That is, the higher theshared utilization of a scarce

resource, the slower we go. Trafficsystems, networking systems, andqueuing theory in general predictthis behavior. However, we inmanagement have not thought toapply this same thinking to man-aging portfolios of projects untilfairly recently.

In a traditional environment, wehave individual “resources,” other-wise known as people, who haveavailability. Typically, the portfoliomanager will review the availabil-ity of resources and see that “Bobhas 10% availability, Susan has20% availability, and Venkat has15% availability.” Upon seeingthis unallocated capacity, theportfolio manager will try to startanother project in order to geta jump on the next project andmake these resources billableback to the business. This think-ing is conventionally justified ontwo fronts. First, we have expen-sive resources that have someavailability, and we have a largebacklog of projects. Second, we



Figure 2 — Rush hour traffic.


need to charge their time back tothe business in some way, or wewill need to absorb their benchtime as overhead. However, whatis the effect of adding more andmore projects on the rest of theongoing projects in the portfolio?

It will be just like adding morecars to the highway at rush hour.Newly allocated resources willtake more and more time awayfrom the existing ongoing projectsin order to help support the “newand important” projects. Soon,it snowballs into gridlock. Eachproject is stalled while waiting onsome external resource that is toobusy serving other ongoing proj-ects. We have very high utilizationof our resources, but none of ourprojects are proceeding quickly.Even worse, this situation leadsto very high spending with verylittle early delivery, which, as wementioned previously, is key tofinancial performance. Continuingwith our example regarding NPV,suppose that our project delivered

in a single drop and was twomonths late due to project delays.Let’s also suppose that the teamburn rate dropped, because teammembers were pulled off and hadto spend time supporting otherprojects. The results are illustratedin Table 5.

In months four, five, and six,the team spent less money onthe project — from $100,000 amonth down to $75,000 a month— because it was pulled outto support another project. As aresult, the team ended up notdelivering until month seven.Note that the financial impact isa decrease of some 27% in invest-ment performance even thoughthe team actually spent less insome months.

If optimizing resource utilizationhas these clearly negative effects,what is the alternative for theLean-Agile PMO to deliverprojects faster to market? Weadvocate a sharper focus on man-aging throughput, not utilization.

In a PPM environment, this trans-lates to delivering customerrequirements much faster intoproduction so that they can netreturn for the business. Thismeans that in order to increaseproject throughput, we mustlower the lead time for deliveringcustomer requirements into pro-duction. Lead time is defined asthe time taken to deliver one unitof a product or a service that is ofvalue to customers. From opera-tions management, the relation-ship known as Little’s Law tellsus: Lead Time = Work in Process/Average Completion Rate.

To lower lead time, we need toreduce work in process (WIP),project inventory, or we have toimprove the average completionrate of projects in the portfolio.Herein lie the keys to the portfoliomanagement kingdom for theLean-Agile PMO. Rather thansuboptimizing utilization, manag-ing throughput by reducing proj-ect inventory and improving the



Annual Hurdle Rate

Monthly Rate

Month

Cash Out

Cash In

Net Cash

NPV

NPV Decrease

15%

1.25%

1

-100

0

-100

$563

27%

2

-100

0

-100

3

-100

0

-100

4

-75

0

-75

5

-75

0

-75

6

-75

0

-75

7

0

200

200

8

0

200

200

9

0

200

200

10

0

200

200

11

0

200

200

12

0

200

200


Table 5 — Impact of Utilization on Project NPV

project completion rate are thebest ways to globally optimizefinancial performance.

3. Manage System Constraints

How do we improve the projectcompletion rate of the organiza-tion’s portfolio? How does the rateof starting projects relate to theircompletion rate? At what rateshould we begin and release proj-ects into the portfolio pipeline?How much is too much? Leanthinking would recommend thatwe release new work at thesame rate that work exits fromour tightest organizational con-straint (see sidebar “The TestEnvironment: A CommonConstraint”).

Let’s consider another trafficsituation — it’s not rush hour, but

one of the highway lanes is closedfor construction. The number ofcars on the highway at the begin-ning of the highway represents thenumber of projects begun. Thenumber of cars exiting the high-way past the construction arearepresents the number of com-pleted projects that pop out of theprocess. Note that there is no realrelationship between the start rateand the completion rate.

Projects will complete at a ratethat is determined by the numberof free lanes only. Starting moreprojects early will not makethem finish sooner. A Leanorganization does not wasteresources starting projects that itcannot complete. Instead, it rec-ognizes that throughput is linkedto the project completion rate. In

a project portfolio setting, ourproject completion rate will begoverned by our narrowest con-straint regardless of how manyprojects we begin, just as thetraffic flow is governed by theclosed-off lane. What is the nar-row constraint in your organiza-tion? Is it the capacity of yourSMEs? Is it the availability of yourtest environments? Is it the timethat it takes to integrate with othersystems? A Lean organization willexploit the constraint; that is, useit to its maximum effectivenessand then add to the capacity ofthe constraint in order to increasethe throughput of the entire orga-nization. Intentionally managingconstraints is the way to improveyour project completion rate.

Thus far, we have defined theLean-Agile PMO in terms of itsorganizational structure andoperating principles. Next, we willpresent practices for the Lean-Agile PMO that will apply thoseoperating principles to the job ofmanaging the Lean-Agile portfolio.

MANAGING THE LEAN-AGILEPORTFOLIO

In this section, we will focus onthe practical application of theoperating principles definedearlier. By applying those coreoperating principles, the Lean-Agile PMO can help ensure thatpractices are:

Always focused on the highestpriorities

Responsive to the business inmanaging changing priorities



THE TEST ENVIRONMENT: A COMMON CONSTRAINT

A common constraint in most organizations is the availability of a production-liketest environment. Production-like environments are tremendously expensive, andorganizations cannot afford to have many of them. Yet organizations will startmany more projects than the production-like environments can accommodate.This leads to delays, which lead to lower financial performance.

This situation is common in the manufacturing world as well. Often, a manufac-turer will have a few very proprietary, customized, and expensive machines aroundwhich its unique products are built. If one of these critical machines were to bedown for some reason, it would be treated as an operational emergency. Thesecompanies would also optimize the use of these machines (and these machinesonly!) by automating their setup and changeover processes and constantly moni-toring the health of the machines in order to maximize the throughput of thesemachines. They might even go to multiple shifts on the machine. They have to dothese things since the throughput of their entire organization is governed by thesemachines.

However, do large IT organizations act similarly with respect to their constrainedresources? Do they automate the setup of the production-like test environment?Do they go to multiple shifts on the environment? Do they treat any downtimeof the test environment as an operational emergency? Do they have metrics thatdrive the test environments toward maximum utilization and continuous processimprovement? Not in our experience.


Always delivering the high-est possible value to theorganization

Always in alignment withstrategy

Delivering projects at thegreatest possible speed

Maximizing investment returns

To apply the operating principles,we will next define practices thatthe Lean-Agile PMO can use tomanage the project portfolio.These practices are summarizedin Table 6, and descriptions ofeach practice follow. You mayfind that although many standardportfolio management practicesremain relatively unchanged inan Agile environment, there aresome notable exceptions. Projectideation, scoring, ranking, andselection are often similar in anAgile environment. Schedulingand constraint management, onthe other hand, are remarkablydifferent; and we will spend moretime on those subjects.

In addition to these practices nec-essary in managing the organiza-tion’s portfolio, we define a basicprocess to run the Lean-AgilePMO itself. This basic process isoutlined next.

BASIC PROCESS

We recommend that the Lean-Agile PMO use an Agile processlike Scrum to manage its ownoperations. The basic process caninclude:

Month-long sprints

Monthly sprint review/planningmeetings

Daily standup meetings

Maintenance of a prioritizedlong-term backlog that iscreated and updated in regularrelease planning meetings

Maintenance of a prioritizedshort-term backlog that iscreated and updated in reg-ular sprint planning/reviewmeetings

Regular progress tracking andmonitoring via a tool such asa burndown chart

It is best for the Lean-Agile PMOto secure a dedicated workspaceof its own. We strongly recom-mend an agile “war room” withcharts and so on to aid visualmanagement and to help buildthe Lean-Agile PMO into an Agileteam in its own right.

PRINCIPLE #1: ALIGNCONTINUOUSLY

To actualize this operating princi-ple, we advocate using the follow-ing five practices: communicatestrategic intent; ideate againststrategy; measure businessresults; make ranking and selec-tion open and visible; and repriori-tize regularly, as detailed below.

1. Communicate Strategic Intent

One of the first steps for the Lean-Agile PMO in its review of theorganization’s portfolio is toaddress any changes in strategicdirection. Competitive actions,



e Align continuously

• Communicate strategic intent. • Ideate against strategy.

• Measure business results. • Make ranking and selection open and visible.

• Reprioritize regularly.

Manage project throughput

• Practice Lean project scheduling. • Reduce project inventory/work in process.

Manage system constraints • Identify organizational and process constraints.

Principle Practice

• Optimize and elevate the constraints.

Table 6 — Mapping Operating Principles to Practice

new regulatory findings, newbusiness opportunities, internalreorganizations, and a variety ofother impacts can cause changeseither to the strategy itself or inhow the strategy is going to beimplemented. To avoid changes instrategy known only to the higherlevels of the organization, man-agers in the Lean-Agile PMO needto ensure constant communica-tion of changes in strategy. TheLean-Agile PMO needs to ensurethat changes in strategic directionare propagated throughout theorganization and that appropriatechanges in departmental objec-tives are made. Strategic intentshould drive the kinds of projectsthat the organization undertakes.Communicating changes instrategic intent clearly enablesmanagers throughout the orga-nization to revisit their projectscorings and rankings against thechanges. This constant commu-nication of changes to strategyensures that it is not a one-timeexercise but is instead a livingprocess that is revisited regularlythroughout the year.

2. Ideate Against Strategy

Once strategy is set for a certaintime period, business leadersshould then enter into a processof coming up with ideas for proj-ects that would move the orga-nization forward against thestrategy. Business cases need tobe developed against the ideaswith rough order of magnitudecosts, financial benefits, and otherfactors. It is important for theLean-Agile PMO to ensure thatproject ideas and business casesare reviewed regularly throughoutthe year and that the project ideasare compared with each other asopposed to being reviewed seri-ally. Almost any project can lookgood in isolation, but it is whencosts and benefits of projects arecompared against each other in acompetitive environment that thetrue winners are more likely toemerge. Organizations are alwayscoming up with new projectideas. Business sponsors’ wantsare limitless, but the funds andtime available are quite finite.Once the strategy has been veri-fied, the Lean-Agile PMO can thenaccept new project ideas and

business cases into the set ofpotential investments.

3. Measure Business Results

Before the Lean-Agile PMOteam can make any significantdecisions about project prioritiesand selections, it needs to deter-mine if the current projects areperforming adequately againstfinancial targets, business sponsorsatisfaction, and strategic align-ment. One of the great powersin Agile delivery is the ability tomake more informed incrementalfunding decisions. With actualworking code delivered, the spon-sor can make better informeddecisions on whether to terminatethe project or invest in anotherround of funding for the quarter.With the poor performing projectsremoved from the backlog, andthe new ideas now introducedinto the backlog of project wants,the portfolio management team isonce again in the position of scor-ing, prioritizing, and selecting itsnext wave of projects. It can nowlook at how much budget andtime are remaining in the financialperiod and select the best poten-tial projects from the prioritizedbacklog for the next round ofdevelopment.

4. Make Ranking and SelectionOpen and Visible

Typically, there will be more ideasthan there is time or money, sosome sort of scoring processwill need to be put in place.Organizations often set up formalscoring methods to help themmake objective decisions. Once



Scoring Weight in Points

Project Scoring Criteria High Medium Low

Alignment to strategy 30 20 0

COTS customization 20 10

Impacts high number of users 20 10 0

Supports top-line growth 40 20 0

Drives significant cost savings 30 10 0

Fits our technical architecture 20 10 0

0

Table 7 — Example Project Scoring Mechanism


the selection criteria are decided,the business sponsors and port-folio owners will go through aprocess of scoring each projectidea against the selection criteria.The result will be a more objec-tive ranking of the projects. Forexample, the Lean-Agile PMOteam in working with senior man-agement may adopt the examplescoring mechanism shown inTable 7.

In this environment, the organiza-tion puts its highest weight orpoints on top-line growth projects(40 points). With the objectivescoring criteria in place, the

Lean-Agile PMO team, workingwith projects sponsors, will scorethe potential projects against thescoring criteria. By going throughan open and public scoringprocess with a predefined set ofobject criteria, the organizationcan get away from choosing proj-ects on the basis of “who yells theloudest” or who the project spon-sor is. Also, projects need to beevaluated against each other andnot just on individual merit. So tocontinue the example, let’s sup-pose that the Lean-Agile PMOteam comes up with the projectscores illustrated in Table 8.

Having gone through and scoredall of the projects, the Lean-AgilePMO team can now very easilyscore and rank the projects. Forthis organization, the resultingscores and rankings are illustratedin Table 9.

Now, given the financial quarteror yearly time frame available, thebudget allocated for new projects,and their project rankings, theportfolio managers and businessleaders in the Lean-Agile PMO canselect the projects with the high-est rankings that fit the scheduleand the finances and that line upbest against the strategic intent.



Project Evaluation

Alignment to Strategy COTS

High Number of Users

Top-Line Growth

Drives Cost Savings

Fits Our Architecture

Project A Medium High Low High Medium Low

High Medium Low Medium High MediumLow Low Low Medium High High

Medium Medium High Low Low High

High Medium High Low Medium Medium

Project BProject C

Project D

Project E

Table 8 — Example Project Scores

Project Evaluation

Alignment to Strategy COTS

High Number of Users

Top-Line Growth

Drives Cost Savings

Fits Our Architecture

Project A 20 20 0 40 10 0

30 10 0 20 30 100 0 0 20 30 20

20 10 20 0 0 20

30 10 20 0 10 10

Project BProject C

Project D

Project E

Total

Points

90

10070

70

80

Project Rankings

Project B: 100 points

Project A: 90

Project E: 80

Project C: 70

Project D: 70

Table 9 — Example Project Rankings

So far, the portfolio managementprocess is really no differentunder Agile. However, the Agileorganization could try to favorprojects that have incrementalvalue possibility over projectsthat are inherently single-drop big-bang deployments.

5. Reprioritize Regularly

As with any investment portfolio,the results of our project invest-ments against strategic goalsneed to be reviewed periodically.In the business world, with itsever-changing priorities andtechnologies, the project selec-tions and results probably needto be reviewed on a quarterlybasis. Strategies change due to a changing competitiveenvironment, mergers andacquisitions, and ever-presentregulatory compliance activities.Therefore, project priorities arealways in flux; hence, our man-agement process needs to be able

to quickly and regularly makechanges in product selections andpriorities. To continue our earlierexample, a change in businessconditions could force us to revisitour scoring criteria. For example,results of the latest financialstatements could force us to placea significantly higher value on costsavings. Such a scoring changecould result in different projectrankings.

We recommend that the Lean-Agile PMO conduct a reprioritiza-tion exercise at each of itsmonthly sprint review/planningmeetings (see sidebar “SprintReview/Planning MeetingAgenda”).

PRINCIPLE #2: MANAGEPROJECT THROUGHPUT

Armed with the most up-to-dateproject priorities and the latestproject metrics, the Lean-AgilePMO can now revisit projectscheduling, taking into accountthe current work in progress andthe organizational throughputconstraints. Before schedulingthe next round of projects, how-ever, the PMO will need to analyzeperformance over the last quarterto determine the capacity of theorganization to take on additionalwork. Remember that the focusof Lean is to maximize flow andthat the role of the Lean portfoliomanager is to maximize projectdelivery speed. So in addition tothe usual metrics that most portfo-lio managers focus on, such asschedules and budgets, the Lean-Agile PMO manager will also need

ways to measure project inven-tory, flow, and throughput. Lean-Agile PMO managers may alsoneed to put less emphasis onsome traditional metrics, suchas individual utilization, whichactually impede flow and hamperinvestment performance andbusiness partner satisfaction.

To apply this operating principle,we advocate using these twopractices: practice lean projectscheduling and reduce projectinventory/work in process, asdetailed below.

1. Practice Lean Project Scheduling

At this point, the portfolio man-agement team has now selectedits projects and it is now time toschedule the development teamsto start on them. And here iswhere Lean thinking and Agiledelivery will create a markeddifference in how the Lean-AgilePMO manager will schedule theprojects. In a traditional environ-ment, the portfolio manager willattempt to maximize utilization ofindividual resources and probablytry to start as many projects atonce as possible. As we haveshown, this will lead to high localutilization and will also lead tovery slow throughput. IT spend-ing will be high, and deliverywill be low. In a Lean and Agileenvironment, the Lean-Agile PMOwill only start as many projects asthere are available teams, as illus-trated in Figure 3.

Team structures will need to beanalyzed to determine if they



SPRINT REVIEW/PLANNINGMEETING AGENDA

1. Discuss changes in strategy.

2. Determine new project scoringcriteria for strategy changes.

3. Review in-progress projects;terminate as necessary.

4. Score and rank new project ideas.

5. Assess project throughputand constraints.

6. Schedule new projects.

7. Develop action items to commu-nicate decisions, to removeorganizational obstacles, etc.


have the right skills for the proj-ects at hand. Lean organizationsmight design different kinds ofteams to tackle different kinds ofIT issues. For example, a Lean-Agile organization might havetwo parallel midrange develop-ment teams and one mainframedevelopment team. Each teamis as fully cross-functional as itis practical — containing busi-ness analysts, developmentleads/designers, developers,testers, and perhaps a tools sup-port person. An organization mayalso have separate dedicated sup-port teams. Projects are thenpulled from the prioritized projectbacklog of selected projects andallocated to the appropriate team.The team focuses on this projectalone to the extent possible and,in working closely with the busi-ness sponsor, should be able tofinish it much more quickly thanin traditional environments. Whenthe team completes the project,puts the system into production,and hands the maintenance overto the maintenance team, theteam will then be available to startthe next project. Our experienceand the reported experience ofothers indicate that the impact oflean project scheduling can resultin improvements in time to mar-ket of up to 40% over traditionalmethods.

2. Reduce Project Inventoryand WIP

Little’s Law indicates that the lesswork we have in process (i.e.,the fewer projects being workedon simultaneously — project

inventory), the faster the deliveryon customer requests. Clearly,maintaining large WIP, includinga large inventory of projects, isnot a good thing. Mostly, this isbecause project inventory repre-sents potential portfolio wastethat puts a drag on all projects. Bysupporting fewer simultaneousprojects and making sure that theprojects have a minimal numberof blockages, all projects will actu-ally complete much faster. Toemploy our traffic metaphor men-tioned earlier, maintaining lowerutilization of the project pipelinehighway will result in helping allcars on the highway reach theirdestinations faster. How canthe Lean-Agile PMO effectively

manage and even increase projectthroughput? It can start by:

Actively tracking project flowthrough the organization

Managing the on-ramp orstartup of new projects

Terminating sick projects

Breaking large projects intosmaller projects/increments

Tracking Project Flow

How many projects does theorganization have in progress at atime? Charting this from month tomonth may show buildups of proj-ects that are not completing in atimely manner. Increases over



Figure 3 — Project flow for integrated Agile teams.

time of in-progress projects willwarrant investigation into rootcauses and potential solutions.Where are projects building upand failing to move forward in atimely fashion? Are there lots ofprojects stuck in the “architectureboard review process”? Perhapsthere is a buildup of projects wait-ing to get into the production-liketest environment. Or it could bethat projects are getting stuck inintegration testing. Followingprojects throughout their lifecycleand taking periodic “inventorycounts” of where projects arebuilding up may point to orga-nization constraints that needattention.

Lean-Agile PMO managers canuse the same kinds of tools thatAgile teams use to track projectthroughput using a visual controlsystem. The Lean-Agile PMOcould track the flow of projectsthrough the value stream using5x7 cards on a wall. Imagine hav-ing a whiteboard sectioned offinto four or five columns whereeach column represents majorvalue stream functions in your

organization. Each project can berepresented on a card that travelsacross the board from initiation toproduction release, as illustratedin Figure 4. Managers can thenvery easily and quickly update theboard and see where projects aregetting stuck.

Managing the On-Ramp

If the organization is startingmore projects than it is complet-ing, this may be a sign that we areletting too many cars get onto thehighway and that we may be set-ting ourselves up for future projectdelays as these projects movefurther into their developmentcycles. Obviously, not all projectsare alike, and it is possible to endone large project and correspond-ingly start up several new smallerones in its place, but this metriccan still be useful as a potentialwarning device and as a leadingindicator of delays to come. Usingthe whiteboard, the portfolio man-agement team can see that twoprojects are completed and areready for production and only oneis in initiation phase so, as long as

the new project is not a huge one,the organization may be alright. If,however, the board showed thatfive projects were in initiationphase, then clearly the organiza-tion would be starting projectsfaster than it is finishing and thuscould be setting itself up for atraffic jam.

Terminating Sick Projects

Take, for example, projects thatwere started and then became“sick” or needed to be cancelledafter long and painful “illnesses.”It is reasonable to assume thatthe majority of investment thatwas put into these sick and termi-nated projects ended up wasted— returning very little value tothe business. Consider the timespent by team members on thoseprojects. It is clear that if the port-folio was purged early of theseprojects, and the project inventorythereby reduced, the effort ofteam members could be redi-rected to more productive proj-ects that in turn would havecompleted faster.

Breaking Large Projects into SmallerProjects/Increments

As defined by Mark Denne andJane Cleland-Huang, a minimummarketable feature (MMF) repre-sents a component of intrinsicmarketable value [1]. By catego-rizing and perhaps aggregatingproduct features into MMFs, theLean-Agile PMO recognizes andexploits the fact that sets ofproduct features can have valueto end users, even if the product is



Figure 4 — Project flow tracking.


incomplete. That is, the Lean-AgilePMO can leverage the fact thatdelivering an MMF product incre-ment that has value to customerscan reduce WIP. Instead of carry-ing massive project inventory inorder to deliver product functional-ity in one big bang, the Lean-AgilePMO can reduce project inventoryby delivering products in incre-ments of MMFs and thus improvelead time as a direct result.

PRINCIPLE #3: MANAGESYSTEM CONSTRAINTS

In improving organizational andfinancial performance, Lean think-ing is widely complemented in theindustry with the application of theTheory of Constraints (TOC) [5].Created by Eliyahu Goldratt andenhanced by others, TOC is basedon the premise that the rate ofrevenue generation is limited byat least one constraining process(e.g., a bottleneck). Only byincreasing throughput (productionrate) at the bottleneck process canoverall throughput be increased.

To apply this operating principle,we advocate using two TOC-based practices: identify organiza-tional and process constraints andoptimize and elevate the con-straints, as detailed next.

1. Identify Organizational andProcess Constraints

A key focus of the Lean-Agile PMOteam will be constraint manage-ment. Constraints, which are thenarrow parts of the highway inthe project delivery process,represent the limit at which an

organization can deliver value.Every organization has constraints,and only through finding andexpanding the constraints willorganizations be able to delivermore projects per given unit oftime. Adding more applicationdevelopers in an environment thatis constrained by flow through thetesting organization will add a lotof cost without doing much tomake the organization deliverfaster. But in order to find, man-age, and expand constraints, theLean-Agile PMO manager needsto be able to see where the con-straints in the value stream lie.Unfortunately, getting this visibilityis not a trivial matter. Earlier, wementioned that teams rarely haveall of the skills necessary to do theentire job themselves. There maybe critical skills that are in shortsupply that need to be sharedacross teams. For example,architects, tool support personnel,DBAs, SMEs, network engineers,and others are often in limitedsupply, and each of these special-ized skills represents a potentialbottleneck in the organization.The portfolio manager thereforewill need to monitor these andother aspects of the organizationin order to find the constraints. Forexample, the manager may moni-tor some of the following.

Allocation of specializedskills. Are project teams report-ing lack of access to sharedresources? Perhaps there arenot enough architects or toolsupport staff and the inabilityof the teams to get time from

these people is slowing theprojects down.

Allocation by department.Perhaps there is a particulardepartment that is fully allo-cated in supporting projectsand has zero slack time. Andperhaps many of the projectsneed or must have the servicesof this department. If so, yourorganization has a constraintsituation on its hands.

Allocation of environments. Doall of your projects need to gothrough a formal test process ina controlled production-like testenvironment? How long does ittake to get a project installedand ready for testing? How longdoes the testing typically take inthat environment? The answersto these questions may dictatethe speed at which your organi-zation can deliver.

Integration woes. In largefirms, integration of newprojects into the existingsystem infrastructure can be a daunting task that cansometimes bring progressdown to a crawl.

Recall that very high utilizationand zero slack time will causeproject delays just like that of traf-fic delays on the highway. Lean-Agile PMO managers will need togain visibility into utilization ofskills, departments, and environ-ments in order to find the organi-zational constraints. Once theorganizational constraints arefound and can be monitored, the



Lean-Agile PMO manager canthen and only then:

Schedule projects so as tonot overload the constrainedresources and thereby furtherslow down project deliveries.

Find ways to make the con-strained resources moreproductive by removing nonvalue-adding work, eliminatinglower priority work, or throughprocess improvements.

Make investments to add addi-tional resources at the con-straint points (and only at theconstraint points!) in order toincrease the overall capacity ofthe organization to deliver.

2. Optimize and Elevatethe Constraints

In the earlier example (from Figure4), our attention is immediatelydrawn to the fact that the pluralityof projects are in the integrationtesting phase and perhaps it is thisstep in the process that warrantsattention from the Lean-Agile PMO.That is, the integration testingphase seems to be the chokepointthat is restricting the flow of proj-ects into production.

Simple tools such as a projecttracking board can help the Lean-Agile PMO monitor where theconstraints or bottlenecks are inits processes, reveal some of thecauses, and perhaps shed light onsome potential solutions for proj-ect delays and poor deliverycycles. For example, in the situa-tion earlier, should the Lean-AgilePMO allow more projects to start

up in initiation and development?Perhaps putting those sameresources on to a project thatwill improve the operations, effi-ciency, and throughput of theintegration environment will yielda far greater financial impact byallowing all projects to come tomarket faster.

What should the portfolio man-agement team do to get projectsflowing again and to deliver value?The Lean-Agile PMO should:

Control the flow of projects

Increase efficiency and utiliza-tion at the bottleneck

Invest to elevate the capacity ofthe constraint

These management actions,detailed below, would probablybe seen as extraordinary in a typi-cal project environment but asvery logical and expected in aLean-Agile environment.

Control the Flow

By taking the first action of not let-ting more projects start that canpass through the constraint, we areensuring that we do not generate abig backlog inventory of half-doneproject work. Were we to allowthese projects to start, they wouldall eventually stall waiting to getinto the integration environment.

Once the projects begin to stall,a variety of bad results begin toaccumulate. The financial returnsstart to diminish; we have spentthe money but we are unable to

reap the rewards. We have proba-bly made customer commitmentsthat we are no longer going to beable to keep. Team members andmanagers will feel dejected at hav-ing put so much work into an effortonly to have it not be delivered.

Increase Efficiency and Utilizationat the Bottleneck

With the flow problem undercontrol, our next step is to try toget as much throughput out of ourexisting constraint as possible. Isthere work that the constrainedresource or team is doing thatcould be done elsewhere? Arethere simple process improve-ments that could be implementedquickly that would make this teamor resource more productive? Inthis example, the team might lookat such actions as:

Automating the setup andteardown of the integrationenvironment

Automating testing within theintegration environment

Multiple-shift testing

Invest to Elevate the Capacity of the Constraint

Finally, with efficiency maximizedat the bottleneck, if the constraintis still a drag on the throughput ofthe organization, then the Lean-Agile PMO team may make therecommendation to invest. Per-haps more resources are neededin this department or function.Perhaps more equipment isneeded here, or perhaps majorprocess improvement initiative




should be initiated. By investingonly at the bottleneck, the Lean-Agile PMO can insure that it willbe elevating the capacity of theorganization as a whole, improv-ing time to market for multipleprojects, and improving overallfinancial performance.

Compare these responses withthe more typical one that occurswhen project deliveries aredelayed: “We need to hire moredevelopers/testers!” When we addmore resources, we will probablyend up just creating more inven-tory of half-done work that willonce again get stalled becausewe haven’t focused our efforts onthe actual root causes of poororganizational throughput.

SUMMARY

Corporate project portfolios areroutinely challenged in manyorganizations: across the portfolio,projects are late and overbudget,deliver poor value, and have less-than-satisfied business sponsorsand end users. Though the valuedelivered by Agile methods hasbeen clearly recognized in theindustry at the project level, portfo-lio issues can sometimes be exac-erbated when an organization hasa portfolio mix of Agile and non-Agile projects.

To resolve many of typical PPMissues and effectively managethe project portfolio, Agile prac-tices at the project level must becomplemented by the applicationof Lean principles at the portfoliolevel. The typical PMO focus on

project management practicesdoesn’t align directly with the port-folio management function of theorganization. Aligning the PMOwith the portfolio managementfunction requires the establish-ment of a Lean-Agile PMO that isdirectly tasked with managing theproject portfolio to deliver busi-ness value across the organization.

When organizing the Lean-AgilePMO, we need to avoid a struc-ture that will orient us towardtraditional top-down, command-and-control management andcause stress between the Lean-Agile PMO and Agile teams itwill be chartered to support.Having a combination of linking-pin representatives who areassigned top-down and electedrepresentatives (elected bottom-up to straddle management levels)can help ensure that the Lean-Agile PMO’s hierarchy is not auto-cratic. Committing the Lean-AgilePMO itself to using Agile practicescan help ensure that it stays self-organizing and adaptive to change.

To reduce portfolio waste andmake projects flow through theproject portfolio as fast as possi-ble, the Lean-Agile PMO needs aset of operating principles andportfolio management practices.

A sharper focus on managingthroughput can help organizationsavoid the negative effects associ-ated with the traditional approachof optimizing resource utilization.Managing project throughput isconnected to managing lead

time: lowering project lead timeincreases project throughput. In aPPM environment, this translatesto delivering customer require-ments much faster into produc-tion so that they can achieve a netreturn for the business.

To lower lead time, the Lean-AgilePMO needs to reduce WIP orimprove the average completionrate of projects by managing sys-tem constraints. These, therefore,are the portfolio managementkeys to globally optimizing finan-cial performance: managingthroughput by reducing projectinventory and improving theproject completion rate.

REFERENCES

1. Denne, Mark, and Jane Cleland-Huang. Software by Numbers:Low-Risk, High-Return Develop-ment. Prentice Hall PTR, 2003.

2. Poppendieck, Mary, and TomPoppendieck. “Managing thePipeline.” Poppendieck.LLC.27 September 2006 (www.poppendieck.com/pipeline.htm).

3. Robertson, Brian J. “Holacracy:A Complete System forOrganization Governance andSteering.” Cutter Consortium AgileProject Management ExecutiveReport, Vol. 7, No. 7, July 2006.

4. Schwaber, Carey. “Corporate ITLeads the Second Wave of AgileAdoption.” Forrester Research,30 November 2005.



5. “Theory of constraints.”Wikipedia (http://en.wikipedia.org/wiki/Theory_of_constraints).

6. Thomsett, Rob. “ManagingLarge Projects: A Special Case.”Thomsett International (www.thomsettinternational.com/main/articles/largeprojects/managing_large_projects.pdf).

7. VersionOne. “The ‘State of AgileDevelopment’ Survey Results,”2006 (www.versionone.net/surveyresults.asp).

ABOUT THE AUTHORS

Sanjiv Augustine, ManagingDirector for the Lean-AgileConsulting Practice at CC Pace,is an industry-leading Agile andLean expert. He is a cofounderand board member of the AgileProject Leadership Network(APLN). Mr. Augustine is also theauthor of several publications andthe book Managing Agile Projectsas well as the founder and moder-ator of the Yahoo! “Agile ProjectManagement” discussion group.He presents regularly at Agileand project management con-ferences worldwide, includingProject World and Project Summit.Mr. Augustine has assisted clientsin deploying Agile and Leanmethodologies at many institu-tions large and small. As an in-the-trenches practitioner, he has

personally managed Agile projectsvarying in size from five to morethan 100 people. Mr. Augustineholds a bachelor’s degree inelectronics engineering and amaster of science degree. Hecan be reached at [email protected].

Roland Cuellar, Director for theLean-Agile Consulting Practice atCC Pace, is a leader in helpingenterprise-level clients adopt theuse of both Agile and Lean in theirorganizations. He has helpedexecutives prepare their organiza-tions for Agile transformation byidentifying challenges and oppor-tunities related to Agile and Leanimplementation and developingaction plans and risk mitigationstrategies to insure that Agileand Lean initiatives are success-ful. Mr. Cuellar has led numerousAgile product development teamsin the areas of marketing appli-cations, mortgage, compliance,and logistics. He has also givennumerous Agile training classesto both management and tech-nology teams. Mr. Cuellar hasprior experience leading largesoftware development projects forCapital One, Freddie Mac, IBM,Lockheed Martin, and DHL. Heholds a bachelor’s degree incomputer science and an MBA.He can be reached at [email protected] [email protected].




Index

ACCESS TO THE EXPERTS

Upcoming Topics

Driving Development with Acceptance Tests by Frank Maurer andGrigori Melnik

Effective UserParticipationby Khaled El Emam

Cutter Consortium is committedto delivering top-level, critical,and objective advice to helpyou maximize your use of agileapproaches to software devel-opment and project manage-ment. Directed by Jim Highsmith,Cutter’s Agile Practice offersresearch and content, inquiryaccess, training, and consultingdesigned to help your organiza-tion implement agile softwaredevelopment and project man-agement methods quickly andeffectively, shorten your productdevelopment schedule, andincrease the quality of yourresultant products.

For informationon beginning a subscription

or upgrading your current

subscription to include access

to the Online Resource

Center, contact your account

representative directly or

call +1 781 648 8700 or send

e-mail to [email protected].

Executive ReportsVol. 7, No. 10 The Lean-Agile PMO: Using Lean Thinking to Accelerate Agile Project

Delivery by Sanjiv Augustine and Roland Cuellar

Vol. 7, No. 9 Agile Manager Behaviors: What to Look For and Develop by David Spann

Vol. 7, No. 8 Distressed Projects: Prevention and Intervention Strategiesby Dr. Robert K. Wysocki

Vol. 7, No. 7 Holacracy: A Complete System for Agile Organizational Governance and Steering by Brian Robertson

Vol. 7, No. 6 An Adaptive Performance Management System by Jim Highsmith

Vol. 7, No. 5 Collaboration and Collaborative Leadership: Innovation in the AgileEnterprise by Pollyanna Pixton

Vol. 7, No. 4 Managing a Multiple Team Project by Dr. Robert K. Wysocki

Vol. 7, No. 3 Refactoring Databases: Evolutionary Database Design by Scott W. Ambler

Vol. 7, No. 2 Introducing Agile Techniques in a Small Team Environment: A Case Studyby Frank Maurer and Chris Mann

Vol. 7, No. 1 Standardizing the Standards: Picking Project Management Standards and Guidelines That Match Culture and Strategy by Carl Pritchard

Vol. 6, No. 12 Coaching Community by David Hussman

Vol. 6, No. 11 Are Agile Methods and Enterprise Architecture Compatible? Yes, with Effortby Jim Watson, Michael Rosen, and Kurt Guenther

Vol. 6, No. 10 Responsible Change by Christopher Avery

Executive UpdatesVol. 7, No. 20 The Agile Path by Patrick Wilson-Welsh

Vol. 7, No. 19 Methodology Object Management and Quality Assuranceby Charles W. Butler

Vol. 7, No. 18 Agile Code Priorities: Part II — Using a Priority Hierarchy in Different Types of Scenarios by Patrick Wilson-Welsh

Vol. 7, No. 17 Contracting Agile Projects by Jens Coldewey

Vol. 7, No. 16 Agile Code Priorities: Part I — Using a Priority Hierarchyby Patrick Wilson-Welsh

Vol. 7, No. 15 Creating an Initial Area of Order: A Core Agile Practiceby Donna Fitzgerald

Vol. 7, No. 14 Five Rules to Minimize the Risk Associated with Project Rescueby Tom Mochal

Vol. 7, No. 13 You Are Not Your Code by Patrick Wilson-Welsh

Vol. 7, No. 12 Organizational Culture Is Important in Software Productivityby Bruce Taylor

Vol. 7, No. 11 The Agile Project Manager and the Project Journal by Donna Fitzgerald

Vol. 7, No. 10 The Customer’s Role in Software Development: Part III — Any Color asLong as It’s Black! by E.M. Bennatan

Vol. 7, No. 9 Leadership and Agile Methods by Mike Griffiths

Vol. 7, No. 8 Sustainable Software Development: Cultural Issues by Bruce Taylor

Vol. 7, No. 7 The Customer’s Role in Software Development: Part II — Is It a CultureChange? by E.M. Bennatan

> Agile Project ManagementAdvisory Service

of published issues


mailto:[email protected]

Abou

t the

Pra

ctice Agile Project

Management PracticeCutter Consortium’s Agile Project Management practice provides you withinformation and guidance — from experienced, hands-on Senior Consultants — tohelp you transition (or make the decision to transition) to agile methods. Led byPractice Director Jim Highsmith, Cutter’s team of experts focuses on agile principlesand traits — delivering customer value, embracing change, reflection, adaptation,etc. — to help you shorten your product development schedules and increase thequality of your resultant products. Cutting-edge ideas on collaboration, governance,and measurement/metrics are united with agile practices, such as iterativedevelopment, test-first design, project chartering, team collocation, onsite customers,sustainable work schedules, and others, to help your organization innovate andultimately deliver high return on investment.

Through the subscription-based publications and the consulting, mentoring, andtraining the Agile Project Management Practice offers, clients get insight into Agilemethodologies, including Adaptive Software Development, Extreme Programming,Dynamic Systems Development Method, and Lean Development; the peoplewareissues of managing high-profile projects; advice on how to elicit adequaterequirements and managing changing requirements; productivity benchmarking;the conflict that inevitably arises within high-visibility initiatives; issues associatedwith globally disbursed software teams; and more.

Products and Services Available from the Agile Project ManagementPractice

• The Agile Project Management Advisory Service• Consulting• Inhouse Workshops• Mentoring• Research Reports

Other Cutter Consortium PracticesCutter Consortium aligns its products and services into the nine practice areasbelow. Each of these practices includes a subscription-based periodical service,plus consulting and training services.

• Agile Project Management• Business Intelligence• Business-IT Strategies• Business Technology Trends & Impacts• Enterprise Architecture• IT Management• Measurement & Benchmarking Strategies• Enterprise Risk Management & Governance• Sourcing & Vendor Relationships

Senior ConsultantTeamThe Cutter Consortium Agile ProjectManagement Senior Consultant Teamincludes many of the trailblazers in the projectmanagement/peopleware field, from thosewho’ve written the textbooks that continueto crystallize the issues of hiring, retaining,and motivating software professionals, tothose who’ve developed today’s hottest Agilemethodologies. You’ll get sound advice andcutting-edge tips, as well as case studies anddata analysis from best-in-class experts. Thisbrain trust includes:

• Jim Highsmith, Director• Scott W. Ambler• Christopher M. Avery• Paul G. Bassett• Sam Bayer• Kent Beck• E.M. Bennatan• Tom Bragg• David R. Caruso• Robert N. Charette• Alistair Cockburn• Jens Coldewey• Ken Collier• Ward Cunningham• Rachel Davies• Doug DeCarlo• Tom DeMarco• Khaled El Emam• Donna Fitzgerald• Kerry F. Gentry•Tod Golding• Sid Henkin• David Hussman• Ron Jeffries

• Joshua Kerievsky• Bartosz Kiepuszewski • Diana Larsen• Brian Lawrence• Tim Lister• Michael C. Mah• Lynne Nix• Siobhán O’Mahony• Ken Orr• Patricia Patrick• Mary Poppendieck• Roger Pressman• James Robertson• Suzanne Robertson• Alexandre Rodrigues• Johanna Rothman• David Spann• Rob Thomsett• John Tibbetts • Colin Tully• Jim Watson• Patrick Wilson-Welsh• Robert K. Wysocki• Richard Zultner


Agile Project Management Vol. 7, No. 10 The Lean-Agile PMO · The Lean-Agile PMO: Using Lean...

Documents

Transcript of Agile Project Management Vol. 7, No. 10 The Lean-Agile PMO · The Lean-Agile PMO: Using Lean...