Agile manifesto questions + scam alert

[Tim Cooke]

Lucian Whiteman wrote:I wrote this post to ask people how they react to the scam that agile scrum is

You have gotten your reactions. Just not the bias confirming ones you were hoping for.

Lucian Whiteman wrote: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.

You misunderstand how CodeRanch works. Everyone is welcome and encouraged to post their input to any discussion here. If you wish to have an "agree with me, else be silent" discussion then this is not the place. If you wish to have that discussion I recommend you start your own "Agile is a scam" forum, in which you can make your own rules about what people can and cannot post.

[Jeanne Boyarsky]

Lucian Whiteman wrote: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.

I think most of the posters in this thread are somewhere in the middle. "Agile as a religion" and "Agile as a scam" are two extremes on a continuum. I don't think agile is always right. And in many cases, I think parts of agile (rather than pure agile) are appropriate.

Lucian Whiteman wrote: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.

Most (or all) of the people posting in this thread are not agile consultants. I assure you that I don't preach scrum as a religion nor do I think it is "the one true way." And I don't earn money promoting agile. I do help other teams at work do agile and scrum better when they ask for my help.

Lucian Whiteman wrote: 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.

We never hired an "agile consultant" at my company. And one of they keys with agile that is supposed to reduce overtime. That said, I don't think hiring a *good* process consultant is a waste of money. For example, I showed a team how to move from a (poorly run) 30-60 minute daily meeting to a 15 meeting agile minute. Multiply this by the # attendees and it saves real money. They aren't doing scrum and they shouldn't - it wouldn't work for them. But the process consulting gave them real savings. This was an internal team so I didn't charge them for it. It does show that a small amount of a consultants time can make things better.

Lucian Whiteman wrote:Admins start doing your job please !

Most of the people posting in this thread are moderators. Bear and I are admins. I don't see anything posted in this thread that is inappropriate. You have a position that others disagree with. We are having a discussion about it. Others who find it in a search in the future get to read an interesting discussion about the benefits and drawbacks of agile.

[Jeanne Boyarsky]

Lucian Whiteman wrote:

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.

In that case, I hope I never stop doing what you call "junior developer" work. I don't think it is a bad thing. Let's look at an example:

Suppose you need code that reads a file, removes all the lines the pattern MM/DD/YYYY and writes it back. I think we'd agree this is something a junior developer can do. I can write it in three minutes. (with one more two make it maintainable.) A junior developer is going to take significantly longer. Suppose it takes a junior developer fifteen minutes (which I think is optimistic.) I don't earn five times the salary of a junior developer so it isn't a waste for me to do it. Plus it was fun.

The three minute solution:

Path path = Paths.get("Play-Java/src/jb/nums.txt");
String result = Files.lines(path).filter(l -> ! l.matches(".*\\d{2}/\\d{2}/\\d{4}.*")).collect(Collectors.joining("\n"));
Files.write(path, result.getBytes());

The maintainable refactoring that I spent one minute on top of the existing code.

public static void main(String[] args) throws IOException {
   Path path = Paths.get("Play-Java/src/jb/nums.txt");
   String result = Files.lines(path).filter(l -> !l.matches(regExpForDate())).collect(Collectors.joining("\n"));
   Files.write(path, result.getBytes());
}

private static String regExpForDate() {
   String twoDigits = "\\d{2}";
   String fourDigits = "\\d{4}";
   String slash = "/";
   String anyChars = ".*";
   return anyChars + twoDigits + slash + twoDigits + slash + fourDigits + anyChars;
}

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

That's mildly insulting. Luckily the people I work with don't agree with you. Nor do people in user groups or many other places. I'm glad that I don't work wherever you do that thinks senior developers shouldn't be allowed to do any "easy" tasks.

Lucian Whiteman wrote: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.

No. The junior developer is cheaper because he/she gets less done. Part of this is not having the skills/experience of a senior developer. But part of it is taking longer to get the same work done. See my example above. When I code, I'm MUCH faster that a junior developer.

[Lucian Whiteman]

Jeanne Boyarsky wrote:
In that case, I hope I never stop doing what you call "junior developer" work. I don't think it is a bad thing. Let's look at an example:

What about all the other developers who do not wish to do junior work ? Do you enjoy them being forced by SCRUM to do junior work for way longer than they should ?

Jeanne Boyarsky wrote:
Suppose you need code that reads a file, removes all the lines the pattern MM/DD/YYYY and writes it back. I think we'd agree this is something a junior developer can do. I can write it in three minutes. (with one more two make it maintainable.) A junior developer is going to take significantly longer. Suppose it takes a junior developer fifteen minutes (which I think is optimistic.) I don't earn five times the salary of a junior developer so it isn't a waste for me to do it. Plus it was fun.

There are juniors who do this stuff in 3 hours, and there are juniors who do this in less than 3 minutes. Let us not insult any of them by claiming that it will take a lot of time for all.

Jeanne Boyarsky wrote:
The three minute solution:

Path path = Paths.get("Play-Java/src/jb/nums.txt");
String result = Files.lines(path).filter(l -> ! l.matches(".*\\d{2}/\\d{2}/\\d{4}.*")).collect(Collectors.joining("\n"));
Files.write(path, result.getBytes());

The maintainable refactoring that I spent one minute on top of the existing code.

public static void main(String[] args) throws IOException {
   Path path = Paths.get("Play-Java/src/jb/nums.txt");
   String result = Files.lines(path).filter(l -> !l.matches(regExpForDate())).collect(Collectors.joining("\n"));
   Files.write(path, result.getBytes());
}

private static String regExpForDate() {
   String twoDigits = "\\d{2}";
   String fourDigits = "\\d{4}";
   String slash = "/";
   String anyChars = ".*";
   return anyChars + twoDigits + slash + twoDigits + slash + fourDigits + anyChars;
}

You believe you are better than a junior, yet you format the code way worse than the juniors I teach. My good man(or woman), here is a free formatting lesson for you:

public static void main(String[] args) throws IOException {
   String location = "Play-Java/src/jb/nums.txt"
   byte[] fileContent = getFileContent(location);

   Files.write(path, fileContent);
}

private static byte[] getFileContent(String location) {
   Path path = Paths.get(location);
   ???? filtered = Files.lines(path).filter(l -> !l.matches(regExpForDate())); 
   String result = filtered.collect(Collectors.joining("\n"));

   return result.getBytes();
}

private static String regExpForDate() {
   String twoDigits = "\\d{2}";
   String fourDigits = "\\d{4}";
   String slash = "/";
   String anyChars = ".*";

   return anyChars + twoDigits + slash + twoDigits + slash + fourDigits + anyChars;
}

Jeanne Boyarsky wrote:

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

That's mildly insulting. Luckily the people I work with don't agree with you. Nor do people in user groups or many other places. I'm glad that I don't work wherever you do that thinks senior developers shouldn't be allowed to do any "easy" tasks.

What about the people who agree with me ? Do we not matter ?

Jeanne Boyarsky wrote:

Lucian Whiteman wrote: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.

No. The junior developer is cheaper because he/she gets less done. Part of this is not having the skills/experience of a senior developer. But part of it is taking longer to get the same work done. See my example above. When I code, I'm MUCH faster that a junior developer.

First, let us not insult juniors by claiming they all get less done every single time. Secondly, let us not insult juniors by claiming that whenever junior get the skills needed for a task they still are slower than a senior. I thought racism was not tolerated on this forum. Yet I see this user claiming that a category of people is worse(slower) than another, even if they were to have the same initial skills and training.

[Jeanne Boyarsky]

Lucian Whiteman wrote:What about all the other developers who do not wish to do junior work ? Do you enjoy them being forced by SCRUM to do junior work for way longer than they should ?

I don't think writing "basic" code is junior work. I think it is simply work that people do in different ways/approaches/speeds. And yes, I'd expect everyone on a team to do all "levels" of work. Whether it is a Scrum team or any other type of team, I expect my teammates to be team players. And that means doing whatever is needed to get the project done. I also don't agree that developers *should* stop doing basic development over time. That said, if you want a hierarchy, maybe consulting is a better career option. And even then, some consultants code.

Lucian Whiteman wrote:There are juniors who do this stuff in 3 hours, and there are juniors who do this in less than 3 minutes. Let us not insult any of them by claiming that it will take a lot of time for all.

The junior who can do that in three minutes needs a promotion! He/she is clearly no longer a junior level of coder. Because junior implies less experienced/knowledgable.

Lucian Whiteman wrote:You believe you are better than a junior, yet you format the code way worse than the juniors I teach. My good man(or woman), here is a free formatting lesson for you:

There's many different acceptable coding standards and formats. Both yours and mine are acceptable in different places.

[fred rosenberger]

Lucian Whiteman wrote:

Jeanne Boyarsky wrote:
The maintainable refactoring that I spent one minute on top of the existing code.

public static void main(String[] args) throws IOException {
   Path path = Paths.get("Play-Java/src/jb/nums.txt");
   String result = Files.lines(path).filter(l -> !l.matches(regExpForDate())).collect(Collectors.joining("\n"));
   Files.write(path, result.getBytes());
}

private static String regExpForDate() {
   String twoDigits = "\\d{2}";
   String fourDigits = "\\d{4}";
   String slash = "/";
   String anyChars = ".*";
   return anyChars + twoDigits + slash + twoDigits + slash + fourDigits + anyChars;
}

You believe you are better than a junior, yet you format the code way worse than the juniors I teach. My good man(or woman), here is a free formatting lesson for you:

public static void main(String[] args) throws IOException {
   String location = "Play-Java/src/jb/nums.txt"
   byte[] fileContent = getFileContent(location);

   Files.write(path, fileContent);
}

private static byte[] getFileContent(String location) {
   Path path = Paths.get(location);
   ???? filtered = Files.lines(path).filter(l -> !l.matches(regExpForDate())); 
   String result = filtered.collect(Collectors.joining("\n"));

   return result.getBytes();
}

private static String regExpForDate() {
   String twoDigits = "\\d{2}";
   String fourDigits = "\\d{4}";
   String slash = "/";
   String anyChars = ".*";

   return anyChars + twoDigits + slash + twoDigits + slash + fourDigits + anyChars;
}

I fail to see why either is any better or worse than the other. Can you explain why you think yours is so much better?

[Tim Cooke]

Lucian, have you ever worked in an 'Agile' or 'Scrum' environment?

[Andrew Monkhouse]

Lucian Whiteman wrote:I have over 10 years in the industry,

I have 30. I am a junior compared to some of the people here. Shared wisdom helps us all! :-)

Lucian Whiteman wrote:yet only today I got to read that agile manifesto.

I think this is a great point to start from - since you are admitting that you are new to the agile manifesto, I suspect that some of your misconceptions can be easily corrected.

Lucian Whiteman wrote: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

It is important to realize that the manifesto is not suggesting we do away with the items on the right, or that the items on the left do not happen in other development models.

You have individuals in waterfall, and you have interactions in waterfall. The same problems you mention can also occur in a waterfall environment, however they are often mitigated in waterfall by a "my way or the highway" attitudes - something that can result in bad solutions being developed without consideration for better solutions.

Processes and tools also exist in agile environments. However the idea is that they are considered less important than actually talking with people.

Lucian Whiteman wrote: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 ?

What about technical debt in a waterfall environment? It doesn't matter what process you follow, there will be technical debt. It is up to the company to manage that.

What about efficiency and modularity? There is nothing to say that you cannot be efficient when following agile or waterfall. There is nothing to say that you can, or cannot, write modular code in waterfall or in agile.

It sounds like you have not worked in a documentation heavy company - good for you! I have worked in companies that used the waterfall model, and some of the documentation was amazing. At one company, they had documentation for the project in six large binders before they wrote a line of code. And the documentation turned out to have made some unwarranted assumptions, resulting in reworking of both documentation and coding later.

Again - it is not that documentation should never exist. The authors are simply suggesting that getting the code written is more valuable than writing documentation.

Lucian Whiteman wrote:iii) Individuals and interactions over Processes and tools

You already mentioned this as your first point

Lucian Whiteman wrote: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 ?

The idea here is that we, as developers, should be partners with our clients. We should be working towards a common goal. Contracts still exist, and can define who is responsible for what. Resolution of problems still exist. But the guiding principle is that the customer is a collaborator on the project.

Trying to clearly define who is to be blamed for failure before there is a failure seems to be approaching development from the wrong perspective.

Lucian Whiteman wrote:v) Responding to change over Following a plan
Plan means initiative + research + agency + purpose. Why is there no mention of that ?

Again, there is no suggestion that you should not have a plan. A plan is a good thing. But if you cannot adapt your plan when things go wrong, then you are going to end up in trouble.

Lucian Whiteman wrote:Responding = passive + lack of ownership. How is that better ?

As before, there is a plan. Responding to problems is not lack of ownership.

Imagine if someone was driving down a road, and a child jumps out in front of them. The plan is to drive down the road. Responding to the change means swerving and/or using brakes.

Lucian Whiteman wrote:What causes this change ? What sort of change are you talking about, Obama ?

If we knew everything that could possibly change with the project, then we could cater for it. Can you imagine developing code 30 years ago and being tasked with writing it so that it supports mobile devices? Change happens!

Lucian Whiteman wrote:Where is the big picture and who has the general vision when this change happens ?

The team typically has a decent picture. They are typically working in collaboration with the client, who usually has a bigger picture.

Lucian Whiteman wrote:Following = someone else is responsible for that plan. Responding = someone else is causing your actions yet you are responsible for the outcome.

This feels to me like an antagonistic start to the project - I will do what I am told without worrying about whether it is a failure or not, as it is someone else's plan!

Lucian Whiteman wrote:“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

That is exactly what the "we value the items on the left more" says.

Lucian Whiteman wrote: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 ?

Who cares about precise percentages? The manifesto is talking about a philosophy. Not 1001 rules that must be met exactly.

I'm stopping here for now, but hopefully this gives you some food for thought.