January 15, 2007

Miss Misnformation

When our daughter was in the 5th grade, sher memorized a poem for a class reading titled "Miss Misinformation," from A Pizza the Size of the Sun, Jack Perlutsky. In the poem Miss Misinformation gets nearly everything backwards, wrong or deduces the wrong outcome. Our daughter is now 1 High school Junior and very good Forensics student (debate, rhetoric and humor) and has moved into the realm of understanding the basis of argument, the factual conditions for discussion and general thought process around discovering gaps in both sides of a debate.

Here's the core problem before proceeding

The statement that Plan Based Project Management processes must be Waterfall is false. The inverse - Waterfall processes are plan based is true.

The Mis Misinformation poem reminds me of the current discussion around "waterfall," PMBOK and Agile Project Management. The latest installment is Michele Slinger's series of articles in Sticky Minds titled "Relating PMBOK Practices to Agile. First off I'm not a great fan of PMBOK, but I am a PMI member - College of Performance Management and Aerospace and Defense SIG member. But PMBOK does provide some beginning guidance to project managers. More importantly PMBOK is NOT, I repeat NOT a software development life cycle methodology. PMBOK contains Process Groups and Knowledge Areas.
I borrowed the figure below from several sources (which I can't now remember) but it serves as a clear example of how the PG's and KA's are related.

A reading of PMBOK will reveal that the project management life cycles are for illustrative purposes only. Many readers make the mistake of assuming PMBOK is in fact a guide to manging projects. It is not, the title says it's not and the text in the document with that title says its not. The title is A Guide to the Project Management Body of Knowledge.

The primary reason I'm not a fan of PMBOK is it is too simple mined for my tastes. Not that I have sophisticated tastes - at least in the area of project management methods - it's just that PMBOK leaves too much out in practice and what it leaves in is pretty much obvious and in some areas not sufficient to keep a project out of trouble.

For a better look at a "practical" guide is the DoD version of PMBOK. This document provides the practice of project management along with a guide to the body of knowledge. By the way, there are many "bodied of knowledge" for the practice of project management, PMBOK is but one - but that another topic.

Back to the Topic

Many agilest writers rail against the "waterfall" method of project management. This approach went by the wayside, replaced with evolutionary acquisition and spiral development with agile teams. The 20th International Forum on COCOMO is a place to look for the current process in software intensive systems acquisition. But this is a large topic outside this discussion as well. The point here is many agilest don't do their homework, haven't read PMBOK or hold a PMP. Same goes for CMMI - which is a maturity assessment process - NOT repeat NOT a software development methodology. Software development methodologies can be assessed as to their maturity against the CMMI process areas, but CMMI does not tell you "how" to do things, only "what" needs to be done in order to be appraised at a specific level of maturity. Back to the point again - the suggestion that Plan Based Processes are by default "waterfall" is simply wrong. Plan Based Processes "can" be waterfall, but many are not. Lean Construction is plan based, DoD's IMP/IMS is plan based, the current evolutionary and spiral based development processes are plan based. XP and Scrum are plan based - they "plan" the iteration before its start, reflect on the success of that iteration and its plan as the basis of the next iterations plan.

Planning is a necessary part of project management. The technique by which plans are built various among the methodologies.

Plans are the strategy for successfully delivering the value defined by the customers requirements

If we could all somehow get over the idea that "planning" is a sin, then we could get to the meat of what is different between agile and other approaches to project. These differences are not actually what you think they are:

Customers are on site in major NASA space craft procurements

Iterative development takes place in major defense systems acquisition

Full fidelity testing is a continuous process in manned spaceflight projects

Fix duration iterations take place in avionics software development processes for launch vehicles

etc. etc. etc.

The primary reason traditional software development projects fail is not because of the use of traditional project management methods. It is because the process areas and knowledge groups of PMBOK or any other project management process area and knowledge group are not applied, applied incorrectly or applied in ways that "break" the project.

What Does Agile Do When It is Doing Agile?

It demands short iteration cycles - other only recommend

It demands on site customers - others only recommend

It demands 100% unit testing - other only recommend. BTW 100% UT is far from sufficient in any non-trivial enterprise software project. Integration testing is the critical success factor followed by User Acceptance Testing

It demands accountability for the product - others recommend a hierarchy of control where accountability for the "team effort" is only recommended

It puts people first - but of course the irony is XP and Scrum is highly structured processes. So putting process over people is a bit of a false promise. What is better in agile is the challenge question to justify the process BEFORE it is applied. In other methods, the process comes first.

Comments

Miss Misnformation

When our daughter was in the 5th grade, sher memorized a poem for a class reading titled "Miss Misinformation," from A Pizza the Size of the Sun, Jack Perlutsky. In the poem Miss Misinformation gets nearly everything backwards, wrong or deduces the wrong outcome. Our daughter is now 1 High school Junior and very good Forensics student (debate, rhetoric and humor) and has moved into the realm of understanding the basis of argument, the factual conditions for discussion and general thought process around discovering gaps in both sides of a debate.

Here's the core problem before proceeding

The statement that Plan Based Project Management processes must be Waterfall is false. The inverse - Waterfall processes are plan based is true.

The Mis Misinformation poem reminds me of the current discussion around "waterfall," PMBOK and Agile Project Management. The latest installment is Michele Slinger's series of articles in Sticky Minds titled "Relating PMBOK Practices to Agile. First off I'm not a great fan of PMBOK, but I am a PMI member - College of Performance Management and Aerospace and Defense SIG member. But PMBOK does provide some beginning guidance to project managers. More importantly PMBOK is NOT, I repeat NOT a software development life cycle methodology. PMBOK contains Process Groups and Knowledge Areas.
I borrowed the figure below from several sources (which I can't now remember) but it serves as a clear example of how the PG's and KA's are related.

A reading of PMBOK will reveal that the project management life cycles are for illustrative purposes only. Many readers make the mistake of assuming PMBOK is in fact a guide to manging projects. It is not, the title says it's not and the text in the document with that title says its not. The title is A Guide to the Project Management Body of Knowledge.

The primary reason I'm not a fan of PMBOK is it is too simple mined for my tastes. Not that I have sophisticated tastes - at least in the area of project management methods - it's just that PMBOK leaves too much out in practice and what it leaves in is pretty much obvious and in some areas not sufficient to keep a project out of trouble.

For a better look at a "practical" guide is the DoD version of PMBOK. This document provides the practice of project management along with a guide to the body of knowledge. By the way, there are many "bodied of knowledge" for the practice of project management, PMBOK is but one - but that another topic.

Back to the Topic

Many agilest writers rail against the "waterfall" method of project management. This approach went by the wayside, replaced with evolutionary acquisition and spiral development with agile teams. The 20th International Forum on COCOMO is a place to look for the current process in software intensive systems acquisition. But this is a large topic outside this discussion as well. The point here is many agilest don't do their homework, haven't read PMBOK or hold a PMP. Same goes for CMMI - which is a maturity assessment process - NOT repeat NOT a software development methodology. Software development methodologies can be assessed as to their maturity against the CMMI process areas, but CMMI does not tell you "how" to do things, only "what" needs to be done in order to be appraised at a specific level of maturity. Back to the point again - the suggestion that Plan Based Processes are by default "waterfall" is simply wrong. Plan Based Processes "can" be waterfall, but many are not. Lean Construction is plan based, DoD's IMP/IMS is plan based, the current evolutionary and spiral based development processes are plan based. XP and Scrum are plan based - they "plan" the iteration before its start, reflect on the success of that iteration and its plan as the basis of the next iterations plan.

Planning is a necessary part of project management. The technique by which plans are built various among the methodologies.

Plans are the strategy for successfully delivering the value defined by the customers requirements

If we could all somehow get over the idea that "planning" is a sin, then we could get to the meat of what is different between agile and other approaches to project. These differences are not actually what you think they are:

Customers are on site in major NASA space craft procurements

Iterative development takes place in major defense systems acquisition

Full fidelity testing is a continuous process in manned spaceflight projects

Fix duration iterations take place in avionics software development processes for launch vehicles

etc. etc. etc.

The primary reason traditional software development projects fail is not because of the use of traditional project management methods. It is because the process areas and knowledge groups of PMBOK or any other project management process area and knowledge group are not applied, applied incorrectly or applied in ways that "break" the project.

What Does Agile Do When It is Doing Agile?

It demands short iteration cycles - other only recommend

It demands on site customers - others only recommend

It demands 100% unit testing - other only recommend. BTW 100% UT is far from sufficient in any non-trivial enterprise software project. Integration testing is the critical success factor followed by User Acceptance Testing

It demands accountability for the product - others recommend a hierarchy of control where accountability for the "team effort" is only recommended

It puts people first - but of course the irony is XP and Scrum is highly structured processes. So putting process over people is a bit of a false promise. What is better in agile is the challenge question to justify the process BEFORE it is applied. In other methods, the process comes first.