Start Here: How to Build Amazing Apps

 [00:00:00] Welcome to episode 111 of Amazing Applications. I'm your host, Neil Benson.

G'day from sunny Brisbane in Queensland, Australia. For the past few months or many even longer, I've wanted to do a flagship episode of Amazing Apps that I could refer new listeners to and say, "Start Here. This episode shares my philosophy and proven practices for adopting an agile approach for building Microsoft Business Applications." 

This is it. This episode 111 is my flagship episode. You'll find show notes and a transcript at https://amazingapps.show/111. While you're there, you can join the Amazing Apps mailing list so you can get the inside scoop on new podcast episodes and videos.

IN THIS EPISODE

In this episode you'll learn why I use an agile approach building Dynamics 365 Power Apps applications. And how I got started. You'll learn when an agile approach is suitable and when it isn't. I'll describe the benefits that Microsoft customers and partners experience using an agile approach. We'll define what agile actually means, the history of agile software development and about the principles and values in the Agile Manifesto. I'll tell you about my preferred agile approach, Scrum, and how to get certified in it, and we'll cover the basics of the Scrum framework. And finally, I'll give you some hints into the proven practices that I think business apps teams need to learn to compliment the Scrum framework to have wildly successful projects. 

I'll try to use [00:02:00] lots of chapter markers in this episode, which I hope you find handy. Apple Podcasts supports chapters, but doesn't support chapter artwork and Spotify doesn't support chapters at all. That's why I recommend modern podcasts listening apps, like Pocket Casts, which is my favorite, or Overcast. I'd encourage you to give independent podcast playing apps a go. Let's get into it. 

THANK YOU CUSTOMERY ACADEMY STUDENTS

Just before we get started. I want to thank everyone who has joined the Customery Academy over the past four years and taken one of my online courses. I know lots of you listen to the podcast too. Your support helps cover the cost of running the Amazing Apps podcast and the Customery Academy YouTube channel.

I love answering your questions, but most of all, I love cheering you on as you complete the courses, achieve your certification and transform your careers. And a special thank you to those of you taking part in my special request recently for video testimonials. It means the world to me, and we're raising hundreds, hopefully thousands, of dollars for Save the Children International.

You're amazing.

WHY I USE AN AGILE APPOACH

Here's why I use an agile approach for building Dynamics 365 and Power Apps. I've shared my agile origin story a few times before, but I'd love to share it again because I think many of you might've find yourself in a similar situation.

I was running a Microsoft Dynamics systems integrator back in the UK called Increase CRM. And we'd just won a project with a customer called Premier Medical Group to replace their aging insurance industry workflow system. We had proposed a traditional, sequential approach with analysis, design development, deployment, and operations phases. This was back in 2008, I think. The methodology that was popular then was called Microsoft Dynamics Sure Step. 

We had just completed the analysis and design phases and published our functional requirements document [00:04:00] and our technical design documents together. Those two documents had taken weeks of workshops, meetings, and desk work and produced hundreds of pages of documentation.

We invoiced Premier Medical Group tens of thousands of pounds for reaching this milestone. And we hadn't yet delivered a single feature. No working software, just comprehensive documentation. And we'll come back to that later on. Debbie, the operations director and our project sponsor Premier Medical, didn't react at all how I expected. She was pretty mad actually. She said the requirements were too vague and some were missing and that our technical designs were too complicated for her business stakeholders to be able to review and approve. She couldn't possibly wait 18 months that we had described in our detailed project plan as the release date for the new application.

We had to act fast because her executive team were losing faith in our approach. At that time, I had heard of Scrum. I'd read a little bit about it in magazines and online articles. And I described it to Debbie and she was hooked. But I had to admit to her that I didn't know enough about Scrum and I didn't have any experience executing a Scrum project.

We partnered up with another Microsoft partner called CIBER UK, who had experience with Scrum and we formed a joint Scrum team. And over the course of the next 18 months, we delivered multiple releases into production, including a complex customer service application, custom customer portal and a custom offline application that's synchronized documents locally for doctors and lots more. Premier Medical Group ended up being acquired by Capita Group, a huge public company, in part, because of Premier Medical's leading edge technology. That was the Dynamics platform that we built. That was the start of my agile journey and my first Scrum project building complex business applications on the Microsoft cloud.

Maybe you're facing a similar situation.[00:06:00] Customers, these days, don't want to invest tens of thousands in discovery phases that produce documentation without any working software. You might have customers that expect fixed-price projects and expect all their requirements to be documented upfront. You might've faced the death-march situations where everything was underestimated and your team is under pressure to finish development while slashing the time available for testing and training at the end of the project. Perhaps like me, you've noticed the steady uptick in job ads of Microsoft partners looking for Dynamics 365 professionals with Scrum certifications or experience. Or you might just find yourself facing demand from Microsoft customers who want their partners to take an agile approach, and you're losing out to partners who have a track record in successful agile delivery. 

WHEN TO USE AN AGILE APPROACH

But that doesn't mean that an agile approach is suitable for every type of Dynamics 365 or Power Platform project, or for every type of Microsoft partner, or for every type of Microsoft customer, for that matter.

Let's discuss the three broad dimensions of when to use an agile approach. Those dimensions are the project, the customer and the delivery team. 

First, the project. I find that an agile approach is ideal for projects that have moderate to high levels of uncertainty in the requirements and moderate to high levels of uncertainty in the technical solution.

Projects with moderate levels of requirements uncertainty and solution uncertainty are complicated. Projects with high levels of requirements uncertainty or a solution uncertainty are complex. 

And projects with extreme levels of requirements or solution uncertainty are classed as chaotic. And you're probably best off avoiding those types of projects altogether.

But what about projects with simple requirements or where a proven technical solution is available? I'd class those [00:08:00] as simple projects. And honestly, an agile approach is probably overkill. In fact, it is overkill for simple projects. Let me give you a couple of examples of those simpler projects. If you're building a power app for your own use or for maybe a small team, something that might take you a few days or weeks. That's a simple project. 

Deploying Dynamics 365 Business Central using a repeatable template that you've used to deploy to other businesses as a simple. 

Implementing an off the shelf ISV application that delivers industry specific capabilities for Dynamics 365 Sales or Customer Service could be a simple project.

Simple projects are often best handled with a repeatable implementation approach. A set of proven steps to follow to quickly deploy value into the customer's environment. The more repeatable and the easier those steps are to follow, then the higher the chance of success. 

There might be some minor variations in the requirements of each project, but these are handled with simple configuration changes. Nothing too wild or too crazy. Probably no custom development in Azure or complex systems integration or data migration from multiple legacy systems.

I've chatted to several Business Central partners who could never imagine needing to use Scrum. Their projects are finished in a couple of years. And I've discussed at Scrum with customers who have a Power Apps team operating like a factory manufacturing simple line of business applications for different divisions and departments of their organization. Scrum is probably not going to add much value here. 

On the other hand, a complicated or complex Dynamics 365 or Power Apps project might need a team, or multiple teams of people, and be expected to take months or even years to get. With all the analysis in the world, there's almost no chance of knowing all the requirements upfront or being able to design everything perfectly on paper [00:10:00] before we start development. 

An agile approach that lets the requirements and the designs emerge as we build the software will help to reduce the risk. Scrum is perfect for building these kinds of enterprise, critical business applications. 

Since 2008, I've been building business applications using Scrum to shrink my team's delivery timelines, slash my project budgets and build amazing applications that my stakeholders have loved. And my teams have had heaps of fun building too. 

Using an agile approach works best if you're building complex critical business apps, but probably isn't suitable. If you're building simple applications would have requirements and the technical solutions are well understood. 

While we're on the topic, I've never led a Finance and Operations project yet. I'd love to. A lot of ERP professionals believe that it's impossible to run an agile ERP project. I have run enterprise CRM applications to replace complex legacy CRM applications, where it wasn't possible or practical to deploy into production every sprint. Every six or nine months might be more like it.

I'd love to run a Finance and Operations project with Scrum just to see, just to prove, that it's possible. Because I think it is. Okay, putting my hopes and dreams of agile ERP aside for a moment, there are a couple of other dimensions that guide us towards or away from taking an agile approach. 

One of those is the characteristics of the customer.

You might work for Microsoft customer and you're building internal Power Apps or Power BI applications for other divisions or departments in your organization. You might not be selling applications or selling your services on a commercial basis like Microsoft partners do, but you still got customers, right?

And some customers are ready for an agile approach while others aren't, let's face it. 

The first thing I think customers need to have is someone that I can [00:12:00] identify as ready to become our product owner. I'm looking for a senior leader with a significant stake in the success of our application, who has the capacity, the trust, and decision-making capability to act as our product owner.

I'm not necessarily looking for somebody with previous product ownership experience. Most of my business applications product owners are first timers with no previous experience of Scrum and probably no previous experience being involved in any kind of software project, let alone Dynamics 365 or Power Platform.

If they have the capacity, the decision-making capability and influence, then I think we can coach them to become great product owners. 

I'm lucky enough to have had amazing product owners on all of my Scrum projects. Uh, except one, um, which could hear about an episode 31, that was a Power Apps Portals project that got canceled. Uh, it was a failed project. It was a failed project. I'll admit it. And guess what? It didn't have a product owner. I've succeeded on some projects with multiple product owners, which isn't ideal, but definitely better than none. Having a product owner then is a prerequisite for adopting an agile approach.

I've run Scrum projects in organizations with no previous experience of agile approaches and some were an agile approach is the norm. And certainly it's easier if it's not the customer's first agile project, but that's not a deal breaker for me.

What is a deal breaker is if the customer wants a fixed price, fixed date and fixed scope project. That's a signal that the customer thinks this is a simple application, not a complicated or complex one. Or that they think that shifting all the risk onto the delivery team is going to be less expensive for them or lead to a greater chance of success.

Those are red flags and I would run away. 

I'm happy to deal with fixed price or fixed date, maybe even [00:14:00] both within a Scrum project, but not fixed scope as well. I've used Scrum successfully on projects that are fixed date or fixed cost. The constraint of working in short increments works well in response to these conditions. 

Fixed scope is harder, partly because I believe that fixed scope is usually a myth. It's almost impossible to specify all your requirements upfront when you're trying to solve complex problems. 

Lastly, the third dimension in qualifying a project is my team. 

Do we have an experienced scrum master or can we find one? 

Are the developers in the same location or at least similar time zones? 

Do the developers have capacity dedicated to our project or do we have to wrestle them from other commitments? 

And do they have experience, or the burning desire, to practice agile techniques such as self-management and self-organization and some technical agile practices too, like user stories and planning poker, and pair programming, and unit testing, and test driven development, continuous integration/continuous development, test automation, and lots more.

The more of these questions we can answer 'yes' to then the readier my team is for an agile approach, like Scrum. 

BENEFITS OF AN AGILE APPROACH

If you think building complex business apps with an agile approach might work for you, the next step is to understand the benefits because you're going to need to be able to pitch an agile approach to others and convince them to join you on this journey.

So here are some of the benefits of taking an agile approach to building business applications. I think I've got maybe nine or 10 benefits that my customers and teams have experienced when they've adopted an agile approach. Listen in, and if any of these resonate with you then feel free to use them when you're trying to persuade your boss or your team or your stakeholders to change the approach. Here goes. 

1. Better software. When you're using an agile approach, like Scrum, you analyze and design features [00:16:00] iteratively, and your stakeholders get frequent opportunities to review those features and provide feedback about what's next. Taken together, I've found that just in time elaboration and frequent feedback helps us build better software that's closer to what our stakeholders want and need compared to the traditional approach where we try to specify everything upfront and didn't get any feedback until the UAT. 

2. Earlier releases. With a traditional approach, none of the features are released until they're all ready for release. But with an agile approach, you can deploy a feature or set of features into production as soon as they're ready. At the University of New South Wales, we deployed Dynamics 365 for marketing and customer service in a two year project. But the first release to production was after 10 weeks to replace a ticketing application and avoid renewing some Oracle licenses. Quick win!

3. Faster return on investment. Take those two benefits together: apps that are a better fit for the requirement and apps that are released earlier into production and an agile approach lights a rocket under your return on investment. 

4. Higher user satisfaction. Users love being involved in review sessions and having their feedback incorporated into future versions. Even if only a handful of users participate in reviews, they'll spread excitement among everyone else, who knows that the application was partly designed by their peers. 

5. Better visibility and confidence. Scrum brings transparency to the application development process. Your stakeholders can join any of your reviews and know exactly where you are at. Risks are made more visible and tackled much earlier, which gives governance boards more confidence in your team. 

6. Allocation of capital. Incremental funding of agile projects is a more efficient way to allocate funding. Instead of setting aside millions upfront for capital intensive, big bang [00:18:00] projects. Instead you can approve funding quarter by quarter as more and more features become available.

7. Reduced risk. By tackling risks early, like difficult integrations, data migration, or production releases, you de-risk your project. Agile practices, like spikes, further reduce risks by giving the team an opportunity to evaluate options and find solutions to upcoming requirements.

8. The customer is in control. An agile delivery team is guided by the order of the backlog managed by the customer's product owner. They're not locked into a set of tasks, locked into a Gantt chart. The product owner is accountible and can react to changes in the organization's priorities at any time.

9. Empowered collaboration. Agile teams, especially scrum teams, are trusted to work together collaboratively and closely to achieve the short-term sprint goals and the longer term product goals. They're given autonomy, freedom to manage their own work and get the job done creatively and professionally. That's why so many members of my teams have told me that their first Scrum project has been the highlight of their career. It's just a lot more fun to work on. 

Okay. I think there's nine benefits. If you're asked why you're going to propose an agile approach for your project, pick a couple of those and depending on who you're talking to, and they'll soon be on board.

WHAT IS 'AGILE'?

Once you're onboard, your team on your stakeholders are on board, you're ready to jump in and start using the agile methodology on your upcoming Power Platform project. But wait, there's actually no such thing as 'the agile method' or 'the agile methodology'. That's right, folks. Although I've seen it specified in requests for proposals, "respondents must describe their experience with the agile methodology", there's actually no such thing. 

Let's take a quick history tour and discover what 'agile' actually is and what it means and what it's not. First of all, it's nothing new. Since the [00:20:00] 1950s, when software development really started, we've been trying to find ways of making it suck less. I'm not talking about technical innovations, like object oriented programming or integrated development environments, or even low code, no code application builders.

I'm talking about the ways and methods we use to understand, collaborate, evaluate, verify, and operate our applications instead. It started in the early 1990s with concepts like rapid application development, Scrum, eXtreme programming, user stories, and feature driven development. But none of those things were called agile because the term wasn't actually coined until 2001.

In 2001, Bob C Martin, known as uncle Bob, assembled 17 leading practitioners, authors, presenters, and inventors at a gathering at the snowbird ski resort in Utah. Together, they published a manifesto which described four values and 12 principles of agile software development, which I think Bob originally wanted to be called 'lightweight' software development until one of the attendees coined the phrase 'agile'. 

Here are the four simple values they described. They said:

We value individuals under interactions, over processes and tools; 

We value working software over comprehensive documentation; 

We value customer collaboration over contract negotiation; and 

We value responding to change over following a plan.

And they also described 12 principles, which I'm going to summarize. 

Our highest priority is to satisfy the customer. 

We welcome changing requirements. 

We deliver working software frequently. 

Business people and developers must work together daily. 

We build projects around motivated individuals.

Face-to-face conversation is the most efficient and effective method of conveying information.

Working software is our primary measure of progress. 

We should be able to maintain a constant pace indefinitely.

Continuous [00:22:00] attention to technical excellence and good design.

Simplicity is essential. 

The best architectures requirements and designs emerge from self-organizing teams. 

At regular intervals, we reflect on how to become more effective and adjust accordingly. 

That's all there is to agile: four values and 12 principles. But it's simplicity also makes it tricky. If you adopt 11 of the 12 principles, is your approach still agile?

What if you have a secret passion for comprehensive documentation? Are you still agile. Does it matter? 

I think it does. I think it does quite a bit. I think it matters because of something I've seen called a hybrid approach. Hybrid approach is often one where someone cherry picks stuff from an agile framework that they like, and they jettison the rest.

For example, we document all the requirements upfront and then develop in iterations. With a hybrid approach no one really knows what the hell is going on. It's a "make it up as we go along" approach. It's rarely repeatable. It's rarely written down. I've never seen anyone with a hybrid training course or certification assessment that insurers everyone on the team knows what they're doing. Because they don't. 

THE SCRUM AGILE FRAMEWORK

If you're going to adopt an agile approach and that there's no such thing as 'the agile method' but you want an approach that's repeatable across all of your projects yet adaptable to different types of projects, what's your best option? 

My preferred agile approach is the Scrum framework. Kanban is great for a lot of scenarios too, but honestly, I don't have as much experience with Kanban as I have with scrum. 

Scrum was devised in the mid nineties by Jeff Sutherland and Ken Schwaber. Those two guys who were at Snowbird and they were signatories to the Agile Manifesto a few years later. 

Here's a fun fact you can impress your family with. Scrum got its name from a paper published in Harvard Business Review in 1986 called, "The New New Product Development Game" by Takeuchi. and [00:24:00] Nonaka.

They're contrasted the old sequential approach to product development to rugby, where the ball gets passed around within the team as it moves up the field as a unit. One of their subheads in their article was 'Moving the scrum down field', but I suspect that Takeuchi, Nonaka, Sutherland, and Schwaber haven't played much rugby.

Rugby scrums are contentious set pieces. In fact, my little boy played rugby for the first time, in the first competitive game, this weekend and we had a contentious scrum. No one passes the ball around in a scrum and scrums usually only move a few meters. It's a terrible analogy and it's a terrible name, but it's the one that we're stuck with. 

Scrum is a framework for developing complex products. That's the only eight words. Let's focus on a couple of them. It's a framework. Scrum is a scaffolding into which you're welcome to add your own complementary practices. It's not a complete, prescriptive methodology with templates, role descriptions, and stage gates and all the rest of it.

It's for developing complex products. As we learned earlier, adaptive approaches like Scrum are probably overkill if you're building simple, personal productivity apps on your own. They're much more useful for building complex, critical, enterprise applications as part of a team. 

The Scrum Guide that defines the scrum framework is only 13 or 14 pages. Scrum has just 22 parts. Three pillars: inspection, adaptation transparency. Five values: focus, courage, commitment, openness, and respect. Three accountabilities: product order, developers, the scrum master. Five events: the sprint, sprint planning, daily scrum, sprint review and sprint retrospective. And three artefacts with three commitments: the product backlog with its definition of done. The sprint backlog with it's sprint goal. And the [00:26:00] increment with its definition of done. Just 22 parts, that's it. 

Let's take a quick dive into it. We start with our product owner. She's the person with a vision for solving a challenge with a Microsoft business application. She sets out a vision for the problem that we're going to solve. That's the product goal. And together, we build a backlog of all the work that we need to do to achieve that goal. That's the product backlog, and it contains product backlog items. The product owner's aspirations are turned into business applications by the developers who are responsible for getting all the work done in the ordered product backlog. 

The product owner, the developers, and the rest of the organization are coached by the scrum master.

The scrum team works in sprints. These are time-boxed iterations that last less than a month, often just one or two weeks. Each sprint starts with sprint planning. The team negotiates its goal for the sprint, forecasts which of the product backlog items it'll get done in the sprint, and formulates a plan for getting them done. Every day the developers sync up and adjust their plan for the day in the daily scrum. There are two events towards the end of the sprint, the sprint review and the sprint retrospective. At the sprint review, the team looks out and reviews it's achievement of the sprint goal and its progress during the sprint with the application stakeholders. The stakeholders are invited to share their feedback and any advice they have about the product backlog. At the sprint retrospective, the team looks in and reviews its processes to uncover ways of improving how they work so that they can improve the quality of their interactions, the product they're building, and how they build it. 

There are three deliverables and each deliverable has a commitment. The first deliverable is the product backlog. The product owner is accountable for it and for ordering it and its commitment is the product goal set by the product owner from time to time. The second deliverable is the sprint backlog and its [00:28:00] commitment is the sprint goal. And it's reset every sprint. The third deliverable are increments of verified, working product and their commitment is a definition of done, which defines the quality criteria we set ourselves for our application. 

OUR BUSINESS APPLICATION IS A 'PRODUCT'

For us, the product usually refers to a complex Dynamics 365 or Power Platform application. And although I often talk about Scrum "projects", I think it's helpful if we remember that our application, isn't just a project. It's a product. Even after our initial project to build the application and deploy it into production is over the product, the application, still exists. And it's a product so it needs to be continually enhanced, supported, maintained, and updated over time.

The application's product backlog will continue to exist. Even after the initial project team has packed up and gone home. If you ignore that backlog, then your business requirements will continually evolve while your applications stay still. And eventually they'll drift apart until someday a new project's going to come along and rip everything out and start again. 

I live in a 100 year old Queenslander timber home, and it's got a product backlog too. It needs frequent maintenance, enhancements and updates to meet my family's evolving requirements. And although the project to build the house finished a hundred years ago, I need a fund a small team to keep it updated. That small team is usually me during the weekends. 

I hope your business application receives regular funding and has a small team to work through the backlog, even after the initial project team might've rolled off.

SCRUM CERTIFICATION FOR MICROSOFT PROFESSIONALS

I'm sure most of you listening to this podcast are eager to showcase your talents with Microsoft badges. I know some of you collect Microsoft badges like my kids collect Pokemon cards. Got to have them all. The good news is that there are plenty of badges available for Scrum practitioners too.

There are some great Scrum courses and certifications available, and there are some that I [00:30:00] don't think hold much value at all. Let's start with the two that I recognize and value. I would avoid the rest, to be honest. 

These are the Certified Scrum training and certification series from the Scrum Alliance and the Professional Scrum training and certification series from Scrum.org.

Scrum Alliance was co-founded by the co-creators of Scrum, Jeff and Ken. But Ken later left and established Scrum.org. Scrum Alliance has introductory certifications, including Certified Scrum Master, Certified Scrum Product Owner and Certified Scrum Developer. Certification is only available if you've taken their training courses, which usually cost between $1,000 and $2,000 and take two days of classroom-based training. Their certifications expire after two years, unless you pay to have them renewed. The training is high quality, but it can vary widely since each Certified Scrum Trainer produces their own training material. 

I recommend Scrum.org Professional Scrum training and certification series instead. Scrum.org's Introductory Certifications are Professional Scrum Master, Professional Scrum Product Owner, and Professional Scrum Developer, Scrum.org training classes also costs between a thousand to $2,000, and to take two days. Their training is also high quality and all Professional Scrum Trainers use the same training material. Scrum.org's certification assessments are available whether or not you've taken Scrum.org's training classes, which is the primary reason I recommend them. The certification assessments are rigorous and require a score of 85% to pass. And the other reason I prefer a Scrum.org certifications is that they don't expire. 

If you want to achieve your Scrum.org PSM1 certification then my Scrum for Microsoft Business Apps online course will teach you all the parts of the Scrum framework you need to know for the PSM1 certification assessment, as well as a practice assessment that uses the same [00:32:00] exam engine and format as Scrum.org and it includes dozens of proven practice videos and case studies from my 13 years of building business apps with Scrum. You can find out more about that course at Customery.com/Scrum. And there's a link to that in the show notes.

COMPLEMENTARY PROVEN PRACTICES FOR BUSINESS APPS

Talking about proven practices for building Dynamics 365 and Power Platform apps with Scrum, let me share a couple of those with you, so you can get a flavour of what else we cover in the course.

The first is user story mapping. In Scrum we have the product backlog, which is an ordered list of all the work we need to do to build our application. However, I find it's got a couple of shortcomings, like how do I know if it's complete or whether we forgotten anything or anyone? And how do I know when we can release parts of it into production. User story maps I've found really helpful for answering those two questions. 

The next practice, which I'm sure you've heard of, and maybe even used is user stories. User stories were introduced as a practice in the eXtreme Programming agile framework, as a way of reminding developers, what users want and need. Today, lots of Microsoft customers and partners are using user stories to capture their requirements.

Far too often though, I've seen the user story format followed slavishly and it's complemented with scenarios, and acceptance criteria, and wireframes, and other artefacts, until each story is a mini specification instead of just a reminder to go and have a conversation. 

User stories can be great, but you've lost the original intent if you're using them as a mini specification. Or if you're trying to write every single requirement as a user story. In addition to user stories, my backlogs have non-functional requirements, bugs, chores, spikes, product goals, and features or epics inside them. User stories are useful, but we don't need to use them for [00:34:00] everything.

One more technical practice that I encourage my Scrum teams to adopt is continuous integration/ continuous deployment, CI/CD. CI/CD is the art of frequently synchronizing our work and deploying it to minimize the elapsed time between releases. This practice ensures that we have production ready features that can be deployed whenever the product owner chooses. And it requires us to practice healthy application life cycle management and automated testing. This is a technical practice that's a journey. It varies depending on whether you're building Business Central, Finance and Operations, Customer Engagement and Power Apps or Power BI applications. 

I don't think any of my teams have ever perfected it yet, and Microsoft is always tweaking the platform and enhancing the tools available so that our CI/CD and ALM practices needed to keep evolving too. 

There are lots more proven practices in my Scrum for Microsoft Business Apps course, including proven practice videos for each of the three accountabilities, all of the scrum events, and the scrum artefacts. And, I think there's about 11 videos on managing the product backlog. These practices are not included in the Scrum Guide and they're not assessed in the PSM one certification, but my teams are find them invaluable when we're building business applications with Scrum.

 Okay. I hope you've enjoyed that flagship episode of Amazing Applications. 

INVITATION TO JOIN THE CUSTOMERY ACADEMY

There's lots more I'd love to share with you. 

You can join my free Agile Foundations for Microsoft Business Apps training course at the Customery Academy. It's short, it's one hour. There are some quizzes along the way. When you finish the course, you'll get a special offer to come and join my Scrum for Microsoft Business Applications course. And you get a certificate of completion, that'll get posted on LinkedIn as well. Come and get a flavour of my training and the value it can add to you and to your organization. 

If you want to come and join the Scrum for Microsoft Business Aps course, we'd love to have you. Hundreds and hundreds of Microsoft Business Applications professionals have taken that training [00:36:00] and nearly a hundred of them so far have achieved their professional scrum master level one certification. We'd love to see you join us there as well. 

And finally, I have a new masterclass available. It's just going into private preview over the next couple of weeks. The masterclass is called a Winning Agile Projects and that's in response to the number one question I had from Scrum students, which was "Okay, now we know Scrum, how do we sell it? How do we pitch it to prospective customers so that they're convinced and they'll come along on this journey with us and say 'yes' to using the Scrum framework to building business applications?"

So that's it for me. I really hope you've enjoyed this flagship episode of Amazing Applications. 

We've got lots more interviews coming up. We've got lots more solo episodes coming up. I'd love you to join us. So do remember to subscribe and visit the Amazing Apps dot show website, where you can sign up for our mailing list and get lots of special offers, sneak peeks into more podcast episodes and Customery Academy training videos on YouTube. I'd love to see you there. 

In the meantime, keep sprinting. Bye for now.