Pros/Cons of Agile in the Real World

The "agile" word is kind of like the "UX" word—a lot more firms are slinging that term around than are actually doing it well. Those firms are all over the spectrum on their embrace of agile, too: on the one hand you have firms who don't really understand the basic concept, and on the other you have firms who won't accept any work outside of the agile framework.

In other words, they don't do traditional estimates, they don't have scope discussions, and their client relationships are truly collaborative.

That's right—you aren't really doing the purest form of agile unless those three things are true of your work.

But wherever your firm is on that spectrum, there's no doubt that agile is a very interesting subject to the world that you serve. Here's a chart I pulled from Google's search trends over the last fifteen years:

But as Dave Thomas (a signer of the original Agile Manifesto) said recently, "The word 'agile' has been subverted to the point where it is effectively meaningless."

If you don't mind, I'd like to make a few statements and then expand on each of them. They are declarative in nature, but I'm making them against this background:

• Working with 50-60 new firms every year, most of which are digital to some degree.
• Another several hundred firms that I get to interact with at my seminars.
• Thousands more I speak with at other keynote opportunities.
• Tens of thousands of you who get these emails and send me feedback.

Agile Is Wonderful At Certain Things

It really is a pretty amazing approach to work. It helps you focus on the most important issues to solve rather than following some pre-described chronological path. It allows greater flexibility in deliverables in a way where you welcome what would otherwise be called a change order. It allows you and your client to iterate faster by releasing...and then testing...minimally viable products to let critical feedback influence the overall project. Best of all, agile expresses an appropriate commitment to quality over deliverables.

The common theme through these advantages? The focus is on using your greatest skills to enable the best work possible rather than a blind allegiance to some initial plan, and then all the management required to stick to it.

Focusing on the most important issues to solve is a really good thing.

Agile Is A Challenge For Certain Things

Agile requires very sophisticated, trusting clients. They must be comfortable not being bound by strict deliverable requirements but instead must believe that you are delivering your very best work without wasting their money.

Capacity management and prediction is a massive challenge, too, although practitioners don't often realize that. For agile to work well, you must have a steady stream of exact opportunities lined up for each 3- to 5-person team. Stack up too much and clients get antsy. Run the operation in more of a JIT mentality, and any slippage leaves teams without enough to do. In agile you have assembled teams, and there's a specific mix of work required to keep the team fully utilized. Contractors are more difficult to integrate as you manage around the peaks and valleys. You are challenged by keeping entire teams busy rather than individual contributors; there are fewer moving parts to slide in and around things.

Here's the biggest thing, though: there's a practical cap on what you can make because it's tapped out at what each small team can earn, whether that's $10,000 to $20,000 per sprint. I know: theoretically you could charge as much as you want, but nobody is doing that. In other words, the best you can do is get paid for your time under traditional conventions—value pricing is typically out of reach.

Firms Doing "Agile" Are Really Picking & Choosing Elements Of It

It's all over the place, here, but what's quite clear is that not a single firm is really doing agile religiously. They've borrowed elements of it that fit their style and available staff. That's not a bad thing, but you have to keep it in mind when you hear that a firm is agile or not agile. We should probably be describing each one at a point on the spectrum.

Firms who are borrowing this in the least restrictive sense are really just more flexible in terms of how the work unfolds. They reevaluate their progress and adjust priorities.

On the other end of the spectrum would be firms who don't write closed-end proposals but simply sell two-week segments of time ("sprints") to scratch wherever it itches, don't track their time, and use all the proper terminology, uttered by all the proper staff.

Agile Is A Great Way To Manage Projects...And A Lousy Way To Make Money

You wouldn't think this would be true, right? I mean, how could getting paid for all your time be a bad thing? That's true in principle, but in reality there are always gaps in the schedule, clients who object to the pure application of labor, extra "above-sprint" hours that don't get accounted for, and a dozen other things.

Here's the surprising truth: I am not aware of a single firm getting rich by using agile. They do tend to have more sophisticated clients and a staff that's more content within the work culture, though.

Part of this comes, I think, from a certain mentality prevalent at firms who embrace agile. These same firms are very focused on the quality of their work, and the money they make is secondary. The principals and staff are usually younger, too, and you wonder what might happen if (when?) they get tired of the grind.

Agile Doesn't Mix Well With Value-Pricing

I touched on this above, but I want to state very clearly that there is no earthly reason why agile can't mix with value-pricing, because it can. But that's not how people are doing it.

In timeboxing, you usually try to balance these three constraints: time/schedule, cost/budget, and scope. (Sometimes you'd add quality as a fourth.)

The time/schedule doesn't change, typically, unless you're willing to throw more bodies at the problem (nearly always at your own expense). The cost/budget seldom changes unless the client falls in love with some feature opportunity and steals money from another program. And the scope—in agile—is all over the place, as it should be.

In value pricing, the cost to the client is tied to the value you create. The output (value) and not the input (hours). But that is not the way clients pay for agile. They simply do not. Agile ends up looking like this: doing your best work in segments at a fixed price.

So technically there's no reason why value-pricing won't work, but that's not how the marketplace (a client) is willing to play the game.

Agile Solves Some Problems that are Properly Solved in Other Ways

Some of the firms who embrace agile are drawn to the methodology because of the terror they experience every time they write an estimate. They've been so badly burned by scope creep that they are willing to give up the upside (value-pricing) to protect themselves on the downside (losing their shirt to reach a deliverable state).

But that's a defensive posture meant to protect them. A firm with that mentality is not going to thrive. If that abject terror is driving you to settle for something, think about doing some sort of paid diagnostic, instead, to clear the fog around project deliverables. Especially if you deliver something of value at the end of that stage, clients will appreciate the additional guidance and discovery that you are providing. And it's a better way to hold the terror down without compromising your ability to get paid well for your expertise.

Agile Borrows Some of the Challenges Inherent in Retainers

I've talked about monthly recurring revenue already, so I won't repeat that here except to point you to the article. Retainer relationships come with certain expectations. Most of all, though, they don't age well.

Agile Improperly De-emphasizes AMs and Properly Honors PMs

There's an inverse relationship between the strict practice of agile and the inclusion of strong account managers. They are virtually non-existent. The client experience is minimized and the focus is on the quality of the work. The person who interfaces with the client does so in a secondary role (it's thrown in), and the person chosen for it is usually tied to competence and organization rather than relationship building and the risks that come with growing accounts.

I talked about this a lot in our most recent podcast on what role account people play.

PMs are fantastic people and the most important cog in the process. But putting them in charge of client relationships is a disservice to clients.

Agile has Moved the Focus away from the Deliverable to the Expert

This is a fantastic result of applying the principles of agile. Under that more enlightened arrangement, the expert at the firm is truly empowered to be such an expert throughout the entire relationship...rather than a mere "best guesser" at the outset of the process, when very little is known about what the client really needs.

And while this is true, it highlights a challenge I'd like to throw to the community. To date, most of the integration of agile has come from developers and producers (i.e., project managers). What we need is a revolution that properly includes the voices of those responsible for your firm's positioning, sales, and account management.

To date, sophisticated clients see the value of agile methodology, but they have stopped short of a willingness to compensate firms at a premium. At best, they are willing to pay them for their time, and the gap between those two approaches is significant.

Finally

If you'd like to learn more about agile, start by studying Ron Jeffries' work. Then hop over to Agile Mentoring to support and then read their work. If you're looking for a single book, I'd try Scrum. If you want to be a complete disciple and go the possibly overkill software route, get yourself some Jira. And here are two articles you'll like: one from a team at the US Government, and one from Dave Bailey. Both of these will help you see what it means to really be an agile team.

For terminology, you'll want to start with these terms, all of which are unique to that world: epic, reporter, sprint, user story, story point, backlog, scrum (vs kanban and others), scrum master, product owner, turndown, velocity, standup, planning poker, swim lanes, and timeboxing.