Photo by NeONBRAND on Unsplash

Contracts ruin software projects as much, if not more than, poor execution or client blockers. In most cases, the contract sets out to reduce the client’s risk, yet it does precisely the opposite. I want to dig into the reasons why our industry suffers contracts that work against project success.

Conversely, the pre-contract time is one of joy. The client is excited; the vendor is enthusiastic. The thought of tackling a hard problem together is exhilarating. There is agreement on always building the “most valuable thing.” Chatter about how, through learning, the software will evolve to meet the business needs. A consensus on using Agile methods is evident. There are trust and collaboration. It’s a glorious time brought crashing down to reality by contract negotiations.

Procurement, especially in large enterprises, does not care about Agile Development principles. They care about the risk they can see. When a contract for a new application hits their desk, the threat is non-delivery of the application. The application consists of features, so the contract ties to those features. Features are a known quantity, so they each have a cost that rolls up into a fixed price for the application. Also, a complete project needs an end date, so let’s force the Business to tell us when this project completes. This way, we arrive at a fixed price, fixed scope contract with a deadline. Risk mitigated.

What Happens Today

In the “Agile Contracts Primer," Tom Arbogast, Craig Larman, Bas Vodde encourage non-lawyers in this process (like me and, presumably, you) to consider the legal perspective.

“Don’t you want to work in an Agile manner?” we ask, forlornly.

“Oh, yes! Of course. We’re agile! That’s us. Soooooo agile. You won’t be able to handle how agile we are,” the client proudly exclaims.

“But, um, cementing the scope into the contract and picking a deadline is not an Agile start,” we point out.

“We need to know what we’re getting when we’re getting it, and what it costs. But, um, agile-ly,”

“You understand that scope will almost assuredly change based on what we learn during development and deployment of the first features, right?” we ask.

“Of course, we expect change. That’s agile.”

“So, that means the scope you’re carving into this contract is not the scope you will get,”

“Yup. Agile.”

“You know, saying ‘Agile’ doesn’t make it such, right?”

It rapidly becomes apparent that Procurement wants Waterfall and the Business wants an Agile approach less than it wants funding. At about this point in the process, we receive assurances like:

looks around, then whispers, “We have to word the contract this way to get it signed. We understand that things will change. Don’t worry about it.” followed by a wink and, sometimes, a reluctantly-accepted fist bump.

Unfortunately, we have to worry about it. So, the mitigated risk just shifts from the client to us. Now, we turn into the risk mitigators. Change Management sections spring to life, preceded by sections like “Responsibilities of the Client” and” Assumptions." The contract has devolved into a word avalanche that, put more simply, says, “If things go perfectly, we can deliver what’s in this contract.”

Perfect is the Enemy of Software

As you well know, things never go perfectly in custom software development. In attempting to contract out imperfection, both sides have locked in at their respective extremes. Client and vendor need to meet in the middle to have success, but doing so fights against the contract.

Now, the risk shifts to the development team. Their focus immediately shifts from “How do we solve the customer’s need in the best way?” to “How can we deliver this feature set on time without having to work crazy hours?” Think about that. The people charged to build a company’s latest value creation attempt are focused on features over value. Sound familiar?

It is not a new problem. Companies that don’t work in software development don’t understand the complexity and uncertainty that comes along with it. They understand buying a product and getting a refund if they don’t like the product. Sadly, that is not the most significant risk in custom software, and I can think of a couple of others that are more likely:

• Building the wrong thing for your users
• Not being nimble or responsive enough to adapt to user and market changes

Invariably, these risks come to light one or two sprints into the development process. “We need to add/change features, but we can’t go back to Procurement because they always say' no,' and we need all the original features anyway and can’t y’all just add the new stuff, too??? We’re homies, right??” Regardless of where the negotiations go from here, it’s clear that adapting to change isn’t part of the project. Change is the most significant risk in software development projects if you don’t embrace change as a part of your work.

Complex Adaptive Systems

The question becomes, then, how do we educate buyers on the right risks? How can we educate them on the reason behind Agile processes and create working arrangements that make sense? These are tough questions, and (sorry to disappoint) I don’t think I have the answers. However, I do have suggestions based partly on my experience and partly (mostly?) on books and blog posts about others' experiences.

People should buy custom software development the same way one might handle a Complex Adaptive System (CAS). A CAS is an “array of independent, interacting agents” or any system that has many interacting pieces and leads to emergent outcomes. This description is apropos of software development. We have stakeholders, systems, users, testers, programmers, and who knows what else involved in each product. When all of these items interact, an outcome will emerge. The trick is guiding that outcome closer to a positive one. The examples in the linked article are exemplary:

• Traffic Jam ==> Negative Emergence
• Evolution ==> Positive Emergence

Evolution picks its path based on the experience of organisms in their ecosystems. Evolution does not select a series of traits and then fight its environment to create them. The process starts with today’s reality, learns from it, makes small changes, and then assesses those results. A favorite example of mine (from the wonderful book The Body by the even more wonderful Bill Bryson) is the theory stating eyebrows are an evolutionary change which emerged in humans (no other animals have them) to convey emotions without words. There’s no reason for eyebrows other than to display anger, happiness, surprise, etc. They work well for that, so they’ve stayed around.

Nudging for Emergence

Given that, how can we nudge a CAS toward positive emergence? It’s not by picking a destination far into the future and trying to force it there. It’d be much easier to choose that destination, but take a small step or two and see how reality changes. As time and experiments go on, we start to figure out better ways to get closer to our destination or if that destination also needs to change. In other words, we want to learn quickly and adapt. Well, what conditions support learning quickly and adapting? Experimenting. If an environment promotes and provides for easy experimenting, then requirements for nudging emergence exist. The environments should encourage:

• Many, Quick feedback cycles
• Testing with actual users, customers, etc
• Easy, small-batch, automated deployment with a small team
• Treating Failure as a learning
• Making local discoveries global knowledge

Envisioning a software development environment that encourages these items leads to practices such as:

• A shared product vision
• Cross-functional, empowered and autonomous teams
• Low/No code prototypes
• Infrastructure as Code
• CI/CD platform from Day One
• User testing from Day One and throughout the project
• Code reviews, pairing
• Proof-of-concepts
• Frequent training
• Blameless postmortems
• Testing in production
• A platform team focuses on developer experience

Creating this environment with a software development partner requires the right contract structure. Instead of a list of features and deadlines, the contract should include:

• Frequent demos and check-ins. Each check-in is a chance to review new learning and nudge emergence (or cut losses) (Bake feedback into the contract)
• Multiple milestones that includes a discovery phase and many targets (more on this below)
• Requirements around metrics that matter to software development, such as deployment frequency, lead time of stories, test coverage, and performance metrics. (Identify metrics to drive the creation of the right environment)

A Milestone-laiden Contract

Regarding the “targets” comment above, clients need a way to ensure the money they spend is creating value for the company and the application. It is not realistic to ask a client to develop a series of short contracts, so a single contract with many milestones or checkpoints suffices. The early milestones aim to enable learning and value discovery. The following milestones can confirm that value and begin the task of scaling up. Example:

Milestone 1: Create the platform and the team to run it, along with DevOps and a walking skeleton, for example. Add in design prototyping and a high-level architecture description. In short, everything needed to empower a development team.

Milestone 2: Bet on 2-3 Epics as the next most valuable items. In short, this is more of a release plan in a contract.

Milestones 3-n: Repeat Contract 2, where n is as long as value creation continues. Scale up as you reduce uncertainty and improve.

This approach forces the partnership to have regular breakpoints without the noise of a vast, amorphous feature set and the specter of an impending deadline. Since the milestones are short, the money is a small bet, and the winnings are foreseeable. Estimates are more straightforward and accurate because the work has to fit into a few weeks. Each new contract has a new reality for new bets based on learning. Feedback part of the partnership and the risk is reasonable for both sides.

In essence, this is a bit of a hybrid contract structure between a fixed-price and a retained team. It’s not ideal, financially, for the vendor. Most vendors would prefer a massive, fixed-price, long-term contract to meet predictable revenue desires. However, those contracts are bad for the teams and the client, as the upfront expectations smother experimentation.

Talking Points

Customers don’t want a list of features; they want a working product that can adapt to technology changes, user goals, and market trends. The next time you partner with a software development firm, understand that the right set of features is emergent, so creating the environment and contract with that in mind is paramount. To help that, here’s how I’d frame the ask to the C-suite:

“We’ve chosen a partner to help us build Application X, which is a large application that will provide value to our users. While we have a destination in mind for the application, the route to get their is clouded with uncertainty and complexity. The feature set seems clear today, but that will assuredly change when it comes into contact with users. This is good! As a business, our goals should be to listen to our users and adapt quickly to what they tell us. We need a process that encourages learning and adapts to change. We need to manage an evolution.

I understand the risk of an underperforming partner. I understand the risk of not getting features built. However, if we put features into the contract, then the team’s focus switches from creating value to creating features. If those features are wrong (and some of them will be) or new features are discovered (and they will be), we have to amend the contract, which is a slow process.

We can mitigate the risk of building the wrong thing with a short discovery process that creates a flexible architecture. This architecture needs to fit our team and our problem. This architecture needs to address the quality attributes that are important to our problem. This phase should include design prototypes that resonate with our users. This discovery period should be in the first milestone.

We can mitigate the risk of building the wrong thing by automating deployment. If deployment is easy, then we will always be ready to change direction in a timely fashion. We become nimble. This is foundational to everything else we want to do with this application. Deployment frequency is a metric that can keep our eye on the ball here. The ability to quickly and securely deploy should be in the first milestone.

We can mitigate the risk by making experimentation easy for the development team with modern tools and languages and items like a solid A/B testing framework coupled with solid business analytics. These items should be part of the first milestone.

We can mitigate the risk of building the wrong thing by ensuring a solid test approach with real metrics. Test coverage should be 80% or greater for unit tests. Let’s mandate automated security testing. Let’s identify specific goals around performance testing. A comprehensive test plan should be in the first milestone.

We can mitigate the risk of building the wrong thing by focusing on small batches of features at a time. The next, most valuable features should be obvious. Include automated deployment with proper test metrics and foundational features (i.e., registration and authentication, A/B testing) in the first milestone. Consider this a “walking skeleton” for the application.

Thus endeth the first milestone. Are we happy with our partnership and our foundation? If so, we can move on to the next contract. If not, we can circle the wagons and make a new plan.

Presuming we’re still on the happy path, a series of feature development milestones start here.

With our North Star vision for this application in mind, we should only be looking at the immediate future for execution. What can we get done to progress our application in the next six weeks? Do we need a search capability? Admin portal? Address technical debt? Select items that display tangible progress with the development teams' input. Each of these contracts specifies the features they cover. Measuring and accepting these features happens at the end of the term. Do we need to make some discovery for a feature? That can be in the contract, with specific outcomes to drive understanding. There are many ways to structure a deal in this manner, which is the point. Basing the contract on our latest knowledge and learning builds in the flexibility to create the right software. Otherwise, we end up in a long-term deal that no longer fits.

It’s more work for our partner and us, but it’s a better way to build a product. And that is what we are doing here: evolving a product, not buying a project.”

The next time you’re in contract negotiations for software development, bring emergence and evolution into the discussion. Your contract, partnership, and application should all evolve with time and learnings, so structure them to that end. Build a collaboration around education and reducing the right risks and watch your product grow