When professional managers weaseled their way into Agile, I demoted the word to low-case “agile.” Everything I read in the beginning cried out, “professional developers work better without non-technical oversight.”
The way the manifesto writers sought to accomplish this was through elimination of the middle manager and inclusion of the “owner,” and the creation of the “self-organized team.” Even my target of All Microsoft Hatred, Steven Sinofsky (okay, I hate Steve Ballmer, too) said that middle managers become bottlenecks. And for a manager to say that means something. (Something evil, I’m sure.)
The twin problems of software development are these: 1) there are too few people who can produce good code and workable applications; and 2) there’s too much money that can be thrown at software development.
Back to the 1820s
Business owners and MBAs have all been taught that when production must be increased, you do one or all of several things. Among these things are a) extend the production shifts, b) increase the number of production lines, and c) hire overseers who will threaten or otherwise motivate the line(s).
The twin problems of software development are these: 1) there are too few people who can produce good code and workable applications; and 2) there’s too much money that can be thrown at software development.
Software is not built this way. Software is built by dedicated, intelligent, knowledgeable, motivated, passionate, experienced, people who are articulate in the software platform and eloquent in the business domain.
Kent Beck was probably the most correct in his theoretical approach to software development with his technique he called eXtreme Programming. XP teams do remarkable things.
The modern groups (those who claim to eschew the waterfall methods) who fail most often are the ones who employ some corruption of agile; like Scrum. This is because the fewer managers you have, the closer the developers are to the guy asking for and paying for the software, the more likely you are to succeed.
The fly in the software ointment is the problem stated earlier: Software is built by dedicated, intelligent, knowledgeable, motivated, passionate, experienced, people who are articulate in the software platform and eloquent in the business domain.
There are far too few of these. At the same time, there are far too many MBAs who disbelieve this rule and think the way to handle the staffing problem is to revert to the manufacturing solutions that didn’t even work well in the 19th century.
Managers in Software Development
It has come to the morphological point that we now argue about where to put the middle-manager and what to call him so we won’t irritate the producers too much. But the producers are still keenly aware of the subterfuge and painfully offended at the display of distrust and demotion each additional middle-manager represents.
All the while software development is still a peculiarly individualistic endeavor; and unlike just about anything else ever seen in business or production, the success or failure of a software development team still comes down to the quality of each individual and the utility that each brings to the team.
The oddity of software development is this: when a team or individual slows down, it flags a logical or architectural problem in the design.
Upper-case-A Agile removes the titles and calls the software team a Team. It implies that any of the team could, if called, perform any of the duties. Of course, because of individuality, one would be better on the ORM and another better on the interface, but any of the team should be able to do any of the tasks.
General Alfred M. Gray, Marine Commandant, says, “Every Marine is, first and foremost, a rifleman.” In the same way, every Agile Team Member should be a developer, first and foremost.
But this is not true of the manager. Upper-case-A Agile has a different role/title for the product owner and the sponsor but there exists, nowhere in the original definition of upper-case-A Agile, the role of manager. That is because Agile demands the “self-organizing team.” No managers need apply. If you can’t qualify on the code range, you can’t be an Agile Team Member.
When production slows down, though, “Management” just throws in another manager to get production back to normal. But this is the greatest failure of modern business in their misunderstanding of software development.
It’s a sign, not a problem
The oddity of software development is this: when a team or individual slows down, this is not a problem. It is an indicator that something is wrong. When a dedicated, intelligent, knowledgeable, motivated, passionate, experienced developer slows down or stops, s/he subconsciously flags a logical or architectural problem in the design. Rather than find some whip or prod to spur the developer toward faster production, such a slow-down should spawn a group-slowdown and a team discussion to find the real source of the problem.
A middle manager would not know about this. And only an experienced developer who had seen it a hundred times would recognize it when it happens. To everyone else it looks like a lack of focus or a production problem. To the senior developer, it looks like a clear sign that something’s wrong with the code — that questioning the code, not the process, may avoid trouble. Sensitive reaction to this kind of production slow-down can head off terrible, terrible trouble in the near or distant future. Frankly, the whole project could be on the line.
Managers who ignore these signs — or worse, misinterpret them — should be banished from any software team. The VP In Charge Of Something Important can find somewhere else to employ his brother-in-law. I’m sure Operations needs someone with an advanced degree in Theater.