Call me Jeff — or anything other than Agile Coach

Department of State Change of Name form
Department of State Change of Name form

What happened to all the Agile Coaches?

Over the past year, dedicated agile contracts and, specifically, Agile Coach and Scrum Master roles seem to be disappearing from the federal acquisition space. Should Agile Coaches and Scrum Masters look elsewhere for work? Is agile dead in the federal space? 

We don’t think so. 

The Federal government’s approach to project management has evolved. When agencies decided to experiment with agile product delivery, there was knowledge to baseline, pilot programs to launch, and a steep learning curve to climb. A strict approach to agile was needed; it was a place to start. 

Now, agencies across the Federal space know what agile is and don’t need someone to come in and explain it to them.  They understand the value of collaboration, continuous communication, and flexibility. They’ve incorporated iterative development and product management into their delivery practices. (And frankly, people are probably sick of agile evangelists shoving agile lingo and strict practices down their throats.) 

Though the names have changed, the roles remain largely the same.

Agile and its roles, per se, haven’t disappeared, but is instead being embraced as a cultural and strategic imperative. Its principles are evolving into the DNA of the agencies. We’re seeing language like digital transformation, product-centricity, and human-centered design used in RFPs. The government is moving away from purchasing Labor Categories (LCATs) – Agile Coaches and Scrum Masters– to purchasing product delivery teams. Agencies know they want product development done a certain way and are expecting their vendors to bring their high-performing team to lead the effort.

So, instead of agile call it Product Delivery or Organizational Excellence. Call us former Agile Coaches and Scrum Masters by a different name– Facilitator or Product Manager or Organizational Designer. Hell, call us Jeff.  Just keep embracing the values of great product delivery and continuous improvement– by any name you want to call it.

Agile Acquisitions

Darren Hoevel talking to Johnathan Mostowski and Bryan Miles over Zoom

Darren Hoevel, President of Pliant Solutions, talks with Johnathan Mostowski, Founder & Principal of Agile Acquisitions, about aligning government acquisitions to support agile product delivery.

Moderated by Bryan Miles, Principal of Leadership Development at Pliant Solutions.

Darren Hoevel talking to Johnathan Mostowski and Bryan Miles over Zoom

Youtube: https://youtu.be/MaclzGSRfXE

Jonathan Mostowski (00:05): Hi, this is Jonathan Mostowski. I’m a former contracting officer. Spent about 13 years at the National Geospatial Intelligence Agency. During that time, I discovered some new models around new, at the time, models around acquiring agile development services and modern technology. That led to me co-authoring the Tech Far Handbook, and then being recruited over to the US Digital Service. In the early days, I spent about four and a half years there, three of which focused on the Defense Digital Service before leaving to help start a tech startup focused on selling software to the Department of Defense. And now I lead a consulting company called Agile Acquisitions, helping the federal government and companies come together around agile adoption and implementation in the contracting and procurement world.

Darren Hoevel (00:53): Thank you, Jonathan. My name’s Darren Hoevel, president of Pliant Solutions. Also on the ground with our clients trying to leverage agile practices, organizational design, change management to ultimately bring operational excellence and good product delivery practices. I’ve been lucky enough to partner with Jonathan and on a current client in bringing acquisition best practices as well as how to implement them at the brass tacks level. So the contractors, the product owners are all in line engaged and willing as much as possible.

Bryan Miles (01:32): And, hi, my name is Bryan Miles. I’m principal of leadership development and coaching at Pliant Solutions. And I’ll be facilitating our conversation between Jonathan and Darren today. So thanks so much for making the time. Just wanted to start off this conversation with a little bit about Agile acquisitions. Can you give us just a summary of, you know, the bottom line of what are agile acquisitions and why are we moving to them?

Jonathan Mostowski (02:01): Sure. So, you know, agile acquisitions, just like agile development, is about continuous learning and iterating to prioritize the highest needs. So we just apply those same principles to the acquisition process. As I’m sure you know, the, the government procurement process is a complex labyrinth of rules, regulations, and policies. But it’s also sort of shrouded in a lot of myths and sort of doing things as they’ve always been done. So what we do in agile acquisitions is take best practices that we’ve learned from various agencies various implementations and requirements, and try to simplify and make more efficient the process to get both to the acquisition and then the execution. At its basis, there is no such thing as a truly agile contract. A contract is supposed to enable the delivery of agile development services. So the idea is to separate the contractual requirements from the technical requirements and allow the product owner who should be empowered to direct the delivery the flexibility they need so they’re not constantly running back to the contracting shop to make changes every time prioritization change.

Darren Hoevel (03:14): And I think the other part of agile acquisitions is bringing agility to the contracting process, which is really bringing everyone together, not handing things over the fence. Bringing your core, your CO, your business stakeholder, your product owner, hopefully the product owner’s already been identified, and have them part of the, contract creation process, sharp vision, sharp objectives and outcomes, and baking that into the contract writing process. It’s not an OIT problem, it’s not a business problem. It’s all of our problem to make sure the contract is aligned to the outcomes you’re trying to create. So where we’ve been coming in is facilitating those conversations, not being the subject matter expert necessarily in what they’re trying to do, but more in to try to bring them together as a group versus a phase gate or handoff process, which is what we’ve seen in a lot of agencies in the past. What they’re buying doesn’t matter, uh, what services they’re trying to drive. It’s really is bringing everyone together getting on the same page from the get go. ‘Cause once it’s written into the contract, there is flexibility, but there are some hard deliverables often times and outcomes that’ll lead where the delivery team goes once they get on board.

Jonathan Mostowski (04:37): Yeah, that’s a great point. Agile contracts are notexclusive to agile delivery. You can be more agile in the procurement process for any type of requirement. And it’s, it’s really all those things that Darren just said. But in addition, it’s also about, you know, simplifying the upfront process. So historically where we’ve attempted to detail every possible delivery in the exact way we want it delivered, how can we step back from the process, be very explicit about what we’re at trying to achieve under the endeavor, and then allowing industry to be creative, which is why we’re hiring them in the first place. They’re the experts. Allow them to use their creativecapabilities and innovation to bring the best solutions.

Bryan Miles (05:20): I’m wondering if you can just walk us through sort of a scenario to help, to help us understand more about agile, you know, contracts. So, you know, traditionally in the, in the government contracting world, we would say, we have a hundred million dollars to go build this thing, right? We wanna, we wanna build this software program that allows people to put in applications for a federal job, right? We have a hundred million dollars to do it. Can you walk us through what that would look like? How we would sort of structure that contract from a traditional, traditional contract into more of an agile type of contract?

Jonathan Mostowski (05:56): Sure. I think the first question I would ask is, one, what are we trying to optimize for? Is it speed to contract, speed to delivery? Is it price? Is it innovation? What are we, what are we actually trying to get to? Uh, the second thing I would ask is, you know, when are you expecting delivery for this a hundred million dollars capability? And my expectation based on about two decades of experience is probably no less than five years and probably closer to 10. And so from there, I would probably ask if I were to go back 10 years and ask, what would you like your cell phone to look like? Or How would you like it to perform? And then handed it to you today, how happy would you be? And that’s where I’d probably start to frame the conversation, because where we want to go to next is you probably don’t know what you want for a hundred million dollars five years from now.

You have an idea, you have a vision of where you want to get to. You have an objective that you want to achieve. And so that’s where we would start. Typically on the specific client that Darren was mentioning where we start is we actually do a product vision session. So, you know, it’s like a seven minute training. Let’s just make sure we all understand what a product vision is. It’s not just the product owner, it’s the integrated stakeholders. We get together, we do this quick training, and then we actually walk through building the product vision statementas a team. And what’s so fascinating about that is, even though they will all generally show up thinking they know exactly what they want and are in agreement, we typically find out very quickly, they all have a very different understanding of where they’re trying to get to.

And so that session, which is about 30 minutes in most cases we really get to a solidified agreed to vision, which is the most important place to start. And from there, we would work through, from that vision to a similar session around a statement of objectives. And a statement of objectives differs from the statement of work. It’s not a bunch of shall statements, it’s not the exact end state we’re, we’re driving to. It’s literally the objectives. What is the, what are the outcomes we’re working towards? And from there, it really ties in closely to agile delivery. It’s not what do we want five years from now? It’s what do we, where do we wanna start? What is the first minimum viable product we want to deliver, hopefully, into our hands of users. Now, a lot of agencies have their own sort of way in which they can and can’t deliver quickly.

Those are some of the obstacles that we work very closely together to try and help the agency mature past and, you know, things like security how quickly they can roll capabilities out. And that’s part of what we do with the agency. But sometimes you have to operate within the existing structure and meet your users where they are. So we will take that objective and formulate a statement of objectives. And then it really comes down to human-centered design. Let’s talk to industry. Let’s have really open dialogue in our market research. Not just send out an RFI and get back a bunch of comments. We really want to engage deeply with industry. We want to engage, engage deeply with end users and make sure that, you know, we understand what’s most valuable and most important to them. From there we would determine what acquisition strategy.

Those are some of the obstacles that we work very closely together to try and help the agency mature past and, you know, things like security how quickly they can roll capabilities out. And that’s part of what we do with the agency. But sometimes you have to operate within the existing structure and meet your users where they are. So we will take that objective and formulate a statement of objectives. And then it really comes down to human-centered design. Let’s talk to industry. Let’s have really open dialogue in our market research. Not just send out an RFI and get back a bunch of comments. We really want to engage deeply with industry. We want to engage, engage deeply with end users and make sure that, you know, we understand what’s most valuable and most important to them. From there we would determine what acquisition strategy.

Bryan Miles (10:05): Great. Darren, can you talk a little bit more about your experience with the difference between the statement of objectives and the statement of work?

Darren Hoevel (10:13): I think it, you know, I think the long short of it is you’re trying not to predict the future. We’ve learned time and time again, both on the contractor side, but also partnering with our federal agencies is like, we just don’t know. So in Jonathan’s example, how much modernization is part of that hundred million dollar project? Do you need a CI/CD? Do you need DevSecOps? Do you need the tools in place, or do you already have ’em, they just haven’t been configured or used correctly or in such a way at an enterprise level? The statement of objectives have been great in trying to figure out, what are your objectives? What are the outcomes you’re driving towards? And gives, as Jonathan stated, is give your contractors, the people you’re paying a lot of money for the room to show off their capabilities, their innovation, their creativity to get you to that outcome.

Because if you could have done it yourself, you probably would have. And there’s a lot of shops that don’t have their own development staff, their own delivery staff. So you’re even more dependent on the capabilities of your contractors to do so. So you focus on what you’re good at, which is the vision, the business need, the outcome on the federal side, and then bring in the talent, um, to execute on the, what I say is the, the what and the how to deliver against those objectives. In a statement of work you’re taking a lot of ownership on not only what is the vision, what are the outcomes, but then you’re having the solution inside the contract and giving yourself no chance to change your mind, no chance for flexibility.

And you’re really sort of downgrading whoever you bring in from a contractual perspective, but a contractor perspective. ‘Cause they’re limited to those thou shall statements. And I know there’s ways to adjust that, but why even waste your time doing it upfront when you can really drive from a statement of objectives perspective, versus, you know, tying people down through a statement of work or taking that burden on yourself when there’s probably maybe smarter people that can figure this out for you. And I always say is waiting until the last responsible moment is sometimes you don’t know what you need until it’s closer to you. And then you can have a team that’s capable to deliver against that need when you have more information, more data, and smarter decisions.

Bryan Miles (12:55): I love what you’re both are saying and one thing that we haven’t covered yet that I think we should is, you know, what is the problem that we’re trying to solve here? What is the problem that traditional acquisition process has that we’re trying to solve with agile acquisitions? Can you speak on that a bit? Just wanna <laugh> go back to that and make sure we, we covered that.

Jonathan Mostowski (13:18): The problems in the acquisition space is a target rich environment. So, we could do a whole series on that of what we’re trying to solve. But if I were to try to summarize it in a short bit here, I would say we spend an exorbitant amount of time and resources attempting to bring in capabilities into the government. And typically we don’t have the answers ourselves. That’s why we’re outsourcing it. But the traditional process of acquisition starts from an assumption that we in fact do. And the result is a lot of resources for a capability that the GAO has reported consistently over the last decade is typically and when I say typically around 90% of the time, unsuccessful from a cost schedule and performance perspective, that’s what we’re trying to solve is if we can take those resources and realign them to deliver the things we actually do know to focus on, where are we trying to go?

How do we get the best vendor in and how do we enable the entire team, the vendor and the government team to deliver in such a way that they can take advantage of new technologies as they arise, new requirements as they unfold. And while this isn’t truly a contracting challenge, when I hear acquisition, I think big A and little, a little a is contracting big A is the acquisition sphere. One of the main challenges we face is the product owner role is not a true government role, like a job series in most agencies. And so we anoint people as a product owner. They might have been a project manager or program manager when they went to bed or a Core, and the next day there’s magically a product owner. And that’s a very specific skillset. And so this capability that we build out in the Agile acquisition process only works as well as it’s managed on the execution side.

How do we get the best vendor in and how do we enable the entire team, the vendor and the government team to deliver in such a way that they can take advantage of new technologies as they arise, new requirements as they unfold. And while this isn’t truly a contracting challenge, when I hear acquisition, I think big A and little, a little a is contracting big A is the acquisition sphere. One of the main challenges we face is the product owner role is not a true government role, like a job series in most agencies. And so we anoint people as a product owner. They might have been a project manager or program manager when they went to bed or a Core, and the next day there’s magically a product owner. And that’s a very specific skillset. And so this capability that we build out in the Agile acquisition process only works as well as it’s managed on the execution side.

And the coaches that Darren has been able to bring along, it makes the effort worth it. And it’s what makes it, it’s like the secret sauce. It’s getting people to not just be able to do it, but to learn. So it’s not just, you know, help pay this contractor and they’re gonna tell you all the right answers. It’s, it’s an education on the job where now once they learn, we can move to the next group and, and maybe have touch points, but we know that that program is in good hands and good health.

Bryan Miles (16:25): What I love that you’re saying is that the partnership between the contractor and the agency and it feels, you know, a little bit different. It feels, you know, a lot of times in the past my experience has been, it’s just been, go build this and here you go. And, you know, and that’s sort of the typical waterfall model that Agile is trying to move against. And I’m interested in if you could talk a little bit more about those partnerships and maybe, you know, some experiences about how that partnership between industry and and government has really, uh, improved the, the situation or really built up, um, you know, a better product.

Darren Hoevel (17:07): I can start with this one, Bryan, um, is what the culture, um, the structure and what we like to call the operating model needs to shift or is shifting depending on what agency you’re at in the federal government. And so, as Jonathan pointed out, is what we’re trying to do is drive the federal partners and product owners to lead the vision of the product. And usually a product is a cluster of applications and technology that solves the business problem. So it could be beyond just one application. It could be one application, it could be many point being is it is providing a service or to the federal government based on a business need that they have, um, having that person be accountable on the federal side for that vision. And then partnering with the contractor, that capability they’ve brought into the agency to drive the solutioning of the technology to meet the business need based on the vision of the product owner.

So the great part about it is there’s very clear roles. The accountability becomes even more on the federal side to lead the vision and understand the business needs come even more clear on the contractor side on what the solutioning and sort of what we call technical excellence or product delivery excellence. But it takes both of them to come together on a consistent, regular and constant basis to always make sure we’re building the right thing, building it right, and then building it fast. And everyone contributes to all three of those factors in good product delivery.

Jonathan Mostowski (18:50): Yeah, I can add maybe a different perspective to that answer. When I think of the partnership, I think it kind of starts with the team, the forming of the requirement as we talked about previously, but also with industry. You know, a lot of times when we talk about, you know, agile adoption and we talk about these non-traditional vendors getting new blood into the federal government and in that is sort of like an implicit undertone of like, traditional contractors are bad and they’re not bad. They’re a reflection of the government that they’ve been supporting for a hundred years. So they have built these large companies to do exactly what the government has asked them to do. And now we are helping the government change their perspective on how to do this.

And these are now very large ships, much like the government. It’s hard to turn. And you’re starting to see even the more traditional companies are trying to adopt these practices, it’s gonna take time. Um, we’ve set them up with pricing structures that makes it hard for them to attract top talent. ‘Cause they’re stuck under vehicles with specific rates. So I don’t think, I don’t think there’s sort of a intentional misalignment here. It’s, we’re asking them to do something different. So in the near term, obviously there’s value in bringing new companies in and companies that in their DNA, this is what they do. And so a lot of times that’s where we start. But we have to be mindful of how do we help the entire ecosystem change. Because we can’t do this without our traditional vendors.

They are very much a part of this ecosystem. We need them to come along this journey with us. Andso I think it’s just this open engagement transparency is so incredibly important to this process. And what we’ve found, I think Darren would agree, is like when we take the time to actually sit with our vendors and explain where we’re trying to go, how we want to get there, why this matters, what technology makes sense, not the specific solution, but the nature of the technology, it’ll be cloud hosted, it’ll, we’re gonna use a CI/CD pipeline we’re going to automate testing when we’re very explicit about what our needs are and why we’re doing it. I think industry is more than happy to meet us where we are. And so I think this sort of partnership is all about conversations and transparency. And going back to a comment Darren made earlier, getting away from this approach of throwing things over the wall and say, bring me a rock, and hoping they come back with the right rock, because that rarely ever works.

Bryan Miles (21:20): How have we seen sort of those bigs in the contracting space, how have they been embracing this or is there resistance or how do we sort of move them into this new cycle? And what are some successes that you’ve had around that?

Jonathan Mostowski (21:39): Yeah, certainly there was resistance in the beginning, right? Like, we’ll bite our time. This is another fad, it’ll go away. That is definitely changing. I’ve had conversations with multiple large companies that are all in, how do we do this? We wanna rebrand, we wanna restructure, you know, what can we do to change the perception of who we are? So they’re getting there, there’s a lot of acquisitions of smaller companies occurring. I think that’s a good thing, right? They’re trying to inject the DNA into their companies. So I think the trend is there. I think that everybody acknowledges whether agile is the final answer. Innovation and iteration is the final answer. We are going that way, regardless of what you call it or what brand you stamp on it. So I do believe we are moving there. Like I said, it’s going to take time.

Everything in the government takes time and we need to get the wins we can quickly.The value flywheel suggests, you know, these small wins will enable the greater movement. And so that’s what we’re doing. But it’s not a matter of like, cut these people out and just work with these type of companies. We’ve gotta bring everybody along. And I’ve had a number of examples where I’ve worked with large businesses that they’ll create separate entities within themselves that are purely dedicated to this type of development. And so I think that’s part of the answer as well. It’s a multifaceted approach.

Bryan Miles (22:56): That’s great. What’s in it sort of on the government side, but what’s in it for these contractors? Like what, what’s in it to motivate them to wanna change and, and move in this new model?

Darren Hoevel (23:11): Yeah, I can hit on this real quick. I think the easy answer is their future. This is the new expectation. You know, the people that we’re working with now, the agencies we’re working with now that are just adopting agile, or agile practices, you know, incremental, cloud, like they’re late adopters. Period. And so if they have contractors supporting them, they’re even later adopters. So things like, workforce enablement isn’t just a fed word. It’s like Jonathan shared. It’s showing up on both sides of the street, both federal and contractor, of how do we up our game? How do we increase our capabilities and services in these areas knowing that that is what good product delivery is. Period. When you’re looking at, you know, I’d say products in general, but definitely from a software perspective is this is not the wave of the future. This is the wave of yesterday now. And this will evolve moving forward.

Jonathan Mostowski (24:10): I think it’s probably worth addressing sort of the culture and leadership components of this. So, I think it’s fairly obvious from like senior leaders. You know, they say the right things. They want to do the right thing. They wanna move their agencies forward to meet the mission in, in the most effective way possible. And we see on the front lines, the people who are using the technology, they just want better technology. I mean, they expect it, they see it in their everyday life, and then they show up to work and they’re using outdated, practically inoperable systems to get their job done. And they know it doesn’t need to be this painful. So it’s how do we move sort of the, the middle section of an agency along this journey? And it’s, again, it’s not because they’re bad people or they wanna hold an agency back.

It’s that sort of the middle layer of a bureaucracy, which is what large organizations are not a bad term necessarily. The middle layer of the bureaucracy’s job is sort of, it’s to prevent like wild, crazy ideas jerking the, the organization left and right every day. ‘Cause that’s a waste of resources as well. So it’s how do we affect the larger culture of an agency? And the way in which we do that one is, is sort of the value flywheel I mentioned which is just demonstrating success at the smallest scale possible and building and growing off of that is one. Two is sharing experiences. Where has this been done elsewhere? You’re not the first person over the ridge. How can you take lessons learned from other organizations? And the third is, you know, what is in it for them and what’s in it for them is more efficiency.

And more efficiency means more resources, which means they can accomplish greater good. And I believe most, if not all civil servants joined their agencies because at the end of the day, they want to do good. They wanna do right by the organization’s mission. And so a culture change from the top down at all levels is, what is the key ingredient to all of this? Who is able to take responsible risks understanding deeply, you know, the rules and regulations that you have to follow, how close to the outline can you get and make change without going over the edge? And it’s a careful process that you have to do with experience. And people who have gone through this before I mentioned having the coaches, having people alongside you. A recent study came out that, like most Fortune 500 organizations said, coaching is the most important aspect of their organization, that they rely on it. And it’s not because you have someone cheering you along, it’s because you have someone who has taken the missteps before and can walk you around kind of the landmines and the trip wires and say, I know how this goes. Let me give you some advice on how you can implement this in your specific organization. What’s the flavor that’ll work for you?

Darren Hoevel (26:52): Yeah, yeah. And hit on that point, an example. Jonathan and I are working with a client now and just, you know, the adoption of the18 F’s QASP and getting to the end state that the QASP demands would’ve been just much, way too much for the agency that we’re working with and their contractors. And so building things like progression on how do you get there, and being okay with the fact that we’re not gonna get there in one step. It’s gonna be a two or three or four step process to get to that final destination. And drawing that out, showing the stepping stones, as Jonathan stated, like leadership is, wants to be the champion, but they don’t always know what the stepping stones are to get there and how to articulate that to their people so they can take action and sort of that brass tacks. And so finding the right partners, bringing people in who have done this before and say, this is how it worked here. This is how it worked there. This is how, based on your culture, your environment, your structure, how it, it could possibly work in your agency. And so bring those people in, be willing to take small, measured, risks, but also know that these risks are moving you towards the outcome in which you’ve agreed that is the end point.

###

Transcript has been edited from original form for ease of read.