If one does use Scrum for the Software development portion of a project, does one still use PMBOK or some other project management methodology for the "other" tasks on a project e.g. the business, marketing, training tasks. What is the project management of non software development tasks referred to i.e. traditional project management?
There are three key steps when closing out an Agile project:Tying up loose ends & handing over to operations. Reviewing the project. Celebrating!
Agile Project Closure is about handing over to the operations team, tidying up any loose ends, reviewing the project, celebrating, and going home.
The purpose of the closing phase in the project management lifecycle is to confirm completion of project deliverables to the satisfaction of the project sponsor, and to communicate final project disposition and status to all participants and stakeholders.
That said, Agile methodologies, specifically Scrum, inherently have a Due Date. Most often, this is the Sprint end date. The team has a clear expectation that the planned scope of the Sprint needs to be completed by the end date of the Sprint.
A project is defined in the PMBOK as being something of fixed scope, duration and budget. Failure of the project is defined as breaking outside one of the three sides of this "iron triangle". Scrum is a set of principles, and a few concrete practices, for dealing with all sorts of knowledge work, based on Agile values, and is specifically designed for development efforts that may not be projects, or may have flexible scope, duration or budget.
You are right that Scrum only deals with a few aspects of the software development process, such as planning. It only defines a few roles, meetings and artifacts, this is to keep it as flexible as possible. Scrum can, and should, address parts of the value stream outside of the software development itself. However, as you mentioned, it does not deal with lots of things, such as software engineering practices, and analysing the business case.
Often the standard Scrum solution is to "let the team decide" on matters that are not directly specified by Scrum. Often the guidelines for dealing with such matters come from other cultures and value or principle-systems within the Agile world, such as XP, or lean software development. Other cultures providing useful stuff for Scrum teams include Real Options, the Incremental Funding Method, Evo.
Some of the PMBOK stuff can be useful to a "project manager" or PO on a Scrum team, however one has to be cautious as the PMBOK stuff implies a rather different value-system than that which Scrum is based on. It is usually best to look for solutions within the Agile culture. Some of the PMBOK stuff still applies in an agile context though.
If you look for mailing lists related to "agile project management" you will find many thriving communities discussing such topics.
Agile development and PMBOK should not be mixed. IF you do, you're likely to end up with Scrummerfall. I've seen this happen with traditional project managers who convert to agile. They just don't get it and seem to fall back to old patterns.
However, in my opinion SCRUM doesn't cover all you need for project management. It sort of lacks an overall strategy to rule by. One possibility is combining SCRUM with EVO project/value management or other value management methods. It will however require a different type of legal contract with the customer. Projects are then more like a continuous process that is time boxed, restrained by a budget or ends when the customer feels he gains less than his investment (using business cases and goal measures). An added benefit is that the customer will see you more as a long term partner than a short term supplier.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With