Current Episode

Episode 20:

How do we remove silos when doing government contract work using Scrum?

Ed works for a government integrator and is finding it very difficult to deliver thin vertical slices of functionality every sprint. The difficulty is that, by law, his company cannot have access to the full system they’re working on. I’ve enlisted the help of my friend Patrick McConnell, who’s an Agilist with tons of government experience to help me tackle this thorny issue. While this question mainly applies to government integrators, the discussion will likely spur some ideas on how you can help remove silos in your organization and improve your definition of done.

A non-scrum related note about Patrick: He was on an episode of Marketplace. The episode is charming and wonderful. You should listen to it:

How awesome is your Daily Scrum?

Looking for scrum course?

Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.

Do you have a question for the show? Submit it at

Leave a Reply

Adam Weisbart: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and Agile Coach. Each week, I get your questions about Scrum and agility and I answer them here, on Agile Answers.

This week, I’ve got a pretty specific question. Well, I guess all the questions are specific, but specific to a particular industry. And while this episode pertains mostly to folks that are in that industry, which you’ll hear about in a moment, I think it pertains to everybody, especially organizations that are adopting Scrum that have current processes in place and are struggling a little bit with adoption. This idea of delivering thin vertical slices of functionality can be challenging for any team, especially teams that are working within the government space, which is what our caller is talking to us about.

Thankfully, on the show today, I have a friend of mine. Patrick McConnell is an Agilist and he does a ton of work in the Washington, D.C., area, working on a bunch of government contracts and stuff with government integrators and the like. I brought him on the episode to answer the question with me. But before we jump into the answer, well, let’s listen to the question. I think that would probably be useful.

Ed: Hey, Adam. This is Ed. And I work for a company who does government contracts. And according to the Scrum Guide, we should be delivering thinner, vertical slices of functionality every sprint, not just components that we will tie together later. Trouble is, due to the nature of our contracts, we do not have access to the full system, only our part. So do you have any tips for successfully doing Scrum in this situation? Thank you.

Adam Weisbart: Hey, Patrick.

Patrick McConnell: Hey, Adam.

Adam Weisbart: It’s good to have you on the show.

Patrick McConnell: Thanks for having me.

Adam Weisbart: I get this question really often. And you have a really, really deep knowledge of government work, having been in it for quite a while. So I thought I’d have you on the show to see what your tips and tricks were for this situation. It might be useful for people to know a little bit about your background, though. So if you wouldn’t mind just giving a couple of second intro, that’d be great.

Patrick McConnell: Thanks. Yeah, I’ve been a professional Agilist, doing agile-based delivery for the better part of 10 years now, working as a product owner first, and then a Scrum Master on teams, and then as a coach and trainer. And now, in addition to doing that work, I also direct an Agile Center of Excellence for a very large government integrator. So I serve and coach engagements all across primarily the U.S. Federal Government practice.

A problem I’m really used to is where we have a very long, very attenuated value stream, where one vendor working on one…you know, on behalf of one chunk of the government builds a thing and two or three other vendors are responsible for validating the thing, and proving that it works in some environment and doing things like user acceptance testing and 508 accessibility testing and all sorts of other validation and verification before it can finally touch our productions environment which we also aren’t allowed to touch or run.

Adam Weisbart: Right, so all of these are different vendors who’ve won parts of this contract?

Patrick McConnell: Right. So it might be, you know, 3, 4, 5,7, 8, 9 different companies supporting one chunk of government or several chunks of government trying to work together.

Adam Weisbart: So when this happens in a private company, the solution is to get those teams working well together. Usually, the argument is well, we can’t do that because it’s a different division or a very large company. But even in that situation, it’s all under one company, even if you’re using outside vendors, they work for you. In this situation, you have 5, 6, 7 different vendors that are working for the government, they’re all competitors, and there’s probably not a huge benefit to them working amazingly well together.

Patrick McConnell: That’s true. In fact, the original impetus for how this kind of situation came to be, at least in public sector work, was that the government realized, especially U.S. Federal Government realized that…they felt there was too much risk having all of this work be tied under one single house. So they thought that they were mitigating the risk by splitting up this kind of stuff across a bunch of vendors. What that means is that now, not only might there be contractual firewalls across development versus delivery versus sustainment, there might even be regulations or legal firewalls between those steps where we’re not allowed by statute to touch some other aspect of the work, because it could be seen as a conflict of interest or something.

Adam Weisbart: Sure, so that’s the sort of thing that you don’t usually run into within private organizations. And so the stuff we’re going to talk about now, the solutions for this, just to be very clear, I wouldn’t…even if your problem sounds a lot like what we’re describing, and you’re not specifically working in government contracting, the solutions we’re talking about here are not the solutions you should be using.

Patrick McConnell: Yeah, don’t set it up this way on purpose.

Adam Weisbart: It would be much better to figure out how to remove impediments. In this situation, however, we don’t have any control over the impediment. Do you have specific approach when you run into this problem? Because I’m sure you run into this all the time.

Patrick McConnell: Sure, so for me, there’s kind of three layers of strategy here. There’s like a what do we do right now kind of issue. There’s a what do we do, a little bit longer term or medium term. And then there’s the ultimate long term goal of how we get around this.

So let’s start with the nearest one, which is first things first, what we try to do is use tooling to get around some of the handoff issues. So for example, there’s this thing called 508 accessibility testing, where if it’s a public-facing website that I’m building on behalf of the federal government, I have to prove that people who can’t necessarily, let’s say, see or hear or need other adaptive mechanisms to do work aren’t impeded by the design of that work, website or whatever the application is we’re using it.

Adam Weisbart: So screen readers have to be able to read, etc.

Patrick McConnell: Right. And the weird thing that sometimes happens is the people responsible for doing 508 testing won’t tell us what tools they use. Or we can’t afford to buy the same validators that they’re using on that particular contract or whatever it is. What we do is we find ways to pull in as much of the same validation work that they’re doing within our sprint, so that we’re still pretty sure that we’ve delivered something that will meet their definition of done even if we can’t prove it or we’re not allowed to prove it ourselves.

Adam Weisbart: So your team has a pared back definition of done, just for their specific work, and the stuff that you can assume that other contractors will be testing for, in this case for accessibility.

Patrick McConnell: Right. So the definition of done might be scaled back from potentially skippable down to suitable for the 508 folks to look at and not be confused by. We’re definitely talking about how do we deal with an antipattern that I can’t immediately remove, not a recommendation for how to set things up.

So that is definitely, though, a short-term solution because we’re not really delivering value. We’ve delivering a ghost of value. And we get trapped in this yoyo pattern where we’re building stuff and we hand it off to whoever the next party is. But we don’t actually know that it’s done, so while we’re in our next sprint building us some new thing, they could come back to us and say this isn’t done yet. Well, we’re a good Scrum team, so it’s not like we take that work into this next sprint, but the sprint after that, we will pick this work back up. Which means we’re always doing some new stuff, but fixing things from two sprints ago that we thought were done, which is uncomfortable and painful and annoying.

Adam Weisbart: Right, so if you’re in the private sector, the answer would be well, you don’t have a good definition of done, that’s why you’re running into this and you’d fixed your definition of done, but again, because of the nature of how things are set up, you don’t have a choice.

Patrick McConnell: Right. So that’s…short-term solution is we’re forced to pare down what definition of done means within, basically, it’s a little fit within our contractual swim lane.

The slightly longer-term vision of how we deal with this has to do with visualizing end to end how long this attenuation is actually adding to the process of delivering to production so that when the stakeholders beyond our direct customer show up and they’re mad about why we aren’t delivering faster, we can say to them, “We would love to deliver faster, but it takes us this long to build a thing and then the rest of the chain past us is this, which allows us to focus attention on basically the effects of this antipattern, and gives us leverage to say, “Look, we understand that there might be some regulatory issue that prevents us from doing our own 508 validation,” using that example again, “but if we had the same tools they did, we could run it through the same tests ourself in the sprint, so even if it still needs their formal stamp later, we know it will pass.” And now, we’re not getting surprised with stuff that they find.”

We can do the same thing for security screening, all sorts of other stuff. So we’re kind of growing our definition of done, even if it’s still not a formal [inaudible 00:09:43] stamp.

Adam Weisbart: Yeah, I’ve run into that in private sector work in that the company that I was helping adopt Scrum, the product we were building, they required that we send it to the testers who were in China to test the product. And so we said, well, that’s fine, but we have a tester on our team, so you may be spending extra money that you don’t need to actually to spend them. They said, “Well, we still need to send it to China.” Ang pretty quickly, within a month or two, they discovered that China wasn’t finidig any bugs, therefore they could stop paying Chia for at least for the work that they were cranking out for the teams that they were using Scrum yet. So similar to that, so even people working in the private sector could benefit from building that into your work, of course.

Patrick McConnell: Of course. And of course, tooling is only half of the problem, right? So the other half of this is relationships, and getting everybody else involved, even if, technically, we’re competing vendors, to understand that none of us look good when one of us fails. Because if any of us are letting the side down, as it were, no one is delivering value to prod. It doesn’t really matter who’s fault it is, the customer’s gonna get mad at all of us. So we do have an incentive to figure out how to play nice together, even if we’re technically competitors.

Adam Weisbart: That’s the short-term, yeah?

Patrick McConnell: That’s the short term and kind of medium term strategies.

The longer-term strategy is a little more economic Darwinist, which is that the easiest way to fix this problem is by making the divisions between parties go away. And in government services, typically, that means by taking the other group’s work, one way or the other. We do that, typically, through building a relationship with the customer and showing them how much faster and sometimes, how much also cheaper things would be if one house was doing all of these steps, because then, we can do them all in a single sprint. And so anything that we said was done at the sprint was for real done, all the way to a potentially shippable state. And we would know that in two-week increments, so that there would never be this big yoyo-ing lag between feedback of does it work before we can answer the does it meet the need question.

Adam Weisbart: Right, sounds a lot like customer collaboration over contract negotiation.

Patrick McConnell: Yeah, isn’t that amazing?

Adam Weisbart: Strange, huh?

Patrick McConnell: Yeah. It’s a little risky, long-term, because the way you consolidate this work is convincing someone to combine a bunch of contract scopes, and there’s no guarantee that we’ll be the winner of that eventual bid, down the road. It could be somebody else, it could be one of the other parties already involved, it could be someone who’s never done this before and isn’t’ involved at all today. And also, when I say longer-term, that might be five years from now.

Adam Weisbart: Well, if nothing else, five years gives you plenty of time to build the relationships. If you could just review the three steps that you recommend, people will leave the podcast with a good understanding of the actionable steps they can take if they’re in a similar situation.

Patrick McConnell: Sure. So again, in immediate term, we’re probably paring back our definition of done to meet whatever the current end of our scope is.

Adam Weisbart: Again, don’t do this in a private company. Just have a good definition of done.

Patrick McConnell: The medium term, we’re trying to bridge those gaps across all of those interested parties through personal relationships and through tooling.

Adam Weisbart: Fantastic thing to do in your private company regardless.

Patrick McConnell: And then longer term, expanding scopes so that all of these activities are within a single actor.

Adam Weisbart: And hoping for the best that you then win that bid.

Patrick McConnell: Exactly.

Adam Weisbart: Fantastic. All right, well, how can people get in touch with you if they have some government-specific questions?

Patrick McConnell: They can submit another question to your show, or they can look me up on LinkedIn.

Adam Weisbart: Awesome. I’ll put the LinkedIn, your LinkedIn information in the show notes, so anyone’s welcome to check that out. Thanks for coming on the show.

Patrick McConnell: Cheers!

Adam Weisbart: It’s good to have you.

I’m so stoked that Patrick could join us for the episode this time around. He’s a fantastic guy, with super deep knowledge of government integration work, and it was great to have him on the show. And Ed, thank you for submitting your question. Even though it was pretty specialized, it only pertained to a certain set of Agilists, I think the lessons we take away from it can be useful elsewhere, even if we are not working in the same space. So thank you for submitting it. And for submitting it, of course, you’ll get a pack of my Agile Antipattern Cards, which I’m sending out to you now.

If you have a question, like Ed did, even if it’s super specialized, don’t hesitate to submit it. Go to, and right there on the home page, you can submit your question which I may answer on a future episode. If I do, you’ll get a deck of my Agile Antipattern cards as well.

Thanks for tuning in. Can’t wait to talk with you next week. Until then, stay agile. Never change.

Past Episodes

Episode 24:

What should we do instead of painful “Annual Planning”?

Episode 23:

Agile Virtual Summit Preview: Lyssa Adkins

Episode 22:

How do we make sure we have cross-functional teams and why does it matter?

Episode 21:

What agile practices can you recommend to our game development studio?