Loading ...
Sorry, an error occurred while loading the content.

39483RE: [scrumdevelopment] How exactly do agile methods mitigate scope creep?

Expand Messages
  • Roy Morien
    Jul 2, 2009
    • 0 Attachment
      What exactly do you mean by 'scope creep'? That is the burining question, I believe.
       
      If you mean discovering more requirements than you initially thought, isn't this just redefining the scope to include what should have been included in the first place, if you had had the full knowledge and foresight to identify them back then? Is this 'scope creep'?
       
      Do you mean realising that what was thought to be correct in the first place has now been discovered to be incorrect, and so the 'content' of the 'scope' has changed. Is this 'scope creep'?
       
      What about the situation where a client is given the opportunity to see what is happening in the development activity, and that triggers new thoughts and ideas about how the system could better serve their needs. Is this 'scope creep'?
       
      Do you mean changes to the requirements because business circumstances have changed (eg: like a major global financial meltdown) that renders previously stated requirements irrelevant or no longer required. Maybe this is 'scope retraction' rather than 'scope creep'.
       
      I guess I could go on splitting these hairs in different ways, but the point is, all of this 'scope creep' is really a matter of getting it right, and delivering something the client wants, at the time it is delivered, not at the time it was first thought about.
       
      The term 'scope creep' has taken on a decidedly negative implication over time. It is used to imply incompetence on the part of developers or analysts or users who have not properly and correctly identified all their needs at the start of the project.
       
      But that totally ignores the reality that clients cannot tell you everything up front, in a totally comprehensive, non-contradictory, fully detailed way.
       
      That also totally ignores the reality that things change. This thinking (about 'freezing the spec') is a sort of fascist, fundamentalist way of thinking that says we refuse to accept that we are not totally correct in our thinking. We refuse to learn anything after this date of freezing the spec'. We will carry our ignorance forward as gospel, and close our minds to anything new.
       
      Not a very professional way to behave.
       
      There should be no concept of 'scope creep'. The concept of enhancing and increasing our knowledge over time is what we should adhere to.
       
      This, together with the concepts and practices of openness, truth, transparency, collaboration, communication, should be our way. The result can then only be to deliver as much as we possibly can, of useful and useable software, by the deadline as stipulated by the client. When that deadline is stipulated is not necessarilly at the start of the project. In fact, it could be when the project is '90%' complete and we have much better knowledge and understanding to be able to state the deadline.
       
      Regards,
      Roy Morien
       

      To: scrumdevelopment@yahoogroups.com
      From: wagner.andrew@...
      Date: Thu, 2 Jul 2009 08:24:25 -0400
      Subject: [scrumdevelopment] How exactly do agile methods mitigate scope creep?



      Ok, so I'd like to paint a scenario here, to try to precisely reify what I don't understand about agile methods. Here we go:

      First, a waterfall scenario: the team gets asked to do a project with features A, B, and C in 6 months. They design the project, and begin programming. Of course, as always happens, along the way they realize that they're also going to have to do D and E, and that the customer also decides they can't ship without F and G. But of course we can't move the deadline, so we simply cut quality, work a lot of overtime, and squeeze A, B, C, D, E, F, and G all into 6 months. Whew. Hope we never have to touch that code again!

      Now, an iterative approach: again, the team is going to do a project with features A, B, and C. They decide to do one each sprint. But they're still of course going to discover D, E, F, and G along the way, right? So ultimately, it's still either not going to be done in the 6 months, or it will be done with less than optimal quality. So I could see where the customer would get the opportunity to choose among D-G, to say which ones take priority, but I'm still not sure what precisely the win is. Thoughts?




      Click here to find out more POP access for Hotmail is here!
    • Show all 74 messages in this topic