Ahmad Nassri

> "Scrum/agile was developed in the context of code written for a client that is expert in the problem domain but ignorant of software by a development team inexpert in the problem domain but expert in software."

and if it stayed in that domain, then I wouldn't have a problem with it. leave it in the service industry (a place I don't want to be, or encourage anybody to use as an approach to build software)

Instead it's sold as a method for "Product Teams" everywhere, where that statement about the "customer" is simply not true, hence the opposition to the practices it follows.

> "Most foss projects are infrastructure, utilities and middleware where the end-users are usually tech people (and often the developers themselves are the initial users). Scrum can never fit here."

while statistically you might be correct, realistically though, the largest projects are in fact consumer facing projects. have you heard of Android? Linux (Ubuntu, Redhat, etc ..)? Open Office? I can name many, many more, softwares for all industries, we use everyday.

Yes, there are tons of Libraries, Middleware, Utilities, etc ... which in turn power those same user-facing software projects, so your assumptions or exposure to the open source world is quite limited. I'm willing to bet many of the software and hard you use is in fact powered by Open Source (and not on the low level as you claim)

> "We have to select methodologies and evolve our own team-sized development workflows based on the nature and context of the projects we are working on -- in the same way that we (really should) select our development tools based on the nature of the job they are intended to do."

great statement, fully agreed. can we now agree to Scrum being only suited for the agency & service world perhaps? although I believe the Open Development Method can actually benefit that world greatly, but at least agreeing on that point, can perhaps bring us outside of the mud of the debate to focus on the actual reality of software development and creating more value outside of the so called "cult of Agile"?

oh my, where to start...

> "it reminds me of the days when IT thought they were so important, the business couldn't survive without them."

yes, IT is so important modern business can't survive without it. period.

furthermore, Development != IT, you're using dated terminology, IT is now being fully automated and moving to the cloud. Development is the art of building software (including User Experience Design and Product Design) those are important and modern businesses can't survive without them.

Even cow farmers rely on software and technology. this old world mind-set of "assembly line" mentality where business owners expect people to operate in a straight line, with a clear start and end and visible, measurable steps in between simply does not work in the world of technology, a creative skill, not a robotic, repeatable process.

> "Those were the days when projects would run for months without delivering a single feature while groups of developers had intellectual debates about grand frameworks that would save weeks of effort on an hypothetical future"

when you go to your mechanic to fix your car, do you really want him / her to put in the cheapest and fastest to install parts? after all your life depends on this car being safe. a bit of debate on best practices and best solutions is really a debate on saving your life.

but nevermind that, it seems your company (or perhaps companies with this "IT Problem" you're describing, would rather hire cheap un-trained labour, and throw big problems at them, just work as an assembly line? that should do it?

if your team is not skilled or trained, or perhaps suited to solve your problems, no amount of methodology, or process, or super star Agile coaches and Scrum masters can deliver quality out of that team.

A "carpenter" who builds amazing furniture, delivers on time, and with solid results, does not mean they are suited to build a house, or even a summer deck.

> "someone needs to remind the team that there's a mission to accomplish."

I believe you need to hire a team that believes in your mission, and wants to accomplish it with you, not somebody who's in it for the money, so that you have to hire managers and scrum masters to play leader (on something they don't fully comprehend) and whip teams to work harder.

> "but it's up to the Product Owner to decide what to build."

based on what skill set or metrics? how is the product owner, a none-technologist able to choose the best option for the system architecture? or a none-designer, be able to choose best User Experience Design? perhaps they are capable of measuring Business value, with a background in business, or perhaps they are in fact Technical and able to understand the details, but the reality is no one person can cover all aspects. hence Discussion, Transparency and Democracy.