Since I’m going to slam agile project management (APM), I figured I’d first be very clear: there are times when using agile is great. When you absolutely have to be the first to market with a product, agile may be a good choice. When your product has an expiration date that isn’t far in the future, a modified version of agile may be a good choice.
But if budget is a concern? If quality of product is a concern? If you have a lot of work and your people are already working over forty hours a week? If your agency is a premium brand, or at least a shop known to do great work? If you absolutely have to shine in your client’s eyes at every step? And you’re using agile?
You’re doing it wrong.
The biggest problem with agile project management is that, by design, there is no project manager. A critical role on a project team is eliminated, and the rest of the team is responsible for being able to manage their elements of the project. Getting rid of super-talented producers to replace them with project managers is bad enough, but getting rid of project managers and having no one actually tasked with keeping a project on track on a daily basis? That’s madness. Nigerian email scams don’t employ copywriters – how well are those written?
You wouldn’t expect your art director to be able to code. You wouldn’t expect your copywriter to handle client billing. You absolutely would never let your account manager serve as your creative director. So why in the hell would you expect all of these people to work as your project manager, in addition to what they’re needed to do?
And having project managers instead of producers is insane, as I already discussed here.
Besides, distributed responsibility absolutely, positively, sets up a system of no responsibility. The production systems of the Soviet Union taught us that when someone is only risking punishment by taking on new responsibilities, they don’t take them on. They also taught us that quality of product tanks because, without responsibility for quality, effort levels go down because everyone is equally rewarded or punished, regardless of effort. It’s only human nature to not work twelve hour days when the person sitting next to you gets the same raise for only working seven.
Bloated repetition isn’t just a hallmark of agile, it’s a selling point. Proponents of agile note how the entire philosophy is built around possibly endless iterations of work, often on the same task or feature. My dad, who was a project manager who retired from the phone company, used to sometimes come home angry, yelling, “The bastards can’t afford to do it right the first time, but they can afford to fix and rebuild it again and again and again!” Team members are often required to wait for specific tasks to be completed, because requirements may (and do) change, thus changing downstream work.
Daily scrum, even for projects where agile is best, are always a terrible idea. Having every project team member stand up for a daily meeting, even if it’s only for fifteen minutes in the morning, means constantly missing team members if your people aren’t dedicated to that one project, and a minimum of a half hour lost every day because people don’t stop working seconds before a meeting, nor reach full productive capacity seconds after one.
The bloated costs with agile can be staggering. Most agencies and mid-sized shops are hamstrung by frugal budgets these days. Making four different looks, locations, and on-click functionalities for a “my account” button is a level of critique that no thrifty scope of work can afford. An agile process will guarantee a distended budget, if only because a high-paid art director has to stop what they’re doing, re-open a file that should be closed and delivered, to change a button color’s pink from #FF69B4 to #FF57AA, and then sit around waiting for approval, or worse, making up a palette of pinks that will absolutely, no question, look different on the client’s screen and on the account manager’s screen than on the art director’s. As my dad says, “A camel is a horse designed by committee.”
If everyone in your immediate family had the same social skills, you would be a freak of nature. Why would you ever expect everyone on your project team to have strong social and business management skills? If you have the absolute best copywriter in the world, but she’s a little anti-social, what do you think is going to happen when she’s tasked with reaching out if she sees something wrong, or if everyone is staring at her in a morning scrum meeting? One of the most critical skills of a good producer is being able to be individually inclusive, and build upon the strengths of team members. Agile, however, requires all team members to be fluent in skill sets regularly not required of them.
With agile, if every single team member isn’t a Swiss Army knife, or a unicorn, you’re destined for diminished results.
The goal of agile is to launch sooner, but that rarely happens. You may launch a product, but it could be a terrible, or embarrassing product. Chances are strong that you’ll push customers away due to a bad experience, and worse, they may blog, Yelp, or employ some form of social media to tell everyone they know to avoid your client or product. Sure, you’ll get better and better, but the whole time you’re open for business not making fans, but creating trumpets of bad publicity.
If you are using APM, and you have a project manager or producer on the team? You’re just throwing away money.
While agile will rarely leave you with the documentation future account managers, development teams, and clients will need in the future, there is still a bigger problem: you probably have no critical information architecture (IA) or user experience (UX). Programmers regularly think they must be skilled at IA after years of college coding classes, and programmers who also can draw well regularly fall into the trap of thinking they understand a good user experience. The entire point of the IA discovery process is for someone skilled in process and flow to interview key stakeholders to develop a road map for success and profitability. Agile projects regularly, and almost always, decline to employ full-time IA team members. That means team members are building elements of a project without focused research, strategy, and insight. Employing programmers, designers, copywriters, and other team members to burn two weeks producing a half-baked idea is just that – a lot of time, money, and momentum spent on a guess.
Agile promises an earlier delivery, but it’s almost always delivered later than a waterfall project. That’s not to say there aren’t times where agile could be helpful in a waterfall project – there absolutely are. If you want to create great projects, you’ll employ all different kinds of methodologies, and you’ll hire people with deep, diverse skill sets. In the middle of those people you’ll place a producer – a person first on the ground, and last to leave the field of battle, who acts more as a field marshal than a bean counter. You need to have multiple tools in your arsenal, and be ready to use new ones as you go if you need to, in order to build great things.
Because, as my dad used to say, “If all those bastards will give you is a hammer, every other a**hole is going to slam each problem like it’s a nail.”
Be the first to comment