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

meta solution ???

Expand Messages
  • mike.dwyer1@comcast.net
    I am not sure I agree with you on this Ken. Not that the Dogmatic alligence needs to stop but that Scrum, being organic in nature, can be kept in place. Not
    Message 1 of 6 , Mar 30, 2006
    • 0 Attachment
      I am not sure I agree with you on this Ken.  Not that the Dogmatic alligence needs to stop but that Scrum, being organic in nature, can be kept in place.  Not that I think you are saying that.  But I can't necessarily see that the advanced and the levels of scrum are moving to a methodology.  Quite the contrary  Scrum devolves over time.
       
      What do I mean.  Scrum, as taught in the class, enters into the rhythm of an organization, not just the team.  People become used to and expect to have information on the questions 3, as trust builds information is shared over blurred lines of chickens pigs, horses, (even us asses) but the need to improve also enters the organizations genetic code.
       
      The questions 3 do not meet the bill.  Two of the questions, what are we doing and where we are going fade in importance as people 'believe what they hear'  Now they want to get to the meet of the issue,  What is impeding progress.  How long before DONE is reached?
       
      Work gets faster, makes things happen more, and sooner, and transparency makes it all more revealing.  Big deal from those mistakes comes insights and innovation.  Things move faster again.    Traditional management cannot keep up, traditonal project management is pushed into administrative ditritrium.  Managers become fully engaged, scrummasters measure success by how well they support the people to get things done.  Groups 'tune' the frame to best fit into their culture.
       
      So where in all this is the method,  Traditionalists and dogmatists see it as madness.  This to me is organic organization to get to DONE.
       
      OK now let's fly this crate,  You can't do it with piper cub instruements, nor the navigation tools from the 20th century. 
       
      What does that look like.   First we know that truth and facts have a half life and that you can only go as far and as fast as your numbers keep you from crashing. Finally the numbers mean squat unless they better define DONE.  Since you don't control DONE you don't steer at all.  Business does.  Now they are going to come and ask how to get this and that DONE and all you need to ask them is when and what do they want to drop, or how many more resources you need to make it happen.
       
      This is where A B C and N come into play.  Getting the resources (time in particular) is a global problem.  When your window of opportunity is measured in days, you need people on the job 1/60/60/24/365.  Nervous yet?  I am.  can't wait to need to change my pants.  Can the Scrum we learned from you, as is, fly this?  Does it really matter what we think?  The people dong the job have tweaked it so it fits them better, and they are going to try.  My job is to keep the airframe up to spec.
       
      For those looking for a safe place to be, scrum may not be it because scrum atrophys when it stops getting better leaving it weak.  Then the rules maker and the dogmatist show up to certifiy you are good, when you can no longer measure how much better your product owner is from the last time.
       
       
       
       
       
      --
      Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


      The greatest oak was once a little nut who held its ground. ~Author Unknown
       
      -------------- Original message --------------
      From: "Ken Schwaber" <ken.schwaber@...>

      Tobias, et al

       

      Scrum does have principles, values, ways in which it operates best and worst, and paths in which it has been misunderstood. Over the sixteen years that I�ve worked with others to formulate Scrum and make it visible, I�ve got some pretty good insights into what works and what doesn�t, where Scrum is well understood and where it is poorly understood. I�ve also had some detailed conversations with people who�ve seen CMMI and RUP turn into what they are, despite the best of intentions.

      I do feel responsible for everyone in this group and everyone to whom I�ve taught Scrum. I feel responsible for their understanding of what I�ve taught them and how their understanding has evolved.

       

      When I see that Scrum is heading down paths that are contrary to what I vision its purpose to be, and when I see it heading in directions where other ideas have failed, I do comment and provide guidance. Since I taught so many of you, your response is probably of student to teacher. I�m not sure that I see anything wrong with that. There are a number of healthy developments in team dynamics, planning, product ownership, estimating, and enterprise Scrum usage that I am not the primary influence on that are a pleasure to see grow from the seeds of Scrum. It is my pleasure to watch them grow.

       

      Yes, there were great conversations regarding A/B/C and Advanced. Mostly, they were going toward megaScrum, the methodology. It might have been self-correcting, but it hasn�t self-corrected across eight months. It has only gotten worse. And a course was coming up that would cement the misunderstanding. I felt that my intervention was, if anything, tardy.

       

      The tendency that was occurring in the conversations was too much thought, too much problem solving, too much �meta solution.� This is the nature of our profession since it is how we turn problems into repeatable software. It is also the antithesis of Scrum, since there is no �meta solution,� only hard work as each new situation arises. This is the nature of complexity, this is the nature of Scrum. This is why Scrum needs to remain simple, so that every user of it can wrestle with the specific problem at hand and derive the best in situ solution. Codifying or creating advanced Scrums only stifles this.

       

      Please do remember that when I comment, you all project something onto me that comes from your own backgrounds. Ponder that and you will be better prepared next time.

       

      Ken

       


      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Tobias Mayer
      Sent: Thursday, March 30, 2006 3:14 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Scrum Ownership

       

      When Ken Schwaber posted "Scrum and NonScrum" on Tuesday - http://groups.yahoo.com/group/scrumdevelopment/message/12506 - many of us breathed a sigh of relief, and posted responses accordingly.  It seemed fitting that Ken should step in and provide clarity to all the confusion.  But then I got to thinking...

       

      Does Ken own Scrum?  Are we allowing Ken to own Scrum - are we encouraging Ken to own Scrum?  Why did it matter so much what Ken thought about the whole A/B/C thing?  Why were we (some/many of us) almost waiting for Ken's verdict on this?  I have to wonder, for myself, did I want Ken's endorsement on my own point of view, my own position on Scrum?  Sad answer is yes, yes I did.

       

      But today's exchange on the Rally "Advanced Scrum" course left a really bad taste.  It was essentially a public telling off from the father of Scrum to a wayward child.  This is not healthy.  This is the kind of paternalistic approach that we as "agents of agile change" are hoping to overcome within organizations.  Yet we encourage it here.  Something is wrong with that.

       

      The original discussions around Scrum Types, whether an advanced course was useful/appropriate, etc. were healthy discussions.  Different points of view were aired.  The theme was explored, people got passionate, but never offensive, and much was learned.  To me that felt good. It represented self-organization at it's best.

       

      Ken, you started this group, and you have as much right as any of us to post messages.  And I, for one, am very glad that you are so actively involved.  But Scrum cannot be owned - by you or anyone.  Comments like

       

      > For a while, I thought that I could just "let" Scrum emerge, but I've already seen a number of deleterious trends that will leave it as nothing but another overcomplicated process...

       

      do not promote the self-organization principle.  Nor does denouncing a training course, that a lot of people are interested in, as "not Scrum":

       

      > All participants of the course should be aware that this is not a Scrum course, but a deviant of Scrum course that probably should be using a completely different name. Sigh, I guess it is time to get the name Scrum formally registered as a trademark.

       

      I have an enormous amount of respect for you, and for all that you have done, and continue to do for this community.   But now please practice the Scrum principles within this group.  You cannot be the arbiter of all things Scrum.  It is an impossible position to uphold, and I don't believe you want it anyway. 

       

      I honestly believe the whole issue of Scrum/NotScrum would have found its own solution, according to the needs of this community.  It is not for any one of us to decide on behalf of the Scrum community that one idea is right and another wrong.

       

      Future issues of this type should be allowed a healthy airing, resulting in consensus reached by the community; this may take time, and that's okay.  I hope you contribute, and I equally hope that others in this group (self included) take your comments as just one more voice. I think we do you a disservice by raising you up to Godfather status. 

       

      Let Scrum be what it will be.  The foundation is rock solid.  I vote that we trust to that.

       

      Tobias

       

       

      ---

      note: this was a resend.  The first posting vanished in the ether, if it later appears deal with it accordingly.

       

       


    • Ron Jeffries
      ... You use this phrase sometimes, and I assume (and hope) it s advisedly. The Agile methods are, in my opinion, DEvolving. People are tarting them up and
      Message 2 of 6 , Mar 30, 2006
      • 0 Attachment
        On Thursday, March 30, 2006, at 7:15:01 PM, mike.dwyer1@... wrote:

        > Quite the contrary Scrum devolves over time.

        You use this phrase sometimes, and I assume (and hope) it's
        advisedly.

        The Agile methods are, in my opinion, DEvolving. People are tarting
        them up and watering them down, all with good will I have no doubt.

        To me, there is an /essential/ simplicity to the ideas behind Agile,
        Scrum, XP. Those ideas can be applied in large and complex
        situations, as Jeff and you, and Jim Highsmith and Glen Alleman, and
        others are showing. Those are good contributions.

        However, the elaboration and the watering down, though they make the
        ideas palatable where they'd be rejected, or practical where they'd
        not be robust enough, are, in my opinion literally damaging to the
        essential notion of simplicity.

        I make a decent living visiting software teams all around, who are
        trying to do Scrum or XP or Agile of some flavor or other.
        Invariably, and I mean that literally, they are not doing things as
        simply or directly as the methods, as I understand them, truly call
        for.

        I do mean invariably. I'd wager my fee double or nothing that I can
        walk into any project in the universe and find something that if
        they did it more simply, more in line with the simple dictates of
        Scrum or XP, they would do better.

        I love the richness of Agile. I think about it all the time, try to
        figure out how it works, how to make it work, how to express it so
        that people can understand it, how to fit it to the situations I
        encounter. I've found, over recent years, that I have "softened" my
        story. That makes it easier to sell the ideas, which gets Agile out
        there and helps people who would otherwise not be helped.

        But I think it's not entirely consistent with the ideas -- with the
        thing that I perceive as the "real" agile.

        So if it has to be Ken and me against the world ... I'm glad to have
        him back on line. Besides, he makes me look reasonable. ;->

        Ron Jeffries
        www.XProgramming.com
        If it is more than you need, it is waste. -- Andy Seidl
      • Hubert Smits
        Ron, One of the main techniques to keep Scrum/XP/Agile simple is inspecting and adapting. In order to have this principle add to the simplicity of an agile
        Message 3 of 6 , Mar 31, 2006
        • 0 Attachment
          Ron,

          One of the main techniques to keep Scrum/XP/Agile simple is inspecting
          and adapting. In order to have this principle add to the simplicity of
          an agile method it needs focus on (amongst others) removing waste: do
          not do/produce things that don't add value.

          What is your opionion on these principles (removing waste (muda)): do
          they require attention and space & time to think about how waste moved
          into our processes, unwanted and unseen? Cause that is what our course
          is about, removing waste through study of flow and load.

          --Hubert

          On 3/31/06, Ron Jeffries <ronjeffries@...> wrote:
          > On Thursday, March 30, 2006, at 7:15:01 PM, mike.dwyer1@... wrote:
          >
          > > Quite the contrary Scrum devolves over time.
          >
          > You use this phrase sometimes, and I assume (and hope) it's
          > advisedly.
          >
          > The Agile methods are, in my opinion, DEvolving. People are tarting
          > them up and watering them down, all with good will I have no doubt.
          >
          > To me, there is an /essential/ simplicity to the ideas behind Agile,
          > Scrum, XP. Those ideas can be applied in large and complex
          > situations, as Jeff and you, and Jim Highsmith and Glen Alleman, and
          > others are showing. Those are good contributions.
          >
          > However, the elaboration and the watering down, though they make the
          > ideas palatable where they'd be rejected, or practical where they'd
          > not be robust enough, are, in my opinion literally damaging to the
          > essential notion of simplicity.
          >
          > I make a decent living visiting software teams all around, who are
          > trying to do Scrum or XP or Agile of some flavor or other.
          > Invariably, and I mean that literally, they are not doing things as
          > simply or directly as the methods, as I understand them, truly call
          > for.
          >
          > I do mean invariably. I'd wager my fee double or nothing that I can
          > walk into any project in the universe and find something that if
          > they did it more simply, more in line with the simple dictates of
          > Scrum or XP, they would do better.
          >
          > I love the richness of Agile. I think about it all the time, try to
          > figure out how it works, how to make it work, how to express it so
          > that people can understand it, how to fit it to the situations I
          > encounter. I've found, over recent years, that I have "softened" my
          > story. That makes it easier to sell the ideas, which gets Agile out
          > there and helps people who would otherwise not be helped.
          >
          > But I think it's not entirely consistent with the ideas -- with the
          > thing that I perceive as the "real" agile.
          >
          > So if it has to be Ken and me against the world ... I'm glad to have
          > him back on line. Besides, he makes me look reasonable. ;->
          >
          > Ron Jeffries
          > www.XProgramming.com
          > If it is more than you need, it is waste. -- Andy Seidl
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >


          --

          All opinions in this message are my own, and are not necessarily
          shared by my employer.
        • Deb
          ... That first quoted line caught my eye again today. I think I agree with your idea, Mike. But I think that it s not Scrum that devolves, but team process.
          Message 4 of 6 , Mar 31, 2006
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
            > ... Scrum devolves over time.
            >
            > What do I mean. Scrum, as taught in the class, enters into the
            > rhythm of an organization, not just the team. People become used
            > to and expect to have information on the questions 3, as trust
            > builds information is shared over blurred lines of chickens pigs..

            That first quoted line caught my eye again today. I think I agree with
            your idea, Mike. But I think that it's not Scrum that devolves, but
            team process. Let me explain. It's semantic, so change the channel now
            if you hate that stuff.

            I'm not sure that what we implement is Scrum. (GASP!!!) I've told
            clients that Scrum is what's in the book, it's abstract. (As such,
            it's pretty stable). I tell them that as soon as we implement it we
            are doing "Scrum at ABC Corp." and that each implementation is
            slightly different. (Yes, even though I *urge* them to keep to the
            classic pattern at the beginning).

            I think that Scrum is what we teach. It's the destination we aim at
            when we get on our bicycle and start making course corrections - it's
            a reference point, tells us where we are straying, if we care to look.
            It is very useful that way, especially in its relatively "simple"
            original form.

            But Scrum Implemented, like everything to do with human nature, is
            rife with trade-offs. Hopefully, only small ones, or at least
            temporary ones.

            :-) deb
          • Ron Jeffries
            ... Yes ... ... Yes, of course, removing waste is good. In addition, I think use of the Japanese terms, muda, mura, and mudi is pretentious and whatever the
            Message 5 of 6 , Mar 31, 2006
            • 0 Attachment
              On Friday, March 31, 2006, at 3:49:03 PM, Hubert Smits wrote:

              > One of the main techniques to keep Scrum/XP/Agile simple is inspecting
              > and adapting. In order to have this principle add to the simplicity of
              > an agile method it needs focus on (amongst others) removing waste: do
              > not do/produce things that don't add value.

              Yes ...

              > What is your opionion on these principles (removing waste (muda)): do
              > they require attention and space & time to think about how waste moved
              > into our processes, unwanted and unseen?

              Yes, of course, removing waste is good. In addition, I think use of
              the Japanese terms, muda, mura, and mudi is pretentious and whatever
              the opposite of mnemonic is.

              Yes, of course, the principles do require attention.

              > Cause that is what our course is about, removing waste through
              > study of flow and load.

              That's likely a good thing for a course to be about. I'd like all
              such courses to have names like "Simplifying Scrum" or "Reluctantly
              Adding Practices to Scrum in Unique Circumstances Which Probably
              Don't Apply to You", rather than names like "Advanced Scrum", or for
              that matter "<anyAdjective/> Scrum". Course names of the latter kind
              suggest that there are "kinds" or "types" of Scrum. I believe that
              to be harmful.

              Ron Jeffries
              www.XProgramming.com
              Comments lie. Code doesn't.
            • Mike Dwyer
              Ron has made me think hard about the term devolve. While it does reflect the notion of the master turning over the work to the minions. It does not capture
              Message 6 of 6 , Apr 1, 2006
              • 0 Attachment
                Ron has made me think hard about the term devolve. While it does reflect
                the notion of the "master" turning over the work to the minions. It does
                not capture the change that happens.

                I would like to use the word MELD but it is not the combining, it is more a
                genetic change.

                Mumble mumble mumble

                Any ideas anyone?

                Michael F. Dwyer

                "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 Deb
                Sent: Friday, March 31, 2006 4:13 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Re: meta solution ???

                --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
                > ... Scrum devolves over time.
                >
                > What do I mean. Scrum, as taught in the class, enters into the
                > rhythm of an organization, not just the team. People become used
                > to and expect to have information on the questions 3, as trust
                > builds information is shared over blurred lines of chickens pigs..

                That first quoted line caught my eye again today. I think I agree with
                your idea, Mike. But I think that it's not Scrum that devolves, but
                team process. Let me explain. It's semantic, so change the channel now
                if you hate that stuff.

                I'm not sure that what we implement is Scrum. (GASP!!!) I've told
                clients that Scrum is what's in the book, it's abstract. (As such,
                it's pretty stable). I tell them that as soon as we implement it we
                are doing "Scrum at ABC Corp." and that each implementation is
                slightly different. (Yes, even though I *urge* them to keep to the
                classic pattern at the beginning).

                I think that Scrum is what we teach. It's the destination we aim at
                when we get on our bicycle and start making course corrections - it's
                a reference point, tells us where we are straying, if we care to look.
                It is very useful that way, especially in its relatively "simple"
                original form.

                But Scrum Implemented, like everything to do with human nature, is
                rife with trade-offs. Hopefully, only small ones, or at least
                temporary ones.

                :-) deb





                To Post a message, send it to: scrumdevelopment@...
                To Unsubscribe, send a blank message to:
                scrumdevelopment-unsubscribe@...
                Yahoo! Groups Links
              Your message has been successfully submitted and would be delivered to recipients shortly.