Herding Cats

Agile Notions Already Are At Work

The Projects@Work site has an editorial titled "Agile, by any other name." (Registration required). There is of course the original Agile Manifesto. Then 7 additions clarification points:

• Develop in short cycle times
• Plan short term (the next cycle)
• Develop only what is needed
• Close collaboration with the user
• High visibility and daily reporting
•  Empower the project team
• Test in parallel with development

These approaches are also found on large space and defense programs. There the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) paradigm is mandated for programs greater than $20M. $20M sounds like a lot, but in that domain it's not. Most firms then push this paradigm down onto all programs. As well DID 81650 is mandated along with an Earned Value Management process.

Using the Agile Guidance for Managing Projects

While the 7 items above are usually applied to software development activities, they are generally applicable to any project domain and context. Here's how they are applied on 1/2 billion dollar manned spaceflight software programs, multi-billion dollar Army combat systems and many multi-billion dollar Air Force integrated world wide "everything over IP" program.

• Develop in short cycle times - the primary role of this behavior is to ask and answer the question. How long are we willing to wait before we find out we're late?

Short cycle times have different meanings to different domains. But all defense and space programs have monthly earned value assessment of physical percent complete. Nearly every Earned Value Management System - System Description (SD)

• Plan short term (the next cycle) - rolling waves are used for all non-trivial programs.

This means the current rolling wave is being executed from the Performance Measurement Baseline (PMB). The PMB is a time phased description of the cost, work, and deliverables. The current rolling wave consists of Work Packages, with a duration, resource "spreads" and a single deliverable.

Planning packages are used for "out year" (yes years) work. These Planning Packages has durations and cost spreads, since the the critical path must be identified from Contract Award to Contract Closeout.

• Develop only what is needed - the rolling wave work package process defines explicitly what is to be produced.

In the federal contracting world if you work on things that are not needed for the next Program Event - see Integrated Master Plan / Integrated Master Schedule Preparation and Use Guide - you wouldn't get paid.

It is critical for the program to work on only things that increase the maturity of the deliverables "as planned" in the Integrated Master Plan (IMP). Otherwise the program is decreasing the probability of success. There is an urban myth that programs like this have Big Design Up Front. That is simply a lie, er "red herring." Change is constant in Pre-Milestone C programs. These are System Development & Demonstration. The milestone after that (D) is Low Rate Initial Production (LRIP). SDD is emerging requirements driven.

• Close collaboration with the user - this is not as easy as in small team IT projects.

But Technical Interchange Meetings (TIM) occur frequently for all the obvious reasons - emerging requirements. As well there is daily if not hourly contact with the customer for SDD style programs for again all the obvious reasons. But requirements are flowed down from the customer to the supplier. There is more formality in the development and management of these requirements. This is driven by the production mature of the products. If you're building a one off is a test vehicle in a DARPA style program (a science project), the requirements management is much different than if you're upgrading all the F-18's in the fleet with new GPS navigation systems.

IT projects are almost always "one offs."

• High visibility and daily reporting - well maybe not daily, but certainty weekly.

Most programs we work, do weekly earned value. Monthly is mandated. NASA requires "mid month flash reports." So if you're going to do that, you might as well do weekly. What this means is a weekly "interview" with the Control Account Managers (CAM) to assess the physical percent complete of the planned deliverables. The critical concept is the "physical percent complete." You never confuse effort with results. So the passage of time and consumption of money is not a measure of progress. Physical, tangible evidentury materials are the only measure of progress. How do you assure that the deliverable meets the spec? Why test it silly. Yes Test Driven measures of physical percent complete are the way large defense programs work.

•  Empower the project team - teams work as "teams." usually with a lead and a collaborative staff.

This is how engineering works. For some reason the software world is just figuring this out. No credible engineering firm would work in a command and control manner for long. The product would not get out the door.

• Test in parallel with development - test driven development is the standard system engineering approach.

It can't really be anything but this and have th ability to hold the schedule and meet the cost target. Rework is unfunded in the DOD procurement processes. ANSI-748B does not record BCWP for rework. How do you avoid rework? Built it right the first time. How do you build it right the first time. Test the living !@#$ out of everything as you go.

Agile Projects and Project Management

Craig Brown posted this video, as other will certainty do in the agile community

From the Cognitive Edge.

The point of emergence (for social activities) is very important. Our firm is "emerging" to the next level of revenue and processes that support that revenue.

However, is this paradigm appropriate for projects and the management of projects:

• Would the owner of a newly commissioned SAP project for the Fortune 500 firm like the "emergent" approach defined here?
• How about the leaders of the current manned space flight program - Orion?
• Or maybe the PM for the construction of a large BioFuels and Coal Gasification plant we're current working?
• Our that 30 story high rise going up across the street from our office. The one with the "project management company" trailer in the parking lot. The guys managing the construction of the High Rise.
• Or the ARRA funded bridge replacement I see on CO-36 everyday when I commute to the office, where the High Rise is being built, and the Hospital I pass on I-25 as well?

Let's ask the question of this paradigm?

What class of projects in the commercial or government world (projects using someone elses money) would be appropriate for the emergent process described in the 3rd of the 3 options?

This video has hit a home run with me. The answer to the question above need to be in place before the word emergent can be used with the word project.

Another Strawman Argument for Agile Project Management

Josh pointed me to a post on CIO.com titled The 10 Key Capabilities of Next Generation Managers. Like all good strawman arguments, it's with a statement of the obvious

...shifting business conditions are changing the role of the project manager and the skills associated with it. "Organizations are striving to achieve faster [software] delivery without diminishing quality or increasing cost," she writes. As a result, she observes, they're moving from traditional software development methodologies to more Agile ones.

Really why agile? Getting faster, without diminishing quality and increasing cost is certainly desirable. By why does agile provide this? Is there evidence that agile does provide this? If so in what context and in what business domain?

I have personal experience and samples of others personal experience that agile provides faster response time and sometimes better quality in the "continuous maintenance mode" of commercial IT. PayPal is a good example.

What about standing up SAP or Peoplesoft in a distributed corporate environment? How about developing 21CFR compliant medical software from scratch. Or my favorite, developing and installing flight avionics upgraded to helicopters in the field?

The next classic strawman argument is...

The move to Agile software development "shifts the role of the project manager from a director to a facilitator," writes Gerush, because Agile development methodologies rely on self-managed, cross-functional teams.

Self organized, sure. Self managed. Would the project manager for Chase look forward to self managed teams during the move this week from www.wamu.com to www.chase.com. All my accounts came over no problem. All bill pay history moved. It was a seamless transition from the point of view of the customer. Self managed? I'd be dumbstruck if the teams managed themselves. Self organized? Possibly.

As organizations realize that traditional software delivery methods are bloated with processes and artifacts that add little or no value, they are trending toward Lean Software—and this transition will significantly change how they deliver projects, writes Gerush.

How about a single example? "Little or no value" to whom? SOX compliance be dammed. ARRA reporting through CFR 600 be dammed. ITIL compliance for corporate computing - we don't need that.

"Processes and artifacts, we don't need no stinkin artifacts."

Come on Ms. Gerush, provide some context and domain here. This is pure nonsense in the absence of a business domain and development context. 

As companies distribute their software development around the world, the project manager's ability to communicate with and relate to people from different cultures becomes even more important.

When was this not important, even in the same room? A nice tautological argument.

Project managers also need to be more focused on business value.

When did "real" project managers NOT focus on business value. This business value by the way, must be defined by the business owner not the project manager. This business value in held in the business case, which should be derived from the business strategy (Balanced Scorecard is a good starting point), which defined the needed business capabilities. The PM's job is and always was to deliver that business value from the project in terms of requirements fulfilled.

Ms. Gerush's 10 Key Capabilities include:

1. Emotional Intelligence
2. Adaptive Communication
3. People Skill
4. Management Skills
5. Flexibility
6. Business Savvy
7. Analytical Skills
8. Customer Focus
9. Results-Orientation
10. Character

This is one of those lists where you've forgotten what the point is and agree with the content. This links the initial poorly formed these with an undeniable outcome. The way out of the "false premise" argument approach" which is a good car sales approach as well - is to invert the argument.

Do you want a project manager that has poor emotional intelligence, is a crappy communicator, stinks at people skills, has poor management skills, is inflexible, has no business savvy, no analytical skills, hates customer, never delivers on anything, is missing core charter?

I know of no one on the planet who would want to hire such a project manager. So what's the point? There is no point. It's the restatement of the obvious in the absence of context and domain. An unassailable argument that is then bridged to "agile."

This kind of stuff wouldn't get a D in the high school forensics class (many types of debate, poetry, and drama). We desire a better assessment of the problem of managing corporate IT projects. Forget the $400 price tag. Look to working project management process in industries you work in.

What to see the basis of complete disaster for corporate IT? Follow this advice.

Notably, technical- and traditional project management skills are absent from Forrester's list of core capabilities for next generation project managers, but not because those skills are no longer necessary. While those skills remain important, Forrester maintains that because the softer skills are more difficult to learn than hard project management skills, organizations may be better off hiring individuals who are strong in those key capabilities "even if they lack experience in accepted project management practices."

I can just see it. The PM has all those softer skills, has character, is flexible, business savvy, etc. But is completely clueless about the effort and risks involved with integrating SAP with PeopleClick for FAR 35.1 compliant time reporting in the ARRA grant management business. Eveyone on the project is self actualized, informed, communicated with and holds the highest integrity in their dealing -  but the !@#$ing system doesn't work on the needed "go live" date for the monthly report and the DCMA sends a nasty letter that they'll be on site for next months reporting process audit. Oh yea, we're modern project managers now.

The Real PM 2.0 - An Example in Practice

Take a look at Alistair's key note address to see an example of the progression of development and the management processes around the development.

A couple of comments. Barry Boehm was  at TRW when I started there in the late 70's. In worked TDRSS while Barry was the Chief Scientist. We were on opposite ends of the importance spectrum. Me writing FORTRAN code digital signal processors and Barry inventing the future of software development processes.

One critical point in Alistair's talk is the processes of iterative and incremental development were in place at TRW for flight and ground software development. The complete myth of waterfall as the standard process for software development around the Royce paper is of course complete myth. The majority of those railing against those concepts have never ever worked a flight software program where requirements are constantly changing, 100% test and integration is mandated after each build, and the criticality of the mission measured in 10's of billions of dollars.

So back to the point. Notice Alistair's mention of the next step where the tools support the process. 15 year old tools BTW. Next comes modern tools built into the IDE's, where rapid feedback and tight iterations are the norm. A good friend is the CTO are a primer agile development house here in Boulder. They started in the provisioning side of teleco's and now do CRM systems world wide. As an early adopter of XP - with significant modifications - the tools enabled configuration control, build integrity and automated verification. This in the late 90's

PM 2.0 enabled by tools - as proffered by the current advocates - is actually coming late to the party. For us in our 50's and 60's who built mission critical software in the late 70's and 80's the notion of "the next new thing" brings a smile - yea right.

Let's chalk it up to possibly - "they were in diapers when we were doing many of the concepts they mention as new and innovative."

There is nothing new under the sun
— Ecclesiastes 1:9-14

OK, a few things, but they don't start with the tools.

Calling BS on PM 2.0

The notion of Project Management 2.0 has trigger several responses. I'm guided by Scott Berkun's Calling Bullshit on Social Media post.

For starters: Project Management 2.0 is a term without a context. 2.0 is borrowed from Web 2.0, SOA 2.0, GIG 2.0.

Reading the initial descriptions of PM 2.0 reminds me of watching the infomercials shown on late night cable. The pitch is unabashedly biased, making remarkable claims and with conclusions that are unlikely to hold up under scrutiny.

Project Management in the Context of Projects

All project management processes have a context and a domain. They don't age. They don't wear out. They don't get replaced.They are immutable.

The immutable core processes of project management are, irregardless of what anyone wants us to believe, the management of projects consists of answering these questions:

• What are we building?
• What budget to we have to build it?
• How much will it cost to build it?
• When is it needed?
• What resources do we have to build it?
• Who are the participants along the way?
• What are the impediments to our success?

But the real starting question, independent of any project management method is:

What does done look like?

No matter what you want to call the project management method. Agile, Traditional, 2.0 it must continuous answer this question and all the associated questions that come with it?

The PMBOK Questions

Most agile approaches start by trying to counter the Project Management Institutes Guide to the Project Management Body of Knowledge (PMBOK). PMBOK has 9 Knowledge Areas that are appliacble of every project:

1. Integration
2. Scope
3. Time
4. Cost
5. Quality
6. Human Resources
7. Communications
8. Risk
9. Procurement

So if there is such a thing as Project Management 2.0, we'll need to discover how PM 2.0 covers these knowledge areas. Now you might say, PM 2.0 is not the same as PM 1.0 and the PMI knowledge areas. OK, that's simple. We're done. But if PM 2.0 wants to continue being called "project management," it needs to some how address these areas and several  other "models" of project management.

PMBOK also has 5 Process Groups. These are not phases, but these processes can be found in any phase description of a project management method:

1. Initiating
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing

PM 2.0 and PM 1.0

If PM 2.0 is going to have any traction, it'll need to address how its processes are an improvement over something in the past. Start with PMBOK, start with Prince 2, start with anything and show how those processes - when implemented correctly, with competent management, in the proper domain and context - are lacking in beneficial outcomes.

There are certainty improvements to be made. Agile software development has shown that. It's time for PM 2.0 to show in tangible evidence how it's proposed processes and the method based on those processes can improve the probability of success for a project.

Project Management 2.0 - How Can It Be Described

Frank Patrick commented on my quick post on what the OP called Top Down compared with Bottom Up project management. I had not meant to be so blunt as Frank made me out to be. But on second thought he's right.

Starting the discussion of PM 2.0 in the way the OP started, is a non starter. There is no actionable outcome. Just buzz words, poor comparisons, and no path to increasing the probability of success.

First, the comparison between Top Down and Bottom Up is not the comparison between tradition and agile. Top and Bottom are topological terms not verbs describing the functions of project management.

Second, is the use of the words in the Top Down. Inflexibility, Bureaucracy, Overall Control, Imposed Processes, and my favorite No Moral Motivation. I won't use Frank term. My term is Nonsense.

Nonsense, first in there is no context, no examples, not domain of applicability for that presentation.

Nonsense, in the comparison of the agile terms flexibility, agility, collaboration, and high motivation.

Who says formal CMMI ML5, full NASA verification and validation software development projects have no moral motivation. Wanna see grown men cry like babies. Attend a launch of a Mars Oribtor. Be in the control room when that orbitor is captured at Mars. Or better yet be in the control room when a  sample return vehicle crashes in the Utah desert after 3 years flying around the sun. No moral motivation my ass.

If the role of project management is ever to improve, we must do the following:

1. Stop labeling the processes as agile, traditional, waterfall, or what ever, without also stating tangible, measurable, and verifiable beneficial outcomes for each of the labels. Agilest who do so have unlikely ever worked a project where formal methods are successful. So it'd be hard for them to know what that what they are complaining about is actually bad management.
2. Stop confusing bad management with bad processes. This is the most often encountered mistake with agilest who are not actually project managers in the domain applicable for more formal methods. Instead they start with software development paradigm and extend their experiences to the role of the project management.
3. Understand that developing software with Scrum is not managing the project in which the Scrum developed software is a participant. No matter how hard the agilest want us to believe this, software is one part of the solution to the problem. Yes, many of the methods found in Scrum are applicable to managing the overall project. But it does not replace many other methods needed for success.
4. Start defining effective project management processes in units of measure meaningful to the participants. "If you do this, you will achieve a 10% reduction inf rework of technical specifications." Things like that. Remember Jerry McGuire - "show me the money."
5. Demonstrate these process are effective in specific, named, domains, and contexts. No more blather of "my buzz words are better than your buzz words."

To improve the profession and processes of project management we must ask and answer the following:

1. What processes - no matter what they are - increase the probability of success?
2. What are the mechanisms of this improvement, so we can understand how they scale, where their inherent weaknesses are, and where the latent risks reside?
3. What measures can be found that show these processes are effective in a statistically sound manner. With real, validated data, using credible sampling and measurement techniques?
4. And most importantly, how the lessons of the past can be used to improve the probability of a projects success in the absence of the traditional agilest approach - "old ways are bad, new ways are good." Alistair Cockburn's works are a good place to start. Domain and Context sensitive. Outcome Based. Theoretically sounds and buzz word free.

That's the basis of Project Management 2.0

Let's get started and stop the nonsense of confusing buzz words with actionable outcomes that beneficially impact the success of the project.

Connecting Agile Teams with the Business Strategy

   There is an unwritten notion in agile development that project management and management in general is an unwelcome member of the agile team. This is course cannot actually work in a real business. The "demand management" processes for IT services - adds, changes, deletes of functionality that drive these agile team must start and end with the most senior management member who is accountable for the business benefit of the IT solution. Not the development teams.

Connecting Business Value with IT development

   Why is this business connection with agile the case? First, business leadership must be the source of work authorization. Those authorizing work - be it a simple change or the development of a new system should be either Directors, or Vice Presidents in the business unit.They need to have some "skin in the game." Usually this comes from business performance measures and the performance rewards that result. The lower on the management hierarchy, greater the gap between business alignment and IT development.

   This authorization responsibility should not delegated. Especially down to the agile team itself. It creates gap into value generation process resulting from IT systems and trivializes the work efforts. And it violates the fundamentals of IT governance. It;s just an all around bad idea.

   So how can development teams be "self managed," "self organized," or "self guided" in the absence of senior business management? How can these teams implement the business strategy in the absence of project, program, portfolio management? Project, Program, and Portfolio management with business leadership at the helm?

The answer? They can't.

   The connection between business strategy and the implementation of this strategy at the software development level requires management. Management of the sources of value generation. This is not self-management. It is plain olde management. Good management for sure. But management all the same.

   The best management method I've seen is to have the C-suite agree to a management process driven by a strategy. This means having the Program Management Office lead a cross organizational elements  with financial and operational leadership on the team.

   All IT activities should be considered business management activities. These may be "teaming" activities, but they are not self-managed software development activities.

Are You Doing Project Management?

There is a continuous discussion about agile and project management. Some voices in the agile community claim "we don't have project managers on our scrum projects, we don't need them." Instead of engaging in the conversation about the need or not for project managers, let's look at what project management does. These are the 9 areas of project management according to PMBOK(r):

1. Project Initiation
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
6. HR Management
7. Communications Management
8. Risk Management
9. Procurement Management

So the first - and actually only - question is

Are these activities found on your agile project in any way - independent of who is doing them?

If they are, you're doing project management. End of Discussion. That's it. That's all there is. You can put a name to the person or persons that do these things. You can call them anything you want. But in the end they are performing the activities attributed to a Project Manger.

Self Organizing versus Self Directed

There is always a discussion about Self Directed or Self Organizing teams. There is of course a major difference between Self Organizing, Self Managed, and Self Directed.
    Brad Appleton has collected literature on Self Organized Teams

    My biased is against self directed in any environment outside personal development or development where you're spending your own money. If you're spending someone elses money self-directed says "we got you money and we'll do with as we please." I don't know what it means to be Self Managed in the presence of someone else money.
    Self organizing in the presence of someone eleses money is clear - "we'll optimize our organization to optimize the value returned from the money you gave us."

Agile Water Project

    The road from our neighborhood to the main road (Niwot Road) is getting a new water system. Moving water from a reservoir to the west to the water treatment plant 6 miles to the east. It's a two lane road, no shoulder - bad for bikes - and typical overhanging cottonwood trees, bounded by stables and farms, a golf course or two and the IBM Global Services Plant.
    I drive this route most mornings when I go to the office in Denver. I finally noticed something. The construction company would dig a trench for the water pipe - a 48" diameter blue plastic snap together segment. Place the pipe pieces in the ditch, laid on sand, cover is up, pack down the top soil and cover that dirt with hay.
    That's do a couple 100 yards a day. In the evening all the equipment was back in a storage area in a farmers field. There was evidence of work, but no open ditch, no partially completed work. All the blue pipe stacked neatly ahead of the next days work.
    At the crack of dawn - around 5:15AM here in the mountains, the work began. Around 6:00PM the sweepers where finishing off the final clean up for the day.
    I thought tonight on the way home

One day iterations
100% completion at the end of each day
No wasted materials, effort, or motions

Agile water project! If they can do this, why can't IT? Good question.

There are lots of moving parts, supervisors, dump trucks coming and going, road graders, ditch digging machines, pickups with plans and schedules on the hoods in the morning, people in hard hats walking the side of the road with radios in their hands in the late afternoon. Pickup trucks parker everywhere along the side roads, in fields, and the ubigtuous flag-man directing the one-way movement up and down Niwot Road.

No "self organizing teams," no "cow boy developers," not a customer in sight. OK, one Left Hand Water district pick truck parked up the road.

Waterfall? What Waterfall?

The discussion still abounds comparing Agile Software Development methods with Waterfall. There is absolutely no doubt that some, if not many, IT shops still plan their project in a "Waterfall" style manner.

But my sense is the agilest confuse speaking about the writing of software at the lowest level of the program activities – that task level in the IMS - while using the term "waterfall" at the programmatic management processes of a program.

I also know from daily practice that even in the highest ceremony business of all - US DoD Defense Acquisition - the traditional vision of a "Waterfall" project management method is long ago dead and in the ground.

So why this "red herring" as the basis of discussion? Can't really say. But I can say what is current practice in the domain in which we work.

The current DoD 5000.02 guidance eliminates the term "spiral" (used in 2003) and replaces it with "evolutionary acquisition."

Here's a quick assessment of the new impacts of .02

A Short Survey of the Current DoD 5000.02 Processes

The spiral development process was directed in 2003 through DoD 5000.2 along with incremental.

Another Short Overview of 5000.02

Here's a summary from INCOSE as well:

A Slightly More in Depth of How Programs are procured under DD 5000.02

Especially look at Page 13 of the INCOSE brief

Looking at individual service guidance - NAVAIR for example - the topologies found in waterfall - linear acquisition - were replaced a decade of so ago with incremental, iterative, spirals.

So what's the issue here and why is this conversation important?

1. When we have a discussion about development methods and confuse them with Program Management methods, neither side of the discussion is informed.
2. Confusing software development methods with project management methods, removes a large percentage of the work activities for a project from the conversation and possibly from the project, leaving the project open to risk. Wanna answer why project fail. Look at the real statistics - Poor Planning and Controls. No Requirements Management, No measure of Physical Percent Complete - Agile does shine here.
3. The context and domain of many development methodologies is just that "the development of software" - code. No the management of the program. Round Peg Square Hole.

In the end providing a Value Proposition of Agile has served us better than comparing Agile to some mythical obsolete method no longer allowed in the DoD. Tell me "why" I should use something, not "why" the old way is bad.

 

Enterprise IT is not a Science Experiment

I fat fingered a reply to good point Pawel Brodzinski was making on a previous post about change. I deleted his post by mistake while trying to update my response. So here's my response

Enterprise IT is Not a Science Experiment. If we need a discovery phase for some portion of the system, plan and budget that discovery phase. Change at the code and lowest functional level is part of the development process - which is itself a science experiment. Change at the business process level is considered a “non recoverable sunk cost.” I’m speaking and will start to always make it clear – that the undesirable change I mean  is at the business process level.

The absolute problem with frequent changes at the business process level is the customer is wasting money by being lazy and engaging in sloppy thinking. Unless those changes are reviewed approved, warranted, assessed, confirmed, budgeted, ... Otherwise change is simply the churning of money with no return. When we see high - un warranted change - we see poor planning and poor thought process on the project management and business management side of the operation.

Of course "change" happens, but it absolutely must be for the right reason.

Now if it's your own money, who cares. If it's the public's money there's a public accountability issue. If it's the stock holder’s money, there’s a SOX issue.

I know many hold dear to their hearts this notion of "change is good," but as a stock holder in the firm in which someone is churning my paid in value by making changes to the corporate ERP system  to things they should have thought about before you started, I'd be selling short.

Ask ourselves this - what is the reason for the change?

1. Was the business lazy and didn't plan far enough ahead to know that the database architecture doesn’t scale?

2. Was the business bought by another firm and the database architecture doesn't scale?

3. Did the business buy a database engine from a firm that went out of busines?

The Blanket statement "change is good" without a context or domain is not very useful. I will try my best to include context and domain as well.

Agile Development Versus Traditional Development

Brad Egleland has a post titled Agile Software Development Project vs. Standard Software Development Project where he conjectures there is less cost, lower rework, and the final product is closer to the customers needs. Which may or may not be true. It'd hard to tell without parallel projects. But that's not the point.
    He describes the traditional project activities as:

• Requirements definition
• Development
• Unit/system testing
• User acceptance testing
• Deployment
• Post-deployment support (break/fix & tech support)

Nothing wrong, that's pretty much what happens ON EVERY SOFTWARE DEVELOPMENT PROJECT independent of the development method. Yes I'm shouting.
    It's the granularity of how long each of these is performed. Nothing in the "agile," approach be any different in the end. It's simply not possible. Agile MUST:

• Capture the requirements in some way - use cases, story cards, hand waving at the white board
• You gotta right the code
• You gotta unit test and system test
• The user needs to confirm no matter what
• The system needs to be placed into service
• And of course updates and the like have to take place

    So why is type of comparison still occurring? I don't know.
    I had an long ago picture from Kent Beck that showed the evolution of XP. Starting with the traditional Design > Code > Test > Fix sequence. All linear. Then evolving into multiple shorter cycles of DCTF. Then a two week cycle of DCTF.
    My friend who is the CTO at BoldTech here in Denver has a DAILY DCTF, and on some projects a twice a day DCTF.
    No matter the method the steps Brad shows in the traditional approach MUST be done, in SOME order.
    It's the order, the granularity, and the response at the end of the cycle that seperated agile from traditional. It's NOT agile versus traditional is GOOD project management Versus BAD project management. Everything else is a matter of granularity.

So to take up Brad Challenge - Show Agile is Better

In the agile world you find problems faster. By agile I mean finer granined cycles. Finding problems faster lets you fix them faster. That's obvious. If you have a stable baseline for the next iteration, you can improve the quality as the process proceeds. That's likley meausreably better. Agile is simply good rick retirement planning. The same risk retirement planning we employee on multi-billion manned spaceflight programs. Like build a full scale mock up of the same weight and shape to see if the crew can fit inside. Like taking a short flight in the desert - the Flight Test Article

Agile is a sweet spot software development process. But remember it's just that a software development process, not a complete end-to-end project management method.

The Recurring Agile Myth Article

Over at Gantt Head Dr. Andrew Markar has a column titled "Debunking Agile Myths." (You'll need a free account to read this.) Andrew is a frequent commenter here and has contributed to advanced the profession of project management.
    Andrew's article makes some good points, so please sign up and read this and other articles. I'm always troubled though by some items that are missing from discussions like these. So here's my additions to Andrew's good content.

• Agile Myth Number 1: Agile is just an excuse to code with no documentation

    The notion of incorporating the "right" amount of documentation is in the eye of the beholder. Actually its in the eye of the IT Governance Committee. Good IT development processes has the "right amount" of documentation. This "right" amount is rarely defined by those developing the software - the "developers."

    Having been a developer in a former life - embedded control systems for products ranging from refineries to missiles. I personally would do only the bare minimum of documentation. It's the standard approach. But in fact I wasn't writing software for my self, I was writing software for the air force, for Exxon, for Boise Cascade, for the Navy. It was their software in the end, since they were paying for it. They wanted documentation that described the Who, What, When Where, Why and How of the delivered product.

• Agile Myth Number 2: Agile doesn't follow any PMBOK compliant processes

    Agile is a provider of technical solutions. Agile is a engineering process. Take a look at the CMMI-DEV V1.2 process areas to see there are many other activities involved in building software products that writing code. There is process in Agile. Agile is a process. A disciplined process. PMBOK is a description of Process Groups and Knowledge Areas.

    PMBOK is NOT a project management method. In the same way Agile is NOT a project management method. Agile is a software development method. If the software is the one an only outcome of the project, then agile can be substituted for the project management method. But I have never in my life - and it's a long life of software and project management - been on a project where the software was the business outcome. The business outcome is the business outcome.
    The software was the means to achieve that business outcome. Even when the business outcome is to fly to the moon or kill people on purpose, the software is just the means. The project or the program provides the means, the software is just one piece. When you substitute Agile for Project Management you're confusing development with management.

• Agile Myth Number 3: There is no planning in agile

    Planning is in the eye of the beholder, just like documentation. When Andrew says there is more planning in an agile project than in a waterfall project (what ever that means), I'd like to see the waterfall project. It's probably a bad waterfall project. We (our firm) provides program planning and controls staff to a manned spaceflight avionics program. This program is a mix of software, firmware and hardware. The current rolling wave for all this work runs about 30K lines of MSFT Project schedule. For about $500M worth of development. This is a big project. Smaller projects have 5K to 10K lines of activities for $20M to $50M worth of software and hardware development.
    Having a plan means you not only know where you are going, but how long it might take to get there and how much it might cost when you arrive.

• Agile Myth Number 4:Agile Won't Work with Distributed Teams

    Most of the programs we work are distributed. Most are software intensive programs. Coordinating the actions of teams across the continent or across the world has pretty much the same problem. If you can't look someone in the eye then it is a narrow band communication channel.
    Other ways of increasing the bandwidth are needed. Agile addresses some of these, but others are needed. NASA solves this with full fidelity simulation - Simulation Based Acquisition is the official term.

    In the end here's the issue if have with the agile view of the world. In the right hands agile is a wonderful paradigm for developing software. In the right context and the right domain it remains a wonderful paradigm for developing software. But software is a product. The product is NOT the project. The product is the means to the delivering value to the project. The project (or program) may be commercial - process insurance claims. If may be scientific - point the orbiting telescope at a distance galaxy. It may be industrial - process tall skinny pines trees into money (paper) at a rate of $4B per year in southern Louisiana. Or it may be more dark - fly the missile to a target in a distant land and delivery it's cargo.
    But in all cases, the project is larger than the software. While to Scrum folks would have us believe Scrum is a project management method, when you map Scrum to the PMBOK Process Groups and Knowledge Areas you come up with empty cells. When you map Scrum to CMMI-DEV V1.2 Process Areas you come up with more blank cells. When you map Scrum to a DoD 5000.02 Integrated Product and Process Development map you come up with loads of blank cells.

    Agile is a software development method

Putting "project" in the title of an article, a training course or a certification does not make it so.

Simple, Isn’t Really Simple

During a discussion – of sorts – with Mary Poppendieck about Chapter 2 of her upcoming book, I suggested several ideas needed clarification regarding the use of "Waterfall" in modern project management. Mary forwarded a paper – an opinion piece actually – from Denning, Gunderson and Hayes-Roth titled "The Profession of IT: Evolutionary System Development," Communications of the ACM, Vol 51, No 12, December 2008.

Mary's book by the way looks like good reading – as usual. It is completely my issue, when I get wrapped around the axle about the details of how information is being presented. The perfunctory simplification of a topic for editorial reasons, or simply because of one's point of view. The use or mis use of Earned Value and the understanding or misunderstanding of such a topic is typical of the exchange between agilest and traditionalist. Dave Nicolette has suggested a discussion of the irreducible principles of project management to turn the light on the differences between principles and practices and that agile and conventional practice have much in common.

In this article they suggest that the failure of large systems is caused by inability to rapidly adapt to the changing environments. They provide an example of a system built within the U.S. Department of Defense using an agile approach:

The W2COG is a self-selecting collaborative community of experts formed among federal agencies, DoD, and commercial firms to enable agility, aka "netcentricity," via adaptive, open, SOA by removing the traditional barriers to cross-stovepipe collaboration.

W2COG projects …"include netcentric studies, demonstrations, and prototypes of bundled off-the-shelf capabilities validated against operational use cases. These are essentially "reference designs" if you were in the hardware/firmware platform business.

One of the backgrounders states …

Joint Interoperability Test Command (JITC) employs the W2COG Institute (WI), a government and industry expert body established by OSD, to serve as a computer network-enabling "Capability Broker." Accordingly, the WI has designed a "Mission Thread Market" (MTM) process to incentivize sustained COTS software competition around government use case requirements in 90 day production cycles. In particular, Government seeks to incentivize industry to bind innovative SOA solutions to government-furnished high assurance services, e.g. for authentication and authorization.

The ACM paper goes on to state several things that need some examination:

• Dependable large system can only be attained through rigorous application of software engineering design process (requirements, specifications, prototypes, testing, and acceptance).
• The key design objective is an architecture that meets specifications derived from knowledgeable and collectable requirements.
• Individual of sufficient talent and experience can achieve an intellectual grasp of the system.
• The implementation can be completed before the environment changes very much.

So like many topics in our domain, simple answers usually come from simple understandings. When in fact the actual understanding is much more complex. So I decided to do a little weekend research.

The authors provide no references for these assumptions. So it must be assumed these are their personal assumptions. They then proceed to use these assumptions with the anecdotal examples of failed systems. Several examples of failed large systems include:

• FBI Virtual Case File – a project that violated every single principle of project management on the planet.
• NMCI – a project that "failed to meet its two strategy goals," according to the GAO Report titled:"TECHNOLOGY: DOD Needs to Ensure That Navy Marine Corps Intranet Program Is Meeting Goals and Satisfying Customers," http://www.gao.gov/new.items/d0751.pdf

Examples of successful projects using evolutionary design include the World Wide Web and Linux.

Comparing Apples to German Sheppard's

While there are well document failures in the large complex systems development business, providing a counter example of the WWW and Linux seems curious. The web is certainly evolutionary as is Linux. But these were projects whose market was evolutionary and emergent as well. The FBI Virtual Case File systems and the NMCI system had specific operational needs, with measurable business and mission benefits. Not the same as a solution looking for the problem. As a very early user of DRAPA – Net at Wright Patterson Air Force Base, we had "interest" in communicating over a network that was not dial up. But I doubt anyone who was a user at our level – FORTRAN signal processing programs using DEC-10 running BBN's Tenex. There were visionaries for sure. It wasn't us though.

But the FBI VCF and to some part NMCI were purpose built systems, with the "capabilities" predefined – solve this problem in this manner.

This by the way is one of those diversionary approaches by some in the agile community. Use an example of poor or even downright bad management as the counter example for some agile techniques.

The FBI Virtual Case File

The VCF failures are well documented:

• Lack of a strong blue print from the outset led to poor architecture decisions – what does "done" look like?
• Repeated changes in specification
• Repeated turnover of management
• Micromanagement of the developers
• Use personnel with little or no domain experience for software development
• Scope creep – continuous adding requirements while at the same time experiencing schedule delays and cost overruns
• Code bloat due changing specifications
• Adding more people as the project fell behind. An explicit violation of Brooks' Law.
• Planning to use a hard cut over, removing any chance to "try before buy"

NMCI

GAO reports states … "analysis of available performance data, however, showed that the Navy had met only 3 of 20 performance targets (15 percent) associated with the program's goals and nine related performance categories. By not implementing its performance plan, the Navy has invested, and risks continuing to invest heavily, in a program that is not subject to effective performance management and has yet to produce expected results."

... "analysis also showed that the contractor's satisfaction of NMCI service level agreements (contractually specified performance expectations) has been mixed."

… "analysis further showed that NMCI's three customer groups (end users, commanders, and network operators) vary in their satisfaction with the program."

Sounds like your typical commercial enterprise project doesn't it? One telling statement in the introduction of the GAO report states …

A plan that the Navy developed in 2000 to measure various aspects of the program, and thereby gauge program goal attainment, has not been implemented, and associated performance reports have not been issued. According to Navy officials, implementing this plan has not been as high a priority as, for example, deploying NMCI and measuring contractor performance. While program officials told us that NMCI has achieved much, they were unable to provide performance data to demonstrate these achievements relative to either the program's strategic goals or the nine performance categories that its 2000 performance measurement plan and other initiatives defined for these goals.

Gee no plan to measure the performance of the various aspects of the program? Sound familiar.

Why And How Can Evolutionary Approaches Correct Poor Management?

The authors don't actually say how. They do reference the W2COG project. Remember this is an integration process of openly available COTS products of a communications system. Now there is a poster child for failure in that area as well. The World Wide Military Command and Control Information System (WWMCCIS), http://archive.gao.gov/d47t13/116661.pdf.

There are some interesting causal issues here:

• the operational concepts were stated too broadly
• the plan prematurely focuses on system architecture
• centralized program management of the current system (WIS) is necessary but unattainable
• modernization efforts were unlikely to resolve the problems with the existing system (WIS)
• an approved concept of operations is needed before proceeding
• detailed information requirements is inadequate
• reliance on technological advances is unwise

In the end the killer statement from this 1980 report is …

Without first identifying the critical data elements needed to carry out assigned missions, the usual result is a system design that does not completely or efficiently meet the needs of all its users. Identifying these data elements before system design and acquisition is essential to ensure proper system sizing and capacity, and hence responsiveness, as well as providing clear guidance to software developers. For these reasons, identification of detailed information requirements--the essential data elements and their associated qualities of timeliness, accuracy, and currency-is incorporated in both DOD and the Office of Management and Budget directives on developing automated systems.

So Why Would Evolutionary Systems Alone Help?

Several fundamental axioms of system development include:

• We need to know what "done" looks like in some way. Without knowing this, time and effort may be applied to work that does not proceed toward "done."
• We need to know at some level of confidence what this will cost in the end.
• Same for duration – some level of confidence how long it will take.

The WWW did not need to operate under these constraints.

So How Can the Best of Both Worlds Be Combined?

This is an ongoing question. No doubt agile has much to offer for the development of software. But for large, complex, mission critical, enterprise systems, can agile alone provide all that is needed for success. The ACM article makes that case, in the absence of evidence though.

Using the NMCI example (an integrated internet solution for the Navy and Marines). How would an evolutionary system development work in the field? In the field of combat Marines with Navy support? Would the Marines get partial capabilities, then upgrade to more capabilities over time? How those upgrades would be managed. Would everyone have to have the same version of the system in order to communicate? Good questions? NMCI is probably not performing as planned. "Users find it does not meet requirements, is inflexible, and has long waits for trouble assistance" [Marine Corp Gazette, Dec 2008]. OK, and evolutionary deployment will fix this?

Maybe. Maybe not. The first problem seems to be no one wants to admit there is a problem. How exactly would evolutionary development make the problems visible in ways not currently being done.

And The Answer Is?

Establish an irreducible set of project management principles. If these principles cannot be found in the programmatic aspects of the project, the project will likely be headed for failure. What are these irreducible set of principles?

Rapid adaptation is nice. But within what principled boundaries. Do the Marines get to choose what machines they use, what networks they communicate over, what software gets loaded on those machines? Probably not.

Did the FBI VCF project come unglued because it was not adaptive to change? That's not what the report says. Only mention of the poor project management processes, manipulative vendors, simply bad leadership.

In The End

When the discussion continues to mix software development methods with project management, we will continue to get sideways with overlapping methods. I'm not hopeful this will be resolved. PMI is starting to use the term "agile." At one time I was adamant that process and product was the same thing in the project management space.

I no longer believe this is a good idea – project management processes (project controls) and product development (software development) are separate - both needed, but not interchangeable.

Bill Duncan is currently spewing out his breakfast coffee at the sound of this admission.

Waterfall? Not Allowed!

    The Red herring of Waterfall has risen again as the favorite stalking horse for agilest when trying to find some way to sell their approach. There are several issues with this tactic, not the least of which is Waterfall as described by an agilest is actually prohibited in the government sector. The second issue comes from the favorite reference to the Royce's paper on Waterfall (father and son). Ignore the details of the paper and use it as an example of how Waterfall was pulmigated and still in use.  But you need to read the fine print in this paper to discover iterations, customer involvement, "do it twice," feedback up and down the line, etc. etc. For 1970 this was far out stuff.

How It's Done on a Larger Scale Today
    The actual top level procurement process for government (DoD) acquisition is an incremental and iterative approach described in the Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System. Notice all the loops in the "W" style systems engineering process down in the Technical Section. Of course this approach should NEVER EVER be considered outside projects larger than $20M. Of course $20M is chump change in the DoD world. But the point is NEVER NEVER speak of this process in any form when discussing procurement or development process in the commerical world.
    But at the same time the Waterfall Red Herring is not allowed even in this world. So why on God's green earth do agile thought leaders speak of Waterfall as the process they are trying to replace. It's simple marketing really. Find the ugliest, least successful, worst track record approach to developing software and use that as your comparison. Never mind that all the "evil" outcomes of the described process are actually BAD Project Management Practices.
    In the end ANY project management method - from "magic beans" to DoD IMP/IMS using ANSI-748 Earned Value needs to have an irreducible set of PRINCIPLES on which to base their PRACTICES. Principles and Practices are different. I already spoken to the irreducible principles that can be found in PMBOK
    So the question can be asked again. What principles of project management would NOT be found in any credible project management practice? I might suggest Procurement would be one. But I'm stumped to think of any others.

Separating Principles from Practices
    So when the latest critique of "waterfall" starts out the discussion rarely if ever is about Principles. It's almost always about practices - and bad practices at that. It's like complaining you can't loose weight while eating Big Macs morning, noon, and night. That !@#$'ing MacDonald's diet just doesn't work. Really? You Think?
    Look at the Principles here and ask which ones you would not want in your favorite project management practice. Now the practices can range from back of a napkin, white board or some other favorite media - to a full blown SAP (heavens no, please) based program management process framework.
    I might conjecture if you ask and answer the project management process questions in this manner all the "us versus them," the "they were really not very smart in the past," and other opening apporoaches to project management replacements go away. And what you're left with is an assessment of th type of Practices best suited for your domain and context.

Agile Status v. Deliverables Based Status

Jason Yip has a nice post describing the status expected from an Agile project. From the point of view of an agile iteration these are:

1. Is the project going to succeed in terms of achieving scope goals within time goals?
2. Where is the project trending in terms of velocity (i.e., rate of completing work)?  Does it require intervention?
3. Where is the project trending in terms of scope increases?  Does it require intervention?
4. How far have we used up overall project buffer in terms of cost?  Does it require intervention?
5. Are there any other issues that require intervention?
6. What was committed to and completed?  What was committed to and not completed?  Why?

From a Deliverables Based Planning^sm approach these are:

1. What is the physical percent progress for the defined deliverables? Each deliverable is implemented in a Work Package. What is the earned value (or some other measure of physical percent complete)?
2. What is the To Complete Performance Index (TCPI) for the collection of Work Packages and the Project?
3. What are the approved changes and what impacts have resulted to the Work Packages in terms of budget, schedule, sequence, and outcomes?
4. How is the project margin erosion trending compared to the planned margin erosion?
5. What is the content of the Risk Registry, the mitigation or retirement plans for each risk, and the allocated budget for these efforts?
6. Are the planned deliverables being actually delivered according to plan? If not, what is the "get to green" plan for the remaining work.

It's not Waterfall versus Agile, It's sample time

The "red herring" of waterfall is rising again. The proponents of agile use waterfall as the whipping boy (or girl) for what's wrong with software development processes. What is completely lost here is:

It's not the serial process that is the problem, it is the improper sample time between process steps before corrective action is taken.

All processes are serial in the end. Steps are taken one at a time, in some order. The old saw:

What is the purpose of "time,?" To keep everything from happening at once

In the control systems world - and one of the anti-serial process authors claims to have been a control systems engineer - the sampling time in the control loop determines how responsive the loop is to change.

• Sample slow, respond slow
• Sample fast, respond fast

Of course it's not quite that simple, but that's the rudimentary principle. You're house thermostat has a few minute sample time, plus a delay for restart, plus a dwell time for shut down. Same for the air conditioner compressor. Your cruise control has a difference sample-compute-response behavior. Our crappy 1997 Suburban cruise control used to hunt when climbing I-70 west of Denver. It was not tuned to the engine, the load, or the grade, but taken from the Chevy Impala - like the A/C compressor. The flight controls for a 777 have difference response times than the controls for Joint Strike Fighter.
   
A "design, code, test" cycle in months has a different response time than one that samples the resulting output in a month, two weeks, or even a day.

    All processes are serial in some form. Parallel activities can take place, but the value stream is usually serial. If it were parallel there are concurrency issues, integration stabilization point issues and a hoard of other artifacts caused by parallel developments.

• Serial is good
• Serial means least rework
• Sample times MUST be tuned for the context and domain

Any control system engineer knows this. You can learn more starting here.

A Nice Overview of an Agile approach to projects

Mike Cottmeyer gave a webcast on an approach to managing projects with agile techniques. This talk has some good points. But like many of these presentations, the non-agile project examples are "notional" at best. This means they are simple examples, and not likely representative of real projects.
    Notional is good at laying the foundational for an educational process. But Notional usually looses it impact when a "real" project environment comes into play. The presentation above has several over simplified statements:

1. The PM is the center of the project. This is one of those notional concepts found in books about how Agile is better. Any sufficiently mature project manager knows that being the PM means having people perform at their best as a "team," not as subordinates of the PM. This arrangement takes place through the Chartering process, where all the participants discover what roles they play, what the basic deliverables are, and what other participants depend on them and what dependencies they are accountable for. This is the essence of team building.
2. Mike suggests that we stop putting activities into the project plans. This is wonderful IFF (if and only if) there are no dependencies between these activities. That is, they can be performed in nay manner chosen by the team. If however there are dependencies between the activities, the place to discover these is during the construction of the network of activities. It may be a tautology in agile, that activities have no dependencies. If so, Mike's on to something regarding the defining the context of an agile project.
3. Focusing on outcomes is always a good thing. This is the very essence of Earned Value, Deliverables Based Planning, and Integrated Master Planning / Integrated Master Scheduling found in DoD projects.
4. Iterative Planning is nearly the same as rolling waves mandated by DoD 5000.2. This has been around awhile, but for some reasons missed by those not thinking very well about what project management planning really means. The key of course is to define in some tangible measurable way, in units meaningful to the customer.
5. Daily standups, yes this is good. But daily may or may not be the right frequency. Knowing the right frequency us a challenge, but answering the question - how long am I willing to wait to find out we're late? is a good start.

But read this presentation, try out some of the ideas, see if they have applicability for you.

Agile Thinkers?

    I was flatered and a bit taken aback when Clarke Ching asked if I'd like to be interviewed for his Agile Thinkers blog. The subtitle for that Blog is "great thinkers in the Agile community." Well that's news to me. I do "think" a lot about a lot of things. Being agile might be one of them. Figuring out how to convey the simplicity of using Earned Value is another. How to apply our Deliverables Based Planning method is the may one, since I'm the Practice Director for that portion of our business.
    I wrote responses to Clarke fine questions and made up one of my own. Reading them tonight, after having discovered the posts, I think my impluses are pretty close to what I feel with some distance between writing and reading.
    See what you think
    Question 1
    Question 2
    Question 3
    Question 4
    The notion of an interview is actually brillant on Clarke's part - good work and thanks for opportunity is be in fine company of some I know and have met - Alistair, Jerry, Johanna, Tom, and others I've discovered have much to say.