Over the past number of years as a Software Development Manager and Leader I have noticed a troubling trend. More and more software development companies are setting up development structures that have NO software development manager position. A large part of this I think is because of the advent and growing acceptance of "Agile" processes. Whether a company formally calls their development process that or not is irrelevant - that is how they actually work.

What I have noted is that software development teams are essentially managed day to day by a scrum master who is really little more than a glorified secretary and who in general reports to a Project Manager or Product Manager. These two 'PM' positions then report to the Head of Product Management or the Head of Marketing or sometimes Sales. (Don’t get me wrong, I have nothing against secretaries or administrative assistants. In many cases, in fact, they are some of the most valuable people in any organisation - but they shouldn’t be managing software development teams.)

The Agile process has been bastardised (or maybe that is actually its intent) into being a process with no actual day to day management or responsibility. It is now simply a process whereby Marketing and/or Product Management and/or Sales and/or the CEO constantly throw new requirements and new feature/functionality or constantly change existing architecture or design or functionality at the whim of the customer, at the "agile" development team who are expected (they are 'agile ' after all) to be able to react on a moment's notice.

There is certainly no proper requirements review, certainly no design or functionality review, and certainly no code review or proper software test engineering.

This also makes recruitment very easy for companies - no need to have experienced software development managers who can judge and find good people. HR just finds people who have the proper set of acronyms on their resume and the word 'Agile', subject him or her to some standard stupid test about wine bottles or piano tuners or sea urchins or some such thing, and - BINGO - 'agile developer' hired.

The other popular alternative is to just outsource to a bunch of 'agile developers' you have absolutely no control over in some offshore country where the developers can't even speak or write English - which of course isn’t their fault because they were never taught or expected to speak or write proper English anyway. Since these new people are all ‘Agile’ there should be no problem sticking them into any ‘Agile' Team. (And of course they will do the job for 1/3 or 1/4 the price of on-shore developers.)

Of course, there is absolutely NO long term planning, no long term defined deliverables, no schedules in place, and no possible way to manage off-shore resources - that would require actual Management and a REAL Manager.

So every day the Scrum master hears all kinds of excuses for why the sprint isn't where it should be and of course introduces more 'requests' from Product Management and Marketing to be done ASAP because a customer is asking for it. (I know that's NOT how Agile is supposed to work but you know the truth.) What happens ? Features and Functionality constantly morph and schedules constantly get ignored as ‘sprints' are revised.

There is no Software Development Manager to manage and stick up for the developers and they go ahead blindly. Typically the deliverable eventually produced is nothing like what it started out to be and the quality is pure and total CRAP. Unadulterated CRAP goes out the door and it’s behind schedule, over budget, designed by nobody except for PM and Marketing and Sales lists of 'need to haves' and 'nice to haves' (and of course none of three departments EVER talk to each other to even notice that some of their "needs" and "nices" are functionally incompatible).

Then of course the customers start to complain and since there is no proper Software Maintenance Team separate from the actual software engineering team the good developers (few as they are) get pulled off literally 10 times a day to fix customer problems.

So they spend 8 hours a day fixing problems that, had there been proper software development management, would never have gotten in the product in the first place. Of course if you spend 8 hours a day problem shooting you only have another 4 - 6 hours each day to actually do any development. And since you are a 'professional' you sure better not complain about 12 - 14 hour days for months on end because they can always find somebody with the right acronyms to replace you.

So you don't get your development tasks done on time and you tell the scrum master who, after all, is an agile expert (without a single iota of knowledge of management) and the sprint gets changed and blah blah blah. This of course pisses off any good developers you have and they quit, meaning HR now rushes out and finds a whole bunch more acronyms. Now there is nobody around who is aware of the product's history, legacy, and whatever design / functionality tradeoffs were made and - BINGO - now we have to totally redo the entire 'Sprint' etc. and on and on and on.

The result is a TOTAL UNMITIGATED RECIPE FOR DISASTER.

There is a severe crippling and potentially fatal malaise creeping into all the software we are putting into the millions of products we use everyday. Unless we get back to actually MANAGING software development and doing so with good, experienced managers instead of pretending that we are being very 'responsive' and 'agile' in our development process, we will destroy much of our technology base - now mind you, we will be very agile in finding new ways to destroy it but it will all end up as nothing more than CRAP on a stick anyway.

There are many, many companies, reports, studies, government analyses saying that Canada is severely lacking in numbers and quality of software development professionals. So what do we do? The government puts programs in place to make it even easier to hire off-shore acronyms. They are all making one HUGE fundamental mistake.

It is REALLY TOO BAD that everybody seems to think it's better to be an "Agile" company rather than a "Managed" company.