JD: Really, it's designed architecturally to have frequent iterations or sprints. So, we're starting to see ... The sort of English language version of this is they're being pushed around the agile organizations and being forced to be decidedly not agile in order to satisfy the requirements of their customers. So, I really became keen on this when the CIO of the DoD said that we're going to be agile, but there was no talk about changing contracts. No talk about changing roles. No talk about changing the way this is conducted.
JV: Right. There was no talk about the frame work or how you're going to do something.
JD: And when you think about agile, it's really an aspirational approach to developing systems. When I say aspirational, it needs to be driven from the C Suite. The C Suite needs to say we're going to be collaborative. We're going to fail fast, we're going to fail early. We're going to be iterative and incremental. But the growth of agile is not in the C Suite. The growth of agile is in the project teams. So, everybody's talking about, oh, agile is exploding, agile is doing great. But it's at a low level of every corporation. It's at the project team level. Yet agile methods are aspirational in nature, not operational in nature.
JD: So, we've got the organizations at the lowest levels saying, yes, we want to collaborate, we want to fail fast, we want to do all these wonderful things that are in the Agile Manifesto. But anything about the project team is saying, yes, whatever. Just get that design done.
JV: There's a big disconnect on what is the role of agile from those two different departments, then, right? You have the people on the bottom are saying in order for us to be good at practicing agile, we need to be in constant communication with you and all these other people. Then the people up top are saying, eh, it's not how we've done things.
JD: That's right. So, this is what I call an organizational type mismatch.
JD: I use that term type mismatch. It's a software term where two variables aren't able to talk to one another.
JV: Uh-huh. (affirmative)
JD: And ... I'm a software guy. So, the problem is s that if you're a futurist at all and you look at what will play out in the future, the only end to this is bad. The only results if you look at this historically ... Forget software, forget agile. Look as this as historian, the only outcome is bad. It means that agile is going to change and become more like waterfall. So, I really started thinking about this a couple years ago, that boy, this is really a problem.
JD: So, one of the things we focus on in our company is working with the executives of companies, trying to transform the entire organization with agile values. That's great that projects are doing agile things, and that's awesome. And no offense to the projects, but that's not really the important part.
JD: The important part is what the organization or the corporation is doing. Or, the government case, what the agency's doing.
JD: So, we came up with this idea of agile resiliency where it's a framework in which an entire company can align itself around agile values. And it's a three tiered frame work, starting with values. The values are pretty simple. They come right out of the Agile Manifesto. We encourage the executives at the senior levels of companies to build an agile framework around the way the operate the business. Then to trace that, we use the term traceability.
JD: It's a common term in software but it's not a common term in companies.
JD: So, to help the organization, start with the agile values, trace the agile values down to the methods or the frame works that we use. So, for instance, if an executive is saying, I would like our organization to be iterative and incremental in the way they deliver systems, that means that they need to embrace a frame work like Scrum, for instance. Which is, by definition, designed to ... Everything in Scrum is designed to embrace these agile values, iterative, incremental, collaboration, trust and all the things that we know about the Agile Manifesto and what they really mean. Then traced from that, we have a third tier, which is the techniques that all the project teams use. So, today what we see with all our clients is, hey, we're agile, we do daily stand ups. Well, daily stand ups are a technique, but they're not really agile. They're a technique that are part of the agile world, but a daily stand up is just one of many techniques.
JD: So, an agile organization is going to adopt all those agile techniques, like daily stand up, like sprint and product back logs, like story time or back light movie and all those great things. But unless the company is also embracing those things, the end of this only ends badly. It never is going to survive to be resilient. It's not going to survive.
JV: So, how receptive have some of these companies and some of these government agencies been, when you sort of approach them with that perspective?
JD: Incredibly receptive when you explain it to them in a way they can understand. So, very big challenge.
JV: Well, you know, we're getting towards the end here, but I wanted to touch a little bit on the Capability Maturity Model Integration. That frame work. Yes, so if you could just elaborate a little bit on that.
JD: Sure. Well, the CMMI is something that's very, very popular in the software development industry.
JD: It's something that, not just government agencies, but many commercial agencies CMMI has been wrongly associated with waterfall-type software development.
JV: It's been lumped in unfairly.
JD: The reason for that is because the federal government and the state government and a lot of corporations ... I don't mean to just point to state and federal government. A lot of companies, like the GMs of the world and the Boeings of the world, they require that the vendors, and anytime you require something you need to achieve a certification, you drive a behavior, right?
JD: So, when you say to me, I have to achieve a CMMI level 3 in order to win a contract, it drives the behavior. So, the behavior that's driven is the wrong kind of behavior. It’s driving a behavior that's document focused and behavior that is heavily laden with heavy processes.
JD: And the fault of that isn't the CMMI. The fault of that is companies walking forward like a bunch of zombies trying to achieve a certification, instead of using this great, fantastic model, CMMI, as a way to improve. My talk is going to discuss the idea that the CMMI provides us with 357 volume knobs. That's what I call them. They're little ways to tweak our performance and it's really a fantastic model if it's used appropriately. If you apply this model to agile methods, it turns out that we can make agile strong and resilient and impenetrable to being pushed around by making it a standard across our industry in a way that Waterfall is the standard today, where agile is just all over the map with the Scrum. Scrum adoption across the country is all over the map. People are getting different things.
JV: Yes, there's no universal standard.
JD: There's no universal standard and some of that is good. Some of that ability to be flexible is a good thing. But if we want to scale this in a way so that when the government agencies come to us or the corporations come to us and say, we want you to be agile, we can say sure, we can do that, but here's all the ways we are going to work, here's all the ways the software's going to be delivered. We have standards and we have ways to improve on that method.
JV: You're speaking their lingo a little bit more then, right?
JD: Completely speaking their lingo. But you'll also have a set of tools. Right now with Scrum, it's fantastic and I love it and I'm a Scrum master and a Scrum product owner and all that kind of good stuff. But, there really aren't tools in place to make it better as a frame work.
JV: Uh-huh. (affirmative)
JD: Because Scrum by definition is very high-level frame work. It doesn't have guidance for how to conduct a code removal, for instance.
JD: Really manage a project and the CMMI has all of that. So the trick here is to integrate the fantastic guidance and tools that are in the CMMI. It also fits really nicely with procurement and what corporations want, but we use it to improve Scrum. We use it to make Scrum stronger and more resilient, so that when a customer says, oh, how about switching those daily stand ups to weekly stand ups, we can say, okay, wait a minute. CMMI tells us that we have to have regular understanding of how the project works and the way we do that is the daily stand ups. We're not only using this method to improve us, we're also using it to prove to you that we're a strong, resilient organization.
JV: Right. It's like a list of goals and then the list of methods to use to reach each goal. You can show that to the clients and hopefully they can come on board.