How can you empower business developers like Carlos?

More than 12 years ago, one of the authors of the Agile Manifesto claimed during a conference keynote that in 10 years, all software developers would be business developers. Like most predictions by Agile thought leaders, this one was way off the mark. What is a business developer? And how can you empower business developers like Carlos? I will try to define what a business developer is. I will use an example from my days as an executive at Ultimate Software (the best place to work ever!). Our product management team had an initiative to build a new module. Ultimate Software’s business was HR, Payroll, Time Management, Onboarding, Recruiting, etc., so adding a new module meant creating a new product – great effort, without a doubt. Like all businesses starting a new project, Ultimate Software wanted to get an estimate of how long it would take.

(I think estimation is a form of waste and one we should get rid of. If you want to learn more about why estimates are a waste of time, please read an old post from my friend Prateek on estimates.)

Still, the product team insisted we get an estimate, and we spent a two-day planning session. After some negotiation, we agreed to a simple t-shirt sizing exercise. Because it was a significant effort, we had three different Scrum teams involved in the session. That meant we had at least 12 developers in a hotel conference room providing estimates for each epic the product team presented.

Because we were there for TWO DAYS (talk about waste), we had several breaks, including lunch breaks, built into the agenda. During these breaks, an interesting pattern emerged: Most developers stayed in their seats or mingled with other developers or team members. Three developers, including Carlos, used these breaks to go and talk to the product team. 

They continued asking questions about the requirements and the business. Those three developers moved from being professional developers to becoming business developers. They wanted to own the solution; to do so, they needed to understand the business better. They tried to understand the domain as profoundly as they could. They are the rare developers who want to talk to a client directly to understand a problem. That is what this Agile thought leader meant when he said all developers will become business developers in 10 years.

The reality is that the number of business developers is around the same as the sample we saw during that session: 3 out of 12. Most developers are interested in expanding their technical skills by learning new frameworks that make them more marketable or sticking to their preferred frameworks that make them feel secure in their jobs. Some eventually understand the business, but most consider that a side effect of their current position, something other than what provides much value to them. They are professional developers whose primary concern is writing code.

Like all ideas, this idea of business developers has morphed into “you only need developers in your team.” There is no need for other professionals like QA or Product. The developers will care for everything; hiring people for different functions is unnecessary. Many organizations try to follow this path today, assuming their developers can handle everything.

I do not know where Carlos is these days, but if he is in one of these places, he must feel anxious. He always wanted to understand the business, but that understanding came through collaboration with other team members like product and QA. He will also feel the anxiety of not knowing the quality of his product. Did we break something after implementing that security fix? The answer is probably Yes. A significant number of security fixes tend to break functionality. The unit tests are passing. Is that enough? The answer is a clear No.

One way to address those gaps in developers-only teams is by using tools that can handle the work. As a business developer, you can do TDD, BDD, or both. You have a suite of unit and acceptance tests running on your CI/CD pipeline. All that is great, but we must achieve a continuous comprehensive testing strategy.

Instead, you end up with these conversations:

Support: “Our customers are complaining about bugs you did not find.”
Developers: “Well, there is no one designing tests to critique the product that can tell us if we are covering all the paths. We are busy writing code; the only tests we run are the unit and BDD acceptance tests.”

Product: “The users said it is challenging to navigate the product.”
Developers: “Well, there is no one conducting usability testing. No one is trying to determine if the product is easy to use.”

CEO: “The users are complaining the web pages are too slow.”
Developers: “Well, there is no one conducting performance testing. We depend on the application monitoring tool to tell us if something is slow. But by then, the users are already complaining about it.”

CIO: “The auditor’s pen testing team found 97 security vulnerabilities in the product. We need to fix them now.”
Developers: “Well, we do not know how to use the security testing tool you bought us. It is complicated and takes time to set up and manage. Product and Sales want us to develop features. Plus, you are the one responsible for security in our company.”

Today, nothing can truly take care of the testing side, at least until Testaify. We’re building Testaify to allow you, a business developer or not, to implement a continuous comprehensive testing (CCT) strategy. Powered by Artificial Intelligence, Testaify only needs to know your web application's URL and test user credentials.

Testaify will discover the domain. Testaify will design the tests. Testaify will generate the test data. Testaify will execute the tests. Testaify will provide you with reproduction steps for every error. You can focus on becoming a business developer who truly understands your customers’ needs.

Wherever you are, Carlos, it is time to get help. The future of software testing is here! Carlos, remember to sign up for our waitlist. You need it.