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

RE: [scrumdevelopment] Re: Aren't we missing something with all the focus on New Products

Expand Messages
  • Ken Delong
    Here s another reference for you to track down in your research. There s an audio program called Lead the Field by Earl Nightingale
    Message 1 of 4 , Mar 25, 2005
    • 0 Attachment
      Here's another reference for you to track down in your research.
       
      There's an audio program called "Lead the Field" by Earl Nightingale (www.nightingaleconant.com).  He talks about a CEO who was overwhelmed by his growing company and called in a consultant for help.  The consultant said: "Write down everything important you need to do.  Now rank the top six in order of importance.  Tomorrow, work on item #1 until it is finished.  Then move on to #2.  Once a week, re-create the list and reprioritize."
       
      Sound familiar?
       
      Ken
       


      From: Mishkin Berteig [mailto:mishkin-agile@...]
      Sent: Thursday, March 24, 2005 11:48 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Aren't we missing something with all the focus on New Products


      Mike,

      I fully agree.  Before I encountered Agile, I had a lot of
      experience working with volunteer groups in my religious community. 
      At the same time, I was developing my professional career as a
      software "engineer" and then an "architect".  At about the same time
      that I encountered I was also starting to think about how to bring
      my experiences in the volunteer field and professional life together.

      Agile and Scrum are currently strongly associated with software
      development and as you mention, new product development in
      particular.  However, there are some very deep underlying themes and
      practices that apply universally to any time of creative team work,
      and even beyond.  The Agile Software Manifesto is a great starting
      point, but it is too focused on the _software_ part rather than the
      _agile_ part.

      I've recently started working on a paper about this.  It isn't ready
      for public consumption, but some of the foundational ideas that I'm
      working with currently are:

      People are Creators
      Change is Constant
      Perception mediates Reality

      These three principles are based on an even more fundamental
      principle:

      Truthfulness is the foundation of all human virtues. (1)

      I'm not certain, and I would love some feedback on this, but I think
      that these principles are the deep foundation of what it is that we
      are doing in the Agile community.

      I am currently working with two other excellent coaches and we are
      realizing that Lean, Agile, etc. are really just labels for
      something much deeper about human and organizational development and
      change.

      By focusing purely on new product development, the Agile community
      is perhaps neglecting a huge fertile forest because we have found
      one beautiful tree to concentrate on.  For some people, this is
      surely appropriate.  I would love to see people start to look at
      some of the other trees.

      One recent experience I have is that I introduced Scrum to a Media
      Arts class at a college in Canada.  The class was learning about
      video documentary and the instructor (my father) was interested in
      trying to apply Agile practices to the creation of a documentary. 
      Now a few months later, they are nearing completion of the project
      using iterations, a Scrum Master, etc.  The feedback from the class
      has been amazing: the students feel that this method has transformed
      their understanding about doing work.

      My feeling is that we need to move from Agile Software Development
      to something greater.  Maybe we could simply call it Agile Work.

      Mishkin.

      --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@c... wrote:
      > To all:
      > Aren't we missing something with all the focus on New Products? We
      talk about increments, iterations, and Agility at the micro level
      and then seem to be declaring victory at the launch. 
      >
      > Excuse me, but isn't that the beginning of the true collaboration
      between the product owner, the customer and the technical folks?
      >
      > We spend a lot of time talking about measurements, money, business
      objectives and yet there is so little focus on $.85 of every dollar
      spent on a product over its life.
      >
      > Lean Manufacturing is, in my experience, getting it better every
      time we did it, not just in the pilot or the initial manufacturing
      run. 
      >
      > If I bring anything from 15 years in line manufacturing to the
      world of software it is a deep and abidding respect for the
      expertise people who do the job day after day, either making the
      product better or using the product to get the job done.
      >
      > Where are we taking advantage of this wealth of experience and
      knowledge?  In the next product, the next release or the next time
      we do our job?
      >
      > If you are asking "Can Scrum, Xp, Agile, do anything with this
      knowledge?" The answer is unequicably YES, but we as a community and
      a profession just seem to not have it on the radar screen.
      >
      > Why is it important?  I know that some of us have been trying to
      get the word out, but if you are not listening then it is not being
      heard.  First, empircal evidence shows that 'average IT application
      programmers' can make Scrum scream.  This alone confirms that Agile
      in general and Scrum in particular, is not limited to small, elite,
      teams of software developers, but that it is a force multiplier for
      any disciplined, competent, professional.  Even more important is
      the fact that code cowboys and software hacks fail miserably when
      they pose as Agilists. 
      >
      > Second it substaniates the fact that Scrum and Agile are  more
      than we can explain.  Various efforts, mine included are showing
      them to be meta-methods and meta-processes as they can work within
      entrenched processes and serve to measurably transform the bowels of
      an organization from a mushroom factory to a hyperproductive,
      customer focused, center that is measurably better than the previous
      way work was done.
      >
      > I rant, frustrated that the facts as they appear in my work, are
      so hard to communicate.
      > --
      > Mike Dwyer
      >
      > "I Keep six faithful serving-men
      > Who serve me well and true:
      > Their names are What and Where and When
      > And How and Why and Who." - Kipling
      >
      > -------------- Original message --------------
      >
      > >
      > > I just heard a presentation about a team at Intuit that recently
      developed a
      > > successful new product. Because team members had previously done
      version
      > > releases of the same product year after year, the idea was to
      change the
      > > mindset so the team adopted the entrepreneurial mindset needed
      for version
      > > one of a new product.
      > >
      > > At product gates, the product team had to answer the important
      questions the
      > > management team had at that gate. In between gates, the product
      team both
      > > designed its own process and its own product. The entire product
      team was
      > > involved in customer visits and everyone was chartered with
      understanding
      > > customer needs. The product team consisted of all functions
      necessary to
      > > bring a new product to market. It was led by a person I will
      call the
      > > product champion, who was (and remains) responsible for the end-
      to-end
      > > product success, from a technical, business and process
      perspective.
      > >
      > > This is the way I developed new products, and I don't quite
      understand why
      > > the responsibility for success needs to be divided between
      technical and
      > > business areas. Either the entire product (or business process)
      is a
      > > success or it isn't, and everyone gets hurt if it isn't, no
      matter how much
      > > one might try to protect the technical team. Better the team is
      organized
      > > and led for overall success than dividing this into two separate
      roles and
      > > pretending that it's okay to have technical success but not
      business
      > > success.
      > >
      > > Mary Poppendieck
      > > Author of: Lean Software Development
      > > www.poppendieck.com
      > > 952-934-7998
      > >
      > > Date: Wed, 23 Mar 2005 11:06:28 -0500
      > > From: Marc Hamann
      > > Subject: Re: The project manager's Declaration of
      Interdependence
      > >
      > > Does this mean that the team determines what the strategic
      business
      > > value(s) should be, and what priority different goals should
      have?
      > >
      > > Marc
      > >
      > >
      > >
      > >
      > >
      > > To Post a message, send it to: scrumdevelopment@e...
      > > To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@e...
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      > >





      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



    Your message has been successfully submitted and would be delivered to recipients shortly.