The Impact of Agile in the Real World

David does all the heavy lifting for Blair in his recent article so they can finally discuss the overlap between Agile as a management method and pricing policy.

Links

“Pros and Cons of Agile…in the Real World” by David C. Baker

2Bobs episode 78: “Phase Your Client Engagements”

Manifesto for Agile Software Development

“Agile is Dead (Long Live Agility)” by Dave Thomas

Transcript

Blair Enns: David, how are you?

David C Baker: I'm good. Thank you. I am really good. I'm like, “Something's wrong,” almost. I'm a little nervous I feel so good.

Blair: I had that thought today too. Everything is going right. Liverpool can't lose.

David: Oh, you had to bring that up.

Blair: My Tesla stock is through the roof. The Win Without Pitching Manifesto is number one on Amazon today after nine and a half years.

David: [chuckles] Didn't take me long to wedge that in, did it? The remarkable thing about that story is usually if a book is going to be number one, it's going to be number one in the first year. Who wrote that book recently? It was really good about how to keep a book as a perennial bestseller. Anyway, he brings out all kinds of stats that make it so unlikely that a book is going to keep doing better and better over the years which your manifesto has. It's remarkable. It pisses me off, honestly.

Blair: [chuckles] I take great delight in the last point. I'd never heard of this book. I'm going to look it up.

David: Ryan--

Blair: Oh, Holiday?

David: Yes, Ryan Holiday.

Blair: Oh, okay. It's a great book. I'm a new Ryan Holiday convert.

David: Yes. He's great. Some of his books I really, really love. I think the next to the last one was on how to keep a book at the forefront of people's minds over a long period of time. Anyway, the whole point I was trying to make is it's remarkable that your book has been selling better and better every year that it's out. It's a great book. If anybody listening to this doesn't have it yet, it's a remarkable read. It's not a long read either. It's something that you're reading it and you're just shaking your head like, “Ah, that resonates. That makes a lot of sense.”

Blair: Thank you very much. That's our podcast for today. [chuckles]

David: Yes, right.

Blair: No, it's not. We're actually talking about something completely different. We're talking about a topic that you and I have threatened to talk about for some time now well over a year. It's basically agile project development. We're using as our reference point a fantastic article that you just published called pros and cons of agile in the real world. I think before I turn it over you to launch us into this and describe as a starting point, what do we mean by agile?

I'll just say that the reason it's taken us so long to get to a topic that we've promised to talk about for so long is somebody had to do all the heavy lifting, and I was waiting for you to do it, and you finally did it. Thank you for that.

David: After we finish this podcast, people are going to say, “You probably should have waited a little bit longer before you wrote this article.” [chuckles] Because we haven't really figured out everything, but we had enough questions that it was worth go ahead and publishing those anyway. Maybe we have a few answers. We'll see.

Blair: But you were telling me before we hit record that this article, it's been a week or so, it's already performing better than anything you've written in years.

David: Yes, I think because people have a lot of questions about that. I've always had lots of questions about it, but I'm particularly fascinated about the overlap between agile as a management method and pricing. How it combines with premium pricing, value pricing, the kind of stuff that you spend your life talking about and researching. It's a really natural topic for us to talk about.

Blair: Let's get into it. You want to start by offering a definition? When we're saying agile, when you hear somebody say, “We're an agile shop.” What do they mean by that? Is their meaning in line with the original intent of the meaning?

David: It's hard to tell because agile if we just step back from this as a concept and just look at it as a word, it just means flexible, not rigid. Back in the early 2000, I think it was 2001, the whole notion of agile as a management concept was around software development, which some key people in the industry felt like it was really broken. It really was broken as well. Their attempt was to refashion how this was done. It was all entirely about software development.

It wasn't until about 15 years after that, 2015, 2016, when the rest of the world outside of software development began to pay attention to this. There were some big symposium-- Symposia, I guess you would say, some articles, Harvard Business Review, McKinsey, those were the two big players at that time, decided that the world was ready to think about agile in a broader context, agile in the sense of how to manage a company. The reasons that spurred the original movement and then the broader or larger movement were all the same.

We're living in a very quickly evolving world. It's complex, it's ambiguous. We can't really see everything about it. There's some fog around it. We can't see too far ahead. That's obvious and notable, but the second thing that really spurred this was this notion that we need to be more collaborative with our clients, which is something that our industry, the industry that you and I serve has not realized until the last couple of decades. You can go back and watch Mad Men to see what I'm talking about. Before that, it wasn't collaborative at all.

It's, “We're going to take a few ideas from you, the client, and we're going to ignore most of them while we nod our head, and then we're going to tell you what's in your best interest, and you either take it or you don't.” That didn't last very long, obviously. Then there was this third reason. That was just to focus on doing the best work possible. The best work possible, the definition of that would change every week or every day, in fact.

Instead of just following this very rigid project path at the beginning, let's do what's in the client’s best interest, even if we could not predict what that would be at the beginning. Then as you start to see what that means, the implications spill over into all kinds of things like how in the world are we going to price something? How are we going to write the specifications before we even start the work? Those challenges around agile are what makes agile so powerful and so beautiful because they're trying to solve the right problem.

Agile was really about approaching in the software development in a way that was more appropriate for a complex world that was difficult to predict. It spread to other things as well. That's not a very compressed definition of agile, but that's the essence of what that mean.

Blair: I think that's nicely stated. As design and software engineering have converged as most design shops are digital in some way, I've written about this convergence of design, consulting and software engineering. It was inevitable that agile was going to make its way into agencies. I wouldn't say non-digital agencies, but you have engineering first firms and then you have firms that are designed first that have some engineering or dev chops or capabilities who are moving towards this method of working.

If you had to identify just a few key things about an agile shop, are there some basics that would have to be in place for us to reasonably consider them to be meeting this label of agile?

David: Boy, that's something we could have a very long discussion about because it really is a spectrum. I guess that the purest end of this spectrum, if a firm was really doing agile, they would not be able to tell a client in advance exactly what the specifications were. They wouldn't be able to tell them what the total cost would be. What they could do is say, “These are the people that will be working on the teams”-- Of course, agile has their own words for all these things.

“These are the people that will be working and this is what it costs you for every two weeks sprint or however you want to divide that up and we will be in touch with you frequently to adjust how we approach this.” That would be a very pure agile. If you start to step away from that, then you might be borrowing from the concepts of the agile, but it's really picking and choosing from agile. In other words, if you're doing a full estimate ahead of time with specifications, that's really not pure agile. Very few firms are at that end of the spectrum, real purists.

Most firms are simply borrowing the concepts of it, but they're not able to be pure about it is largely around the areas where clients aren't ready for it yet. A lot of clients are not sophisticated enough to accept the pure agile approach.

Blair: I think that's one of the most interesting to me aspects of agile is it's a new way of working for the firm, but it forces in all but the newest most modern companies, I'm thinking of it like the big tech companies. It forces the established clients to work differently because, as one of the elements, it demands this collaborative approach through cross-functional teams the clients at the table, people from different departments of your own firm are at the table working collaboratively, but if your client’s organization is really siloed, your agile working methodology runs into the clients and clashes with the way the client works.

In some ways, what I find interesting about it is if agile in some version is going to prevail over the long term, it's going to force the clients to actually work differently. I think that's a big win if it happens.

David: Yes, that's so interesting. What else does it require? They have to not be in silos. They also have to have a really high degree of trust in the agency that they are doing their best every week. Even though that looks different, we're being very flexible of what we do, but we really trust that the agency's doing their best, that nobody's sitting around. It goes on and on in terms of what it expects from both sides of the equation.

Blair: You wrote about that. I printed out the article old school and highlighted and made some notes here. I'll read the quote here. You say, "Agile requires very sophisticated trusting clients." Then you go on from there to talk about what you mean, but just that sentence, requires sophisticated trusting clients. Then I wrote down the word, procure con!! What I mean by that-- I've talked about this before I was at this marketing procurement conference. Sophisticated, let's put that aside in terms of how sophisticated clients are because there are a lot of sophisticated clients out there.

How open are they these days to going into these open-ended relationships and essentially trusting that this agency is going to lead them forward without a plan, without a budget effectively, and this isn't going to sound good, but I don't mean to be disparaging, effectively not knowing-- Well, I don't want to say not knowing what they're doing, but essentially saying, "Well, we're going in this direction and we'll know we're there when we get there." That's an overgeneralization oversimplification, but from the client's point of view trying this on, I'm sure that's what many of them are feeling.

David: Yes. Not only requires a client that's trusting, it requires an agency that's trusting too. I think that could be just as big a drawback because agencies and dev shops and so on, I'm including all those under that umbrella, they're not willing to be as transparent as they would like because they've been burned too much. Lifting the kimono is not something that comes naturally to them because, in the past, when they've done that, the client has simply taken advantage of them. They don't necessarily see the value in that. There's too many downsides to them.

How many clients out there are really sophisticated? I think there's a higher percentage of sophisticated clients out there than there ever has been, but I think it's somewhat of a divide in that, there are fewer clients in the middle, there are more clients that are better clients and more clients that are worst clients. We're missing in this is the middle class of clients. It highlights something else that we're not really talking about today, but it's so important to have a clear positioning, a clear point of view about what makes a good client for your firm.

Because if you don't get that right, then agile is very difficult, it's nearly impossible to pull off. We roll this all the way back up to positioning. What makes a great client for us? That delves down into the softer part of that as well and it means we have to have more options so that we can say no to opportunities that aren't a great fit. I know you and I are capable of tying every episode back to positioning, but this is an example of one where it really, really does fit.

Blair: I'm going to jump to the net take away of this article in this podcast and then we're going to back up a little bit. I'm going to read from some of the original Agile Manifesto, but the net takeaway, your conclusion of the article is that-- the bottom line for you is you don't see agile shops making more money. In fact, correct me if I'm putting words in your mouth, but you see that agile-- well, maybe it's helpful to get to a certain base level of profitability. In your experience, it's an impairment or an impediment to more significant profitability. Is that a fair statement?

David: It is and that's also the reason I wanted to write this article. I've wanted to write this article for so long and felt like I needed to do more research, more experimentation because it bothered me. I've worked with so many firms that are doing this and I have yet to come across a firm that's doing agile well that's making a lot of money and that bothers me because it seems like if we're doing what's in the clients best interest, shouldn't we be able to make more money at that? That's something I'm interested in getting your perspective on at some point today as well.

That bothered me, yes. I didn't see that happening all that much. I don't know exactly what to do with that. Now, there have been some really great benefits that have rolled out to firms, even if it hasn't shown up in the money yet. One of those is that the employee environment tends to be one where there's a higher cultural integrity, there's more emphasis on doing great work, the workers feel more involved and in charge of the process, they're more proud of the work that's done.

There are a lot of great benefits, but one that hasn't shown up to my knowledge is making a lot more money. A lot of these firms don't care too much about that. I don't know if I should care more about it than they do, but it's just a fact that agile is not a method that automatically generates more money for you and that bothers me.

Blair: When I think of different strata of financial success, there's the efficient firm and through the pursuit of efficiencies, you can get so profitable, but if you want to transcend that, you really have to let go of efficiencies altogether and move to value-based pricing. This is the clash and we'll come back to this clash, but it would seem to me-- I know that an agile shop that even fully utilized isn't going to earn the compensation, the profit above and beyond wages, that of semi sophisticated value-based pricing firm would.

I would assume that within that strata of firms pursuing efficiencies, and profitability through the highest level of efficiencies, I would assume that a really well run agile shop would be actually quite profitable at 20%, 25% maybe. You might even see 30% in some case because my assumption is if most firms who are working in an agile manner are selling sprint, although it's interesting to know that term sprint does not appear anywhere in the Agile Manifesto. Most firms are selling sprints, and therefore they're essentially fully utilized when they're working on client projects. Do you see that at all? Am I seeing something that's not there?

David: No, I do see that. I think it's accurate to say that a well-run shop that's running in an agile manner could get paid for all their time, but the problem comes after that. What's next on that highway? Because agile doesn't have a methodology for getting paid more than for the time that you're spending. It doesn't have a methodology to tie value pricing to it. That's the part that I'd like us as an industry to figure out because you are naturally capped at the ability to get paid for all your time.

Now, for most firms that's actually progress because they are not getting paid for all their time. It's not like this is some terrible roadblock that we can't get around because, in 80% of the cases, this is progress for firms, but it seems odd to me that our compensation is capped at whatever it means to get paid for our time and that's something that I haven't quite figured out yet.

Blair: Yes, I think that's the crux of it all to me. I referenced this just briefly in my book Pricing Creativity. As you and I have talked, when the second edition does come out, which maybe it certainly isn't going to be in 2020, but at some point, it merits a bigger discussion around the clash between value-based pricing and agile project management.

Blair: The challenges in agile, you're always selling the inputs of time and material. Like as you've pointed out, this isn't a step backwards for anybody, for a lot of firms, and I think you said roughly 80%, it represents a step forward. I'm simply making the case that if you want to get to that higher level of entrepreneurial success beyond getting paid for your time, then at some point, you're going to have to let go of agile. The agile adherence push back and say, "Well, no, it just can't be done. It just absolutely cannot be done," because this stuff is not scopable.

It's irresponsible to arrive at this plan and then work specifically to this plan without acknowledging that things can change, et cetera, et cetera. My argument is that's not the case that's simply a point of view. I'm fond of the phrase that all strategy's autobiographical. The people who insist that you cannot deviate from agile, it would be irresponsible. Most of these folks have an engineering mindset. I don't mean that like it's a bad thing, but what I mean is they're systematic, they're process-oriented, and it's really important to them to have visibility into the future.

You might think, "Well, that clashes with agile because there is no visibility into the future." You're feeling your way forward. You are on the project with the client, but from a financial point of view, it gives you 100% visibility. It reduces all of your risk, it pushes-- it's a pricing mechanism selling sprints specifically that pushes all of the risk onto the client and pricing based on value requires you to take some of that risk on yourself and, "In business," says Peter Drucker, "all profit is derived from risk."

I think the people who are just absolutely stuck on that we have to do it this way selling sprints specifically under the banner of agile. Usually, they are really risk-averse and they are not comfortable with the messiness that is required in value-based pricing. They would rather the messiness be in the project itself where the risk is the clients and not the agencies.

David: Yes, absolutely, that is the case. These firms are almost universally operating from a point of not getting paid for their time because of a sloppy estimating process where they don't sufficiently cover themselves. If they cover themselves so that they don't lose money in the project, then they have trouble getting clients to sign up for it. I wanted to tie two episodes together. By the time this comes out, the episode right before this, deals with the diagnostic and prescription which really should be viewed as somewhat an alternative or at least an additive to thinking from an agile standpoint.

It's the idea of getting paid to look a little bit further ahead and then use that information to feed a value pricing conversation. These two things are really tied together. What you said is exactly right. I think there's going to be quite a bit of push back on what you just said, but I think it's correct. Value-based pricing to me, it's really about managing risk. I don't think that's the best way to manage risk. Even though there are a lot of great things about agile, I don't think we should be using it to manage risk.

Blair: You tied in nicely this idea of diagnostic. The idea if you're proceeding on a phase engagement by selling a diagnostic is before you scope the project, you essentially get paid to understand the client's situation and to scope the project and put a price on that scope. From there you can sell the inputs of time and materials or you can sell the deliverables and offer the client a price certainty. If you come in underestimated time, it's more profitable. If you go over, it's less profitable or even costs you money. That's at the opposite ideological end of the spectrum from agile.

If you're proceeding with the phase engagement, the first phase is a diagnostic, you are proceeding on the assumption and from the point of view that this thing is scopable. We just really need to roll up our sleeves and do a proper amount of initial work. There's one point of view saying, "Yes, we can scope this. It's just a lot of work, you're going to have to pay us for it." The other point of view is, "We can't scope this. Let's just get started. Let's get to a minimum viable product and will iterate, iterate, iterate from there."

What's interesting is I'm working with the firm in New York next week who recently worked with Agency Agile. Now, I know these folks. I've met the two owners a couple of times, run into them in various places around the world. I thought they were teaching agile development to agencies, but they're not. What they're teaching is more of a formalized diagnostic way. They say it's not software agile for agencies. It's something else.

What's interesting is the name has agile in it, but it's really their point of view is that other point of view that I just laid out, that this is scopable, you just need to have a rigorous methodology for scoping the project and that's what they teach. I think it's really interesting that there's an organization out there that's almost trying to bridge that gap by using the agile word, but really teaching the other point of view. I tend towards the other point of view.

I think most projects are scopable or I think it makes sense to actually proceed on that basis because you give your client some degree of price certainty, but then you have to be careful and sophisticated about scope creep. Really the issue is scope creep, when you scope something out, when the client tries to change that scope or your own people are just as often the culprits, they try to change the scope by not drawing a hard line with a client. That's when you run into trouble.

It does bring up the subject of change orders. You have to embrace change orders if you're going to work this way, but they are really two different points of view. I think as people are listening to this, they identify with one point of view versus the other. Any thoughts on that? I'm just rambling now.

David: I enjoy the rambling. I think one of the reasons why somebody listening to this-- let's say, they're in the software development camp and they're hearing you say that things are scopable and they're just shaking their head back and forth thinking, "He didn't understand our world. The stuff we do, we keep discovering new more innovative ways of doing things that we need to weave in and there's no way we could have anticipated that."

What I would say is there's certainly an element of truth in that but I think one reason why people instantly react against this idea of scopable work is because they're positioning, again sorry for introducing this, but they're positioning has not yielded client relationships that are similar enough to each other. They're consistently getting thrown into inconsistent scenarios where they are learning too much on the job and that coupled with Part B is that they are not leading the clients efficiently. They're more reacting to what the client needs or things they want.

If we could solve those two issues, in other words have your client relationships be a little bit more similar from one to the next and if we led our clients more, I think those are two factors that make it easier to scope projects. My dream is to be in an audience someday and have you talking about value pricing and have people who are just dyed-in-the-wool agile disciples shaking their head yes and agreeing with this where they finally understand how that works because we're really trying to bring two worlds completely together.

This is such a deep project as well. There's some interesting unintended consequences of this whole focus on agile that I see two around staffing. For instance, I see a really glorified in an appropriate role of project managers at firms and I really like that. Now, they're called, in the software world, they would be called more producers and so on or resourcing folks. That's really good. There's no downside to that at all. Something about agile has minimized the client experience side. What we're tending to do is we're tending to focus more tightly what it is that we're comfortable charging the client for.

We become less and less comfortable charging the client for somebody who's going to manage that relationship well. That is just an odd unintended consequence of all of this and it also results in lost revenue opportunity because you don't believe that account people are worth charging the client for that perspective seeps out to clients and they agree with you and don't want to pay for them. You find the stronger the shop is towards agile on that spectrum, the less they value the client experience as well.

By client experience, I don't mean it quite like that, I mean the professional client experience. We did an episode two or three back that talked about exactly the value of account people. That is something that's missing from agile as well. I'm not sure why. I think it's this purist view about the biggest contributors in our world are the people that do this with their head down and their fingers on keyboards and somehow we minimize the rest of it. I don't quite know where that's coming from.

Blair: You're saying the agile approach devalues account management and overvalues project management? No, you didn't say overvalues.

David: No, properly values, properly honors project managers and improperly deemphasizes account managers. It's not only not in the client's best interest, and I think it does that because the folks on the other side of the aisle, on the client-side are often more engineering types who tend to devalue the account experience as well or wanting to pay for that, but it's also a lost revenue opportunity too. It's another one of those unintended consequences of focusing on agile too much.

Blair: I mentioned I would read some of the key principles from the Agile Manifesto and we'll put a link up to this, but simply it's two columns of things on the left versus the right. We value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. What Dave Thomas said in his most recent article, and he was one of the original authors of this, is we've lost sight of the fact that it's like that the things on the right aren't important at times, we just value the things on the left more.

As he points out in his article, he refuses to celebrate agile at the events, at the anniversaries, et cetera because-- It reminds me of something you said when I interviewed you in one of the first episodes. I think it was an introduction to David Baker. I asked you where you were politically and you said you're an anarchist. You're just waiting for them to get better organized so you could join the movement. Thomas' point was really that there shouldn't be conferences on agile because people are starting to put it into these boxes that was never really intended to be.

Then somebody else earlier on Twitter this week and I forget who it is, I'm sorry, but a published a list of these words and terms that are used in the agile community such as sprints and scrum master and a bunch of other terms, and that we all associate with the agile approach. He said none of those words, none of these terms appear in the original manifesto. The original idea was just be a developer who works with agility and follow these four key principles of honoring individuals and interactions, working software, customer collaboration, and responding to change.

Honor those things, value them over the opposites that I read out earlier, and that's essentially it. Along has come these packages that people have put in place in this kind of industry has grown up around it. I think at the heart of the idea if we go back to how you put forward a proposal to a client, one of my rules is just always offer options. Those options should be more than just like you can buy a bunch of deliverables, you can buy even more deliverables, and you can buy even more deliverables. In their best form, they represent different ways of doing business together.

You can imagine putting forward a proposal to a client that says, "Here's one way we could work together, it's a partnership level. You'll pay us to come in and scope the engagement and then we'll give you a price based on the value that we propose to create. It'll be high risk, high reward for us, we'll put a bunch of competition at risk, not all of it. If you want to work with us on that basis, we can work with you on that basis."

On the other end of the spectrum is, "We can just agree that this is messy, and we're not going to be able to scope it out and we're going to work together in an agile manner and you're just going to pay us as we go based on two-week sprints of three to five-person cross-functional teams." Those just represent two different ways of doing business. One's agile and one's what's typically referred to as waterfall, let's just call it more rigid scopable non-agile. There are two different ways that you could work together.

I don't understand why a firm couldn't put both of those ways in front of a client and let them choose.

David: I just want to restate what you said in case somebody missed it because putting options in front of a client is not always about different amounts of work we're going to accomplish for different amounts of money, it could be about a different way we're going to work. That's what you just said. I think it's really a smart way to think about it. This is a question, I hope this doesn't put you on the spot too much but you just went to that conference on procurement and you've spent a fair bit of time thinking about that world and so on.

Do you ever come across the intersection of agile as a concept and procurement? Do they talk about that at all?

Blair: I have to confess, I'm not deep enough into either of those worlds to be able to answer the question today. I've never seen the two things come up. I think as soon as procurement's involved, the idea that you're going to get away with like in a first thing a procurement person is going to see is like, "What you're saying is there's no budget, there's no cap, you can't give me a price." All of the incentives are aligned to the idea that-- it's in your benefit that this project never ends. You want me to sign off on that?

[laughter]

David: You're not doing a very good job of doing this objectively, let me just jump in and say. I can read the sneers all over everything you're saying. I can picture them saying the same thing. That's why I asked the question. What world are we living in that we think that we're going to do a project like this for a massive client that has any procurement drive in it, unless we have worked with that client for a long time, and we have a very high degree of trust with them, or we have such a reputation in the marketplace, and also a powerful positioning that we can just say, "This is the way we work. Sorry, if it doesn't."

I have a client that is the small firm that has more than a million-dollar PO for one of the massive airlines out there, one of the big three airlines, and they have a relationship with their client that is exactly that. It's completely built on trust and there is no ripping anybody off. There's very little checking to see if people are spending enough time. They just have consistently gotten such great work done together that it works in their world. I think you have to work up to that, the notion of springing agile on a client who's never even heard of the basic concept, just doesn't work.

To recap, I guess agile is really great from a management standpoint, but how does it mix with value-based pricing? How does it mix with selling ideas to clients? It's just a lot more work to be done on here. Maybe I've just raised more questions than I have given more answers, but it's such an interesting topic to me.

Blair: Well, I've been thinking, how do we put a bow around this? I don't know that we do. Neither you or I are for or against it. It's just one of these issues where you go into it with your eyes wide open. There are pros and cons. There are trade-offs. I think for a lot of firms. Maybe it represents a step forward. Some other firms who've already gone far, they're going to find it to be a limiting factor. Just be aware of the trade-offs.

I suspect, we're going to come back to this topic at some point in the future as we hear from people about it because it is a big topic these days. I think this is pretty good first start. Thank you for doing the yeoman's work on this. It was great just to be able to read your piece and then have this conversation with you about it.

David: Thank you, Blair. It's been fun.