29017Re: Scrum / Agile Guidelines and Checklist
- May 1, 2008A 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 email@example.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
- << Previous post in topic Next post in topic >>