Re: [scrumdevelopment] There is no such thing as Technical Success
- On Sunday, July 3, 2005, at 2:56:16 PM, Mary Poppendieck wrote:
> At XP2005 in Sheffield, UK, Kent Beck gave a talk about "KIckingCertainly if the product fails, it's a lot less fun for everyone.
> 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
And I fully agree that it's far better if everyone is invested in
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 sojournerThere is another way, and I think it's a valid way to live: "I am a
> 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!
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.
Computers are useless. They can only give you answers. -- Picasso
- Mary Poppendieck wrote:
> He began by telling us a story about a talk he gave to a gathering ofBefore taking that on as a new motto, consider the source.
> 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."
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.
- 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
"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.
Lawyers' Professional Indemnity Company
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?
From: firstname.lastname@example.org [mailto: email@example.com ] On Behalf Of Mary Poppendieck
Sent: Sunday, July 03, 2005 11:56 AM
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.
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@...
- --- In firstname.lastname@example.org, David A Barrett
> I think that Scrum blurs the definition of "success". Atraditional PM
> definition of success might be, "Completion: On time, on budget, onscope".
Agree. Traditional software development defined success based on the
triple contraint you described as it was measured at project
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
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
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.