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

RE: [scrumdevelopment] New to SCRUM and agility

Expand Messages
  • Mike Cohn
    Alice— ... Absolutely! Scrum is an infinitely viable approach to development. Because of the way Scrum puts direct emphasis on the prioritization of work it
    Message 1 of 2 , May 3, 2002



      > Is this a viable approach to development?

      Absolutely! Scrum is an infinitely viable approach to development. Because of the way Scrum puts direct emphasis on the prioritization of work it leads to very successful projects. Scrum encourages the technical and business teams to work very closely together (but without some of the “be in the same room” concepts of XP that I find to get in the way of real-life projects).  I have delivered somewhere close to two dozen projects using Scrum. I won’t be naïve and say something like “and all were successful” or “and all were underbudget” but I will go so far as to say that all were more successful with Scrum than they would have been with any other process.


      > What benefits does it bring to the customers?

      Scrum gets value into customers’ hands more quickly than most other processes. It also has the benefit of typically bringing risks to the surface quickly which means that if things are going to go wrong you’ll find that during the first month rather than the last month, which will give you time to correct problems rather than simply going over-schedule. Scrum puts great emphasis on delivering working software. An example: I ran one project where we estimated the project to take 9 sprints (months). The boss was OK with that but told us that we had to be prepared to go live with it any time after 3 months in our own call centers with 30 days notice. He knew we wouldn’t have 9 months of features in 3 months but it set our tone for identifying the absolutely critical features that needed to be done in 3 months. Thankfully we didn’t go live in 3 months but we did go in 7. The project was essentially right on track--we eventually finished in 10 sprints but we deployed an initial version 2 months earlier than our original estimate (again, it had less in it but it kept our business going).


      > What obstacles might we run into were we to try this?

      You might find groups that want you to definitively say “well have x functionality done by june 17”. My frequent response to that is “Anyone who can promise you a set amount of functionality by a set date with set resources is either padding his estimate, lying, or both.”  Scrum doesn’t work like most gantt-chart driven processes that spit out a deadline date. What Scrum promises is that you can get the most functionality from your team in a given period of time. When pressed to give dates (which is almost always) I give something like, “From what we know now we should be able to delivery in 4-6 sprints.”  I add that what I mean is not what most project managers mean (“I’m telling you 4-6 but that means the last day of 6 is the earliest you’ll see it.”). What I mean is that “based on expectations about the work, the team, etc. the team should have enough in 4 months to meet what I think your needs are but it may be 6 months and that the decision is really yours. It won’t be the software team at the end saying ‘we need more time’, it will be a business decision you’ll be able to make between more functionality / earlier delivery.”  Personally, I think that’s a great tradeoff to give a business in exchange for a date that was never real anyway.


      I’ve also encountered some groups that don’t like Scrum because they like to plod along slowly. In particular I’ve seen this is companies with groups of System Analysts / Requirements Writers that have an over the wall approach to passing requirements to programmers. Those groups are reluctant to change because their current way of working isolates them from ever getting any blame about how the system was delivered.


      > What skills are critical to do this?

      I haven’t found any unique skills to be critical beyond the usual ones (hire the best you can all the time regardless of process!). It requires some new ways of thinking and some open-mindedness but that’s about it. You will need someone to work as your Scrum-master—this can usually be the project manager if he or she is on board with the process change. Certainly the Scrum-master should read the Ken Schwaber/Mike Beedle book on Scrum (Agile Software Development with Scrum). Sometimes it’s nice to bring in a scrum master from the outside, if even for only the first few sprints, because an outsider is usually more able to ruffle feathers to make the change happen. Ken is probably your best choice for this.


      > How are developers, liking this type of environment?

      Some resist it at first but I can’t think of a developer who didn’t eventually come around. Some don’t like the freedom of not being told exactly what to do and how to do it. Some don’t like the idea of a daily scrum meeting—it feels like micromanagement to them. After usually no more than 2-3 weeks they eventually realize I’m there to remove obstacles to their success and that when I ask daily how long something will take it is not so I can yell if it’s going slowly.


      > Anything else?

      Go for it. Find a really high priority project and use Scrum on it. Read the Schwaber/Beedle book, ask lots of questions of this group, and then start planning your backlog. I really think that once you’ve done a project this way you won’t go back to any other way. I’d love to hear how the project is going once you get started with it.


      Good luck.


      --Mike Cohn





      -----Original Message-----
      From: Alice.O'Hanlon@... [mailto:Alice.O'Hanlon@...]
      Sent: Friday, May 03, 2002 6:05 AM
      To: scrumdevelopment@yahoogroups.com
      Cc: Alice.O'Hanlon@...; Jack.Benjamin@...; Jim.Womble@...; Judy.Pena@...; Michael.K.Kelley@...; Michelle.Hall@...; Prashanth.Tirunahari@...; Roland.McDaniel@...; William.Battle@...
      Subject: [scrumdevelopment] New to SCRUM and agility


      Dearest Scumdevelopers......

      Our team is already working on answering these questions for our environment, but it would be nice to hear input from folks that have already done this.

      Does anyone have any thoughts on the following?

      Is this a viable approach to development?
      What benefits does it bring to the customers?
      What obstacles might we run into were we to try this?
      What skills are critical to do this?
      How are developers, liking this type of environment?
      Anything else?


      Alice S. O'Hanlon
      Sr. Manager
      Federal Reserve Bank of Richmond

      Success Begins With IDEAS!
      Enterprise Application Solutions


    Your message has been successfully submitted and would be delivered to recipients shortly.