Jeff Dalton is an author, a consultant with more than twenty-five years of software process improvement experience, and president of Broadsword, a management-consulting firm. In this interview, Jeff talks about agile resiliency and large organizations making the agile transistion.

Jonathan Vanian: This is Jeff Dalton. Thank you so much for taking time out of your day to talk with us, Jeff.

Jeff Dalton: Thanks for having me.

JV: Yes, no problem. So, Jeff is going to be speaking at the upcoming Agile Development Conference West in Vegas.  So, Jeff, why don't we start off by just having you tell our listeners and readers a little bit about yourself.

JD: Sure. My name is Jeff Dalton and I live in Detroit, MI, or outside Detroit and I run an organization that is called Broadsword. Broadsword is a company that helps companies increase performance improvement. The name of our company comes from one of our clients. The CIO of a really large energy company said we really like working with you guys because you know how to cut through all the noise and get right to the point. We came up with the name Broadsword about ten years ago because that's exactly what we do. We come in, we cut through the politics, we cut through the noise and we help your company be the greatest company it can be.

JV: Very nice. Yes, that's a very powerful sword.  Very strong, big sword.

JD: Very large sword.

JV: It's a very large sword, right.  So, you're going to talk a lot about agile resiliency in your upcoming session, so let's just start out and can you just give a little run down on what is agile resiliency? 

JD: Sure. agile resiliency is an idea that we need to work together to make agile methods stronger and more robust so that we can scale them. But more importantly, the really large adopters of agile, these are organizations that are starting to use agile like General Motors and the Department of Defense and Lockheed Martin and the really big companies are all starting to declare that agile is something that they want to start adopting. 

JV: Right.

JD: I started to become concerned about this because when I was a young programmer, waterfall was considered to be the next great thing.

JV: Sure.

JD: It was considered back in the seventies and eighties, we were saying, oh, waterfall is so cool.  It's going to make development predictable and easier and much better.  Of course, now, waterfall is almost a bad word.  It's a curse word.

JV: Right.

JD: In the software industry, right?

JV: It sounds very old fashioned. 

JD: It sounds very old fashioned. Trust me on this.  I know, I see from your video that you're kind of a little bit younger than I am, but you probably are like, oh, waterfall, what a terrible thing. And back in the seventies and eighties, that wasn't what it was.  It was like, oh, this is the coolest new thing, you know?

JV: Well, I try not to harbor too much of a bias, because I talk to so many people who grew up in that era. So, yes, I don't. 

JD: Right. But, the thing is is that it was the doctors that needed the heavy, ugly thing that it is today.  It was the federal government, the Department of Defense, the General Motors of the world, and I'm using that metaphorically, that said, oh, we want to pile all kinds of heavy process and over head and documentation and all this stuff.  The reason they did it is because that's the way they already did business.

JV: Yes.

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?

JV: 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. 

JV: Right.

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?

JV: Yes.

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?

JV: 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.  

JV: Right.

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. 

JV: Right.

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.

JV: Okay.

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. 

JV: Sure.

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.

JV: Right.

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. 

JV: Right.

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.

JV: Yes.

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.

JV: Yes.

JD: The important part is what the organization or the corporation is doing.  Or, the government case, what the agency's doing.

JV: Sure.

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.

JV: Sure.

JD: It's a common term in software but it's not a common term in companies. 

JV: No.

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.

JV: Sure. 

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. 

JV: Right.

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?

JV: Sure.

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.

JV: Right.

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. 

JV: Right.

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.

JD: Exactly. So, companies can still start saying we want you to be level three to work with us because that's really ... CMMI is nothing more than a definition of how a great company performs.  The problem with it is when people use it to achieve a certification.  They start doing things that aren't great.  We want to use it as a way to improve the way we perform. So, we use it, we bang it up against the Scrum frame work and it turns out it makes Scrum super resilient and super powerful.  It gives us the ability to repeat it over and over again.  It gives us the ability to scale it at our companies.  So, when we apply CMMI to a project that uses the Scrum or Scrums approach, where we might have a Scrum team running seven, eight, nine, ten other Scrum teams, all in synchrony, the CMMI is the perfect too to make this work.  That's what we're focused on and that's what this message is about. 

JV: Got you.

JD: And the reception has been incredible. We're just flying all over the country doing this for companies.  Really, all over the world. We've just got so much going on, it's been crazy.  So, we're really excited about it.

JV: Very cool stuff.  Sounds very exciting.  So, any final things you'd like to leave our listeners regarding your upcoming presentation?

JD:: Well, I think that if you want to learn about immediate ways to strengthen your approach to agile, but not only that, make it scalable, and make it accepted by your senior management company, than this is the presentation you want.

JV:: Got you.  All right, Jeff.  Thank you so much for taking time out of your day.

JD:: Excellent, Jonathan.  I really appreciate the time.

JV:: Yes, definitely.

JD:: Have a great day.

JV:: You too.

 

Certified SCAMPI lead appraiser and CMMI instructor Jeff Dalton is an author, a consultant with more than twenty-five years of software process improvement experience, and president of Broadsword, a management consulting firm serving North American clients in the aerospace, commercial software, automotive, embedded engineering, manufacturing, and DoD market sectors.