Management needs to stand aside and let Scrum development work its magic
Scrum, when sincerely implemented, has shown repeatedly that it yields much better results than does micro-management, the kind of supervision used on soldiers and most software development teams. And yet, so many companies seem incapable of letting go and letting it work its magic.
So long as companies do not implement Scrum sincerely, Scrum teams will not deliver the promises that Scrum makes.
If you are a developer, ask yourself: do you feel micro-managed? Over-supervised? Or feel like it isn't the most competent person who gets promoted but the most politically popular (i.e., popular with the current management)? That is because the modern management paradigm is based on a system established for not just a political organization but also a military one. In such a system, loyalty and predictability is everything, and one can understand why. But as a result, competence takes a back seat.
The typical manager / employee ratio for most business operations is 1:5 or 6. But why 5 or 6 and not ten? Or three? It has to do with the human ability to keep track of things. Studies show that the typical person maxes out in being able to juggle variables at around a count of 7. This is why many people find restaurant menus a bit much -- too many variables and choices.
Some lines of work do require close supervision, even perhaps a 1:5 ratio. But the bulk of occupations that have a 1:5 or 6 ratio today don't really need that ratio. They can get along fine with 1:10, 1:20, etc. So why do so many organizations still use 1:5 or 6 as a standard? Three reasons:
- Old habits die hard. Humans like their traditions and have trouble letting go, or perhaps no one has seriously questioned this ratio.
- Fear of loss of control. Business owners or higher-level managers often are the kind of people who like to be "in charge". To do this, they need to act in charge, i.e., control something. Creating many subordinate managers helps fulfill this desire.
- Political interests. "Large and in-charge" type people often judge each other and themselves by the size of the pie they control or manage. The more managers appointed to a senior manager who answer to him or her, the bigger their "profile" -- and perhaps likelihood of one day sitting in The Big Chair.
Today, a handful of professions do not use a military management paradigm. Doctors, lawyers, professors at colleges, are all essentially self-managing, i.e., each one practices his or her craft roughly independently after what amounts to lengthy apprenticeships. In a sense, they follow a guild paradigm. Members of this class of workers oversee one another. In the case of doctors and lawyers there is legal accountability for serious misconduct or negligence. For matters not rising to that level, members are held to account via professional association discipline processes.
Recently, the Agile paradigm became popular. Scrum is the name of this process as applied to software engineering. Agile/Scrum applies this professional worker model to software engineers. It acknowledges that software engineers typically are more productive and generate better outcomes for employers when they are treated like professional workers rather than white collar workers. As far as management is concerned, white collar workers are much like blue collar workers except in that they work in an office, not a factory. The military paradigm of close supervision is applied to both blue and white collar workers.
The reason the professional model of organization works so well among software engineers is because, simply put, like doctors and lawyers, the following is true about software engineers:
- They tend to have higher than average intelligence, sometimes much higher.
- They tend to value their reputation and understand that it is important to their employability.
- They tend to be the kind of people who show initiative and are creative -- provided they are allowed to.
- They tend to be self-organizing (again, when allowed to be) and identify and defer to those among them who are better-qualified or more capable, not unlike a guild.
- They tend to be able to work independently of close supervision and still produce value-added results.
The modern economy is filled with examples of highly-relevant and profitable software products and businesses that were started or crafted by software engineers on their own initiative or via independent actions. Blockchain software is a recent example, but entire businesses now exist founded on software that came into being without a managerial class of person overseeing the production process. Only after the innovative software was written, shown to be effective, then commercialized, was a management layer added. Adding management tends to have the effect of slowing down progress in development of new features and bug fixes.
Some product teams have responded by electing not to commercialize their code but instead release it as open-source, inviting other developers to participate. Occasionally an owned product is released into the world for community maintenance, such as with the entire Java language, because even attempting to manage it in the military paradigm sense is ludicrous on its face.
The foregoing is not to suggest management has no role to play in corporate IT. Far from it. It is to point out that Scrum is the response to the fact that the greatest source of IT process failures is not bad programming but instead mismanagement, a challenge that industry seems to have no answer to except to finally treat software engineers as professionals instead of as white collar office workers.
Repeated studies have borne this fact out yet businesses still insist on micro-managing software developers, layering on various kinds of overseers, each with their own ambitions, goals, and agendas. The Scrum plan has been "modified" in many IT departments by management such that so-called Scrum teams are in fact being micro-managed as always. The titles change, there are now daily meetings and sprints, but management simply can't let go. It's no wonder software engineering itself seems to be a secondary if not tertiary consideration in meetings, especially the typical kinds driven by managers or their representatives.
Some companies have implemented Agile/Scrum in actual fact. Many others however have done so in name only. These are called SINO teams: Scrum In Name Only.
Attending a SINO team meeting, one quickly surmises the disconnects between Scrum and SINO. Some things are done: daily meetings, sprint planning, story grooming, etc., but you can spot SINO based on who in fact is running the meetings.
Some questions to ask:
- Is most of the talking being done by people who don't program as a principle duty in fact?
- Are stories being fiated to the team with an insistence that all supplied stories be completed at the end of the sprint, hell or high water?
- Does the team take a beating delivered by someone who doesn't write code but aggregates and reports to superiors?
- Is the team actually genuinely free to manage its own workflow?
- Is the backlog large and imposing, and populated by fiat from outside the team?
- Does the team feel empowered to implement technology and processes as it feels are appropriate or are the technology and processes being dictated by external groups?
- Is the manager:programmer ratio less than 1:10? Assuming here that one manager must be assigned to the team. And is that manager actually adhering to a Scrum manager role?
- Is the manager the permanent Scrum-master or does that role rotate as it is supposed to?
- Does the manager* seem to be driving the meetings?
- Does the manager chastise the team over progress fairly regularly?
Bear in mind, "manager" is anyone who doesn't write code as a primary duty. Actual titles don't change reality but can be used to try to obfuscate it. This is common in SINO groups.
Take stock of your Scrum/Agile teams; are you really implementing Scrum? Or are you just one of many SINO shops found in today's IT world?
Be honest, now.