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.