Hi Steve. No, I do not consider this impolite - it s a good discussion and I appreciate you sharing your point of view. You summarize it the best in my eyes.Message 1 of 135 , Dec 31 4:45 PMView Source
No, I do not consider this impolite – it’s a good discussion and I appreciate you sharing your point of view.
You summarize it the best in my eyes.
“The objective should be to reduce the cost of project failures, not eliminate them or even figure out who to blame for them.”
I could not agree more with you on this – I am not advocating elimination of all failure. What I would like to see is accountability. People are too often accountable when there is success, but when there is failure, the tail goes between the legs and everything else but the people that made the situation what it is take the hit. I guess the phrase “grow some balls” comes to mind. J
The other topics could probably be debated for days, but we’d need food and beer for that.
I hope my continuation of the argument is not considered impolite:
Suppose the company is acquired by another company who already has a competing product and therefore kills the project. Whose failure is that?
Suppose the market suddenly changes so as to make the product being developed unprofitable. Whose failure is that?
Suppose there never really was a profitable market for the product, but that fact could only be discovered by market testing the version produced after 2 months of development. Whose failure is that?
Suppose that building the product within a reasonable budget with the current state of technology is not feasible, but this fact could only be verified/discovered by trying for 2 months. Whose failure is that?
Even in the type of example you cite, management might conceivably be making a good business decision when it decides that unblocking one particular project would threaten too many other projects or even normal business operations. Eventhough management is "failing" to support a project and the decision looks irrationally political from the point of view of the people on that project, if the decision making is rationally based on the bigger pricture, then perhaps there is no failure occurring at all on the part of any person or process. I suspect this is true in less than half of such cases, but it does happen.
If no projects are failing at a company, one of the two conditions below is most likely:
- The company is not assuming enough risk to be competitive in the long run, or
- All failures are being covered up by the managers whose careers would be threatened by admitting the failure (in these cases, millions of dollars are wasted continuing the project to completion even after failure was obvious to everyone involved).
The objective should be to reduce the cost of project failures, not eliminate them or even figure out who to blame for them.
On 12/31/06, Mitch Lacey <mitch.lacey@...> wrote:
I agree and disagree, politely. J My take is this:
Say everyone on a project has the best intent. Say an issue arises, and I try to do the right thing by overcommunicating the issue to help unblock the team / organization. Say I get slapped and politics are cited, like "that's not the way we do things here" or "your job is to test, nothing more".
I guess in scenarios like these, even though the team (or just me) has the best intent, it is impossible for everyone (and I mean every possible touch point) to have the same intent. There are always detractors.
As a result, the people fail – the process only highlights or masks that failure – and as a result, since most people don't like to take accountability for failure (only success), the process has failed.
I've seen this happen over and over and over again at my last company (search the DL for my previous posts and you'll figure out who the company is) – so it's my perception and experience that processes do not fail, people do.
Have a good new year!
On 12/28/06, Mitch Lacey <mitch.lacey@...
> In reading all the posts to this thread, twice, I was surprised that no one pointed this out.
>with regards to "the agile process failing"
> There is an assertion made by the original poster and then again below
>Even this is not totally true. Sometimes a project fails despite the
> Processes do not fail, the people working in them do.
very best intentions and efforts of everyone involved.
One thing I like about the agile approach is that if the seeds of
failure are there, they tend to be discovered and confronted much
earlier than in traditional command-and-control approaches where it
seems to be in nobody's interest to point out that "the emperor is
wearing no clothes".
The earlier discovery of the potential seeds of failure sometimes
means we can fix the problems or successfully campaign to get the
problems fixed if they are outside our sphere of influence, but in
some cases it just means the failure is quicker, less painful, and
less expensive that if we had not confronted the issues. Is this
failure or success?
>pointed out, would traditional teams of the same inexperience do better, or even worse?
> Now there are advantages and disadvantages to everything, but like Ron
>I have experiences some large organizations in which an early failure
or reduced scope was considered a worse result than a project
completed to spec whose financial return was less than the cost of
producing it, finally getting it to work, deploying it and maintaining
it. In such bizarro worlds ruled by politics and accounting tricks,
it is quite possible that traditional teams would seem to fare better.
Ewww! Slimy hands! Dave ... http://kw-agiledevelopment.blogspot.com/2007/09/disadvantages-of-agile-software.htmlMessage 135 of 135 , Sep 5, 2007View SourceEwww! Slimy hands!
--- In firstname.lastname@example.org, "Henrik Kniberg" <h@...> wrote:
> Interesting list of "disadvantages" :o)
> - Active user involvement and close collaboration
> - Requirements emerge and evolve
> - Agile requirements are barely sufficient
> - Testing is integrated throughout the lifecycle
> - Frequent delivery, and the need to signoff each feature as Done.
> Challenges? Yes, certainly.
> Disadvantages? Well....
> Calling "Requirements emerge and evolve" a disadvantage sort of
> implies that "You must specify everything upfront" would be an
> Sort of like saying:
> "The disadvantage of having the lethal tumor removed is that the
> surgeon has to cut me"
> or "The disadvantage of pulling the leach off my body is that my hands
> will get slimy".
> I do get your point though. Many people of a waterfallish mindset will
> initially *perceive* these as disadvantages, while the real
> disadvantage is the fact that the transition may be difficult and
> costly, which we must take into account.
> Great site BTW.
> Henrik Kniberg
> +46 (0)70 492 5284
> On 9/4/07, kswaters1 <allaboutagile@...> wrote:
> > My thoughts on question #1 - what are the disadvantages of agile
> > software development?
> > http://kw-agiledevelopment.blogspot.com/2007/09/disadvantages-of-
> > agile-software.html
> > Kelly Waters
> > http://www.allaboutagile.com
> > --- In email@example.com, "Mike Bria" <bria526xp@>
> > wrote:
> > >
> > > For clarity, I'd like to point out that I feel Deepinder has asked
> > two
> > > largely distinct questions:
> > > 1/ What are the /disadvantages/ of using an agile methodology?
> > > 2/ What are the /potential pitfalls/ when using an agile
> > methodology?
> > >
> > > Some of the responses so far have addressed question #2.
> > > Some of the responses have addressed an unasked (but good)
> > question: "What
> > > might adopting Agile expose about your organization?"
> > > I don't think #1 (the subject of the thread) hasn't gotten much
> > airtime
> > > though.
> > >
> > > Does anyone have any thoughts on #1?
> > > --MB
> > >
> > > On 12/28/06, PaulOldfield1@ <PaulOldfield1@> wrote:
> > > >
> > > > (responding to Deepinder)
> > > >
> > > > > All of you have experience in Agile and Scrum, I would like to
> > know what
> > > > > are the disadvantages of using Agile process where all it can
> > fail as
> > > > > compared with other traditional processes?
> > > >
> > > > Going by reports I've heard rather than any in-depth study; I
> > seem
> > > > to hear that while a relatively inexperienced team can do a good
> > > > job at detecting problems, they are often not experienced enough
> > > > to change things in a way that makes things better.
> > > >
> > > > One way to help counter this is to 'go by the book' for at least
> > 6
> > > > months and start to build up experience of what 'going by the
> > book'
> > > > can do for you (and hopefully, why it does). Another way is to
> > get
> > > > some good, experienced help to make any necessary tweaks
> > > > and explain why they are good changes to make.
> > > >
> > > > Paul Oldfield
> > > >
> > > >
> > > >
> > >