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

9455RE: [scrumdevelopment] Re: Following the rules

Expand Messages
  • Mike Dwyer
    Oct 1, 2005
      Interesting. Help me understand how these phrases structure your approach.

      Individuals and interactions over processes and tools
      Working software over comprehensive documentation
      Customer collaboration over contract negotiation
      Responding to change over following a plan

      I really need to see this as I am now walking away with is the notion your
      presentation of Scrum is an

      'us - them game' - not interactions between individuals

      Our way or the highway. we don't collaborate with the customer and they are
      not part of the team; we make the rules and they better follow it.

      We have a plan and we will work it. throw away any life experience we or the
      Product Owner have and dogmatically follow a set of rules.

      Just to make it very clear Scrum and other Agile methods are vehicles that
      carry the Agile Manifesto. As a 'formal' method, this approach had been in
      the public for a very few years. You are all, in the long run, a member of
      the pathfinder team in this effort. No two implementations of Scrum are the
      same, there will never be as long as we transport the Agile Philosophy.

      Yes Jeff is doing incredible things, but when you meet him next ask him who
      changed Scrum the teams involved or he and Ken.

      If what you are saying is you need a starting point, then yes you do. Scrum
      methods may be the jumping off point but keep in mind the reason Scrum fails
      or succeeds is not so much following the rules but understanding how to set
      up the Agile and Scrum boundaries where you are doing it.

      For example if you are an employee, then the key starting point is the agile
      principles and the Nike slogan "Just Do It" Smile, agree, and deliver.
      Keep in mind Scrum and Agile are only about Delivery of good stuff to the
      product owner. Let them carry the word forward, help them to know where to
      say it. Commit to their organization that you will work with them to get
      this done. In effect let them fight the battle of Scrum acceptance, not
      you. They got the clout, while you have the baggage of decades of their
      disappointment in IT and software development.

      First do NOT make Promises, they are weak ways of saying I'll try. Who
      cares, no try - Only Do or Don't Do - there is no try.
      Make commitments, follow through on them and do it transparently (in public
      to a broad audience). If you commit not to work on stuff that has not gone
      through the planning and the negotiations, then keep you commitment and
      publically state you cannot break your commitment and do this one little
      thing without the planning, negotiations and agreement. Use the Corporate
      ethics stuff hanging around to tie what you are doing to what the company
      has stated is its value statement. Use the traditionalists love of
      bureaucracy to tie up implusive behavior, but in all cases deliver, deliver,
      deliver!

      Commit to collaborating with the Product Owner, if you are defining, scoping
      what have you at the high end, Keep in mind that the Product Owner is the
      only person that can make those kind of decisions, all you can do is state
      how much you can implement.

      Work to priorities, Since the only way to measure priority is through
      commitment, if the Product Owner doesn't show up to define what they want or
      answer questions, stop, report it as an impediment and when it fails at the
      end of a Sprint, take it into the retro and question if this effort is
      really that important, since no shows to get the job done. make that
      transparent well.

      Keep in mind collaboration and teamwork do not require friendship only
      respect and discipline. But first you have to have those things in your
      self.

      If this sounds too hard, it is not, it is very difficult and does require
      certain amounts of courage and stupidity that does not allow you to quit.

      Michael F. Dwyer CSM, P

      "Planning constantly peers into the future for indications as to where a
      solution may emerge."
      "A Plan is a complex situation, adapting to an emerging solution."

      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com
      [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Victor Szalvay
      Sent: Friday, September 30, 2005 4:20 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Following the rules

      Dave,

      Well put, you've captured the essence of my message better than I.
      Keith's team is new to Scrum; I would not advocate deviations from
      the original "rules" until the team, PO, and management understand the
      principles well enough know how the rules can be bent and what needs
      to remain constant so as not to break the underlining principles.
      Advanced teams are a different story completely, as evidenced by the
      incredible things Jeff Sutherland's company is doing (among others).

      -- Victor Szalvay

      >
      > [DAB] I'll take the pot up to $0.04... Scrum is like any other skill or
      > technique that you learn. At the beginning (by definition) you lack the
      > experience to anticipate the impact of some of the things you do. To
      > mitigate that, you rely on the written material and experience of
      others to
      > guide you until you have a chance to observe the process in action for a
      > while. This is what we are calling, "Following the rules", and its
      value
      > is that improves your chances of success while you build your skills
      with
      > the techniques. Scrum is deceptively simple, and this makes it look
      easier
      > to tinker with than it really is. Every organization that adopts
      Scrum is
      > going to have its own unique quirks and ways to make Scrum work
      better and
      > it will probably take time to find out what those are. In the meantime,
      > what's wrong with saying to everyone, "We're still learning this, so
      we're
      > going to stick pretty close to the "rules" for first few months"?
      >
      > You listen and understand where all of your team is coming from and work
      > with them to get to where you want to go.
      > Mike Dwyer, CSM, P.
      >
      >
      > -- Victor Szalvay
      > Danube Technologies, Inc.
      > http://www.danube.com/
      >
      >
      > Dave Barrett,
      > Lawyers' Professional Indemnity Company





      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Show all 34 messages in this topic