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

There is no such thing as Technical Success

Expand Messages
  • Mary Poppendieck
    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
    Message 1 of 6 , Jul 3, 2005

      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

       

    • 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 2 of 6 , Jul 3, 2005
        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 3 of 6 , Jul 4, 2005
          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 4 of 6 , Jul 5, 2005
            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 5 of 6 , Jul 5, 2005

              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 6 of 6 , Jul 5, 2005
                --- 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.