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

//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.