EricGu has a great post on something he calls scrumbut.  It rings very true.  One of the teams I was in formerly did exactly this:

  • Train everyone on Scrum
  • Used “Scrum, but” with all the changes that work against agile principles like no customer on the project, and wildly long deliverable cycles
  • Called it scrum
  • Blamed Scrum and Agile when it failed.

Certified Scrum Masters should be derided if they allow a process to be called Scrum if it doesn’t stick with some basic practices:

  • scope managed as a backlog
  • customer decides priority for any items on the backlog
  • sprints not to exceed 30 days
  • team (individual contributors only, no PM, no chickens) picks the items off the backlog that they can do in a sprint. 
  • Use of a daily burndown to track progress, not Project or Primavera
  • Monthly demonstration of progress directly to the customer or customer representative

 

 

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

3 thoughts on “We do Scrumbut”
  1. There’s a lot of XP But out there, and surprisingly, a WHOLE lot more of RUP But.  

    To the point where I saw someone on the MS Agile list say, "There’s agile processes, like XP and Scrum, and then there are waterfall processes like RUP"

Leave a Reply

Your email address will not be published. Required fields are marked *

two × 4 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.