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

Re: [scrumdevelopment] There is no such thing as Technical Success

Expand Messages
  • Ron Jeffries
    ... Certainly if the product fails, it s a lot less fun for everyone. And I fully agree that it s far better if everyone is invested in overall success. At the
    Message 1 of 6 , Jul 3, 2005
    • 0 Attachment
      On Sunday, July 3, 2005, at 2:56:16 PM, Mary Poppendieck wrote:

      > At XP2005 in Sheffield, UK, Kent Beck gave a talk about "KIcking
      > it up another Notch." He began by telling us a story about a talk
      > he gave to a gathering of business executives. At one point, he
      > used the term "Technical Success", whereupon the audience made it
      > clear to him in no uncertain terms that "There Is No Such Thing As
      > A Technical Success." There is Success and there is Failure. If
      > the product fails, it makes no difference how good the technology
      > or technical team happens to be.

      > This reminded me of a conversation on this discussion group a
      > couple of weeks ago on Agile Project Managers; there was some
      > discussion about the breadth of responsibility of various people.
      > Far as I can tell, it is no fun working on something which
      > eventually fails, no matter whose fault the failure might be. Thus
      > I agree with Kent: kicking it up another notch means we assume
      > responsibility for what we can influence, not just for what we can
      > control. Thus everyone should be invested in the overall success
      > of the product or business process for which the software is being
      > developed.

      Certainly if the product fails, it's a lot less fun for everyone.
      And I fully agree that it's far better if everyone is invested in
      overall success.

      At the same time, let's recognize that there are lots of people and
      lots of organizations out there, where the input of the technical
      people on what's a good product idea is just as unwelcome as the
      input of the product people on what's a good technical idea.

      I deplore it when it happens, but I can understand why a technical
      person, say, would feel the need to find his joy in the exercise of
      his art, because he can't feel the influence he has, if any, on the
      overall product success.

      And, frankly, I can understand why someone might choose just to live
      in his art. He's good at it, he enjoys building software or
      computers or radios or whatever it is. That's OK.

      There's that story about the three stonemasons. Here's a version I
      found on the Web:

      > Several years ago a friend shared with me a story of a sojourner
      > who came upon three individuals working with stone. Curious as to
      > what the workers were doing with the stones, the traveler
      > approached the first worker and asked, "What are you doing with
      > these stones?"

      > Without hesitation the worker quickly responds, "I am a stone
      > cutter and I am cutting stones." Not satisfied with this answer,
      > the traveler approached the second worker and asked, "What are you
      > doing with these stones?" The second worker paused for a moment
      > and then explained, "I am a stone cutter and I am trying to make
      > enough money to support my family."

      > Having two different answers to the same question, the sojourner
      > made his way to the third worker. The would-be philosopher asked
      > the third worker, "What are you doing with these stones?" The
      > third worker stopped what he was doing, bringing his chisel to his
      > side. Deep in thought, the worker slowly gazed toward the traveler
      > and shared, "I am a stone cutter and I am building a cathedral!

      There is another way, and I think it's a valid way to live: "I am a
      stone cutter, and I'm making these stones as well as I know how."

      I don't choose to live that way: I'm always out influencing, for
      better or worse. But I can respect someone who just cuts stone as
      well as he knows how.

      I suggest that we all can, and that we need to learn how to make
      effective use of the really great stones that person can cut for us.

      Ron Jeffries
      www.XProgramming.com
      Computers are useless. They can only give you answers. -- Picasso
    • Dave W. Smith
      ... Before taking that on as a new motto, consider the source. If I were a business exec, I might well look dimly on one part of a failing project patting
      Message 2 of 6 , Jul 4, 2005
      • 0 Attachment
        Mary Poppendieck wrote:
        > He began by telling us a story about a talk he gave to a gathering of
        > business executives. At one point, he used the term "Technical Success",
        > whereupon the audience made it clear to him in no uncertain terms that
        > "There Is No Such Thing As A Technical Success."

        Before taking that on as a new motto, consider the source.

        If I were a business exec, I might well look dimly on one part of a
        failing project patting themselves on the back for succeeding on
        their part. It might look to me like gloating, and since (with my
        pretend executive hat on) I've been pushing "we're all in this
        together", anything that looks like gloating is Not a Good Thing,
        particularly when I'm unhappy.

        Alternatively, I might look with great pleasure on a project that
        has been a resounding success in the market (making me lots of money
        in the process), even though it left the engineering organization
        burnt-out and demoralized, with few feeling that they'd produced
        professional work. I'm happy, and if they're not, then they're
        not team players. And anyway, my fellow executives assure me I can
        replace them cheaper offshore anyway.

        Business executives may not be the ones we want to take our
        definition of success from. And, keeping their definition in mind,
        sometimes it might be best to enjoy our successes quietly. We
        can certainly take more responsibility for things within our sphere
        of influence, though I doubt that more than a very few of us have
        spheres of influence large enough to cover all of the parts that
        need to work together to make a product succeed.

        Dave
      • David A Barrett
        I think that Scrum blurs the definition of success . A traditional PM definition of success might be, Completion: On time, on budget, on scope . Perhaps the
        Message 3 of 6 , Jul 5, 2005
        • 0 Attachment
          I think that Scrum blurs the definition of "success". A traditional PM
          definition of success might be, "Completion: On time, on budget, on scope".
          Perhaps the biggest spanner Scrum throws into the works is that the idea of
          scope as a fixed metric is tossed out. What does, "on scope" mean in a
          Scrum context? We've also had the "How do we know when when we're done?",
          discussion on this list before which tends to muddle the PMP idea of a
          project as having a "definite end".

          I think that Scrum gives the opportunity to redefine what "success" means
          (since you pretty much have to, anyways). You'd probably still have
          something involving customer satisfaction, but maybe it should mean more
          than just delivery of a working product. Customer satisfaction with the
          process of developing the product, and their involvement with it, can
          itself be an important component of customer satisfaction.

          Ken listed a bunch of things like, "a better Scrum process", and a "better
          development team" as deliverables of every Sprint in a post a while back.
          You could make a strong case for including those elements into the
          definition of a successful project. How has the team grown? How has the
          team's relationship with the other departments in the company or with the
          customer grown? What has the organization learned?

          I can see cases where the team delivers a "complete" product on time and on
          budget, but the process has so poisoned the team and its relationships
          between its members and with the rest of the company that the project would
          have to be considered a failure. On the other hand, I can see a case where
          the team, working with the customer, is able to determine in a Sprint or
          two that the entire project is a waste of time and money and should be
          abandoned as quickly as possible, and that doing so should be considered a
          success.

          "Technical Success"? Beats me, but I think that the idea of "success" is a
          whole lot more complicated than we've been led to believe in the past.


          Dave Barrett,
          Lawyers' Professional Indemnity Company
        • David Roberts
          I think the audience was being a bit zealous then. I ll probably stand alone on this but IMO its ok for some to say, it was a technical success, but the
          Message 4 of 6 , Jul 5, 2005
          • 0 Attachment

            I think the audience was being a bit zealous then. I’ll probably stand alone on this but IMO its ok for some to say, it was a technical success, but the product failed miserably.

             

            I work with military readiness primarily. There are several aggregate pieces of information that are go/no-go statuses. The admirals wants to know why something is a no-go.

             

            Questions like: did the new technology we employed do the job?

             

            Answer: Yes sir, but as you see here, this is degraded in manning, not equipment.

             

            There have been many technical successes in our time that turned out to be failures in marketing, management, politics, etc… I think there are valuable lessons to be learned from these successes. Most importantly, why did the product still fail?

             

            One more note, I’ve never seen success and failure as black in white for a product. Every product I’ve been responsible for has had an essence of both failure and success to it. If you can do it twice as fast for half the price and a quarter of the maintenance, was it a success?

             

            David Roberts

            InnovaSystems Intl

            (619) 955-5864

             


            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mary Poppendieck
            Sent: Sunday, July 03, 2005 11:56 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] There is no such thing as Technical Success

             

            At XP2005 in Sheffield , UK , Kent Beck gave a talk about “KIcking it up another Notch.”  He began by telling us a story about a talk he gave to a gathering of business executives.  At one point, he used the term “Technical Success”, whereupon the audience made it clear to him in no uncertain terms that “There Is No Such Thing As A Technical Success.”  There is Success and there is Failure.  If the product fails, it makes no difference how good the technology or technical team happens to be. 

             

            This reminded me of a conversation on this discussion group a couple of weeks ago on Agile Project Managers; there was some discussion about the breadth of responsibility of various people.  Far as I can tell, it is no fun working on something which eventually fails, no matter whose fault the failure might be.  Thus I agree with Kent :  kicking it up another notch means we assume responsibility for what we can influence, not just for what we can control.  Thus everyone should be invested in the overall success of the product or business process for which the software is being developed.

             

            Mary Poppendieck

            www.poppendieck.com

            Author of: Lean Software Development: An Agile Toolkit

             



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



          • Bill McMichael
            ... traditional PM ... scope . Agree. Traditional software development defined success based on the triple contraint you described as it was measured at
            Message 5 of 6 , Jul 5, 2005
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, David A Barrett
              <dave.barrett@l...> wrote:
              > I think that Scrum blurs the definition of "success". A
              traditional PM
              > definition of success might be, "Completion: On time, on budget, on
              scope".

              Agree. Traditional software development defined success based on the
              triple contraint you described as it was measured at project
              completion.

              An alternative is a balanced scorecard approach. Balanced scorecards
              are often used to guage organizational performance but typically not
              not defined / measured at a project level.

              A project's success would be measured in different perspectives.
              Another key point is that you measure thoughout the project (to make
              the necessary portfolio decisions), and you do not stop measuring at
              the completion of the project. As financial, customer satisfaction,
              and quality measures may not be known till months after the completion
              of the project.

              Here are the typical perspectives using a goal/measure approach.

              1) Shareholder perspective -- (eg. cash flow, quarterly sales, market
              share, ROI)
              2) Customer perspective (eg. on time delivery as defined by the
              customer, customer partnership measures, customer satis.)
              3) Internal business perspective. This involves among other things
              the triple constraint you mentioned (on time, on budget, on scope), as
              well as quality, engineering efficiency metrics)
              4) Innovative and Learning Perspective. Perhaps this is what you are
              referring to as "technical success" (eg. did we improve our
              technological skill/ processes to deliver the next project
              better/faster).

              So, I disagree there is no such thing as technical success. All of
              these perspectives collectively provide project value.

              I think Scrum does a good job in a more strategic view of project
              success by focusing success on business value.

              How we measure project success and how well these measures are aligned
              to overall company strategy is the Enterprise Agile concepts that have
              been discusssed here. A balanced scorecard is a good tool to do this.


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