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

RE: [scrumdevelopment] Who is Responsible for Success?

Expand Messages
  • Mary Poppendieck
    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
    Message 1 of 18 , Mar 24, 2005
      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 <marc@...>
      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
    • Steven Gordon
      It is not controversial that every contributor is responsible for a success. What is controversial is the implication that every contributor is to blame if
      Message 2 of 18 , Mar 24, 2005
        It is not controversial that every contributor is responsible for a success. What is controversial is the implication that every contributor is to blame if the result is a failure.

        If the developers raise the right business issues, faithlfully implement the feautres they were given, but these features did not lead to a successful result, are the developers still responsible for the failure? If so, does that mean the developers should ignore the features they are given on the next project and just do what they think will be successful?

        It seems to be that the root cause of each project failure must be determined and addressed. To hold anybody who did everything they could and should have done responsible is to court cowboyism on the next project.
        .

        -----Original Message-----
        From: Mary Poppendieck [mailto:mary@...]
        Sent: Thu 3/24/2005 6:36 AM
        To: scrumdevelopment@yahoogroups.com
        Cc:
        Subject: RE: [scrumdevelopment] Who is Responsible for Success?


        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 <marc@...>
        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
      • Marc Hamann
        ... I ve certainly experienced this first hand. ;-) In my understanding and practice of Scrum, there is harmony between the two things. The success of the
        Message 3 of 18 , Mar 24, 2005
          Mary Poppendieck wrote:
          >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.

          I've certainly experienced this first hand. ;-)

          In my understanding and practice of Scrum, there is harmony between the two
          things. The success of the project can only be measured by the extent to
          which it fulfills its business goals in a cost effective and
          technically-sound way. (When it comes to ASSESSING those attributes, the
          product owner can best assess the success of business goals, the team the
          success of technical goals, but that is merely areas of expertise.)

          My understanding of the distinction that Ken makes is about who decides
          that the business goals are a good idea in the first place.

          If the business people decide that what the company needs is a Widget A to
          compete with a similar product, the team will take responsibility for
          making the best Widget A for the least time and cost expenditure.

          But what if producing Widget A is a TERRIBLE idea? Maybe there is no more
          market for it, or the competitor has a lock on mind-share, or the whole
          idea is a passing fad.

          The team can (and probably should) offer feedback to this effect to the
          business, but when the product owners decide to go that way anyway, well,
          that's their prerogative. They get to set the goals and their priorities.

          Once those priorities and goals are set, the team then has total
          responsibility to realize those goals (business and technical) in that
          priority order.

          Is that still a different scenario from the one you are suggesting?

          Marc
        • Ken Schwaber
          Life is full of complexities and Mary is certainly right about the best ingredients for a successful product. An idifferent team, one that is solely the engine
          Message 4 of 18 , Mar 24, 2005

            Life is full of complexities and Mary is certainly right about the best ingredients for a successful product. An idifferent team, one that is solely the engine that produces product directed by the product owner, is great to use but less than a product team member. A full team of the product owner, scrum master and development team collaborate according to their skills, roles, passion and knowledge, and produce great products. However, there is one person responsible for making decisions about ROI and investment, the product owner, or customer. This person is responsible for getting all of the information and, at the end of eachiteration, deciding what is the best use of the money. Sometimes, despite great efforts, this is a decision to end the investment; other times it is to redirect the investment. I was asked what percent of time a Product Owner should be on the project, and I answered that it should be enough time ---- as a minimum --- that there are never any surprises. This person should be on top of things making sure the money and effort represented by the money is optimally expended,

            Ken

             


            From: Mary Poppendieck [mailto:mary@...]
            Sent: Thursday, March 24, 2005 8:36 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] Who is Responsible for Success?

             

            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 <marc@...>
            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@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




          • Ron Jeffries
            ... Mary ... a question, please. I understand and agree that everyone should share responsibility for everything. But are you going so far as to say that the
            Message 5 of 18 , Mar 24, 2005
              On Thursday, March 24, 2005, at 5:36:18 AM, Mary Poppendieck wrote:

              > 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 ... a question, please.

              I understand and agree that everyone should share responsibility for
              everything. But are you going so far as to say that the business
              people (product managers, or the people contracting with the team
              for the product) have no more of a say in what's chosen to be done
              than do the programmers?

              Thanks,

              Ron Jeffries
              www.XProgramming.com
              Questioner: How do I sell my executive team on doing this stuff?
              Jim Highsmith: Don't. Just do it. They don't know what you're doing anyway.
            • Mary Poppendieck
              Scrum suggests making the entire technical team jointly responsible for the technical success of the product. Why isn t the entire product team jointly
              Message 6 of 18 , Mar 24, 2005

                Scrum suggests making the entire technical team jointly responsible for the technical success of the product.  Why isn’t the entire product team jointly responsible for the success of the product or business process?

                 

                This is not to say that there isn’t a leader responsible for system design and key decisions about the product or process under design. But leaders are only as successful as the team they support, and a good leader works with a team to figure out how the technology can support the business and vice versa. 

                 

                If the team is set up for success, and the company is healthy, there isn’t a blame game to be played. 

                 

                Mary Poppendieck

                Author of:  Lean Software Development

                www.poppendieck.com

                952-934-7998

                 

                From: Steven Gordon [mailto:sagordon@...]
                Sent: Thursday, March 24, 2005 8:01 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] Who is Responsible for Success?

                 

                It is not controversial that every contributor is responsible for a success.  What is controversial is the implication that every contributor is to blame if the result is a failure. 

                 

                If the developers raise the right business issues, faithlfully implement the feautres they were given, but these features did not lead to a successful result, are the developers still responsible for the failure?  If so, does that mean the developers should ignore the features they are given on the next project and just do what they think will be successful?

                 

                It seems to be that the root cause of each project failure must be determined and addressed.  To hold anybody who did everything they could and should have done responsible is to court cowboyism on the next project.

                .

                -----Original Message-----
                From: Mary Poppendieck [mailto:mary@...]
                Sent: Thu 3/24/2005 6:36 AM
                To: scrumdevelopment@yahoogroups.com
                Cc:
                Subject: RE: [scrumdevelopment] Who is Responsible for Success?

                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 <marc@...>
                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

              • Mary Poppendieck
                Well, Ron, let me ask you: Who is responsible for the technical success of a project? The project manager? The architect? Verification? Is it not the
                Message 7 of 18 , Mar 24, 2005

                  Well, Ron, let me ask you:  Who is responsible for the technical success of a project?  The project manager?  The architect?  Verification?  Is it not the entire technical team, and don’t we try mightily not to distinguish between different roles on the technical team?

                   

                  If you imagine that marketing and business people are just as much a part of the team as developers and testers and so on, instead of thinking of them as people ‘contracting for a product’, then perhaps your question might be different. 

                   

                  I think that all really brilliant software is born only when people who deeply understand the technology and people who deeply understand the business need get a ‘mind meld’ in some manner.  Often there is one person who has a deep understanding of both areas in a startup company.  For on-going success, that meeting of the minds has to be replicated somehow.  I’m looking for a team where that meeting of the minds happens because the technical people care deeply about understanding the business and the business people care deeply about understanding the technology.  

                   

                  Cheers!

                   

                  Mary Poppendieck

                  Author of:  Lean Software Development

                  www.poppendieck.com

                  952-934-7998


                  From: Ron Jeffries [mailto:ronjeffries@...]
                  Sent: Thursday, March 24, 2005 8:31 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Who is Responsible for Success?

                   

                  On Thursday, March 24, 2005 , at 5:36:18 AM, Mary Poppendieck wrote:

                  > 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 ... a question, please.

                  I understand and agree that everyone should share responsibility for
                  everything. But are you going so far as to say that the business
                  people (product managers, or the people contracting with the team
                  for the product) have no more of a say in what's chosen to be done
                  than do the programmers?

                  Thanks,

                  Ron Jeffries
                  www.XProgramming.com


                   

                • Mary Poppendieck
                  There are plenty of companies that can t afford the luxury of chasing after terrible ideas, and no one should have a preoperative to do so. If the
                  Message 8 of 18 , Mar 24, 2005

                    There are plenty of companies that can’t afford the luxury of chasing after terrible ideas, and no one should have a ‘preoperative’ to do so. 

                     

                    If the development team members were also owners of the company, they wouldn’t spend their time chasing ideas they knew would fail.  In some companies, teams are set up and chartered to improve the success of the company – for example – by being jointly responsible for the P&L of the product they are developing.  I think this is a rather healthy charter for a product development team.

                     

                    Mary Poppendieck

                    Author of:  Lean Software Development

                    www.poppendieck.com

                    952-934-7998


                    From: Marc Hamann [mailto:marc@...]
                    Sent: Thursday, March 24, 2005 8:02 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] Who is Responsible for Success?

                     

                    Mary Poppendieck wrote:
                    >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.

                    I've certainly experienced this first hand. ;-)

                    In my understanding and practice of Scrum, there is harmony between the two
                    things.  The success of the project can only be measured by the extent to
                    which it fulfills its business goals in a cost effective and
                    technically-sound way. (When it comes to ASSESSING those attributes, the
                    product owner can best assess the success of business goals, the team the
                    success of technical goals, but that is merely areas of expertise.)

                    My understanding of the distinction that Ken makes is about who decides
                    that the business goals are a good idea in the first place.

                    If the business people decide that what the company needs is a Widget A to
                    compete with a similar product, the team will take responsibility for
                    making the best Widget A for the least time and cost expenditure.

                    But what if producing Widget A is a TERRIBLE idea?  Maybe there is no more
                    market for it, or the competitor has a lock on mind-share, or the whole
                    idea is a passing fad.

                    The team can (and probably should) offer feedback to this effect to the
                    business, but when the product owners decide to go that way anyway, well,
                    that's their prerogative.  They get to set the goals and their priorities.

                    Once those priorities and goals are set, the team then has total
                    responsibility to realize those goals (business and technical) in that
                    priority order.

                    Is that still a different scenario from the one you are suggesting?

                    Marc





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


                  • Jeff Sutherland
                    I m revising the draft of my Agile 2005 paper to address the Scrum responsibility issue. Here are my initial thoughts about it. Comments are welcome as it
                    Message 9 of 18 , Mar 24, 2005
                      I'm revising the draft of my Agile 2005 paper to address the Scrum
                      responsibility issue. Here are my initial thoughts about it. Comments
                      are welcome as it needs a lot of refinement.

                      Scrum Evolution: Type A, B, and C Sprints
                      Jeff Sutherland, Ph.D., Certified ScrumMaster Practitioner
                      Patientkeeper, Inc., Brighton, MA, USA

                      Section 3.2 Product Owner as Part of the Scrum Team

                      The original Japanese view of a product development Scrum created a
                      team that was totally responsible for the product [4]. In some
                      companies, such as Individual in 1996, the Product Owner was at every
                      Scrum meeting. In others, like the original Scrums at Easel
                      Corporation in 1993-94, the Product Owner was on the road much of the
                      week and was always at the Friday Scrum meetings [2, 3].

                      The Product Owner owns the business plan for the product, the
                      functional specification for the product, the product backlog for the
                      product, and prioritization of the product backlog. As a member of the
                      Scrum s/he works side by side with the ScrumMaster to introduce
                      product backlog items into a Sprint where they are broken down into
                      tasks by the team for execution as Sprint backlog. In a Type C Scrum,
                      the Product Owner manages the automation of movement of tasks in and
                      out of the Sprint backlog in consultation with the ScrumMaster.

                      The linkage can be very tight between Product Owner and ScrumMaster.
                      For example, at PatientKeeper, the mobile device development team
                      leader is the lead designer and coder on the team, the Scrum Master,
                      and one of three Product Owners in the company reporting to the VP of
                      Marketing and the Director of Engineering in a matrixed fashion. The
                      two other Product Owners are responsible for clinical applications and
                      financial applications on handheld and web devices. For clinical
                      applications, the clinical Product Owner and the mobile device Product
                      Owner are joined at the hip with the ScrumMasters. Together, they are
                      totally responsible for the business plan, the product specification,
                      and working day to day with engineers on product design.

                      After working as head of engineering in nine companies, I have found
                      that the best way to think about Scrum responsibilities is to think of
                      Scrum team as analogous to a high performance car in a rally race. The
                      Product Owner is the navigator and the ScrumMaster is the driver. The
                      team is the engine, the chassis, the drivetrain, and the wheels. The
                      ScrumMaster follows the navigational directions of the Product Owner
                      precisely and drives the car adroitly. The car and its occupants are
                      totally responsible for winning the race. At the end of every Sprint,
                      other players move in and can make modifications to improve the timing
                      of the next Sprint.

                      New ScrumMasters tend to view this analogy as too prescriptive to a
                      team that assigns its own responsibilities and self-organizes.
                      Consider a football team. It self-organizes under the Coach where
                      those best suited to roles, assume positions of quarterback, center,
                      tight ends, and so forth. In the huddle, they may quickly make minor
                      refinements to individual roles and responsibilities. However, when
                      the ball is hiked, there is no discussion of what anyone is supposed
                      to do. To be successful, they must know what they are to do and
                      execute it quickly and professionally.

                      In some companies new to Scrum, engineers have claimed no one is
                      responsible because there is not a "project manager." If you look at
                      project managers in technically driven companies, they are usually at
                      the mercy of the technical team. As a result product management, and
                      therefore product ownership, is weak. This compromises the
                      effectiveness of Scrum and prevents a Scrum team from entering a
                      hyperproductive state [1].

                      In a well run Scrum, particularly a Type B or C Scrum, the ScrumMaster
                      must be able to drive the race car and the Product Owner must be able
                      to direct the ScrumMaster to the right destination in the timing
                      necessary to win market share and attain profitability. Failure at
                      either of these tasks leads to replacement of the appropriate person.
                      Success means one or both go on to greater responsibilities. For those
                      who lead hyperproductive Scrums, career advancement is rapid and they
                      usually wind up as CTOs, CEOs of their own companies, or VPs of
                      Engineering of larger companies within a few years. The ScrumMaster of
                      the IDX Web Team left the Scrum team to lead the U.K. division of IDX
                      and closed over $2B of new business within 3 years of leaving the
                      Scrum. This is a great example of a ScrumMaster who learned how to own
                      the business and the technology side by side with the Product Owner.

                      1. Beedle, M., et al., SCRUM: A Pattern Language for Hyperproductive
                      Software Development, in Pattern Languages of Program Design, N.
                      Harrison, Editor. 1999, Addison-Wesley. p. 637-651.
                      2. Schwaber, K. and M. Beedle, Agile software development with scrum.
                      Series in agile software development. 2002, Upper Saddle River, NJ:
                      Prentice Hall. xvi, 158 p.
                      3. Sutherland, J., Agile Can Scale: Inventing and Reinventing SCRUM in
                      Five Companies. Cutter IT Journal, 2001. 14(12): p. 5-11.
                      4. Takeuchi, H. and I. Nonaka, The New New Product Development Game.
                      Harvard Business Review, 1986(January-February).

                      --- In scrumdevelopment@yahoogroups.com, "Mary Poppendieck"
                      <mary@p...> wrote:
                      > Scrum suggests making the entire technical team jointly responsible
                      for the
                      > technical success of the product. Why isn't the entire product team
                      jointly
                      > responsible for the success of the product or business process?
                      >
                      > This is not to say that there isn't a leader responsible for system
                      design
                      > and key decisions about the product or process under design. But
                      leaders are
                      > only as successful as the team they support, and a good leader works
                      with a
                      > team to figure out how the technology can support the business and vice
                      > versa.
                      >
                      > If the team is set up for success, and the company is healthy, there
                      isn't a
                      > blame game to be played.
                      >
                      > Mary Poppendieck
                    • Ron Jeffries
                      ... Yes, certainly we do. ... It might be, except that they are generally a different kind of outsider, and they often report into another organization -- even
                      Message 10 of 18 , Mar 24, 2005
                        On Thursday, March 24, 2005, at 2:24:48 PM, Mary Poppendieck wrote:

                        > Well, Ron, let me ask you: Who is responsible for the technical success of
                        > a project? The project manager? The architect? Verification? Is it not
                        > the entire technical team, and don't we try mightily not to distinguish
                        > between different roles on the technical team?

                        Yes, certainly we do.

                        > If you imagine that marketing and business people are just as much a part of
                        > the team as developers and testers and so on, instead of thinking of them as
                        > people 'contracting for a product', then perhaps your question might be
                        > different.

                        It might be, except that they are generally a different kind of
                        outsider, and they often report into another organization -- even
                        another company. They may have "final" authority over certain
                        decisions, and to the extent that they have that and exercise it,
                        they remove authority -- and therefore responsibility -- from the
                        other team members.

                        > I think that all really brilliant software is born only when people who
                        > deeply understand the technology and people who deeply understand the
                        > business need get a 'mind meld' in some manner. Often there is one person
                        > who has a deep understanding of both areas in a startup company. For
                        > on-going success, that meeting of the minds has to be replicated somehow.
                        > I'm looking for a team where that meeting of the minds happens because the
                        > technical people care deeply about understanding the business and the
                        > business people care deeply about understanding the technology.

                        I agree with all that, Mary, and if that's "all" you meant, I think
                        we're on the same page. My question was whether you mean in your
                        model that there is not some designated decision maker for the
                        business decisions at whom the buck stops. Is the team a unit with
                        no head, or is there an interface element who is being held
                        responsible by some outside element, who can, and may, make final
                        calls?

                        Ron Jeffries
                        www.XProgramming.com
                        He who will not apply new remedies must expect old evils. -- Francis Bacon
                      • Mary Poppendieck
                        Hi Ron, At 3M we had the idea of a product champion who ultimately owns responsibility for the business success of the product. At Toyota there is the concept
                        Message 11 of 18 , Mar 26, 2005

                          Hi Ron,

                           

                          At 3M we had the idea of a product champion who ultimately owns responsibility for the business success of the product.  At Toyota there is the concept of a chief engineer who has similar responsibility.  In both cases, the champion or chief engineer is a technical expert who is expected to have developed deep customer understanding and communicate that understanding to the development team.  If there are disagreements about how to proceed (and there always will be), the champion or chief engineer would have final decision-making authority.  However, when I was a champion, what I usually did was assign the controversial decision to the most logical person on the team.  (Eg. A decision on whether or not the product was ready for a show was made by the team member from the quality department.  A decision on whether or not the specs were manufacturable was made by the manufacturing representative on the team, etc.)

                           

                          The problem with Scrum is that there is more than one leader.  A product champion plays three roles:  One is business responsibility and relevant decisions around that if they are not obvious to the team.  Two is technical leadership and the relevant decisions around technical issues if there is a disagreement on the team.  And three is making sure that the development process is followed, the typical ScrumMaster role.  

                           

                          In typical product development, there is a product manager who has business responsibility, there is a technical leader  who takes on responsibility for good design, and there is a coach, scrum master, or project manager who is responsible for the process of getting things done.  I am used to all three roles being played by one person.  If they are NOT (and quite often that will be the case) then the two or three leaders must be ‘joined at the hip” so to speak, so they act as a single voice of leadership to the team.  To me this means that they assume responsibility for all three aspects of success – process, design, and business.  If they are in conflict on any one, the team is not working in a healthy environment.  That’s why it’s easier if all three roles reside in one person.

                           

                          In the end, the leader of all three aspects of development (business, technology, and process) would delegate as many of the decisions in their area to a competent team.  Their job is to keep the vision of the ultimate goals before the team at whatever level of detail necessary for the team to make appropriate decisions.  If, however, the market vision, technical vision, or process is being violated, then the leader would have the final say.

                           

                          I think we are in agreement except on one point, Ron.  You say that the business or marketing people are usually in another organization or ‘world’ than the development team, so they are exempt from being ‘part of the team’.  I don’t buy that – it may happen frequently, but it certainly isn’t necessary and is hardly the ideal case.  I would not build a process around that assumption any more than I would build a process around the assumption that the Scrum Master is not the same person as the Product Owner and does not share ultimate responsibility for the economics of software development.  I think all three leaders should jointly share responsibility for process, business, and technical success.  And they should delegate to the team as much of this as they can, even while the retain ultimate responsibility.  

                           

                          Mary Poppendieck

                          Author of:  Lean Software Development

                          www.poppendieck.com

                          952-934-7998


                          From: Ron Jeffries [mailto:ronjeffries@...]
                          Sent: Thursday, March 24, 2005 8:04 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Who is Responsible for Success?

                           

                          My question was whether you mean in your
                          model that there is not some designated decision maker for the
                          business decisions at whom the buck stops. Is the team a unit with
                          no head, or is there an interface element who is being held
                          responsible by some outside element, who can, and may, make final
                          calls?

                          Ron Jeffries
                          www.XProgramming.com
                          He who will not apply new remedies must expect old evils.  -- Francis Bacon




                        • Ron Jeffries
                          ... I guess I d agree that it s not ideal, and it certainly isn t necessary. However, all contract software development, and most IT software development, is
                          Message 12 of 18 , Mar 26, 2005
                            On Saturday, March 26, 2005, at 8:33:25 AM, Mary Poppendieck wrote:

                            > I think we are in agreement except on one point, Ron. You say that the
                            > business or marketing people are usually in another organization or 'world'
                            > than the development team, so they are exempt from being 'part of the team'.
                            > I don't buy that - it may happen frequently, but it certainly isn't
                            > necessary and is hardly the ideal case.

                            I guess I'd agree that it's not ideal, and it certainly isn't
                            necessary. However, all contract software development, and most IT
                            software development, is done today between organizations and
                            between companies. So it's /a/ normal case, though not /the/ normal
                            case, and not the ideal case.

                            > I would not build a process around
                            > that assumption any more than I would build a process around the assumption
                            > that the Scrum Master is not the same person as the Product Owner and does
                            > not share ultimate responsibility for the economics of software development.

                            As far as I know, no process is built around that assumption. It
                            would be wise, I'd think, for a process to /accommodate/ that
                            assumption.

                            > I think all three leaders should jointly share responsibility for process,
                            > business, and technical success. And they should delegate to the team as
                            > much of this as they can, even while the retain ultimate responsibility.

                            Certainly.

                            I understand everything above, except the part where you say we
                            don't agree. :)

                            Ron Jeffries
                            www.XProgramming.com
                            Think! -- Aretha Franklin
                          • Laurent Bossavit
                            ... Neat ! ... Isn t the team itself one part of the larger system ? With a corresponding share of responsibility - and of influence - in these very
                            Message 13 of 18 , Mar 29, 2005
                              Diana:

                              > Recently I read a paper that posited a different description -
                              > "leaderful" teams

                              Neat !

                              > As someone else pointed out, where it comes a cropper is when the
                              > larger system wants to ensure

                              Isn't the team itself one part of "the larger system" ? With a
                              corresponding share of responsibility - and of influence - in these
                              very behaviours ?

                              Cheers,

                              -[Laurent]-
                              Adding manpower to a late project makes it later. -- Fred Brooks
                            • Mary Poppendieck
                              When a sports team fails to perform, the coach gets fired. I believe that failure is almost always a management problem; success belongs to the team. Perhaps
                              Message 14 of 18 , Mar 31, 2005

                                When a sports team fails to perform, the coach gets fired.  

                                 

                                I believe that failure is almost always a management problem; success belongs to the team.  

                                 

                                Perhaps this is why I spend little time worrying about who will be the scapegoat if things go wrong – I already know that most failure is caused by the system under which people operate, and systems are the responsibility of management.  

                                 

                                Mary Poppendieck

                                Author of:  Lean Software Development

                                www.poppendieck.com

                                952-934-7998


                                From: DianaLarsen [mailto:dlarsen@...]
                                Sent: Tuesday, March 29, 2005 11:43 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: Réf. : Re: [scrumdevelopment] Who is Responsible for Success?


                                As someone else pointed out, where it comes a cropper is when the larger system wants to
                                ensure there is someone to blame if things go wrong. Who do we fire? Whose pay do we
                                dock? Who gets pilloried? So that all the rest of us can pretend we had no role to play in
                                what went wrong as we point fingers and melt into the woodwork. As long as our focus is
                                on success (and not the avoidance of failure), sharing the responsibility for that success is
                                easy. If our focus is on the avoidance of failure, we require a scapegoat.

                                Diana

                                Diana Larsen
                                www.futureworksconsulting.com   503-288-3550

                              • todd
                                ... It depends on the relative strengths of the groups. In the NBA the players are highly paid with guaranteed contracts so the coach usually gets fired. In
                                Message 15 of 18 , Mar 31, 2005
                                  Mary Poppendieck wrote:

                                  > When a sports team fails to perform, the coach gets fired.
                                  >
                                  It depends on the relative strengths of the groups. In the NBA the
                                  players are highly paid with guaranteed contracts so the coach usually
                                  gets fired. In the NFL the players do not have guaranteed contracts. A
                                  powerful coach in that situation will last a lot longer. Most of
                                  development is in the later category. Management is usually in the former.

                                  Another variant is the powerful eccentric owner, like Mark Cuban. In
                                  that case the owner will do whatever they want because they have all the
                                  power and money and act pretty much anyway they please.

                                  Extraordinary skill can buffer many a problem. Who would want Barry
                                  Bonds on their team if wasn't so great? Nobody.

                                  > I believe that failure is almost always a management problem; success
                                  > belongs to the team.
                                  >
                                  That's how a good coach acts :-)

                                  > Perhaps this is why I spend little time worrying about who will be the
                                  > scapegoat if things go wrong – I already know that most failure is
                                  > caused by the system under which people operate, and systems are the
                                  > responsibility of management.
                                  >
                                  Very true. Replacing a system is one of the hardest things of all
                                  without a revolution of some sort. There's no place people can grab on
                                  to. Today GM reported some bad earning news and the reason given on NPR
                                  was because the system doesn't work anymore. That's after getting a new
                                  CEO to fix everything.
                                • Jeff Sutherland
                                  I was struck by the comment on GM. My view of the situation at GM is that Toyota is cleaning their clock. Toyota decided 10 years ago that hybrids were the
                                  Message 16 of 18 , Mar 31, 2005
                                    I was struck by the comment on GM. My view of the situation at GM is
                                    that Toyota is cleaning their clock. Toyota decided 10 years ago that
                                    hybrids were the future of Toyota and probably the future of the auto
                                    industry. They used Scrum-like processes to get there.

                                    If you read Takeuchi and Nonaka's new book, you will find about a 100
                                    pages on Toyota.

                                    The GM stock crash is just the opening volley in the transformation of
                                    the auto industry. Scrum paired with disruptive technology is an
                                    unstoppable force.

                                    Jeff Sutherland

                                    --- In scrumdevelopment@yahoogroups.com, todd <todd@p...> wrote:

                                    > Very true. Replacing a system is one of the hardest things of all
                                    > without a revolution of some sort. There's no place people can grab on
                                    > to. Today GM reported some bad earning news and the reason given on NPR
                                    > was because the system doesn't work anymore. That's after getting a new
                                    > CEO to fix everything.
                                  • todd
                                    ... To show you what I know I thought GM was on the right track. They were completely rethinking the car with their new fuel cell cars. Really good fascinating
                                    Message 17 of 18 , Mar 31, 2005
                                      Jeff Sutherland wrote:

                                      >
                                      > I was struck by the comment on GM. My view of the situation at GM is
                                      > that Toyota is cleaning their clock. Toyota decided 10 years ago that
                                      > hybrids were the future of Toyota and probably the future of the auto
                                      > industry. They used Scrum-like processes to get there.
                                      >
                                      To show you what I know I thought GM was on the right track. They were
                                      completely rethinking the car with their new fuel cell cars. Really good
                                      fascinating stuff. And the hybrids are winning in the short term at least.
                                    • Chamberlain, Eric
                                      Hmmm. All that may be true but Toyota is barely breaking even financially on their hybrids. Their biggest advantage there is in the P.R. value. My
                                      Message 18 of 18 , Apr 1, 2005
                                        Hmmm. All that may be true but Toyota is barely breaking even financially on their hybrids. Their biggest advantage there is in the P.R. value. My information is that the real reason is that the Toyota's US plants have a younger workforce which places lighter pension loads on the company than the older US-domestic manufacturers.

                                        I am all for Scrum success stories but the Toyota/GM battle involves other, much larger forces than the use/non-use of Scrum.

                                        == Eric ==

                                        -----Original Message-----
                                        From: Jeff Sutherland [mailto:jeff.sutherland@...]
                                        Sent: Thursday, March 31, 2005 8:34 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: [scrumdevelopment] Re: Who is Responsible for Success?



                                        I was struck by the comment on GM. My view of the situation at GM is that Toyota is cleaning their clock. Toyota decided 10 years ago that hybrids were the future of Toyota and probably the future of the auto industry. They used Scrum-like processes to get there.

                                        If you read Takeuchi and Nonaka's new book, you will find about a 100 pages on Toyota.

                                        The GM stock crash is just the opening volley in the transformation of the auto industry. Scrum paired with disruptive technology is an unstoppable force.

                                        Jeff Sutherland

                                        --- In scrumdevelopment@yahoogroups.com, todd <todd@p...> wrote:

                                        > Very true. Replacing a system is one of the hardest things of all
                                        > without a revolution of some sort. There's no place people can grab on
                                        > to. Today GM reported some bad earning news and the reason given on
                                        > NPR was because the system doesn't work anymore. That's after getting
                                        > a new CEO to fix everything.





                                        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.