JD: They already were like that. So, they turned this waterfall thing into something very heavy, very command and controlled. Not because Waterfall itself was heavy and command and controlled in nature, but because that's just the way they already were. Right?
JD: So, a couple years ago, or probably about a year ago, the DoD and General Motors, who are the two largest buyers of IT services in the world. General Motors has a $4 billion IT budget. This dwarfs the average agile user by $3.9 billion.
JD: The average agile project is four people, eight people for a year and it's probably worth a few hundred thousand dollars and that's really cool. But now that General Motors has said we're going agile, I started to worry about what that meant, right.
JV: Yes. What exactly does that mean? When someone, when they say they're agile, what does that mean?
JD: Well, it means a couple of things. So, a lot of people know what agile is, but when a large corporation like GM or Ford or Chrysler or the Department of Defense or Veterans Affairs, when they say they're going agile, they want the perceived benefits of agile. They want to see delivery faster. They want to see delivery more quickly. They want to see more agile techniques being used. But they don't really know what they're asking for. They want those benefits, but they don't really know what it means. We're already starting to see this in the industry where these big companies are saying, yes, we want you to be agile, but why are you bothering our customers? Why are you asking them to come to daily stand ups? Why are you asking them to participate in this process?
JV: Yes, yes. Definitely. The feedback.
JD: Right. You know that agile is all about collaboration and working together and it's a values shift, right?
JD: Being agile is a value shift. So what's happening is these big companies who are very much in command and control. You think about procurement and executive management and operations.
JV: Oh, sure.
JD: They're not agile at all.
JV: Yes, and I'm thinking like government contracts. If you're thinking, that's the ... That doesn't apply to agile in the slightest.
JD: Right. They pay you by deliverable, right?
JD: So they say when you're done with the design phase, we'll pay you. When you're done with the testing phase, we'll pay you. And the agile guys are saying, whoa, whoa, whoa, wait a minute. That's not how it works. It's frequent, every two weeks, every four weeks, and procurement officers are saying, no, no, no, no, no.
JD: We want to pay you this way. So, my concern on this whole thing was that, aren't they going to change agile? Aren't they going to make it more like waterfall, because we're already seeing these companies that are agile organizations, but now they're using Microsoft Project and building these big, break down structures and building big requirement specs up front because that's the only way they can get paid.
JD: So, these great, wonderful, high-performing organizations are being driven towards a waterfall approach because that's what the business is forcing them to do.
JV: Are they being driven like though, like using the tools that are available. I mean, what are some of the forces, I guess, that are driving those?
JD: Well the real forces have that customers aren't interested in participating in the collaborative process and procurement officers aren't willing to structure the contracts in a way that make sense for an agile organization. So, a typical agile project might have a fixed team for a fixed period of time, delivering something every two to four weeks, let's say.
JD: Where they deliver a piece of working software. Well, the procurement officer's like, yes, great, but where's the design for the whole application? Where's the requirements for the whole application? That's sort of traditional thinking and there's nothing wrong with traditional thinking, in this particular case, but that's just not how the agile method is designed.