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

Adjusting Scrum for Maintenance Teams, and Multi-Customer Products

Expand Messages
  • Kurt Häusler
    Hi, we just had an interesting release retrospective, most people feel that Scrum works well for us, albeit in a modified form. (Estimating in hours rather
    Message 1 of 63 , Jul 8, 2009
    • 0 Attachment
      Hi,
      we just had an interesting release retrospective, most people feel that
      Scrum works well for us, albeit in a modified form. (Estimating in hours
      rather than story points, specialist developer only teams rather than cross functional teams,
      bug fixes must count towards velocity as that is the majority of our work,
      user stories are more like technical descriptions of what needs to be done,
      rather than the user-centered "as a, i want, so that" format.)

      However people have noticed some issues, relating to basically all aspects
      of our development process, such as flexibility, role of the PO (as our
      support consultants and project managers have the customer contact), less
      communication within the department now that we are split up into small
      teams etc, lots of little things.

      We are happy overall, but have a feeling that it may not fit quite right.

      A lot of what I read suggests Scrum evolved in an environment of project
      based, single customer, internal development of new projects, rather than
      the Product based, multiple customer, maintenance work that we are involved
      in.

      We will be evaluating things next week, and I wondered if anyone had any
      pointers to adjustments to the standard scrum that could make it more ideal
      for teams like ours.

      Thanks a lot
      Kurt
    • Petri Heiramo
      Interesting comments, Victor, ... Good reasoning is also dependent on culture and background. For some, the _logical_ ( I mean, it s not reasonable to expect
      Message 63 of 63 , Jul 14, 2009
      • 0 Attachment
        Interesting comments, Victor,

        > I would like to add here that common sense is very different from using a
        > good reasoning.
        > Common sense depends a lot more on culture than reasoning and good
        > thinking.

        Good reasoning is also dependent on culture and background. For some, the _logical_ ("I mean, it's not reasonable to expect me to give you a quote on what it will cost if you can't be more specific than that!") way to buy software is waterfall...

        Anyway, you're right in that "common sense" is defined by each person, and it's usually used to demean something "stupid" someone else does. :)

        > In many aspects I think, today, common sense is actually the enemy of an
        > empirical control method.

        There may be conditioning in the picture, too.


        Petri

        ---
        Petri Heiramo
        Process Development Manager, Agile Coach (CST)
        Digia Plc., Finland
      Your message has been successfully submitted and would be delivered to recipients shortly.