G'day and welcome to Amazing Apps. I'm your host, Microsoft MVP, Neil Benson. I'm on a mission to help you master Agile practices and build amazing apps on the Microsoft Power Platform and Dynamics 365. Amazing Apps is the result of my curiosity and experiments with new ways of building amazing business apps and high performing teams. It's full of advice from my guests and examples from some of my work over the last few years leading business applications, teams, and practices.
If you enjoy this episode, head over to https://amazingapps.Show for additional resources. You'll find more episodes of Amazing Apps as well as my videos, free workshops, ebooks, and my online training courses. In this episode, I'm going to try and persuade you to continue learning through experimentation as we embark on our AI adoption journey. We're going to be talking a lot about experiments. But let's start with smallpox. When's the last time you or someone you know well had smallpox?
I bet it's never, at least I hope it's never. According to the World Health Organization, people have been trying to inoculate themselves against smallpox by exposing themselves to the virus since the 15th century, maybe as early as 200 BC. In 1721, Lady Mary Wortley Montagu brought smallpox inoculation to Europe by asking that her two daughters be inoculated against smallpox. That was a practice she had observed in Turkey. By all accounts, she was quite the adventuress of her day.
Fifty years later, in 1774, Benjamin Jesty makes another breakthrough. Testing his hypothesis, that infection with cowpox, a bovine virus which can spread to humans, could protect a person from smallpox. He and his family were spared from the smallpox infection that swept through the southwest of England in 1774. Jesty was one of several people thought to have practiced inoculation around this time, but the credit for inventing vaccination is generally given to our next character.
Twenty years later, in 1796, a British doctor, Edward Jenner, conducted one of the bravest experiments I've ever heard of. He swabbed the ugly cowpox lesion of a milkmaid and used it to infect an 8 year old boy, James Phipps. If any of you know any 8 year old boys, this isn't a practice I would recommend. Phipps was unwell and suffered a local reaction, but he made a full recovery. So what did Jenner do?
Two months later, in July 1776, he tested Phipps resistance by infecting him with matter from a human smallpox lesion. Cowpox in humans results in ugly lesions, often on the hands and arms and face, but it's mild and rarely deadly. Smallpox, however, is far more infectious and in 1776 it often resulted in a slow, painful death. It's reported to have been responsible for between 10 percent and 20 percent of all deaths in the 18th century. Whatever happened to 8 year old Phipps?
Well, he remained in good health despite the smallpox exposure. He's considered to be the first person vaccinated against smallpox. And did you know, the word vaccination is derived from vacca, Latin for cow. This is a painting of Benjamin Jesty's cow, Blossom. The most famous cow in the world, at least in 1774. Other experiments since then by scientists have led to vaccinations against over 20 human diseases. Receiving vaccines has become routine for many of us, especially since 2020.
Many of us wouldn't be here if our antecedents hadn't been vaccinated against smallpox and other deadly viruses. In 1996, I was studying biochemistry at the University of Edinburgh where I spliced the gene from green fluorescent protein, which is found in the jellyfish, Aquorea victoria, through a bacterial vector into yeast, saccharomyces cerevisiae. According to my professor, our experiments were related to gene targeting and cancer research.
Through ultraviolet microscopy, we could see exactly where inside the yeast cell DNA was being expressed and proteins were subsequently located. My goal was just to make glow in the dark beer. Can you imagine traffic cop with a UV torch? Honestly, officer, I haven't been drinking. But I found the conversational skills of baker's yeast to be pretty poor compared to C# developers. So I ended up pursuing a career with the IT crowd instead. But my passion for running experiments hasn't abated.
Today, I'm the co founder of SuperWire. ai, a Microsoft partner and independent software vendor building engagement applications for superannuation funds on Power Platform, Dynamics 365, and Azure. I'm also the founder of Customery, an online training provider helping Microsoft teams adopt and master Agile practices. In both businesses, we love learning through experimentation.
We start with a hypothesis, run a short experiment to test the hypothesis, review the results, and reassess our hypothesis to improve our knowledge. Instead of learning through experiments, lots of development teams attempt to design everything up front, in the belief that if we could just understand enough at the analysis and design phase, that everything will be alright.
If you are analysing your users requirements up front, and designing your solution in advance, you're doing it at the point of peak ignorance, also known as Mount Stupid. At the start of your project, your team knows least about the users and their needs. And your users know least about the application you're building.
Instead, if you can defer the requirements analysis until the last possible moment before you need to start developing the feature, you'll have learned a lot more about the requirements by then. Don't spend months analyzing requirements before development starts. Instead, work in short bursts. Keep the users involved in planning your experiments and reviewing the results. Learning through experimentation, working in short increments. Emergent analysis and design.
Collaborating with users while building the app. We've got a label for working like this. It's called Agile Software Development. Especially the Scrum framework, which is founded on empiricism, which is the theory that we learn from the experience derived from our senses. That is, complex solutions can't be designed up front. We need to learn through experimentation. Let me give you an example of how we experiment while building Microsoft business apps.
One of my teams is currently working for a Queensland government department. They register and monitor the training contracts for Queensland's trainees and apprentices. Every year, they process 90,000 expense claims submitted by trainees who have attended an approved training class away from home. 63,000 of these claims are PDF forms that are emailed to the department, and 17, 000 are submitted online via a webpage developed 12 years ago.
A 12-year-old .NET web app is considered pretty modern by this department's standards. How could we improve the trainees expense claim experience and the department's processing efficiency? The first idea we had was a new mobile-optimized Power Pages site that would connect directly to Dataverse where the trainee data is already stored. We would automatically calculate the distance from the trainee's home to the training location.
And we already provide a portal for the training provider to confirm the trainee attended the training. And then we would send the payment to SAP for processing. But the department can't force trainees to use a webpage, and many of them are handed PDF forms by the tutor at the end of the training course, and it's easy for them to get the form approved there and then.
Instead, we're going to experiment with the Power Platform's AI builder by training a form processing model to read the PDF expense claim documents, turn them into a digital expense claim record in Dataverse so that we can process most of them automatically. We call this type of work a spike in our product backlog. Like a rock clamors spike. Our spikes allow us to safely explore a new rock face and discover if there is a path towards progress.
At the same time, our risk of falling and dying is reduced because we time box the spike and contain it into a fixed amount of effort within our two-week sprint. During the sprint review, we'll report the results of our spike back to our stakeholders and invite their feedback about whether or not to pursue that solution or try another experiment. I remember Frieda, our CRM product owner at the University of New South Wales, wasn't happy that all our spikes went well.
If every experiment succeeds and proves your hypothesis, said Frieda, then it's because your experiments were too safe. It's only when half of your spikes fail do you know that you're being bold enough and building an amazing new business application. Our government department is also considering implementing a new business rules engine to replace the 20 year old rules engine that supports the legacy PowerBuilder application we're replacing with Power Apps.
When a new training contract is submitted to the department, they need to validate the trainee's details, the employer's details, the workplace location, the contract dates, the training organization, the training course. There are hundreds of validations to perform on each contract, and thousands of rules in the rules engine. Instead of a business rules engine with a fixed set of deterministic rules, could we use AI to validate training contracts?
Could we build a model of valid training contracts, then train a co pilot to spot invalid training contracts, and ask it to validate all the new training contracts coming into the department? Arguably, this approach is not actually artificial intelligence, it's machine learning, because the system will be identifying patterns in the contracts provided to it And improving its decision making capability based on our feedback about new contracts.
Whatever we call it, I think it's an interesting hypothesis to test. What's the smallest, useful experiment we could conduct to help us advance our knowledge about whether AI, really it's ML, could validate training contracts without a hard coded rules engine? Well, we start Sprint 1 on Monday. If you follow me on LinkedIn or subscribe to my podcast, Amazing Apps, I'll let you know the results. I love building in public. Until then, experiment.
Find a hypothesis, run a test, learn from the results, share the outcomes with your stakeholders, or better yet, share them in public. But, please don't experiment on 8 year old boys or infect anyone with a deadly disease in your attempts to harness artificial intelligence. Thanks for listening or thanks for watching. I hope you enjoyed this Amazing Apps episode and found it useful.
If you want to accelerate your career by building amazing Power Platform and Dynamics 365 apps your stakeholders love, then join me in my free interactive workshop. Inside, I share the three secrets to successfully using Scrum to build agile apps so that you can deliver projects faster, under budget, have more fun, and get promoted. Register today at https://customery.com/3secrets. You'll also find that link in the episode description, in your podcast player, or in the YouTube video description.
Until next time, keep experimenting.