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

24972Re: SV: [scrumdevelopment] To SCRUM or not

Expand Messages
  • Peter Hundermark
    Nov 4, 2007
      --- In scrumdevelopment@yahoogroups.com, "Martin Jul - Ative" <mj@...>
      > Banibrata,
      > Even if you don't want to change entirely to Scrum I would at least
      take a few of the practises:
      > First, I would introduce iterative development driven by business
      value - implement the most business-valuable features first, and deliver
      production-ready, running, tested software in small increments, say
      bi-weekly. Since you are on a tight deadline this takes a lot of the
      risk out of the project - or rather, moves the risk to the lowest-value
      features rather than any feature.
      > Also, even if management does not think there will be much change my
      experience is that they get inspired at the demos of working software
      and see all the missing features and the features in the spec that are
      not really needed.
      > Inside an iteration make sure that you are not doing a mini-waterfall
      (see my post Iterative Development Gone Wrong about the Mini-Waterfall
      . Rather, try to teach people to complete the application
      > Using a daily stand-up meeting to talk project and a status indicator
      such as a burndown chart is really useful, too. If you are used to
      estimating in hours you can use this - you don't need to learn user
      stories to get benefit. Just track the total estimated-time-remaining
      for the tasks in the iteration every day and you will have good
      visibility into you status.
      > Also, if you have to deliver frequently you will see all the
      impediments in your organisation - so even if you don't call your
      project manager a Scrum Master, listen to the team and try to help the
      team work around the dysfunctions of the organisation - or change it for
      the better if possible.
      > I realize the above has most of Scrum in it, albeit with other
      wording, so I guess it is kind of a Trojan Horse approach to
      implementing Scrum - or at read it as an advice to get the "frequent
      delivery of valuable business functionality" cycle going and then take
      it from there.


      I find your description appealing, yet for me there are some gaps that
      need filling:

      1. You refer to prioritising feature development by business value. In
      the absence of a formal sprint planning session, how does the team get
      to know what to do?

      2. You refer to delivering production-ready software bi-weekly
      [fortnightly?]. In the absence of a formal review, to whom are these
      shown or delivered and how does the team know that they are, indeed,

      3. You mention the team seeing the impediments in the organisation. In
      the absence of a formal retrospective, when and how does the team expose
      these or examine and improve its process?

      4. You mention listening to the team and trying to help them. Who does
      this? What (Scrum) skills does she need to do this?

      I'm always curious to learn more about managing people's fear of change.

    • Show all 8 messages in this topic