Aligning Teams, Architecture, and Governance: An Interview with Dennis Stevens

Cameron Philipp-Edmonds: Today we're joined by Dennis Stevens, the co-founder of Leading Agile. He's giving a presentation titled "Aligning Teams, Architecture, and Governance." To start things off, first let me thank you for joining us today.

Dennis Stevens: Yeah, it's great to be here. I appreciate the opportunity.

Cameron:  All right. Can you tell us a little bit about yourself and your role at the company?

Dennis: I'm the chief operating officer and the vice-president of delivery at LeadingAgile. What that means is I have oversight over the delivery of all of our consulting engagements. LeadingAgile basically helps organizations transform their product development practices to lean and agile practices from whatever they're currently doing.

Cameron: Now you're giving this presentation. What led you to the idea of the presentation?

Dennis: One of the consistent challenges that we see in organizations that are trying to move to agile delivery is that the architecture, the way that they fund projects, the way the organization moves people around, the actual definition of their agile team, are all out of sync. They're all entangled together and was very difficult to make agile work to scale. We come up with a very clear way to talk about it and support that. The idea was to sort of come explain that model to people. I think it's a problem that will resonate with a lot of people and we'll be able to present the solution to them.

Cameron: Fantastic. Now your presentation talks about the importance of aligning teams, architecture, and governance to improve the team. With that being said, is it possible to succeed without having all of those aspects aligned?

Dennis: It just depends on what success is. When your architecture is really tightly coupled or there's business logic in a million places, or a bunch of people are updating things simultaneously. And you've got teams stepping all over each other, it's just going to increase your testing cycle on the back end, it's going to make your lead times to implement new features longer; makes changes to the product longer. When your funding model moves people around and you can't actually form teams because you've got to maximize resource utilization, companyies have delivered software successfully in these patterns forever. The difference is when you align them you're going to be able to move a lot faster or be a lot more predictable and improve your quality as you're moving through the cycle.

Cameron: There's three aspects there. There's the teams, architecture and governance. Are they all three equally important to have aligned or is their one that supersedes the others?

Dennis: That's a very interesting question. If I were building brand new product today you would want to form the teams around the architecture you wanted to emerge. You wouldn't end up in this conflict. In the circumstance where you've got architecture out of alignment today I would say you've got to form the teams the way that you want them today. I think teams is the first one. You've got to have teams, be able to fund them, keep them together, have them own parts of the product. I'm saying teams become the most important one.

Cameron: That's a great answer. What causes those aspects to become misaligned and is it easy to tell when they're out of sync?

Dennis: Yes. They get misaligned a number of different ways. One is when everything is owned by different people and they're trying to mitigate risk or have control over something locally. The architects building one thing, and you've got people trying to resources utilized in another place. Then you've got a governance model which is trying to put giant projects in and there is not a lot of time for planning. Often their run by different people trying to solve different problems. What's really interesting is in those cases that actually increases the risk of delivery while trying to locally optimize at each level. It's easy to tell when it out of sync when developers are stepping all over each other. You have lots of unintended problems when you deploy code. When you're doing six weeks of integration testing at the end the end of the six week development cycle. Things like that are pretty good clues that they're out of sync.

Cameron: So it's not just a general feeling you can also look at the numbers and the time it's taken, everything like that and that will indicate that you're out of sync.

Dennis: Yep.

Cameron: OK. You talked about parts there for a second there too and teams. In a lot of companies there are different parts of the organization that own different aspects of the project and that can limit effectiveness. Why do you think this is so common in so many organizations?

Dennis: Just because historically the way that we've siloed organizations, the way that we've formed organizations around functional expertise, the management of practices for the last fifty years have lead to those types of problems. Frankly, it made sense twenty years ago to do product development that way. The challenge is there's so much uncertainty in the products that we're building today that that model isn't effective anymore.

Cameron: With that being said, in your presentation you cite that inter-dependencies between team design, architectural design and governance contribute to organizations failing to reach desired business benefits. As you said it's kind of an outdated model, so a lot of people still think it's a good thing that parts of a complex organization are dependent on each other, but, that's not the case. Why is that?

Dennis: Yeah, so that's interesting. What we have to do is be very, very careful about how we define the interfaces between different parts of the business. When everything is too tightly coupled you can't move very fast. You have to change everything to make any change. I'm not sure that organizations think that inter-dependencies are a good thing. When I go to make a change in the way that I do cart and check out on a website and that breaks the way that I'm going to do inventory in a store, that's not a good thing. The fact that we have a shared understanding and some common services that are shared by each other if when designed properly works very effectively. Being able to reuse things and have shared capability is a good thing, but, having things too tightly coupled or having business logic spread in too many different places those just aren't good things. So the type of inter-dependencies and the intentionality around it are really important to resolve correctly.

Cameron: What is the time table one should expect for aligning the aforementioned aspects with the strategy of the organization?

Dennis: That's interesting too. Depending on where you are in the organization it can take years to fully decouple some of the complex parts of the business. One of the things that we'll talk about is the ability to come up with a road map to move the organization from a tightly coupled sort of place to an effectively decoupled place, to align the different aspects of the organization. You probably will never untangle a big complicated bank, for example, or a big complicated automobile organization. It doesn't make sense to invest in changing things that aren't going to change or are strategically important. So coming up with the road map and the plan for it can happen pretty quickly; six to eight weeks for a large organization and you come up with a pretty good plan for where you're heading. Implementing it can take years.

Cameron: So six to eight weeks to get the idea and then it can years depending on all the different variables, including size and how entrenched the organization is and how tangled it is?

Dennis: Yep and how much demand is coming on the organization. The big thing is whether people want to change or not and how broken some of the stuff is. Sometimes things are just so difficult to change there's no value in getting a whole lot better at it; that you should never untangle that part of the organization.

Cameron: When you say broken, do you mean it's been so entrenched in the company, they've been doing it that way for so long that it hasn't adapted or broken as in that it's not effective?

Dennis: Broken as in trying to change it is not effective. One of the things we've done in a lot of cases, you've got a mainframe piece of code that's been running for twenty-five years and has to keep running because the transaction volumes and how tightly it's wound into your third-party suppliers, we're not going to try to fix that at the mainframe level. A lot of times that's where you wrap service and things around it and allow the organization to evolve independently from that large legacy piece of code or infrastructure.

Cameron: In addition to being the co-founder of LeadingAgile, you're also a fellow of the Lean Systems Society, you've been published in Harvard Business Review, and you were awarded the Naval Commendation Medal by the Marine Corps during Desert Storm. By all accounts, that really makes for an impressive CV and I had to brag about you a little bit there. What does the future hold for you and your career?

Dennis: What we're really enjoying doing right now is just building the business. Being an entrepreneur, trying to figure out how to apply it to our business and our model some of the things that we're consulting with for the organizations. I think in the future you'll see more start-ups and more effort building new products and new business models.

Cameron: I look forward to that. Getting away from software for a second, I was reading your little biography piece here, and you attended college on a violin scholarship. Do you have a favorite violinist?

Dennis: Isn't that funny, I can't think of his name right now. I wasn't prepared to answer it. One of my favorite stories about him is he came out of Carnegie Hall where he'd been playing, some lady came up to him and said, "I would give my life if I could play the violin like you do." He responded to her, "Well I have."

Cameron: Oh, that's a good quote. I like that. All right. Now do you still play any instruments?

Dennis: Little bit of guitar. Little bit of piano. Still have my violin, play it pretty frequently. I can also play the baritone; I haven't played that in a long time. Yeah. A little bit of music still out there.

Cameron: All right. Fantastic. Now you also were a rugby player, which makes you pretty well rounded, kind of a jack-of-all trades. Are there any other hidden talents you're keeping secret?

Dennis: Yeah. Over the last ten years I've gone and gotten my bareboat sailing license. I've been working really hard at learning to sail. I intend to do some sailing around the Caribbean and maybe some sailing out in the Pacific sometime in the future. That's my next thing that I'm developing, is sailing sort of a large off-shore boat.

Cameron: That's pretty awesome. As one last question here, you cover a lot of different things in your presentation, teams, architecture, governance; three really important parts. Is there anything you'd like to say to the attendees of Agile Development Conference & Better Software Conference East before they the conference and before they come to your presentation?

Dennis: Yeah. I think one of the important things to sort of understand is that the problem that we're solving with agile at LeadingAgile, is not small teams building products in an independent sort of fashion where there's not a lot of challenges. What I'm talking about is what large companies that have been building complex systems for a while are trying to solve. And frankly, I think thats a bigger problem and more interesting problem for most organizations than how to make agile teams effective in an independent sort of way. What's interesting is if we work through this right, Cameron, is we'll get to where we can have those types of independent agile teams work effectively in the organization. But it's quite a long process to get there.

Cameron: All right. I think the process will be well worth it. Once again, this was Dennis Stevens of LeadingAgile and he's giving a presentation at Agile Development Conference & Better Software Conference East 2014 down in Orlando and his presentation is titled "Aligning Teams, Architecture, and Governance." Make sure to check it out. Once again, thank you so much Dennis.

LeadingAgile cofounder and vice president of delivery, Dennis Stevens is passionate about how leadership, organizational design, governance, and enabling technologies can increase organizations’ ability to create value for their customers. Dennis spends most of his time contributing to LeadingAgile’s approach and supporting delivery to their clients. He was on the steering committee that created the PMI-ACP certification. Dennis is a fellow of the Lean Systems Society, has been published in the Harvard Business Review, and was awarded the Naval Commendation Medal by the Marine Corps during Desert Storm. Dennis originally attended college on a violin scholarship—and played rugby.

Podcast Music: "Han Solo" (Captain Stu) / CC BY-NC-SA 3.0