This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
    Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Agile manifesto questions + scam alert

 
Ranch Hand
Posts: 62
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator
Hi all,
I have over 10 years in the industry, yet only today I got to read that agile manifesto. I have some observations and questions for you. I would appreciate polite and constructive answers.

Agile manifesto:

i) Individuals and interactions over Processes and tools.
Individuals = conflicting interest, conflicting visions, different capacity, egos. Why is there no mention of that ?
Interactions = on the fly decisions, inability to research the experience of others, the idea with most followers gets automatically chosen

ii) Working software over Comprehensive documentation
Working = it works today, what about its technical debt ? What about its efficiency ? What about its modularity ? Why is there no mention of that ?
Documentation = straw man fallacy. How stupid needs one be to compare software with documentation ? Why don't they compare working software with free of bugs software, or with durability optimized software, or with cheap but buggy software ?

iii) Individuals and interactions over Processes and tools
Individuals = conflicting interest, conflicting visions, different capacity, egos. Why is there no mention of that ?
Interactions = on the fly decisions, inability to research the experience of others, the idea with most followers gets automatically chosen.

iv) Customer collaboration over Contract negotiation
Client has conflicting interests and vision with software firm and developers. Thus client cannot be best friends with dev. Why is there no mention of that ?
What about conflict situations and unpredicted difficulties ?
Who is responsible for what and who gets blamed for failures ?

v) Responding to change over Following a plan
Plan means initiative + research + agency + purpose. Why is there no mention of that ?
Responding = passive + lack of ownership. How is that better ?
What causes this change ? What sort of change are you talking about, Obama ?
Where is the big picture and who has the general vision when this change happens ?
Following = someone else is responsible for that plan. Responding = someone else is causing your actions yet you are responsible for the outcome.

“That is, while there is value in the items on the right, we value the items on the left more.”
Not enough courage to claim that the things on the right are of less value (to them) than the things on the left
How much more value is one item on the left is worth than one on the right ? left = 101% right or left = 237% right ?
How much value ? How is this relevant to our daily work ?


The 12 agile principles:
1) “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Really ? I thought our highest priority was to make profit.
Satisfy ? What if he is happy now and in 2 months realizes the code has tons of bugs, is he still satisfied then ? Does the customer know when he is satisfied today that he will not be mad tomorrow ?
Early ? What if after the delivery we have to delete code to make room for new functionality ?
Valuable ? By what metric is this value measured ?

2) “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. ”
What costs does this change bring with it ?
- code written now is deleted later
- code with not be isolated in independent, isolated, tested modules
- nobody will have the big picture, as there is none
- all design (and code written) will cost 30% more as it will be written to be easily changeable

Change has costs thus it is a huge business disadvantage. Claiming it brings an advantage is a false cause logical fallacy.
Compared to nothing one can pretend change is good. Compared to early clearly defined requirements this change means failure.

3) “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. ”
What happens to the delivered software ? Who maintains it and with what cost ?
Why is working software done fast cheaper than solid software done slower ?
There is no optimization for producing better software, nor a mechanism to prevent bad software.

4) “Business people and developers must work together daily throughout the project. ”
Why do you think developers are not business people ? They at least own a business that brings them a paycheck.
Developers will spend time to learn the business and business people will spend time to learn coding ?
If it is just one sided, business people micromanaging developers, who pay for all the wrong technical decisions taken by a business person ?

5) “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Different people are motivated by conflicting interests.
Trust developers by having them give daily reports ?
All responsibility in case of any kind of failure now falls on the developers.

6) “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Was there any study done on this ?
Emails force one to organize his thoughts, research his ideas, and are easy to remember.
Conversation forces people to take on the spot decisions and to adopt opinions without previously researching them.

7) “Working software is the primary measure of progress.”
Why not good/maintainable/robust/readable software ?
What is progress ? It clearly is not a better product in this scenario.
If that is the primary, what are the second and the third measures ?

8) “ Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
How does it promote that ? Whose job is it to say “team you are working too fast and too good, it is not sustainable”.
Constant pace means slow pace to make up for the various issues and difficulties that randomly arise.

9) “Continuous attention to technical excellence and good design enhances agility. ”
What does attention mean, and how is it measured ?
Why is agility a goal in itself ?
What are the costs of continuous attention ?
The blame for lack of technical excellence falls solely on developers, in this perverted religion.

10) “Simplicity -the art of maximizing the amount of work not done- is essential. ”
Essential for whom ?
Who gets rewarded for simplicity ? Who gets punished for lack of simplicity ?
Does delivering nothing gets rewarded because it achieves maximum simplicity ?
Simplicity in coding and design means doing a lot more work - not less.
Why do you lie about the definition of simplicity, so that people believe they will o less work ?

11) “The best architectures, requirements, and designs emerge from self-organizing teams.”
This means responsibility falls on the team, and rewards fall on the one who created the team.
Who performed that study ? What metrics did they use ?
What about the best maintenance, testing, code review and development time, do they also emerge from self-organizing teams ?

12) “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
At what cost ?
Who is to blame when tuning does not produce increased efficiency ?
How do they measure their efficiency in order to reflect upon it ?
How can one member reflect on what some other member does without knowing his job ?
How do you enforce that all members reflect equally and not just some few ?

What Agile promises
To clients:
- more productivity at the same cost
- constant reports and surveillance of devs
- change specifications without much costs
- sole focus is on clients immediate needs not on long term technical excellence
- make plans without needing to have a room for error
- the scrum master has the nasty job of punishing employees
- process matters and not individuals
To devs:
- less work
- more decisions are taken by them
- less surveillance from clients
- more room to express their creativity
- more focus on long term technical excellence
- individuals matter and not the process

Who pays for Agile ?
Devs become interchangeable cogs - at equally low paychecks: see the attached paycheck comparison graph.




Picture1.png
[Thumbnail for Picture1.png]
 
Ranch Hand
Posts: 417
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator
I have always took agile with a grain of salt, a little like I take the cloud.
 
author
Posts: 23835
140
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:
I have over 10 years in the industry, yet only today I got to read that agile manifesto.



Please quote your sources -- ie. there is a big difference between the official source, and some out of work engineer looking to blame someone/something.

Henry
 
Sheriff
Posts: 13559
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Report post to moderator
Much of what OP writes here are argumentative, loaded, leading questions and indicate a great number of misconceptions about Agile development and the concept of "agility". Many of the "questions" seem to be based on invalid assumptions.

For example:

Regarding "Responding to change over Following a plan", OP writes: "Responding = passive + lack of ownership. How is that better?" How does OP even equate responsiveness to passiveness and lack of ownership? This post is pure nonsense.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Henry Wong wrote:

Lucian Whiteman wrote:
I have over 10 years in the industry, yet only today I got to read that agile manifesto.



Please quote your sources -- ie. there is a big difference between the official source, and some out of work engineer looking to blame someone/something.

Henry



Is this some sort of joke ? The agile manifesto + 12 principles appears in every single Agile book ever written.
Manifesto: http://www.agilemanifesto.org/
Principles: http://agilemanifesto.org/principles.html

I am pretty sure anyone at least familiar with Agile is expected to know of these things.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Junilu Lacar wrote:Much of what OP writes here are argumentative, loaded, leading questions and indicate a great number of misconceptions about Agile development and the concept of "agility". Many of the "questions" seem to be based on invalid assumptions.

For example:

Regarding "Responding to change over Following a plan", OP writes: "Responding = passive + lack of ownership. How is that better?" How does OP even equate responsiveness to passiveness and lack of ownership? This post is pure nonsense.



Do you have proof or at least arguments to your "argumentative, loaded, leading questions " accusations ?

Regarding your example: responding forces one to be passive and wait for his input, then process it, then and only then react to it (after all that delay). Much worse than having a plan from the start.

Responding to something = you did not create that something = lack of ownership.
Responding to something = you first have to wait for that something to happen = passiveness.



 
Henry Wong
author
Posts: 23835
140
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:
Is this some sort of joke ? The agile manifesto + 12 principles appears in every single Agile book ever written.
Manifesto: http://www.agilemanifesto.org/
Principles: http://agilemanifesto.org/principles.html

I am pretty sure anyone at least familiar with Agile is expected to know of these things.



The links that you provided has none of the interpretations / conclusions from your original post... in other words, the conclusions are yours only. Or do you have more sources that you didn't provide?


Now, I'll admit that not all processes are perfect for everything -- as I have seen them used incorrectly. They are definitely over used in many cases... but using words like "scam", or the language in the original post implies that it is personal.

Henry
 
Henry Wong
author
Posts: 23835
140
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Report post to moderator

Let me put on my moderator's cap for a second.

Lucian Whiteman wrote:
Do you have proof or at least arguments to your "argumentative, loaded, leading questions " accusations ?



If the purpose of this is to debate on how to debate, then fine. It may be a little off-topic, but is still valid. And we can split this off to another topic if needed.

If the purpose of this is to simply continue the language in the original post, or perhaps even escalate it, then it is not fine. Javaranch is a moderated site, and Junilu is a moderator. You know the tone of your original post, and we will not humor the "lack of knowledge of the rules" defense.

Apologies if that was not your purpose. Removing my moderator's cap now.

Henry
 
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator
Considering that your original post in this thread appears to be nothing but personal opinion, you sure are tetchy when other people voice their opinions in opposition of your own.

If you think that the adoption of an 'Agile' style of working replaces the practice of making plans then you have grossly misunderstood what Agile is. Sure you still make plans, how else do you even get started or do anything at all? But you also expect to encounter change, you embrace it. 'Responding' doesn't mean you sit around waiting for some input, it means you do the best with what you know right now but are prepared to change when new knowledge arrives.

I also have to comment on the chart you have presented in your original post which I propose is fiction. What you label as "money that no longer goes to devs" is in reality "company money you wasted because you refused to improve your processes". Do you have some data to back that chart? Some evidence that 'agile' developers get paid significantly less than 'waterfall' developers, especially as you become more senior? I'm curious because this has not been my experience.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Tim Cooke wrote: 'Responding' doesn't mean you sit around waiting for some input, it means you do the best with what you know right now but are prepared to change when new knowledge arrives.



Even so, this still means a lot of waste. There is just no way 'responding' can compete with a plan from the start.

Tim Cooke wrote:
Some evidence that 'agile' developers get paid significantly less than 'waterfall' developers, especially as you become more senior? I'm curious because this has not been my experience.



Surely you are aware that a junior is paid less than a senior. And 'interchangeable cogs' means you become a senior in 20 years instead of 10.
 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator
Does that mean you should stick to the plan no matter what? Even if the knowledge you had when you made the plan turns out to be wrong? Even if the customer made a mistake in their requirements? Even if you find out later you made a bad plan? How do you manage these unforeseen events with an "upfront plan at all costs" approach?

There are so many things that can and often do happen throughout the lifetime of product development that you just can't predict. Expecting something to go wrong and being prepared to deal with whatever that may be is the foundation of an 'agile' style.

If you fancy a read then I recommend Ron Jeffries' "The Nature of Software Development". As one of the original signatories of the Agile Manifesto, Ron presents in this book a set of processes and practices that together he believes make an effective way to write software in a team. It's presented as stuff that makes sense to him and he's observed to work well, which just happens to form the foundation of the manifesto. It's worth a read if you want to see what 'agile' is all about without the hype.

I surely am aware that a junior is paid less than a senior. No dispute there. However, I will dispute that two engineers of roughly equal experience, skill, and ability, will have vastly different earning potential based solely on the software development process they work with.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Tim Cooke wrote:Does that mean you should stick to the plan no matter what? Even if the knowledge you had when you made the plan turns out to be wrong? Even if the customer made a mistake in their requirements? Even if you find out later you made a bad plan? How do you manage these unforeseen events with an "upfront plan at all costs" approach?



Surely having a plan from the start will have its drawbacks, but are you really thinking about claiming that Agile is better ?!
 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator
I'm not saying that Agile doesn't require you to plan from the start. So what do you think I'm claiming Agile is better than?
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Tim Cooke wrote:I'm not saying that Agile doesn't require you to plan from the start. So what do you think I'm claiming Agile is better than?




Let me explain a bit more clearer for everyone else. For purposes of debate I shall give numbers to my assumptions. Feel free to contradict me or approve with me:

1) Nobody is born knowing everything about java or IT
2) Learning something new takes time. There is a time cost that is always > 0.
3) A project takes a finite amount of time, from its day 1 to last day. Thus it takes N days (including weekends).
4) The only time you learn things while physically being at work are the times you physically are at work.
5) The time you are at work (working on that project) is less than those N days.
6) Hopefully by now we have established that the amount of time to learn, during the project you are working on, is finite (<= N days).
7) If there is more than 1 person in the team then each person int the team will work on something else in a certain given moment.
8) Since no 2 atoms can be in the same place at the same time, no 2 persons can do the same thing at the same time. For all the 'debaters' out there: if I press the button 'a', and my colleague presses that same button 'a' at the same moment, there are 2 different buttons pressed. No semantics disagreements to claim that 2 persons can work on the same thing at the same time.
9) The project will thus have N * P man days, where P = persons working on it.
10) Out of those N * P man days only N are mine.
11) Out of those N*P parts(slices of work) of the projects I can and will only do N or less.
12) If we choose parts at random I will learn some stuff about those parts. Thus if there are X fields of knowledge (who require equal work on) that can be learned in this project, I will only have N/X man days to learn about each.
13) If I only get to do the stuff regarding X, I will then have N man days for that field X and 0 for others.
14) Thus someone using Agile and being an "interchangeable cog" will know way less about X than someone who does only X.


Do you agree with me thus far ? Can you all see that the programmer pays a huge price for being an "interchangeable cog" , namely the price of not learning as much programming in those man days he puts in a project ?


15) How much less do I know about field of knowledge X if I only put in N/X compared to putting in N man days on it ? Here is something interesting, if you have a field of knowledge that required A days to become a beginner, B days to become intermediate and C days to become an expert, and C = 10* B and B = 10* A, and B is bigger than N/x then you will never be more than a beginner in A, and sometimes a lousy beginner.

This is why I say that Agile keeps you in a perpetual state of being a junior or at best intermediate in regards to some subjects. A well rounded junior, but still a junior, receiving the pay check of a junior.






 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator
I guess we're done talking about the false proposal that Agile precludes planning? Have we now moved on to another false proposal that Agile hinders your professional development?

Your analysis is a little confusing in places because you introduce X as a number as in "X fields of knowledge" and then go on to reference it as a field of knowledge as in "stuff regarding X". But I get what you mean.

Let's take my work as an example. I work with electronic trading systems. If I were to follow your proposal for progressing my career quickly would I have to focus on a small part of the product only to do so? Should I focus all my efforts solely on the part of the system that sends email notifications to our customers, say? Should I avoid gaining knowledge on all other parts of the system because it would cause me to be less skilled in the email sending part?

Which engineer do you think is more valuable to a company: The guy who knows everything about the email sending part of the system? Or the guy who has a broad understanding of the entire system and its interactions within the larger ecosystem of a trading platform? Which guy would you promote first?
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Tim Cooke wrote: Have we now moved on to another false proposal that Agile hinders your professional development?



Until you have proven my proposal is false, you should not be hasty to proclaim it as so.

Tim Cooke wrote:
Let's take my work as an example. I work with electronic trading systems. If I were to follow your proposal for progressing my career quickly would I have to focus on a small part of the product only to do so? Should I focus all my efforts solely on the part of the system that sends email notifications to our customers, say? Should I avoid gaining knowledge on all other parts of the system because it would cause me to be less skilled in the email sending part?



You are deliberately being misleading. Maybe you fail to see that investing 10 consecutive days into learning all about that email system is more efficient than spending 20 days each separated by 2 weeks apart.

Maybe you fail to see that investing 10 consecutive days in A (the email system), then 10 consecutive days in A2, then 10 in A3, ..., and finally 10 consecutive days in A10 - is much better than investing 1 day in A1, then 1 day in A2 then 1 day in A3,..., then 1 Day in A10 then again 1 day in A1 and so on.

I never claimed you work on a single subject. I did claim that you work on more subjects, but you first get good with the first one then and only them move along. Stop trying to claim I said otherwise and please use real arguments.

Tim Cooke wrote:
Which engineer do you think is more valuable to a company: The guy who knows everything about the email sending part of the system? Or the guy who has a broad understanding of the entire system and its interactions within the larger ecosystem of a trading platform? Which guy would you promote first?



Obviously the one that knows all about the email system is more valuable than the one with moderate knowledge of the entire system, and both of them are more valuable than the one with little knowledge of the entire system. At least this is what their pay checks say.
 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:Until you have proven my proposal is false, you should not be hasty to proclaim it as so.


You have not proven that your proposal is true either so you have no grounds to dismiss others' opinion on the matter.

Lucian Whiteman wrote:Maybe you fail to see that investing 10 consecutive days in A (the email system), then 10 consecutive days in A2, then 10 in A3, ..., and finally 10 consecutive days in A10 - is much better than investing 1 day in A1, then 1 day in A2 then 1 day in A3,..., then 1 Day in A10 then again 1 day in A1 and so on.


I don't disagree with that. I have not said anything in opposition, nor does it have anything to do with Agile, or Waterfall, or any other method of working.

Lucian Whiteman wrote:Obviously the one that knows all about the email system is more valuable than the one with moderate knowledge of the entire system, and both of them are more valuable than the one with little knowledge of the entire system. At least this is what their pay checks say.


Really? That has not been my experience.

Lucian Whiteman wrote:You are deliberately being misleading ... Stop trying to claim I said otherwise and please use real arguments


I find your responses quite argumentative and I have a mental image of us having this conversation where you are almost shouting with anger that I'm not falling over myself to agree with you. You say "Feel free to contradict me" but you don't really mean it. Any time an opposing view has been offered, you seem offended that a person can be so dumb to not see the brilliance in your argument.

Your attitude in this thread is: "Here is a bunch of my personal, unfounded, and unsubstantiated opinions on the Agile Manifesto. Prove me wrong else accept them as true".

It is worth remembering that when you bring a heavily opinionated argument to a public forum, you're going to get opinions in response. The burden of proof is yours, not ours.
 
Junilu Lacar
Sheriff
Posts: 13559
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:
8) Since no 2 atoms can be in the same place at the same time, no 2 persons can do the same thing at the same time. For all the 'debaters' out there: if I press the button 'a', and my colleague presses that same button 'a' at the same moment, there are 2 different buttons pressed. No semantics disagreements to claim that 2 persons can work on the same thing at the same time.


This is a perfect illustration of the attitude that Tim points out. Your literal interpretation of "working on the same thing at the same time" has nothing to do with the collaborative nature of agile software development. On my teams, we do pair and group programming all the time and the software we produce through this practice is far more superior to the software that any single developer on our team working solo can produce.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Junilu Lacar wrote:

Lucian Whiteman wrote:
8) Since no 2 atoms can be in the same place at the same time, no 2 persons can do the same thing at the same time. For all the 'debaters' out there: if I press the button 'a', and my colleague presses that same button 'a' at the same moment, there are 2 different buttons pressed. No semantics disagreements to claim that 2 persons can work on the same thing at the same time.


This is a perfect illustration of the attitude that Tim points out. Your literal interpretation of "working on the same thing at the same time" has nothing to do with the collaborative nature of agile software development. On my teams, we do pair and group programming all the time and the software we produce through this practice is far more superior to the software that any single developer on our team working solo can produce.



My good man, this is the example of your dismissive attitude. You claim that "software we produce through this practice is far more superior to the software that any single developer on our team working solo can produce".

This has zero relevance to the topic ! Sure you will write better code if someone is sitting next to you and gives you and extra opinion about it, nobody ever claimed otherwise. Yet this has nothing to do regarding my question about Agile being a scam.

In order for your example to have relevance to the topic, you must take a team working in pairs using agile, and another one working in pairs without agile, then compare the 2.
 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:... my question about Agile being a scam.


Would you mind clarifying exactly what your question is please? Mostly what I'm seeing here is a vigorously defended opinion.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Tim Cooke wrote:

Lucian Whiteman wrote:... my question about Agile being a scam.


Would you mind clarifying exactly what your question is please? Mostly what I'm seeing here is a vigorously defended opinion.



My initial question:
How much money does each programmer loses daily (through lower wage and lower opportunity) because of the Agile scam ?

Further questions:
How much of that money goes to the Agile "coaches" and how much does it go elsewhere ?
Who are the ones who betrayed us and profited out of this scam ?
How can we punish the ones who robbed us through the Agile scam ?
How can we make sure such scams never occur again ?
 
Junilu Lacar
Sheriff
Posts: 13559
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:
In order for your example to have relevance to the topic, you must take a team working in pairs using agile, and another one working in pairs without agile, then compare the 2.


It is difficult to be objective with that kind of comparison. Comparing work done by developers on one team to work done by developers on another team is like comparing apples to oranges. In fact, when you suggest making that kind of comparison, it seems to me that you are treating programmers like equal and interchangeable cogs in a machine, something which agile definitely recognizes that they aren't.

I do, in fact, have a basis for comparison on the projects that I work on because from time to time, some of the code that is written is done through solo effort. This might happen for several reasons such as unavailability of other team members for pairing or a relatively small estimated effort involved, etc. However, since I am quite a stickler for doing code reviews, when I review code that has been developed via solo effor, there are invariably things that we need to refactor to improve the quality of the code. When we do pair or group programming, the code review is built in and refactoring happens as the code is written. This is how I can say that collaborative development generally produces better quality software. The other advantage of the collaborative development encouraged by agile techniques is that a common understanding of the code and design is naturally developed through the process, something that takes more time and effort to garner on projects where development efforts are less collaborative.
 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:How much money does each programmer loses daily (through lower wage and lower opportunity) because of the Agile scam ?


I believe that programmers don't earn less money and have less opportunity when working in an 'Agile' environment as opposed to some other environment.

Obviously you believe this to be true, so can I ask you to substantiate your claim with some evidence? Some real proof that this is true?

Lucian Whiteman wrote:How much of that money goes to the Agile "coaches" and how much does it go elsewhere ?


Not all companies using Agile have dedicated coaches, sometimes it's a shared role rather than a dedicated title.

My question to you: Using waterfall, how much money is spent building product features the customer doesn't need before you find out they explained it badly at the beginning?

Lucian Whiteman wrote:Who are the ones who betrayed us and profited out of this scam ?


Lucian Whiteman wrote:How can we punish the ones who robbed us through the Agile scam ?


Lucian Whiteman wrote:How can we make sure such scams never occur again ?


To answer these would be to acknowledge that Agile is a scam, which I don't.

Where's the scam? Who profits? Who is exploited? Explain how? Explain why?
 
Junilu Lacar
Sheriff
Posts: 13559
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Report post to moderator
There is a legitimate consideration to make about consultants who offer coaching and training services at very high hourly rates. There are also many who hawk their own "system" of Agile, especially when you are talking about "enterprise Agile" -- Scaled Agile Framework (SAFe) and the like come to mind. The community is quite divided about this and rightly so, IMO. There are those, myself included, who think that many organizations are being taken for a ride at worst and ill-advised at best in taking on consultants who propose things like SAFe. Agile is difficult enough as it is with small teams and it becomes exponentially more difficult at the enterprise level when you have a number of immature teams in the mix. I would wager that the rate of failure is higher than the rate of success. Consultants, however, will generally still get paid no matter what the outcome of the Agile adoption effort.

This doesn't, however, constitute some kind of "scam" although I concede that it's not entirely unjustified to perceive it as such. Most of the agile proponents I know are sincere in their desire to help teams improve and do better. Still, caveat emptor - let the buyer beware. Proper education and setting reasonable expectations is key to avoiding disappointment and disillusionment about Agile. Nobody ever said that Agile is easy and people who say that Agile is absolutely better than anything else probably is selling something. Always look for the qualifier if you're the buyer and if you're pushing Agile, always try to qualify your statements. Agile may not be the best thing ever, but it certainly has the potential to make a difference for the better if you understand and execute it properly.

Edit: Lastly, I find it better if you think of Agile as more of a mindset and a way of being rather than a "thing" that you follow or do.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Tim Cooke wrote:

Lucian Whiteman wrote:How much money does each programmer loses daily (through lower wage and lower opportunity) because of the Agile scam ?


I believe that programmers don't earn less money and have less opportunity when working in an 'Agile' environment as opposed to some other environment.



In every country there are sites that show the average paycheck of java developers. Take a look at 10 companies usign agile and 10 using waterfal - for all levels begginer/medium/senior the paychecks are the same !!!


Now open you eyes and ask yourself this: if I as an agile developer need twice as much time to become a senior compared to me working using waterfall, how much money does that cost me ?
 
author & internet detective
Posts: 39396
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:Now open you eyes and ask yourself this: if I as an agile developer need twice as much time to become a senior compared to me working using waterfall, how much money does that cost me ?


I read the entire thread and don't see where this assertion comes from. Why do you believe it takes an agile developer twice as much time to become a senior developer?
 
Ranch Hand
Posts: 789
Python C++ Linux
  • Mark post as helpful
  • send pies
  • Report post to moderator
Where did Picture1.png originate? It's a classic hokey sales device - the graph with no scale. Experience could be 100 years, and $ could be one penny.
 
Sheriff
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:Take a look at 10 companies usign agile and 10 using waterfal - for all levels begginer/medium/senior the paychecks are the same !!!



Right. So that does demonstrate that programmers don't earn less money when working in an 'Agile" environment, as Tim said. I don't know how you interpret that statement as a contradiction of what Tim said.

Or at least it would demonstrate that if it were true. In most places it would be extremely difficult to survey 10 companies and find out what their salary ranges were and what development styles they were using. Practically impossible, really. But do you have an actual example of that from some country?
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Jeanne Boyarsky wrote:

Lucian Whiteman wrote:Now open you eyes and ask yourself this: if I as an agile developer need twice as much time to become a senior compared to me working using waterfall, how much money does that cost me ?


I read the entire thread and don't see where this assertion comes from. Why do you believe it takes an agile developer twice as much time to become a senior developer?



In SCRUM each developer is an "interchangeable cog". Thus you get to do repetitive monkey job a lot.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Paul Clapham wrote:

Lucian Whiteman wrote:Take a look at 10 companies usign agile and 10 using waterfal - for all levels begginer/medium/senior the paychecks are the same !!!



Right. So that does demonstrate that programmers don't earn less money when working in an 'Agile" environment, as Tim said. I don't know how you interpret that statement as a contradiction of what Tim said.

Or at least it would demonstrate that if it were true. In most places it would be extremely difficult to survey 10 companies and find out what their salary ranges were and what development styles they were using. Practically impossible, really. But do you have an actual example of that from some country?



Come on ! I know you want to defend scrum, but really ?!

So one guy is a beginner for 5 years (them middle level for another 5, with a greater pay check), and another one is a junior for 10 because he uses scrum. Though both have at first the same junior paycheck, you claim that those 2 earn the same during those 10 years !?

 
Paul Clapham
Sheriff
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:Come on ! I know you want to defend scrum, but really ?!



I'm not defending anything. I just don't like bad arguments.

So one guy is a beginner for 5 years (them middle level for another 5, with a greater pay check), and another one is a junior for 10 because he uses scrum. Though both have at first the same junior paycheck, you claim that those 2 earn the same during those 10 years !?



I didn't claim anything. You're the one making the claims. I asked you to provide some basis for those claims. But instead of doing that, you just made more unsubstantiated claims.
 
Junilu Lacar
Sheriff
Posts: 13559
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:

Jeanne Boyarsky wrote:Why do you believe it takes an agile developer twice as much time to become a senior developer?


In SCRUM each developer is an "interchangeable cog". Thus you get to do repetitive monkey job a lot.



First, Scrum definitely does not treat each developer as an "interchangeable cog" as you claim. I don't know where you got that idea but it's absolutely not true. Don't generalize your bad experiences with what it's supposed to be.

Second, how does your response even come close to answering Jeanne's question?
 
Jeanne Boyarsky
author & internet detective
Posts: 39396
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:In SCRUM each developer is an "interchangeable cog". Thus you get to do repetitive monkey job a lot.


If that's how your team does Scrum, they are doing it wrong. Take a look at this on foruming, storming, norming, etc. When my team gets a new developer, it takes time to gel and reach peak productivity again. If developers were interchangable cogs, someone could just give the new developer code to write and be on their way.

More importantly, everyone on a Scrum team is supposed to be empowered. We all make decisions. We all understand what is going on. This is the complete opposite of code monkey where you are just expected to code and not ask questions.

Lucian Whiteman wrote:So one guy is a beginner for 5 years (them middle level for another 5, with a greater pay check), and another one is a junior for 10 because he uses scrum. Though both have at first the same junior paycheck, you claim that those 2 earn the same during those 10 years !?


So your hypothetical guy manages to go 10 years and hardly learn anything? He should be bringing this up at *every single retrospective* that the team could be doing better. He should be speaking up at sprint planning and the daily scrum. He should be asking to pair with people on interesting tasks. And after a year of that not working, find a new job on a better team.

Let me ask you this: who on your "Scrum" team does the analysis, design and other 'senior developer work." If it isn't the people on the Scrum team, I'm puzzled who is left.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Jeanne Boyarsky wrote:
Let me ask you this: who on your "Scrum" team does the analysis, design and other 'senior developer work." If it isn't the people on the Scrum team, I'm puzzled who is left.



This is precisel my point: " the analysis, design and other 'senior developer work." is what one needs to become a senior, and in a scrum team everyone does an equal little bit of that. Compared to other approaches where one would get to do mostly that (if not only that) once he gathers experience.

Compare 10 months of doing 10% senior developer job and 90% junior developer - this is SCRUM, with another approach where you get to a point where you do 90% senior dev job and only 10% junior.

 
Marshal
Posts: 67275
170
Mac Mac OS X IntelliJ IDE jQuery Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator
I've worked in an Agile environment for my previous 5 jobs. I do 100% "senior dev" work. I'm still not getting your point. You've worked in organizations that implement Agile poorly -- we get that. How is that an indictment of the process when properly applied?
 
Tim Cooke
Sheriff
Posts: 4648
300
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
  • Report post to moderator
I think my takeaway from this thread is that Lucian has developed some incorrect preconceptions about Agile and, alas, is defending them with belligerence.

The extent to which the opinions differ from reality leads me to believe that the OP has either been exposed to an 'Agile' environment done very very very badly, or has never been exposed to it at all in practice. It saddens me to see someone with "over 10 years in the industry" be so dismissive about something they appear to know little about and be so closed to reasoned discussion about it.

I expected more.
 
Jeanne Boyarsky
author & internet detective
Posts: 39396
763
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator

Lucian Whiteman wrote:This is precisel my point: " the analysis, design and other 'senior developer work." is what one needs to become a senior, and in a scrum team everyone does an equal little bit of that. Compared to other approaches where one would get to do mostly that (if not only that) once he gathers experience.

Compare 10 months of doing 10% senior developer job and 90% junior developer - this is SCRUM, with another approach where you get to a point where you do 90% senior dev job and only 10% junior.


I disagree with your conclusion. If nothing else, because it allows one to get exposure to "senior" tasks earlier. Suppose you have a brand new developer on a Scrum team named Mary. Mary just graduated school so is very junior. At sprint planning and the daily scrum she arranges to pair with people on everything because she isn't particularly self sufficient. She quickly becomes a better coder by working with more senior people. She also gets some insight into design and more right away. Now, Tom graduated at the same time as Mary. He works on a waterfall team. He is given a spec and codes and implementation for it. At some point, he masters the junior developer role and gets promoted. Now he starts to see design and the like.

Now fast forward five years where both Mary and Tom are on the verge of getting promoted to "senior" developer. (I think our industry has a problem that we use "senior" so early). Mary has been doing pieces of higher level work for five years.) They both get a new junior developer on the team. Mary has been working on design for five years as a piece of her job. She's been observing someone coaching her and has lots of experience with pairing. She is all ready to start leading someone new through it. Tom is figuring it out as he goes since he is newer to design.

Who is better off? I'm guessing you think Tom. I think Mary.
 
Jeanne Boyarsky
author & internet detective
Posts: 39396
763
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator

Bear Bibeault wrote:I've worked in an Agile environment for my previous 5 jobs. I do 100% "senior dev" work. I'm still not getting your point. You've worked in organizations that implement Agile poorly -- we get that. How is that an indictment of the process when properly applied?


I'm not sure what this "senior" dev work is. I do a mix of things. Some could be done by a junior developer (like coding an implementation for an API). I do it much faster and better, but it could be done by a junior developer. Does that mean I do junior development work?

On my team, we don't happen to have any junior developers at the moment. Everyone on the team has more than 10 years of programming experience. So we don't sit around thinking about what "junior dev" work is. There's work. There's problems to be solved. We do it. We don't sit around making a hierarchy of work. We have had interns in the past. We paired more then. We did more up front analysis so the person could do some work independently. But it was carving out work the person could handle. And we had a junior developer on the team at one point. She needed more explanation and coaching on tasks, but did plenty.

I don't like the term "senior dev work". I like "senior dev skills." A senior developer brings up certain things, thinks more about non-functional requirements/maintenance/future changes, has more vision, etc. And that's something that nobody can take away because you are doing some kind of "lower level work." You do it better and it becomes "senior" work. I think that is a key difference. A senior developer is more likely to say something if asked to do something inefficiently or wrong. A junior developer is more likely to just do it.
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Likes 1
  • Mark post as helpful
  • send pies
  • Report post to moderator
Guys and girls: you are simply wasting my time.

I wrote this post to ask people how they react to the scam that agile scrum is, and most of you keep on claiming that I am wrong to say agile scrum is a scam.Please post here only if you believe , like I do, that it is a scam and harmful to developers. If you do not believe than then stop posting here as you are only trolling me.

There are plenty of consultants that get rich by preaching agile scrum as a religion. It is only normal for them to go on the internet and claim agile is not a scam whenever someone asks about it.


Take a look at this post: a lot of people repeating the same words "it is not a scam, you are not just doing it right". None of them bother to actually consider who pays for the consultants salaries and why so many managers are too eager to change to agile. Where does this extra money and productivity comes from ? I say it comes out of developer having lower paychecks and working overtime, yet you do not even acknowledge this.

Admins start doing your job please !
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator

Jeanne Boyarsky wrote:
I'm not sure what this "senior" dev work is. I do a mix of things. Some could be done by a junior developer (like coding an implementation for an API). I do it much faster and better, but it could be done by a junior developer. Does that mean I do junior development work?



Yes it does ! That pretty much is the definition of it.

Jeanne Boyarsky wrote:
On my team, we don't happen to have any junior developers at the moment. Everyone on the team has more than 10 years of programming experience. So we don't sit around thinking about what "junior dev" work is. There's work. There's problems to be solved. We do it. We don't sit around making a hierarchy of work. We have had interns in the past. We paired more then. We did more up front analysis so the person could do some work independently. But it was carving out work the person could handle. And we had a junior developer on the team at one point. She needed more explanation and coaching on tasks, but did plenty.



This is why someone who only does senior work is much more better than you. And has a much higher paycheck.

Jeanne Boyarsky wrote:
I don't like the term "senior dev work". I like "senior dev skills." A senior developer brings up certain things, thinks more about non-functional requirements/maintenance/future changes, has more vision, etc. And that's something that nobody can take away because you are doing some kind of "lower level work." You do it better and it becomes "senior" work. I think that is a key difference. A senior developer is more likely to say something if asked to do something inefficiently or wrong. A junior developer is more likely to just do it.



Wrong. During the hours you are doing junior dev work you are simply doing junior dev work. Hire a junior for that because his time is much cheaper.
 
It is sorta covered in the JavaRanch Style Guide.
    Bookmark Topic Watch Topic
  • New Topic
Boost this thread!