Your first introduction to the scientific method may have come in elementary school, but it has several hundred years of proven impact that reaches far beyond any textbook—even extending into the world of business. You didn’t learn about the agile methodology in elementary school, but it closely mirrors the scientific method. In agile, solutions and product features are developed in direct response to business problems. Instead of investing in a full solution, organizations observe and test before making a full investment.
While each has its unique components, agile and the scientific method can both be used to improve IT operations, from company-wide communication to collaboration among teams to product development and launch. Here’s how it works.
The best scientists and IT decision-makers are always open to new discoveries via observation. It sounds simple and straightforward, but the process goes beyond simply seeing and analyzing what’s happening in your IT department. Time writes, “Scientists actively engage with their perceptions…they organize and analyze what they’ve seen after the observation session is over.” Observation can be even more powerful if it’s based on quantification of events, such as your average rate of software adoption, or the typical deployment time of new applications.
In a contemporary IT department setting, business intelligence (BI) and analytics can be key to the “field notes” necessary for productive observation. Understanding how your key metrics stack up against goals and are changing over time can reveal key opportunities for improvement and IT innovation.
These observations lead to drawing a hypothesis, which Live Science defines as a “suggested solution for an unexplained occurrence that does not fit into current accepted scientific theory.” In order for a hypothesis to provide value in a laboratory or IT team setting, it must be testable. “If/then” statements are a common way to format hypothetical statements, which can be rejected, modified, or accepted based on the outcome of testing.
Your IT team might hypothesize that a complex UX is correlated with the high rate of errors from your accounting team’s daily processing workflow. You develop a hypothesis that one-click call logging has improved your sales team’s ability to consistently update contact records. It’s crucial to ensure that your hypotheses are not only testable, but also based on information from your observations.
Predictions and hypotheses are closely related, but they’re not the same. It’s important to think of predictions as a direct product of your newly formed hypothesis. Based on your hypothesis of how one-click logging has improved end user engagement rates with a tool, you might predict that implementing a similar feature for your accounting team could improve adoption.
Predictions should be made based on data, observations, and hypotheses, without IT team bias. When forming predictions, it’s important to think toward developing ideas that can be tested by groups within your organization or your QA team.
Agile QA processes are closely based on the scientific method. Testing software to “see if it works” is a vague assignment that can set IT teams up for failure. Broad functionality is much vaguer and more difficult to prove than testing single hypotheses, or user stories, as they’re called in agile, to validate single features and workflows.
The concept of focusing tests on a single hypothesis can lend value to your entire IT team. Regardless of whether you’re testing with A/B split testing, analytics results, a QA team, or user focus groups, focusing on validating or invalidating your hypothesis can lead to better accuracy in test results, and reveal strengths and weaknesses in your observations. Regardless of the outcome of your test, it can strengthen your ability to make sound decisions in the future.
The scientific method has the power to transform your IT department’s strategy, even beyond your in-house software development and testing processes. If your goals include shifting to more agile means of operations, switching to a model of observations, hypotheses, and testing can provide accuracy and nimbleness.