How Agile and Scrum are Destroying your Project.

Is your project suffering, wounded, or dying? Are you using all the trendy buzzwords, management techniques, and cute little sticky notes, but still feel off course? Are you hiding out in meetings “strategizing”, but deep down you know that you have no idea how to salvage this sinking ship? Are you using platitudes like “Work smarter not harder” as a last-ditch effort to seem authoritative?

After the seminar and certification you felt like you could take on the world and that your amorphous “manager” role now had direction. What went wrong?

What went wrong was that you were sold “Management and Development Techniques”, but what you really got was scheduling and tracking techniques.

Just because you are leading a meeting does not mean you are leading a project. The problem with Agile and Scrum is not the techniques themselves, parts of which may be useful. The problem is that these methods pretend to manage while leaving the true role of managing the project vacant.

They also have subtle but equally destructive qualities that lean away from efficiency and toward bureaucracy.

1. They mask the Pseudo-manager’s accountability. This allows the Pseudo-manager to make no decisions and still benefit from a successful production, because they ”trust them to get the job done.” Trusting your team is good, but managers also need to have technical knowledge of process creation, streamlining and the medium they are working in. This allows them to take a true leadership role and understand when a particular method is inappropriate. Providing an environment to “let them figure it out” is good, but it needs to be backed up with competent leadership.
2. The Pseudo-manager doesn’t have to be an expert in any of the disciplines; instead, they rely solely on each discipline’s lead manager’s expertise. The problem arises when you have a multi-disciplinary team that doesn’t know how to communicate. This is where the Pseudo-manager starts losing control of the project. They must hope that they have a team member that steps up and can control the situation. If no one rises up, the Pseudo-manager will not have the ability to get the project back on course. If someone does step up and rescues the project, he will get a pat on the back, but the Pseudo-manager and techniques will get all the credit and promotions.
3. They are self-insulating. The Pseudo-manager imposes unnecessary procedural burdens on production. The project will still get done despite, not because of them. This makes it appear as if the method worked, when in fact it was just a distraction.
4. Some of the principles of Agile are so ambiguous, broad, or so obvious that they become non-principles, such as , “Continuous attention to technical excellence and good design enhances agility.”
5. They are designed to work in a software development environment where everyone speaks a common (programming) language. They break down when working in video games and multimedia where three or four more disciplines are present.
6. The most insidious quality is that these pseudo-management techniques leave a team rudderless, and before the project fails the Pseudo-manager has enough warning to sink back into the bureaucracy and start the process over again on a different project, while the rest of the team works inhumane hours on a death-march to unemployment.

A real manager is like a clock-maker. He coordinates hundreds of moving pieces and knows each function and how to engineer their efficiency. He seeks to understand all the moving parts of a production and to streamline inefficiencies out of the pipeline. There is no seminar formula for this. Ask questions, find problems and create solutions. Agile and Scrum are not clock-makers, and if used incorrectly it becomes obvious that they were one of the extraneous gears that was causing the watch not to work.

Have you seen this happen to your project? Am I totally off-base? Let me know in the comments.