Read a Agile Rant: Why Agile Has Failed

[Paul Z. Wu]

I just feel that software development the  mixing of
arts and science. Whatever methodologies may not matter that much. 


 Code rant: Coconut Headphones: Why Agile Has Failed



Code rant: Coconut Headphones: Why Agile Ha...
The 2001 agile manifesto was an attempt to replace rigid, process and management heavy, development methodologies with a more human and software-centric appr...
View on mikehadlow.blogspo... Preview by Yahoo
 
 
Paul Z. Wu
 
http://www.elookinto.com

[Scott Shipp]

Good post. Thanks for sharing. Dave Thomas just chimed in on this recently as well: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/

Scott

To: seajug-***@public.gmane.org
From: zwu_net-/***@public.gmane.org
Date: Fri, 11 Apr 2014 16:47:23 -0700
Subject: [seajug] Read a Agile Rant: Why Agile Has Failed




























I just feel that software development the mixing of
arts and science. Whatever methodologies may not matter that much.
Code rant: Coconut Headphones: Why Agile Has Failed

Code rant: Coconut Headphones: Why Agile Ha...The 2001 agile manifesto was an attempt to replace rigid, process and management heavy, development methodologies with a more human and software-centric appr...View on mikehadlow.blogspo...Preview by Yahoo Paul Z. Wu http://www.elookinto.com

[Jason Osgood]

Moving to the Right
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan

Note that last one.

The project is the plan. No plan, no project. If you don’t have a plan, you cannot do project management.

Not having a plan is called R&D, prototyping, scouting, having a hobby, fiddling. All worthy activities. None are project management.

I’m a PMI critical path kinda guy. Works great. When there’s a plan, and everyone knows the plan, there’s very little overhead (e.g. meetings) and much work is accomplished. Very nimble.

Responding to change is what I’d call risk management, reducing the cone of uncertainty, negotiating tradeoffs between time, resources, and scope.


Exactly none of the “agile" teams I’ve been on had a plan. Just a bunch of make work and ceremony to give the appearance of progress. Software development kabuki. Tedious, slow, laborious, confusing, maddening, counter productive, soul robbing. The furtherest things from being agile.


I readily acknowledge that PMI critical path is not a cure all. It’s all about the people, after all. And most people have not seen a successful, functional project. On time, within budget, scope delivered, high quality. So my rants are all just “opinion”.


Cheers, Jason

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Scott Shipp]

"...most people have not seen a successful, functional project. On time, within budget, scope delivered, high quality."~Jason Osgood
versus"All this has an important bearing what constitutes a successful project. A predictive project is often measured by how well it met its plan. A project that's on-time and on-cost is considered to be a success. This measurement is nonsense to an agile environment. For agilists the question is business value - did the customer get software that's more valuable to them than the cost put into it. A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw."~ Martin Fowler, "The New Methodology" http://martinfowler.com/articles/newMethodology.html

Date: Sun, 13 Apr 2014 11:08:12 -0700
Subject: Re: [seajug] Read a Agile Rant: Why Agile Has Failed

Moving to the Right
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan

Note that last one.
The project is the plan. No plan, no project. If you don’t have a plan, you cannot do project management.
Not having a plan is called R&D, prototyping, scouting, having a hobby, fiddling. All worthy activities. None are project management.
I’m a PMI critical path kinda guy. Works great. When there’s a plan, and everyone knows the plan, there’s very little overhead (e.g. meetings) and much work is accomplished. Very nimble.
Responding to change is what I’d call risk management, reducing the cone of uncertainty, negotiating tradeoffs between time, resources, and scope.
Exactly none of the “agile" teams I’ve been on had a plan. Just a bunch of make work and ceremony to give the appearance of progress. Software development kabuki. Tedious, slow, laborious, confusing, maddening, counter productive, soul robbing. The furtherest things from being agile.
I readily acknowledge that PMI critical path is not a cure all. It’s all about the people, after all. And most people have not seen a successful, functional project. On time, within budget, scope delivered, high quality. So my rants are all just “opinion”.
Cheers, Jason
------------------------------------
Yahoo Groups Links

[Stewart Buskirk]

These two outlooks seem to have very different unsaid assumptions about what constitutes "success".

If the question is "Are we (the team/client/customer/etc.) better off now with the results of this project than at the last check, and if so, was that value worth the expense?", then the measure of success is to be able to continually answer that question positively. I think there are many contexts where that is an appropriate measure, especially in some startup or R&D oriented environment.

But if the question is "Have the requirements been met when needed, on time and on budget?", I would have little confidence in a religiously pure agile approach as described in the quote. And quite often, that *is* the appropriate question to ask.

Or to put in another way - if a project has a known endpoint, it needs "project management" to successfully get there. If a project has *no known endpoint*, bring on the agilistas.

I don't think it has to be either/or - you can certainly do project management successfully while using agile development techniques if you're more practical than religious about it - but if an "agile environment" has no plan longer than an iteration, then it may not be the best way to meet longer term goals. And of course the project plans have to distinguish between reasonably predictable work ("Week 3 - Complete four data entry screen layouts") and hope ("Week 3 - Develop novel algorithm for predicting porpoise fertility from container ship movement patterns").

Agile seems to be a way to try to cope successfully with change and lack of foreknowledge. But it gives up a lot in doing do that does lead to trouble sometimes being coherent in any timeframe longer than an iteration, and it does it by redefining what "success" means - which doesn't play all that well if you do in fact actually have specific longer term goals.

And I really don't like the implied disdain that comes through in a lot of agile theology - that it's just *impossible* that *anyone* could know ahead of time exactly where they should be or want to end up, that the Magic of Agile will always produce "something different and better than the original plan foresaw.". Sometimes the best possible (or objectively successful) outcome is precisely the one from the plan.

Post by Scott Shipp
"...most people have not seen a successful, functional project. On time, within budget, scope delivered, high quality."
~Jason Osgood
versus
"All this has an important bearing what constitutes a successful project. A predictive project is often measured by how well it met its plan. A project that's on-time and on-cost is considered to be a success. This measurement is nonsense to an agile environment. For agilists the question is business value - did the customer get software that's more valuable to them than the cost put into it. A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw."
~ Martin Fowler, "The New Methodology" http://martinfowler.com/articles/newMethodology.html

[Jason Osgood]

Hi Scott, Stewart-

Post by Scott Shipp
A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.

Martin is an optimist. One of his best traits. As opposed to the pessimism of Yourdon.

Otherwise, he and I are saying the same thing.

Post by Scott Shipp
Agile seems to be a way to try to cope successfully with change and lack of foreknowledge. But it gives up a lot in doing…

Now I will defend Agile.

Whenever I write “Agile”, I mean the fiction of effectively managing people and their work.

Use of Agile can improve communication. This is the single potential benefit of using “agile” methods.

Agile methodologies can be useful for maintenance work. Commonly called IT. Everything but new development. Keeping legacy systems running. Move, add, delete of features. Bring existing systems into compliance. New business needs like yet another quarterly TPS report. Integration between systems. Bug fixes. Migration to new servers. Patches. Upgrades.

Most software dev work is maintenance. (70%? 90%? I forget the accepted wisdom.)

In the work I’ve been doing these last few years, which falls somewhere between archeology and hands on sewage treatment plant operator, I cannot imagine any way other than agile / scrum to tackle this work.

The de facto IT methodology is now being victimized by JIRA or equivalent. It’s called “agile”, “scrum” or whatever. Whatever it’s multitude of conceptual, implementation failings, using JIRA does capture and daylight people’s activities.

Actually, thinking about it, that’s not fair to JIRA. Scrum, kanban, etc. is a jobs creation program for the middle management plebes who are baffled by MS Project and its more mature, sophisticated cousins (Primavera). It’s a sly way to trick all the Junior Power Rangers to adopt some best practices, like having fewer meetings, agendas, minutes, and ready made status reports.

Anything that makes the throngs of middle management “business analysts” less terrible is a win for developers. It now occurs to me what a terrific propaganda win Agile is. Usually, management fads are evidence free top down reorganizations of the Ant Farm (vigorous shaking). Agile originated with the devs, albeit the consultant class. No other example of successfully “managing up” to change behavior comes to mind. Hmmm. I should be more impressed by the cultural phenomenon of Agile.

Any way.

We can liken Agile to the rollout of automatic espresso machines at Starbucks. Starbucks used to spend huge money training everyone how to be a barrista. Product quality was still highly variable. Now any monkey can pull a fairly decent shot (refill thru the top, push a button). The qualitative cost is the elimination of very good (enjoyable) shots. The band (range) of quality is narrowed. But the floor was raised much higher than the ceiling was lowered. So overall the espresso machines are a win for Starbucks.

Overall, Agile is probably a win for IT.


Cheers, Jason




------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Scott Shipp]

Jason and Stewart - I am curious what your exposure to Agile is? Mine is first participating in two labeled-as-agile projects where, like the Dave Thomas article mentions, the term Agile was misappropriated by some consultants and sold to these companies as a couple of practices that were then applied even more out of context and achieved the exact opposite of what they promised.

Second, just last year I went to the Construx "Agile Developer Bootcamp" taught by Melvin Perez over in Bellevue and came away with a really different view of what Agile was. I had a lot to think about. I'm still thinking about it. I started reading what Agile proponents really taught. I read Lean Software Development by Mary Poppendieck and Tom Poppendieck and came away with an even more different view. I've continued on to read a lot of 8th Light and Thoughtworks articles, watched videos and listened to webinars to hear what these gals and guys say in their own words, and I'm generally spending time as we speak catching up with what Agile is supposed to be, not what it generally is in the wild. I'm reading Jez Humble's Continuous Delivery right now.

I am a perpetual learner. I hope I don't come off as being pedantic or condescending in posting this. What I'm trying to say is I used to agree with everything you guys have written, based on my experience with "agile projects," but now I may be in the process of converting. I've realized that what I experienced weren't really agile projects. I'm trying to understand what it really looks, feels, and tastes like, and the differences between Agile, Lean, XP, and Software Craftsmanship. I would encourage the same for you.

Scott

Date: Mon, 14 Apr 2014 08:49:14 -0700
Subject: Re: [seajug] Read a Agile Rant: Why Agile Has Failed
Hi Scott, Stewart-

Post by Scott Shipp
A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.

Martin is an optimist. One of his best traits. As opposed to the pessimism of Yourdon.
Otherwise, he and I are saying the same thing.

Post by Scott Shipp
Agile seems to be a way to try to cope successfully with change and lack of foreknowledge. But it gives up a lot in doing…

Now I will defend Agile.
Whenever I write “Agile”, I mean the fiction of effectively managing people and their work.
Use of Agile can improve communication. This is the single potential benefit of using “agile” methods.
Agile methodologies can be useful for maintenance work. Commonly called IT. Everything but new development. Keeping legacy systems running. Move, add, delete of features. Bring existing systems into compliance. New business needs like yet another quarterly TPS report. Integration between systems. Bug fixes. Migration to new servers. Patches. Upgrades.
Most software dev work is maintenance. (70%? 90%? I forget the accepted wisdom.)
In the work I’ve been doing these last few years, which falls somewhere between archeology and hands on sewage treatment plant operator, I cannot imagine any way other than agile / scrum to tackle this work.
The de facto IT methodology is now being victimized by JIRA or equivalent. It’s called “agile”, “scrum” or whatever. Whatever it’s multitude of conceptual, implementation failings, using JIRA does capture and daylight people’s activities.
Actually, thinking about it, that’s not fair to JIRA. Scrum, kanban, etc. is a jobs creation program for the middle management plebes who are baffled by MS Project and its more mature, sophisticated cousins (Primavera). It’s a sly way to trick all the Junior Power Rangers to adopt some best practices, like having fewer meetings, agendas, minutes, and ready made status reports.
Anything that makes the throngs of middle management “business analysts” less terrible is a win for developers. It now occurs to me what a terrific propaganda win Agile is. Usually, management fads are evidence free top down reorganizations of the Ant Farm (vigorous shaking). Agile originated with the devs, albeit the consultant class. No other example of successfully “managing up” to change behavior comes to mind. Hmmm. I should be more impressed by the cultural phenomenon of Agile.
Any way.
We can liken Agile to the rollout of automatic espresso machines at Starbucks. Starbucks used to spend huge money training everyone how to be a barrista. Product quality was still highly variable. Now any monkey can pull a fairly decent shot (refill thru the top, push a button). The qualitative cost is the elimination of very good (enjoyable) shots. The band (range) of quality is narrowed. But the floor was raised much higher than the ceiling was lowered. So overall the espresso machines are a win for Starbucks.
Overall, Agile is probably a win for IT.
Cheers, Jason
------------------------------------
Yahoo Groups Links

[Paul Z. Wu]

Here it seems we cannot even agree what Agile is.  Interestingly, I work in a big Telecom and I used to be in  a big division of it.  One day the head of the division decided we all must go Agile. Well, the small potato like me, or even the potatos much bigger than me, have no choices but obey.   It is interesting, for many cross-team projects, one could have to attend 'several' scrums a day.

 Cheers,

 
Paul Z. Wu
 
http://www.elookinto.com


________________________________
From: Scott Shipp <scottashipp-1ViLX0X+***@public.gmane.org>
To: "seajug-***@public.gmane.org" <seajug-***@public.gmane.org>
Sent: Monday, April 14, 2014 9:15 AM
Subject: RE: [seajug] Read a Agile Rant: Why Agile Has Failed



 
Jason and Stewart - I am curious what your exposure to Agile is? Mine is first participating in two labeled-as-agile projects where, like the Dave Thomas article mentions, the term Agile was misappropriated by some consultants and sold to these companies as a couple of practices that were then applied even more out of context and achieved the exact opposite of what they promised.

Second, just last year I went to the Construx "Agile Developer Bootcamp" taught by Melvin Perez over in Bellevue and came away with a really different view of what Agile was. I had a lot to think about. I'm still thinking about it. I started reading what Agile proponents really taught. I read Lean Software Development by Mary Poppendieck and Tom Poppendieck and came away with an even more different view. I've continued on to read a lot of 8th Light and Thoughtworks articles, watched videos and listened to webinars to hear what these gals and guys say in their own words, and I'm generally spending time as we speak catching up with what Agile is supposed to be, not what it generally is in the wild. I'm reading Jez Humble's Continuous Delivery right now.

I am a perpetual learner. I hope I don't come off as being pedantic or condescending in posting this. What I'm trying to say is I used to agree with everything you guys have written, based on my experience with "agile projects," but now I may be in the process of converting. I've realized that what I experienced weren't really agile projects. I'm trying to understand what it really looks, feels, and tastes like, and the differences between Agile, Lean, XP, and Software Craftsmanship. I would encourage the same for you.

Scott

Date: Mon, 14 Apr 2014 08:49:14 -0700
Subject: Re: [seajug] Read a Agile Rant: Why Agile Has Failed
Hi Scott, Stewart-

Post by Scott Shipp
A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.

Martin is an optimist. One of his best traits. As opposed to the pessimism of Yourdon.
Otherwise, he and I are saying the same thing.

Post by Scott Shipp
Agile seems to be a way to try to cope successfully with change and lack of foreknowledge. But it gives up a lot in doing


Now I will defend Agile.
Whenever I write “Agile”, I mean the fiction of effectively managing people and their work.
Use of Agile can improve communication. This is the single potential benefit of using “agile” methods.
Agile methodologies can be useful for maintenance work. Commonly called IT. Everything but new development. Keeping legacy systems running. Move, add, delete of features. Bring existing systems into compliance. New business needs like yet another quarterly TPS report. Integration between systems. Bug fixes. Migration to new servers. Patches. Upgrades.
Most software dev work is maintenance. (70%? 90%? I forget the accepted wisdom.)
In the work I’ve been doing these last few years, which falls somewhere between archeology and hands on sewage treatment plant operator, I cannot imagine any way other than agile / scrum to tackle this work.
The de facto IT methodology is now being victimized by JIRA or equivalent. It’s called “agile”, “scrum” or whatever. Whatever it’s multitude of conceptual, implementation failings, using JIRA does capture and daylight people’s activities.
Actually, thinking about it, that’s not fair to JIRA. Scrum, kanban, etc. is a jobs creation program for the middle management plebes who are baffled by MS Project and its more mature, sophisticated cousins (Primavera). It’s a sly way to trick all the Junior Power Rangers to adopt some best practices, like having fewer meetings, agendas, minutes, and ready made status reports.
Anything that makes the throngs of middle management “business analysts” less terrible is a win for developers. It now occurs to me what a terrific propaganda win Agile is. Usually, management fads are evidence free top down reorganizations of the Ant Farm (vigorous shaking). Agile originated with the devs, albeit the consultant class. No other example of successfully “managing up” to change behavior comes to mind. Hmmm. I should be more impressed by the cultural phenomenon of Agile.
Any way.
We can liken Agile to the rollout of automatic espresso machines at Starbucks. Starbucks used to spend huge money training everyone how to be a barrista. Product quality was still highly variable. Now any monkey can pull a fairly decent shot (refill thru the top, push a button). The qualitative cost is the elimination of very good (enjoyable) shots. The band (range) of quality is narrowed. But the floor was raised much higher than the ceiling was lowered. So overall the espresso machines are a win for Starbucks.
Overall, Agile is probably a win for IT.
Cheers, Jason
------------------------------------
Yahoo Groups Links

[Nimret Sandhu]

top-down management styles will not result in teams which are empowered to
deliver solutions, regardless of methodology.

people should not be attending multiple scrums unless they have a real need
to.
Agile techniques are about enabling communication, not enforcing it. If you
or a team member has questions for another team, attend their scrum so you
can get the questions answered in one place from the relevant folks rather
than chasing issues down. If your team has to attend multiple scrums,
delegate that responsibility in a rotating fashion to a couple of folks on
the team (ideally the ones who may actually have q's for the other team).

cheers,
-
Nimret Sandhu
http://www.nimret.org

Here it seems we cannot even agree what Agile is. Interestingly, I work
in a big Telecom and I used to be in a big division of it. One day the
head of the division decided we all must go Agile. Well, the small potato
like me, or even the potatos much bigger than me, have no choices but
obey. It is interesting, for many cross-team projects, one could have to
attend 'several' scrums a day.
Cheers,
Paul Z. Wu
http://www.elookinto.com

[Konstantin Ignatyev]

Post by Nimret Sandhu
top-down management styles will not result in teams which are empowered to
deliver solutions, regardless of methodology.

Nor team of freshman-s can create a decent manageable and extendable system
without guidance.

But such a team can create a lot of activity which can easily look like
progress. And that is why I think 'Agile' become so popular: following
Agile 'letter' (not spirit) makes it easy for consultants and teams to milk
client/company/etc. It is just good ol' "time and material" type of
contract.

I am not saying that 'Agile' cannot work, as everything it can and it
depends on team composition and people at the helm. But statistically
speaking, I think Agile does more harm than good.

[George Smith]

I am a Developer (and sometime Manager), and back in 1999, I felt that "we"
were not making progress (from a development methodology perspective) and
then I read Kent's White XP book, and was of the opinion that trying the
practices could resolve a number of the issues of a dev team and their
relationship with the other parts of the company.

I had the good fortune to be able to join a company lead by Bruce
Winegarden, with Jeff McKenna as coach. This team, doing XP, did just about
everything right and was a fabulous learning experience. I next joined
ASIX for another XP team. This team also did almost everything right.
Since then I have been an another XP team that was NOT doing a lot right,
and a number of "SCRUM" teams that I don't know what they were doing, but
thanks to this email thread and the referenced articles, I now know that
these companies were doing "SCRUM as Cargo Cult"!

Some points:

1. A "proper" XP team does more "formal" planning, both per "Iteration"
and per "Release", then any other methodology I have used!
2. All my "agile" experiences since the first two XP teams, has IMO,
brought negative ROI vs good old fashion SEI CMM Level 1!
3. I feel that the Agile Manifesto and the non-XP methodologies ushered
in by the "Methodology Consultants" has been primarily about generating
"Methodology Consultant" revenue and less about improving a company's dev
team effectiveness!


George




On Mon, Apr 14, 2014 at 12:24 PM, Konstantin Ignatyev

Post by Konstantin Ignatyev

Post by Nimret Sandhu
top-down management styles will not result in teams which are empowered
to deliver solutions, regardless of methodology.

Nor team of freshman-s can create a decent manageable and extendable
system without guidance.
But such a team can create a lot of activity which can easily look like
progress. And that is why I think 'Agile' become so popular: following
Agile 'letter' (not spirit) makes it easy for consultants and teams to milk
client/company/etc. It is just good ol' "time and material" type of
contract.
I am not saying that 'Agile' cannot work, as everything it can and it
depends on team composition and people at the helm. But statistically
speaking, I think Agile does more harm than good.

[richard v boyd]

GEORGE



AMEN !!!!!!!!!!!!! :(



/richard





From: seajug-***@public.gmane.org [mailto:seajug-***@public.gmane.org] On Behalf Of George Smith
Sent: Monday, April 14, 2014 4:53 PM
To: seajug-***@public.gmane.org
Subject: Re: [seajug] Read a Agile Rant: Why Agile Has Failed





I am a Developer (and sometime Manager), and back in 1999, I felt that "we" were not making progress (from a development methodology perspective) and then I read Kent's White XP book, and was of the opinion that trying the practices could resolve a number of the issues of a dev team and their relationship with the other parts of the company.



I had the good fortune to be able to join a company lead by Bruce Winegarden, with Jeff McKenna as coach. This team, doing XP, did just about everything right and was a fabulous learning experience. I next joined ASIX for another XP team. This team also did almost everything right. Since then I have been an another XP team that was NOT doing a lot right, and a number of "SCRUM" teams that I don't know what they were doing, but thanks to this email thread and the referenced articles, I now know that these companies were doing "SCRUM as Cargo Cult"!



Some points:

1. A "proper" XP team does more "formal" planning, both per "Iteration" and per "Release", then any other methodology I have used!
2. All my "agile" experiences since the first two XP teams, has IMO, brought negative ROI vs good old fashion SEI CMM Level 1!
3. I feel that the Agile Manifesto and the non-XP methodologies ushered in by the "Methodology Consultants" has been primarily about generating "Methodology Consultant" revenue and less about improving a company's dev team effectiveness!



George







On Mon, Apr 14, 2014 at 12:24 PM, Konstantin Ignatyev <kgignatyev-***@public.gmane.org <mailto:kgignatyev-***@public.gmane.org> > wrote:



On Mon, Apr 14, 2014 at 11:20 AM, Nimret Sandhu <nimret-rf+Eeaps6PzQT0dZR+***@public.gmane.org <mailto:nimret-rf+Eeaps6PzQT0dZR+***@public.gmane.org> > wrote:



top-down management styles will not result in teams which are empowered to deliver solutions, regardless of methodology.









Nor team of freshman-s can create a decent manageable and extendable system without guidance.



But such a team can create a lot of activity which can easily look like progress. And that is why I think 'Agile' become so popular: following Agile 'letter' (not spirit) makes it easy for consultants and teams to milk client/company/etc. It is just good ol' "time and material" type of contract.



I am not saying that 'Agile' cannot work, as everything it can and it depends on team composition and people at the helm. But statistically speaking, I think Agile does more harm than good.

[Teri Radichel]

This thread is timely.

I wrote up how our team functions, when allowed, for a new team member (see
link below). For projects where we are able to follow the process In the
link below, have been told we have one of the most productive teams that
delivers iterative business value.

I agree with the consultant comments.

I welcome feed back - have already adjusted based on some received earlier
today.

http://websitenotebook.blogspot.com/2014/04/agile-and-scum-how-to-make-it-work.html

Teri Radichel
@teriradichel

On Apr 14, 2014, at 6:56 PM, richard v boyd <richard.v.boyd-***@public.gmane.org>
wrote:



GEORGE



AMEN !!!!!!!!!!!!! L



/richard





*From:* seajug-***@public.gmane.org
[mailto:seajug-***@public.gmane.org<seajug-***@public.gmane.org>]
*On Behalf Of *George Smith
*Sent:* Monday, April 14, 2014 4:53 PM
*To:* seajug-***@public.gmane.org
*Subject:* Re: [seajug] Read a Agile Rant: Why Agile Has Failed





I am a Developer (and sometime Manager), and back in 1999, I felt that "we"
were not making progress (from a development methodology perspective) and
then I read Kent's White XP book, and was of the opinion that trying the
practices could resolve a number of the issues of a dev team and their
relationship with the other parts of the company.



I had the good fortune to be able to join a company lead by Bruce
Winegarden, with Jeff McKenna as coach. This team, doing XP, did just about
everything right and was a fabulous learning experience. I next joined
ASIX for another XP team. This team also did almost everything right.
Since then I have been an another XP team that was NOT doing a lot right,
and a number of "SCRUM" teams that I don't know what they were doing, but
thanks to this email thread and the referenced articles, I now know that
these companies were doing "SCRUM as Cargo Cult"!



Some points:

1. A "proper" XP team does more "formal" planning, both per "Iteration"
and per "Release", then any other methodology I have used!
2. All my "agile" experiences since the first two XP teams, has IMO,
brought negative ROI vs good old fashion SEI CMM Level 1!
3. I feel that the Agile Manifesto and the non-XP methodologies ushered
in by the "Methodology Consultants" has been primarily about generating
"Methodology Consultant" revenue and less about improving a company's dev
team effectiveness!



George







On Mon, Apr 14, 2014 at 12:24 PM, Konstantin Ignatyev <kgignatyev-***@public.gmane.org>
wrote:



On Mon, Apr 14, 2014 at 11:20 AM, Nimret Sandhu <nimret-rf+Eeaps6PzQT0dZR+***@public.gmane.org> wrote:



top-down management styles will not result in teams which are empowered to
deliver solutions, regardless of methodology.









Nor team of freshman-s can create a decent manageable and extendable system
without guidance.



But such a team can create a lot of activity which can easily look like
progress. And that is why I think 'Agile' become so popular: following
Agile 'letter' (not spirit) makes it easy for consultants and teams to milk
client/company/etc. It is just good ol' "time and material" type of
contract.



I am not saying that 'Agile' cannot work, as everything it can and it
depends on team composition and people at the helm. But statistically
speaking, I think Agile does more harm than good.

[Jason Osgood]

Hi George Smith

Post by richard v boyd
I had the good fortune to be able to join a company lead by Bruce Winegarden, with Jeff McKenna as coach. This team, doing XP, did just about everything right and was a fabulous learning experience.

You’re made of sterner stuff than me. Once you’ve tasted success, it’s hard to go back.

Be honest: When you first meet a project team, you know almost immediately if they’re heroes or zeros. Amirite?


Cheers, Jason

[Nimret Sandhu]

Post by Konstantin Ignatyev
Nor team of freshman-s can create a decent manageable and extendable
system without guidance.

that's what pairing is for (or peer code reviews, standards, etc)
mix up the teams

But such a team can create a lot of activity which can easily look like

Post by Konstantin Ignatyev
progress. And that is why I think 'Agile' become so popular: following
Agile 'letter' (not spirit) makes it easy for consultants and teams to milk
client/company/etc. It is just good ol' "time and material" type of
contract.
I am not saying that 'Agile' cannot work, as everything it can and it
depends on team composition and people at the helm. But statistically
speaking, I think Agile does more harm than good.

so have the product owner call bullshit when the demos don't show progress
:)

cheers,
nimret

[Konstantin Ignatyev]

Post by Konstantin Ignatyev
Nor team of freshman-s can create a decent manageable and extendable

Post by Konstantin Ignatyev
system without guidance.

that's what pairing is for (or peer code reviews, standards, etc)
mix up the teams

That is if there are senior members in the team and if team listens to them
rather than making them outcasts (mob rule)

Post by Konstantin Ignatyev
But such a team can create a lot of activity which can easily look like

Post by Konstantin Ignatyev
progress. And that is why I think 'Agile' become so popular: following
Agile 'letter' (not spirit) makes it easy for consultants and teams to milk
client/company/etc. It is just good ol' "time and material" type of
contract.
I am not saying that 'Agile' cannot work, as everything it can and it
depends on team composition and people at the helm. But statistically
speaking, I think Agile does more harm than good.

so have the product owner call bullshit when the demos don't show progress
:)

That is possible if product owner is smart enough, but oftentimes product
owner is confused by flurry of activity demonstrated by the team.

You Nimret basically corroborating to my point: with right people Agile can
work.
But with right people _any_ process can work.

What I see is that statistically Agile is worse because companies tend to
hire whole bunch of freshmans in India, or consultants who have no clue but
sound convincing and deliver something that look good: a real world
equivalent of a standing house without insulation in the walls, but it is
summer, so nobody notices or cares.

Post by Konstantin Ignatyev
cheers,
nimret

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Jason Osgood]

Hi Konstantin.

What I see is that statistically Agile is worse because companies tend to…

I’m in the uncomfortable position of not being the harshest critic in the room.

I would love to have updated win/loss stats for software projects, taking into account Agile etc.

Meanwhile, I cannot imagine a better way of tackling IT work than with Agile. Whatever that means or entails. The (cargo cult) artifacts of Agile are far superior to the prior status quo methods.

“It has been said that democracy is the worst form of government except all the others that have been tried.”
— Winston Churchill

Agile methods for actual project management of an actual product, as in achieving a clear goal, is akin to given kindergartners fire hoses to blow out their birthday candles. Sure, it can work. But you won’t like the result.


Cheers, Jason

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Jason Osgood]

Hi Paul Z. Wu.

Post by Paul Z. Wu
Here it seems we cannot even agree what Agile is.

Easy. The Agile methodology is to argue about the Agile methodology.

What is Art?


Hi Scott.

Post by Paul Z. Wu
I am curious what your exposure to Agile is?

Over exposure. Like being force fed McDonald’s Happy Meals while watching Japanese TV game shows. Makes me feel sick and I can’t figure out what people are talking about.

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Nimret Sandhu]

no single methodology is a silver bullet. All have pros/cons. They are in
place to enable a well oiled team to deliver business value (working
software to address business needs). On the flip side, well oiled teams
deliver value irrespective of methodology :)

Just adding daily stand-ups and creating sprints (2 weeks, a month,
whatever) in and of themselves don't imply that a team/company are agile.
Though they may be steps in that direction.

Regardless of methodology, one really needs both a strategic goal and
tactical steps to achieve them. A backlog (Epics/stories in various stages
of grooming) can serve as a way to define strategic direction while
tactically the current/upcoming sprints can help execute against them.

btw I've settled on Scrum-ban as my current methodology since that's what
most scrum processes tend to become anyways.

As for the original article - having non-technical scrum
masters/managers/whatever can have both pros and cons. That responsibility
does not entail just technical acumen though that may be helpful.

I'd be happy to hear about alternatives to agile techniques from other
folks :)

cheers,
-
Nimret Sandhu
http://www.nimret.org

[P.Hill]

Post by Jason Osgood

Moving to the Right
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan

Note that last one.
The project is the plan. No plan, no project. If you don’t have a plan, you cannot do project management.
Not having a plan is called R&D, prototyping, scouting, having a hobby, fiddling. All worthy activities. None are project management.
[...]
Exactly none of the “agile" teams I’ve been on had a plan.

Then they and you read the list the same way -- as a binary. The list
means an emphasis toward the one (the "over") vs. the other not none or
one and none of the other. It is sad really that too many people over
simplify such things.

-Paul




------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Doug Schwartz]

I'm not sure I get the big deal about calling someone a"programmer who develops with agility" instead of an "agile programmer". Does that mean we should abandon "Java programmer" and instead use "programmer who develops with Java"? Is anyone really going to get this tempest in a tea pot but us?

I grok how the term "agile" has been bastardized by companies looking to make a buck from it. Name one technology, programming language, etc. that hasn't experienced similar effects at first blush. It's the nature of our industry. Someone thinks they have a better solution. Early adopters claim tastes great, less filling, and cures cancer. Consultants trumpet massive productivity gains with only two weeks training. Old timers just smile, nod their heads, and point out the numerous previous breakthroughs that are now considered passe.

I must be getting cynical in my old age.