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

29017Re: Scrum / Agile Guidelines and Checklist

Expand Messages
  • Tobias Mayer
    May 1, 2008
      A little off-track perhaps, but this thread reminds me of an organization that I worked with about eighteen months ago.  The team members there created a charter for themselves, to indicate their sense of responsibility to the organization and the Scrum process.  This is it:

      Framework: We commit to following Agile principles to the best of our ability using the whole Scrum framework.
      Quality: We commit to building quality into our products at every stage of their development and to continuously review and improve our techniques for achieving this.
      People: We are professionals and have a responsibility to respect each other, act honestly, communicate openly and assist/seek assistance where appropriate.
      Process: We commit to working with the organization to define a minimal process to guide our activities over the duration of each sprint, empowering teams to get the job done.
      Growth: As individuals, we commit to enhancing and furthering our knowledge and to share that knowledge, as appropriate, with others at [this_company].

      I like the simplicity of this, and the fact it was generated by three teams, collaboratively. I also like that it is non-prescriptive and focuses on values rather than detailed tasks and activities.  The blog post I wrote about how this charter emerged is here:  Spiderman Says...

      A document like this is certainly a starting point for conversation.  I am not sure that the document Michael Wollin proposed will have that effect, mainly because I am not convinced people will even read it. 


      --- In scrumdevelopment@yahoogroups.com, Ilja Preuss <it@...> wrote:
      > banshee858 wrote:
      > >> I agree, when the document states what the team members expect from
      > >> each other, and when all the team members agree that it is the right
      > >> thing to do, and agree on the content of the document. That is, when
      > >> the document is the *result* of a conversation between all the
      > >> affected people.
      > >>
      > >> That's not what I understood Michael's situation to be. It sounded to
      > >> me as if the document codified what the team expected from "outside"
      > >> members, and as if those possibly even hadn't been asked whether they
      > >> wanted such a documented, and as if the document came *before* the
      > >> conversation with all those affected. To the amount that this
      > >> impression is correct, it would trouble me.
      > >>
      > > We don't know that.
      > Correct. That's what I tried to express.
      > > This could be the first draft or a starting point
      > > for the discussion.
      > In my experience, a document is seldom a good starting point for a
      > discussion. And if it is supposed to be, it doesn't make much sense to
      > get it *right*, anyway - in that case, we are simply the wrong people to
      > get input from.
      > > A lot of people do not understand what Scrum is
      > > or how it works day-to-day, describing that makes things clear.
      > And one of the base tenets of Agile - and therefore I guess also Scrum -
      > is that face-to-face conversation is ways more effective than written
      > communication. If we believe that to be true, we probably should act
      > that way, too, shouldn't we?
      > > FWIW, it is a little detailed for my taste and could be boiled down to
      > > a few key principles that remind us of the details. Much like a user
      > > story reminds us of the details of the requirements.
      > I like that analogy! :)
      > Cheers, Ilja
    • Show all 20 messages in this topic