Rarely, if ever, is the conversation around agile and its relation with project management processes set in a domain and a context in that domain. It's time to reset the conversation with the just those items. To establish the "rules of engagement" for the conversation.
- When we say Project Management what do we mean?
- When we say agile, in what domain and context are we speaking about?
- When we say anything about anything, what is the domain and context?
The discussion around PMBOK and agile first needs clarity. PMBOK is a set of principles (of sort) that can be applied to a wide variety of project domains and contexts within those domains. It is agnostic about "how" these principles are executed.
For example, 5.2 Define Scope, says
Define Scope is the process of developing a detailed description of the project and product. The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness; additional risks, assumptions, and constraints are added as necessary.
There Inputs, Processes, and Outputs for Defining Scope. This "clip" is from PMBOK.
Now if an agile software development process - say Scrum - has artifacts or process steps that can be mapped to this process flow - great.
But Here's the Rub In The Discussion
The starting point in the PMBOK and Agile discussion is PMBOK. The Guide to the Project Management Body of Knowledge®. Not the other way around. Or at least not the other way around from my point of view.
So when Mike Griffith s makes a nice map from PMBOK to Agile, we're starting to connect the dots. But here's the rub.
That map - the connection of the dots - is context and domain sensitive. That is the practices that are connected to the principles of PMBOK has a domain - software development, and a context - agile software development team, with all the associated attributes of a software development project using agile.
This is all fine and good, but without stating the Domain and Context it might be seen as a replacement for the principles of PMBOK®
This is not normally the case, but it needs to be said upfront. In the proposal business and on program execution, we use a term - "rules of engagement." How are we going to engage each other in conversation? Essentially what is the domain and context in that domain for moving forward with our work?
