Ken NixonSenior Project and Portfolio Manager| IndependentMeridian, Id, United States
What are your thoughts on how we classify Agile-SCRUM, Iterations, and Waterfall? Are they all really Project management - or are they perhaps styles of Work Management?
Our organization currently has a Project Methodology that is merged with a standard SDLC. That is too constrictive. While looking at how to split the two and how to define and organize our suggested Activities and Artifacts I ran in to my opening question. Do you see it?
I see Agile-SCRUM as a way several of our development and quality teams work together to get work done. They don't care if the work is enhancements, non-critical support, or a deliverable for a project. I care, as the PM, how I will plan and complete project deliverables on time and on budget.
I see one project as using a mix of iterative development, Agile "stories" and perhaps multiple phases to get all the work done.
What are your thoughts? Saving Changes...
Sort By:
Bernard GorePortfolio, Programme & Project Professional| NZ PoliceWellington, New Zealand
Agile-SCRUM is certainly part of Project Management. Agile-SCRUM is more than just developers getting work done, it overlaps with requirements elicitation, prioritisation of work packages, planning, resource management, tolerances, etc.
If your developers just use what they claim is Agile in isolatio to deliver their work package, they aren't really doing Agile at all, and certainly not SCRUM. If thye were truly using SCRUM then it absolutely would impact considerably on your PM job as it would seriously change what they would deliver to you.
There is no reason why a project can't mix Agile and other approaches, within an over-arching PM methodology, but these need to be managed within that methodology and specific PM techniques to stitch this all together. Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
Agile, Scrum. XP, Kanban, and even SDLC are software development practices and though they certainly can be used within the context of project-organized work, they are not exclusively in the domain of project work.
It is unfortunate that Scrum billed itself as a project management methodlogy; it and the rest of the agile methologies primarily focus on the software development and seem to be focused on what I would call either product development or operations and maintenance. The key differentiator is that these latter two do not have a defined begining and end. Projects, at least by PMBoK definition have a beginning and end and addressing the start up and close out phases is not covered in any agile methodology.
Agile methodolologies are very effective when used within the execution phase of a project, and are also apropriate for non-project organized work. Agile and Project Management are overlapping techniques and both are required if one is attempting "agile project management."
Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Great explanation by Wayne and Bernard.
Although I agree with Ken on the part - that part of project management is to manage the works to ensure that they are properly delivered - but project management itself is not just managing the works alone. There are other areas that fall under the umbrella of project management, e.g. stakeholder management, communication management, human resource management, cost management, risk management etc.
So, unless your definition of 'work management' includes all these, then I would say that there are more in project management than just managing the works to be delivered. Saving Changes...
Ken NixonSenior Project and Portfolio Manager| IndependentMeridian, Id, United States
I appreciate the insightful responses! Keep them coming.
I fully agree the PM is responsible for the full spectrum of project management processes. Some of those processes will be included within the "work management" approach if that is Agile/SCRUM or iterative development, or multi-phase waterfall. The fun part of setting up a separation between the overarching project management methodology and work management is to define those connections.
I have started down that path and can already see it is hard for some who are accustomed to a methodology imbedded with the SDLC to envision the split. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Hi Ken,
When you mentioned "The fun part of setting up a separation between the overarching project management methodology and work management is to define those connections", what connections were you specifically referring to? I am interested to find out more on this. Would you mind sharing? Saving Changes...
Ken NixonSenior Project and Portfolio Manager| IndependentMeridian, Id, United States
Wai Mun Koo, glad to elaborate:
Think of the PM processes regarding Requirements.
The project manager will certainly want to collect high level requirements in every project that support the scope statement and key deliverables. How about the detailed requirements?
If the development team is working primarily within the SCRUM process they put Stories in the Backlog that may not have all the detailed requirements in them - yet. Then when the Story is reviewed in the Sprint Planning session, more requirements are defined. When the Story is pulled into the Sprint and tasks are defined, even more requirements may come to light.
Now, step back and think how the project methodology would speak to Requirements. Keep in mind that at its core the methodology governs all types of projects, not only those working with Agile teams. Some projects are build, others buy, some are software focused and others focused on Hardware.
How do we write the methodology to cover all these scenarios without being too prescriptive, yet giving guidance to newer PMs, ensuring consistency of results?
Does that clarify the "connections" element a little better?
Same concept may apply to project schedule, communications plans, deployment plans, and more.
Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Hi Ken, thanks for your elaboration. I believe I know where you are heading to. Maybe clearly demarcate the project management processes from the product delivery processes could help. You may then vary the product delivery processes based on the nature and complexity of the project and the product/work to be delivered while, at the same time, keeping the project management processes as standard as possible with minimum changes. Saving Changes...
