7 June 2010

Can scrum stand alone as a project management framework?

A couple of times I have made the statement that Scrum is a complete and fully integrated project management method. I’ve also said I don’t think there are any significant contradictions between scrum and the PMBOK.

I've been asked to explain myself and in a couple of upcoming posts you'll see my attempt.

To start with I mapped my opinions on how well Scrum covers the integration management processes described in the PMBOK.  This is just a first pass and I'll elaborate later.  I am very interested in your views, so help me out and add a comment below.

The first thing I want to highlight is that my view of what scrum delivers and the range of integration activities seem to more or less reconcile.  

Each sprint can be a mini project and can potentially be self contained or can be followed up by further investment.  

The first sprint in a larger project will start with some product envisioning and ramp up work.  And a sprint review can be a sufficient closure.

Lastly, this little graph says to me that the most important tool in scrum is the project backlog - thus the goal is still a customer who knows what they want.

The second thing to note is the emphasis on monitoring and controlling.  Work is monitored and measured at every step and you get early insight into problems.  There is also a strong emphasis on directing and managing the work.  These two aspects are fairly tightly lined, because scrum, like other empirical approaches value the utility of the feedback loop.

These are my first thoughts.  What do you think?  I'll add more in a couple of days.

16 comments:

  1. Craig,

    Really nice job. The only other thing I would add - which I believe would be very helpful in this conversation - is which of the Scrum roles typically perform or are responsible for each of the Scrum processes. Is it the Scrum Master, the team, or the Product Owner.

    At the end of the day, I think that the Agile Project Manager ends up supporting the Product Owner in those cases where the projects are so big that the Product Owner responsibilities overwhelm a single owner.

    ReplyDelete
  2. I am mainly interested on how the Product Backlog drives creation of a plan... but even more interested on how a Product Backlog gets created in the first place in order to use it planning.

    ReplyDelete
  3. Craig,

    Where would you call out:

    ▪ Cost management - what's the method for forecasting the Estimate At Completion for the project, managing to this baselined EAC, and controlling any overruns in the absence of approved changes to the Total Allocated Budget?

    ▪ Time management - fixed iterations may address this, but how about a plan for 100% done for the project, including the software but also all the other deliverables around the project - transfer to production, transfer to business, business operations, process changes, etc. Are those included in your Scrum processes?

    ▪ HR Management - the team may be fixed, so this might be minimal.

    ▪ Risk Management - is that manage impediments? Is there a plan for managing and mitigating these impediments?

    ▪ Procurement Management - this may be minimal as well.

    No doubt you've augmented classic Scrum with project management process areas - good job.

    But how does this project backlog appear? Requirements architecture, project and program governance and decision rights of the firm. These are defined in the change control processes of monitoring and controlling.

    Is it really the case that Scrum has formal change control processes tied to governance of the business and the projects that support the business.

    I'd suggest there is absolutely no doubt that Scrum is a wonderful software development method embedded in projects. But are projects just about software development.

    If so, you may have the right solution. If there's more to the project than just software there is possible uncovered areas in your suggested replacement of PMBOK-style project management frameworks.

    ReplyDelete
  4. I really enjoyed the post and Glen's comments - they got me back to thinking about this topic myself - since I was not able to add images to my comment, I have ended up posting a couple of additions myself here --> http://just-another-blog-for-kicks.blogspot.com/2010/06/scrum-agile-and-real-project-management.html

    ReplyDelete
  5. Glen

    Yes, the points you mention are absent, but are they necessary for all projects?

    I will qualify this discussion with a context soon.

    ReplyDelete
  6. David - I need to do a post on this - but essentially the product backlog is delivered on the same principle as a product breakdown or work breakdown structure.

    ReplyDelete
  7. Glen

    Another point - yes scrum is augmented with some additional thinking. Some of it PM domain knowledge, some of it commercial sense and some of it common sense.

    ReplyDelete
  8. Dennis

    A good idea. I'll have a look at that in a coming post.

    ReplyDelete
  9. Tom,
    Why does Chrome think your site is maleware?

    Google says,

    Of the 8 pages we tested on the site over the past 90 days, 4 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2010-05-29, and the last time suspicious content was found on this site was on 2010-05-24.

    Not a good recommendation for a Blog, you may want to look into this.

    ReplyDelete
  10. Craig,

    Whether the process groups and knowledge areas are needed to be present on any one particular project is likely domain and context sensitive.

    Not all those are needed from PMBOK either in all cases.

    Here's how we address the "graded application" in our government domain (Department of Energy)

    http://herdingcats.typepad.com/files/graded-application-of-project-management-req.pdf

    But deciding how to do this grading of the application of PMBOK (DoD PMBOK actually), there was much thought and testing of the applicability, done with consideration of the longer term impacts.

    ReplyDelete
  11. Craig,

    Having participated in many Scrum teams in the enterprise IT world, I'd be very surprised to find a PMBOK-style (881A) WBS driving the product backlog.

    My observations have been that the pro duct background is pretty much a list of features needed by the customer, ordered in the way the customer needs them, placed on an iteration, in exactly the way Scrum defines how to do that.

    Could you provide an example of a WBS/PBS that drives a backlog? Thanks in advance.

    ReplyDelete
  12. thanks for the note regarding maleware - I will check it out. Look forward to an ongoing discussion!
    Tom.

    ReplyDelete
  13. Craig, I have looked around at different descriptions of PBS. They still assume that the customer will say what product(s) they want. If a customer does not know, or cannot describe it effectively, what do you do then? And how do you know if that has occurred? By delivering something the customer rejects?

    I may sound picky here, but it is the root of success or failure as I see it.

    ReplyDelete
  14. Anonymous12:48 pm

    Craig - I really like what you have done here, please do keep working on this! I am a PMP and CSM also and find that the two work together very well. I look forward to your updates. Thank you!

    Bob

    ReplyDelete
  15. I read this article, please one more update related article,

    Thanks for sharing..

    ReplyDelete

Search This Blog