Government solicitations to purchase custom software are often nightmarishly long and complicated documents that take many months or even years to write. 18F, a government office dealing with software development, favors agencies using agile software developers because the savings of time and money in the procurement process are enormous. An agile software solicitation can be about a dozen pages and written in less than a day.
A fourth-generation attorney with a decade of tech industry experience before law school, John Grant tears down the federal government’s Agile Software Development Solicitation template from 18F, part of the General Services Administration’s (GSA) Technology Transfer services. Grant explains how understanding agile and 18F’s template will help you draft better contracts.
Questions
- Why use a template?
- How does agile project management differ from traditional?
- How do scrums and sprints Work?
- Why should you deliver user stories?
- Why is agile better for quality assurance?
Why use a template?
The Agile Software Development Solicitation template is a government document used when hiring a software development company. The template helps crystallize the how, the why, and for whom the software is being developed. It also details the cost and delivery details of the project.
Solicitation for software development: Know Agile vs Waterfall. #ContractTeardown. Click To Tweet
The template is the starting point for anyone putting together a solicitation for custom software development. The document is part of the RFP process, and these terms become incorporated in the final software development contract.
18F Improves Government Through Tech
18F is the GSA office that works with other agencies to improve government services through modernizing government technology. If you are selling software development services to the federal government, you will be dealing with 18F.
The Goal is to Solve a Problem
Attorney Grant explains that 18F wants to be really clear they are not just building software for the sake of building software. 18F really wants the software to solve a problem. They are purchasing a solution, and the code is just the tool. The problem needs to be clearly and explicitly defined. The template is the beginning of that process.
Section 1.2 states, “The software product or service will be developed to solve a problem on behalf of users” and calls for you to include a concise summary of the problem being solved.
Project Management 101 – The Iron Triangle
Attorney Grant explains that you need a bit of project management background to understand the differences in agile contracts. Traditional project management is often described as the Iron Triangle of project management, where the three corners symbolize time, scope, and resources.
Knowing project management basics helps with drafting agile software solicitations. #ContractTeardown. Click To Tweet
Traditional project management, often called waterfall, assumes that the project’s scope is the most important part. The scope describes all of the things to be delivered and can be pages and pages of deliverables. When things take longer than anticipated, as is often the case, the amount of time and money increases. The typical and traditional software projects always seemed to be late and over budget.
Agile Scrums and Sprints
Attorney Grant says that software developers got tired of hearing the late and over-budget complaints, so they came up with a different system – Agile. The developer and the client still define the scope, but this time, they have to prioritize them. At that point, they agree on a fixed price and a fixed time. The time is “boxed in” for a short period of three weeks or so. The team finishes as many scope items as possible, working on them in order of their priority.
Agile has its own terminology. A scrum is an agile method where the teams get together often, (like rugby, where the term is from,) and learn quickly from experiences to plan continuous improvement. The sprint is a short time-boxed period where the team works to complete a set amount of work.
During the sprint, the developer completes what scope items they can, and then the parties get back together to plan the next sprint. The agile method creates rapid development because the teams do short work sprints and get constant input from the customer during the process. Change orders do not exist in agile because of the continuous short sprints and meetings that lead to rapid development.
Backlog of User Stories
Section 3.0 instructs you to include a backlog of users stories. If you contract to produce widgets, you can count the widgets to see if the contract is being fulfilled. But, computer software is not as straightforward.
Attorney Grant explains that a “user story” is the delivery unit in software development, even though it is not especially measurable. The goal is to determine what the user is trying to accomplish. Most software development contracts focus on how the software is used. With agile, the focus is on why it is used.
| 3.1 | Backlog |
|
A User Story frames a problem in a particular format as follows: As a (blank), I need to be able to (blank) so that I can (blank).
An example might be:
“As a consumer, I need to be able to find the current interest rate on the 10-year T Note so I can determine if my credit card charge will increase.”
A banker, broker, or hedge fund trader might also want to know the current interest rate, but the reasons would differ from the consumers. Attorney Grant says the backlog of user stories is a wish list of all the things you think you want, but they need to be prioritized.
| 3.2 | List of Deliverables with Quality Assurance Surveillance Plan (QASP) |
|
Quality Assurance Surveillance Plan (QASP)
Speed is great, but what about quality? Section 3.2 describes the List of Deliverables with Quality Assurance Surveillance Plan (QASP). This is another core feature of an agile development group.
Traditional software development did things in a linear sequential fashion. In order, you might do user experience, development, coding, then quality assurance, and then integration. Attorney Grant explains quality assurance suffered when the project inevitably ran late because the contract called for a certain amount of code to be delivered. As time ran out, the code at the end of the project was problematic.
But, an agile team has all of those functions on their team at the same time. Cross functioning is a cornerstone of agile and allows quality assurance to be developed almost in real-time. Paired programming allows two coders to work on the same lines of code at the same time. That is real-time quality assurance.
Learn From Agile Methods
Attorney Grant explains the first and most important step for an attorney drafting or reviewing a software development contract is to ask the client which methodology is being used, agile or waterfall. If it is waterfall, you need one set of templates and terminology. If it is agile, you need the agile templates, terminology, and assumptions.
Attorneys can learn much from agile project management as it spreads to other businesses and industries, including the legal sector. It creates rapid delivery and has real-time quality assurance. It also gives you a clear picture of who the user is and what problems they are trying to solve. If you review or draft software development contracts, a major part of your job will be to know agile methods.
Show Notes
THE CONTRACT: 18F’s Agile Software Development Solicitation
THE GUEST: John Grant is the founder of Agile Professionals and is a consultant known as the “agile attorney”.
THE HOST: Mike Whelan is the author of Lawyer Forward: Finding Your Place in the Future of Law and host of the Lawyer Forward community. Learn more about his work for attorneys at www.lawyerforward.com.
If you are interested in being a guest on Contract Teardown, please email us at community@lawinsider.com.
Transcript
John Grant [00:00:00] Not just that we’re solving a problem of world hunger, we’re we’re we’re getting more specific than that, which is to say that we want to solve hunger in the panhandle of Texas. The point of this isn’t to just develop code that does a thing, is to develop code that that solves the problem for somebody and to somebody that the government decided that they care enough about to to enter into a contract here.
Intro Voice [00:00:25] Welcome to the Contract Teardown show from Law Insider. Where legal experts tear down contracts from some of the most well-known companies and high profile executives around the world.
Mike Whelan [00:00:38] In this episode, John Grant, a consultant known as the Agile Attorney, walks us through an agile software development agreement. This one comes from 18 F, the hiring agency for Government Services software in the United States. You’ll learn how agile contracts differ from traditional development agreements, as well as how you can draft to prioritize speed while still defining important limits. So let’s tear it down.
Mike Whelan [00:01:05] Hey, everybody. Welcome back to the Contract Teardown Show. I’m Mike Whalen. The purpose of this show is what the name sounds like. We take contracts and we beat them up using smart friends like my buddy over here. Everything’s backwards on this recording thing. My buddy over here, John Grant. John, how are you today?
John Grant [00:01:23] I am good. So that mean you’re here? Okay. Oh, I did. I know, right?
Mike Whelan [00:01:26] Everything’s backwards. I do have to give you guys just by word of warning, we’re recording middle of the day during covid, which means kids and birds. We have this new bird that we just got who says what the F word. And so if you suddenly hear if this has an E rating next to it, it’s not my fault, OK? As the birds fly, John, you and I are going to be talking about a particular document that is super weird. This is sort of a special special edition episode over here. It’s this document. It’s titled Blank Program Statement of Objectives for Blank Product. As you guys can see, this is not a finished document. We’re going to go through this step by step. But, John, what is this document?
John Grant [00:02:08] Yeah, so this document comes from an entity called 18 F, which is an address. I don’t remember exactly what, but it is basically it has to do with the Government Services Agency. Right. Which is the the contracting arm of the federal government. And the the first version of this document came into existence. Gosh, probably about 10, maybe 12 years ago in the Obama the early days of the Obama administration, because what they realized when they came in to executive power was that all of the government contract templates were built around this assumption of a particular form of project management, which used to just be known as project management, is now sort of known as either traditional or waterfall project management. However, what they problem they ran into was that software vendors and technology companies had adopted an entirely new and different form of project management known as agile. And so this is actually the agile contract format for this particular document. And I think this one might be the an RFP type contract. But what is interesting about it is the first instances of there being a contract template and obviously it’s evolved since 12 years ago. But it’s the first instance of a of a government contract template specifically geared towards the Agile Project Management methodology.
Mike Whelan [00:03:46] So looking at this document, again, if I’m understanding correctly, the purpose in this thing is essentially, if you are a lawyer and you’re going to work with software development companies, you’ve got to know something about agile. And here is a document that sort of the government is saying you’ve got to sprechen ze this language that was the closest to German I could get. And this is the document that we’re going to use as an example to tell you how this sort of thinking works. So, John, you why you why are you here? What do you know about this agile thing? What’s your background?
John Grant [00:04:17] Yeah, well, so I claimed the moniker the agile attorney. Right.
Mike Whelan [00:04:22] And the domain was there.
John Grant [00:04:24] Somebody is going to get it. Was there. Yeah, it was not because I was a high school pole vaulter, although that is true. It it is because I learned about the agile methodology and I, you know, maybe not unique among lawyers, but I had about a 10 year career in the technology industry before I went to law school. And interestingly enough, the company I worked for was kind of proto agile at the time. Right. I left them in the year 2002 the Agile Manifesto. And yes, there is a manifesto, was the year two thousand, I believe, so we were doing some things that were agile like, but then after law school I went back and was in-house counsel at that same company, and they had gone completely agile while I was while I was away. Right. I’m learning about the rule against perpetuities. They’re revolutionizing the way the software gets developed and and it was better. So I remember like once I got back and was spending time obviously learning how to be a lawyer, but also with a lot of friends and colleagues and contacts that were still in sort of the delivery part of that company. And and I was learning about agile. And I’m like, wow, this really is better. It’s it’s faster. It’s less contentious. They seem to be delivering more often. I wonder if this could work for lawyers. Right. I had this thought in my head, but I was so busy at the time, like learning how to be a lawyer that I didn’t get to bottom it out until a few years later. So really, for the last gosh, eight, nine years, I’ve been sort of very specifically looking at ways that lawyers and legal teams can adopt agile methodologies, not just to know them for the clients that they serve, but to actually use them in their own practices. And I’ve been doing it full time now for about three years.
Mike Whelan [00:06:21] And anybody who like John Grant uses the phrase proto agile in a sentence, you know, they’re cool enough to talk about this stuff. So what we’re going to do now, John, is we’re going to dig into this document. So am I right that the sort of the triggering event for this particular document is a government agency is going to is going to hire a software development company and this is the document they’re going to use for that engagement, is that right?
John Grant [00:06:48] You got it. Yeah. And actually, I think this is this particular document is part of the RFP process to bring those in. And it’s basically getting the government agency to do some preplanning. But these terms will eventually become part of the contract with that software.
Mike Whelan [00:07:02] All right. And with the caveat that, you know, our intention here is not to be an encyclopedia of terms. There are certain terms that, you know, if you’re not used to this agile context, then you’re going to have to know those to figure out how you deal with these kinds of contracts. You know, contracts in general are just trying to define scope and exchanges. This is just doing the same thing with some kind of flexibility. So we’re going to start, John, with this section one point two on the problem. The government says that this is the software product or service will be developed to solve a problem on behalf of users. So give us that summary. Talk to me about this section one point to what’s the purpose if I’m drafting, how do I make sure that I add the right kind of problem language in here?
John Grant [00:07:44] Yeah, so. So that’s just it. Right. And in a traditional contract, that would be the domain of the italicized whereases at the very beginning. And you’d be forced to try to sort of find some thread of like what the heck are we doing here? And basically what we said is enough with all that. Let’s actually be really clear that we aren’t just building stuff. We’re building software both for the sake of government handouts. Right. We actually want to solve a problem. And so let’s be really express and explicit about how we define what that problem looks like to us. Right. And and in this particular document, I think it’s meant to be a starting point for some conversation back and forth with the potential vendors. But it really does elevate this idea of, OK, there’s a problem and what we’re buying is a solution to the problem. Code is just the tool, right? Software is is the vehicle through which the solution is going to be delivered. But what we’re trying to do is solve a problem first and foremost. Right. And that’s that’s sort of the the first of many sort of mindshift changes that I think are good ones. Right. And frankly, good practice to get into for contracting in general. And and, you know, in some lawyers are doing more and more of that, I think, out in the world.
Mike Whelan [00:09:07] Hey, everybody, I’m Mike Whalen, I hope you’re enjoying this episode of the Contract Teardown Show real quick. I want to ask you to do me you really a quick favor. Look down below. You’ll see a discount code to join the Law Insider premium subscription. When you do that, you get access to more content like this. You’ll see webinars, daily tips on contract drafting, not to mention access to the world’s largest database of sample contracts and clauses. It will help you write better contracts faster if you want to do it. Right now, there’s a code below. So get there. Also, if you’re part of a larger team, if you’re in-house or in a law firm, just email us. We’re at sales at law insider dotcom. We’ll make sure you get a deal as well. Come join us in the community. The code is below. Let’s get back to the show.
Mike Whelan [00:09:53] So we’re like normally if I’m if I’m doing a contract for purchase of goods or whatever, I’m saying I’m going to buy 30 widgets. And here’s on the thing. You’re going to get 30 widgets delivered by this date. It sounds like what this thing is saying, this section is saying is this isn’t so much about widgets. This is we got an issue. You got some people who are going to work on the issue. Let’s talk about what that issue is, because that’s what’s defining the scope of that, is that
John Grant [00:10:15] you got it right. And with software, it isn’t. Software isn’t a widget, right? I mean, you know, there might be components or whatever that are that are plug and play that are our widget like. But again, at the end of the day, what we’re trying to do is accomplish some need or solve some problem in a way that is either new or better than the solutions we already have.
Mike Whelan [00:10:36] Right. So at the risk of solve world hunger being the title line, we’re going to jump down to one that’s titled Product Vision. And in this section, you know, is seems to dig a little deeper. It says the government says you want to consider who is affected, what is the problem, how are we helping? What is the outcome? So this is starting to move from we’ve got this very broad problem to let’s talk about at least a vague idea of what a solution would be that you’re going to work on.
John Grant [00:11:04] Yeah. And you hit on the key word, which is who. Right. So it’s not just that we’re solving a problem of world hunger. We’re we’re we’re getting more specific than that, which is to say that we want to solve hunger in the panhandle of Texas. Right. Or some very. And that might be too narrow. Right. For four broad government, but we want to solve hunger across this particular population or across this income band or in this geographic area. But it’s really getting to who are the people that we’re solving this problem for. Right. And getting to that with some specificity, because, again, the point of this isn’t to just develop code that does a thing right. It’s to develop code that that solves the problem for somebody and for somebody that that the government’s decided that they care enough about to to enter into a contract here.
Mike Whelan [00:11:56] I know all of the lawyers who are listening to this are like this is some froufrou nonsense. Where are the numbers? So I’m looking down at two point two because it talks about this defining the period of performance, the budget, the ceiling price. How would a lawyer address this kind of section that says, yes, we got this big thing that we’re dealing with. But, man, you know, solving world hunger is expensive, so let’s draw a line somewhere.
John Grant [00:12:22] Yeah. And so this actually gets to really one of the, I think, biggest differences between traditional waterfall project management and agile project management. And to understand the difference, I got to give you a little bit of project management one on one. So when I first worked in the software world, they sent me to like a little project management, a couple of days training. And what I learned then that nobody who goes to law school seems to learn but is true, right. Is that there is what’s called the iron triangle of project management. So I think a triangle, right. It goes three corners and at one corner is time, right. Or duration. At another corner is scope. Right. What is the what are the things that we’re trying to do in the project? And at the third corner is resources. Right. Which is often human power, a number of people. But it could be money, it could be tools and all the rest. And the reason it’s called the Iron Triangle of Project Management is that if one of those things changes, then at least one, if not both of the other, are going to change as well. Right. So and probably the place where maybe people have encountered this in the real world is at their car mechanic or at the backwoods general store when they’re on a road trip. And there’s a cute little sign that says good, fast or cheap pick to right. And most of us have seen that in the wild. That’s basically the iron triangle of project management and action. So with. Waterfall, traditional project management, it assumes that the most important thing is the scope, right? And so the contractor spends a lot of time defining what are all the things that are going to be delivered within this project. And then it also wants to say that, OK, we’re going to have a timeline and we’re going to have a budget. But if one of those things winds up being wrong, then oftentimes the thing that will float is going to be either the time or the budget or both, because we want all these things. The scope is the most important thing, which means if the surprises come up along the way, which they inevitably do right, that is just the laws of project management, is that it’s going to take longer and be more expensive to to execute a fixed piece of scope than you thought. So that’s traditional. Right. And the problem. Right. And the whole reason that Agile came to be to begin with was this basically recognition that all software projects were delivered late and over budget. And the developers really didn’t like being accused of being the root of those problems. But the business owners to finger point and so the developers, the software people came up with this agile methodology that said, hey, I’ll tell you what, we’re going to commit to a fixed period of time and a relatively fixed budget. Right. So you’re going to pay us X X amount of dollars over the next six weeks and you’re going to tell us all the things that you think you want, that you’re going to have to rank them. Right. We’re going to prioritize them and we will deliver as many of the scope items as we can in that fixed time period. And actually, six weeks is long for an agile project. They’re usually between one and three. But we’re going to deliver as many of these scope items as we can. But you’re going to be 100 percent sure that the budget is fixed and that the time period is fixed. And then at the end of it, we’re going to get back together and we’re going to review what we’ve learned. So what did we deliver? Did it meet your expectations? Did it solve the small problem that you were trying to solve with this special, with this particular iteration? And then we’re going to get back together and say, OK, let’s do this for another three weeks with a fixed a fixed budget and that fixed time period. And we’ll knock off the next few items of scope. Right. And the idea is by basically breaking the time scale down into these very rapid iterations. And this is this is not all agile. This is the specific sort of flavor of agile known as scrum, but it is the most common form of agile. And it’s this idea that, again, you’re having these iterative things. So so like
Mike Whelan [00:16:53] they’re thinking about, you know, a traditional sort of contract environment in which you say, I’m going to do X and you’re going to do Y or whatever. And here’s this amount of time and something happens because something always happens. Like you said, you submit a change order and now we’re renegotiating a new document anyway because it’s got some kind of changes that everybody’s going to compensate for. It is this kind of document designed to give you the flexibility so you don’t do change orders or is it these iterations are sort of like change orders?
John Grant [00:17:22] I would say that, yeah. I think that’s a good question. So one way to answer it is that there are no change orders because you’re basically breaking off such small chunks and you’re delivering it so frequently that frankly, by the time you could, like, spin up a change order, that particular sprint is going to be done. Right. So it’s basically saying, OK, since everything seemed to wind up and change orders anyway, we’re just going to plan to have a new change order every three weeks or sometimes every week. Right. And it’s this idea, and I don’t think we’ve hit on it yet. But to note, two more weird words that are going to come up is that we will create a backlog of user stories. Right, and the backlog is basically this is all the thing, you know, this is our wish list. These are all the things we think we want. But again, we’re going to have to prioritize them. We’re going and that’s OK.
Mike Whelan [00:18:18] That’s down in three one. And here’s the language. The government says it OK. Guidance for this, they say, include the draft product backlog of user stories. In some instances, Epic’s were more appropriate for capturing the agency. Need what?
John Grant [00:18:31] What? Oh, yeah. The epic. The epic. OK, so. Right, there’s there’s a lot in this. So let me start with what’s the user story. So because again, this is sort of different in in a traditional contract, you would say, OK, I need a widget. Right? I need I need a, you know, a unit of whatever and in agile project management and especially in agile software development. The the the unit is the user story and, oh, by the way, it’s not especially measurable. So what a user user story is, is a very sort of specific sort of Madlib tm that basically frames a problem in a particular format. And it goes like this as a blank. I need to be able to blank so that I can blank. Right. So as a user. Right, as a particular person in a population, sometimes as a particular person in a population wearing a certain hat. Right. So but it’s getting as specific as you can with who the person is or the population is that you’re trying to solve the problem for that’s part one. Then I need to be able to blank, which is do a thing right. I need to be able to, I don’t know, find what the interest rate is on the 10 year note. Right. Or some other that’s the most governmental thing I can think of of done my head right now or maybe find out whether I’m eligible for peplum. Right. So that I can blank as the third part. And that’s the part that is often missed in traditional contracting, which is like not just what are you trying to do, but what are we trying to accomplish? Right, right. So it’s one thing to be able to say, OK, I know what the interest rate is on the note, but what’s this particular person trying to solve rather than an institutional banker? Because that’s a very different sort of person then, so that I can figure out how much my credit card interest rate is going to go up or how know whether I need to hedge against inflation differently or whatever it might be. Right. So there’s there’s different populations that care about that number for different reasons. Mm. Yeah. I think that’s it’s our. Go ahead.
Mike Whelan [00:20:52] I’m thinking about as this, there’s a lot of flexibility. Right. And it’s by design. We’ve talked about this with Matias Aranguiz on the the safe document, the Y Combinator Safe document, that there’s this in software development, there’s this favoring for speed. Right. You got to be able to drive. But I’m thinking about quality. Right. This is an issue that the lawyer is supposed to care about, ensuring that what’s delivered is is any good, especially because as we talked about with Martin, software can break things can break a lot of things. So looking down at three, two, there’s a section called List of Deliverables with Quality Assurance Surveillance Plan, which sounds scary. And it talks about making sure that the the code is tested properly, styled, accessible, because it’s you know, it’s a block that’s got a mixed in with a bunch of other things. So talk to me about that quality assurance piece.
John Grant [00:21:41] Yeah. So this is another one of the sort of core features of an agile team or an agile development shop that is different than traditional. So so thinking back right in the pre 2000 software era, which is still true in a lot of software shops, although I think less and less common is this idea that, OK, you’ve got the scope and then you’ve got these software developers. And if the contract says you have to deliver SCOPE, right. A certain amount of of lines of code that that do a thing, then all the focus on the delivery team was on the quantity of code that they had to deliver. Right. Or the quantity of features that they had to deliver. And when timeline started to get compressed, which they inevitably did. Right. Because projects always take longer than you think, then what was happening is that the quality assurance phase of the project at the back end was getting cut. Mm. And so now you had this problem where you might be delivering lots and lots of lines of code, but it was buggy as heck and it didn’t solve the problems that you’re trying to do. And so one of the cornerstones is sort of the concepts of agile teams is that they are cross-functional. So instead of saying, OK, we’re going to start with user experience design and then we’re going to move into development and coding, and then we’re going to move into quality assurance and then we’re going to integrate. An agile team will have all of those roles thrown together on the same team. Right. And so the idea is that quality assurance will be happening almost in real time, right alongside the developer. In fact, there’s a one of the sort of agile methodologies is known as paired programing, where you could literally have two developers sitting at the same monitor. Right, pre covid, but even connected through a webcam or whatever, working on the same lines of code at the same time, which lawyers is like, oh my God, I could never double billing clients for that. And spoiler, I have convinced legal teams to use pair programing and it works really well. But that’s a different thing than this. What that is, is Real-Time Quality Assurance. Right. You have basically one person that is coming out and solving the problems and the person kind of double checking it real time. And if they come a. Check it out and they can solve for it right then and there, and it doesn’t create an additional handoff down the road, which inevitably creates delays and so on.
Mike Whelan [00:24:09] Yeah, and I’m you know, as we talk about this, I’m always eager to pull it out to general principles, to be able to say to lawyers who are dealing with these kinds of contexts, how do you know how to figure out what matters for your particular context? So thinking about the lawyer who is either drafting a document like this or is interpreting a document like this, what’s what’s the principle? Right. Not not how do you make sure that you’re including the kind of language everybody wants the lawyer to get out of the way while you’re making the deal? But once the lawyer to have CYA the whole time, once the deal is broken. Right. So how do you balance that in this kind of document?
John Grant [00:24:50] Yeah, so I mean, I would say the first most important step for a lawyer, certainly when delivering or when tasked with either drafting or reviewing a technology contract, although one of the things about Agile is that it has jumped the gates now. Right. It is used in far, many far more context than just technology. So you need to know from your client what project management methodologies are we following here? Because if it’s a waterfall traditional project, then you’re going to need one set of contract templates and terms and assumptions. And if it’s agile, then then you definitely need an agile contract with agile terms and agile assumptions. And if you try to shoehorn one into the other in either direction, then you’re going to create some real headaches for your client down the road at a higher level. I mean, different from that very practical thing. I think that, you know, and obviously this is near and dear to my heart because it’s what I’ve been been teaching for so long. But I think there is a lot that lawyers can learn from the agile methodologies and the agile world about rapid delivery of value. This idea of, you know, real time quality assurance and making sure that it’s built in from the get go and eventually, you know, that can get into using templates and animations. But that’s not where it starts. Right. It very much starts with coming up with a clear definition of who is the user. Right. And maybe who is my client, who is my customer or whatever. And what is the problem they’re trying to solve and and just starting there. Because if you can if you can answer those questions with a reasonable level of clarity now, all of a sudden you’re solving problems and not just delivering widgets in the form of legalese packed contract language. Yeah, and
Mike Whelan [00:26:41] we’ve talked about I mean, we could open a Pandora’s box and question whether hourly billing is an agile pricing structure without actually using any kind of project management. But I don’t want to get too nerdy about that. And what I would say, yeah, what I would say to anybody who’s watching is if you’re, you know, dealing with technology contacts with your clients, you have a requirement for a certain level of competency. Don’t simply go into these kinds of contracts and feel like I know contracts. I could do this. Yes, you’re going to have to learn some terms that are uncomfortable in some context. That’s uncomfortable because you have to adapt to that business, make, you know, decision makers business context. So, John, people want to reach out to you or learn more about this sort of agile contract context. What’s the best way to connect with you?
John Grant [00:27:30] I am at Agile Attorney Dotcom. That is that’s where you’ll find most of the important stuff. I’m on Twitter. I’m at GE Grant three on Twitter, and you can find me on LinkedIn and most of the rest of the social. There is an agile attorney’s Facebook group that’s not terribly active, but when people ask questions, I answer them. So reach out.
Mike Whelan [00:27:51] Well, we’ll put links to all of that in the show notes. All you have to do is go to lawinsider.com/resources. You’ll see it there, as well as a link to this document from the government’s agile contract recommendation. And also, if you want to be a guest on the contract, tear down show, just email us. We are at Community@LawInsider.com. We’ll see you guys at the next Contract Teardown. Thanks again, John.
John Grant [00:28:14] Yep, thanks. Good to see you, Mike.