Origin Stories

Welcome to the Amazing Apps show for Microsoft Business Applications creators who want to make amazing, agile applications that everyone will love.  

Hi, I'm your host Neil Benson. The goal of Amazing Applications is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Power Platform and Dynamics 365 applications.

Welcome to episode one, Origin Stories. You'll find show amazingapps.show/1. 

In this episode, my cohost Dermot Ryan, and I introduce ourselves and let you know how we got started with an agile approach to building business applications. I hope  you find it interesting and can relate to our story. Let's go.

  Hi everybody. This is Neil Benson. Welcome to our new podcast. Hi everyone. This is Dermot Ryan here, and I'm a colleague of Neil and lovely to be on the show we get started with giving us a quick rundown on your background was Scrum and dynamics 365. Sure. So just to introduce myself to everybody my name is Dermot Ryan, and as you can tell, I'm also Irish, just like nail, so hope everybody can understand two Irishmen having a chat over a podcast.

My background is I graduated with a computer science degree, many moons ago, and I started off my career as a consultant with IBM in Dublin, working under AIX range of Unix servers. So after a couple of years of doing that, I relocated here to Sydney and. Quite a good few years. I worked on the trade floor of a large investment bank managing their it infrastructure for front middle and back office.

So it was around this time that I got interested in dynamic CRM and Scrum in particular. So after that I joined a boutique consultancy here in Sydney called XR elements that specializes in Microsoft dynamics. So big shout out to Ines. Prisco Mark Fowler, who are the two principals over there. learned quite a lot of those two guys on all things, CRM and also learned, cut a lot of exposure to Scrum projects working across multiple sectors, such as state, federal government education, financial services, and also in engineering, such as heavy machinery and tools.

So after a few years with XR elements, I moved on to KPMG where I now work and I'm a scrum master. Large Microsoft that I'm extremely six, five CRM implementation for a university here in Sydney. I'm certified scrum master and professional scrum master. And I'm also prince two certified and item certified, which deals with incident, product management, change and release management.

And of course I've got certifications in dynamics 365%. So that's good stuff, Jeremy. Yeah. Yeah. You've got one up on me. I'm not prince two certified. I've got some understanding of prince professional, scrum masters certification, as well as my certified scrum master certification. And maybe we can take some time to contrast those two different sort of key occasion paths.

Absolutely. Yeah. I come from a waterfall background originally and now I'm into Scrum world, so it's good to know both sides of the penny. So yeah, we can talk about. Good. And what's your background? Neil, do you want to give us an introduction? Yeah. Thanks. When I started in sales just over 20 years ago, I was selling and implementing Onyx CRM software, or way back in the nineties for an application service provider.

As we called it in those days, I was in depending Onyx at Rackspace and I loved their hosting model. That was really the early beginnings of the cloud. Whenever I finished that project. I called up Salesforce. I called Sage and Microsoft and said, Hey, I want to host your software for small businesses. And lo and behold, I became a Microsoft serum hosting provider.

And that business was called increased CRM. And I sold that business in about 2009, just before we won a project with a client called premier medical group who after six weeks of analysis and design a massive big requirements specification they, the system. Sponsor there. Debbie couldn't believe that requirement spec was accurate or complete.

And she didn't want to wait for 12 months before seeing the first version. So we switched to something called Scrum. I've used Scrum on most of my projects since then, I became a certified scrum master in 2013 with my cone. And it became a professional scrum masters. And I've used it in all sorts of projects that premier medical group, a guy's and St.

Thomas's hospital trust American homes for rent advantage sales and marketing at red bull and at Toyota, which is a little ironic considering that was the birthplace of lean manufacturing and some of the principles that went into agile software development, and more recently with all of our clients at KPMG Australia, it was well past six.

So plenty of scrum knowledge there, Neil That you a, also at MVP for dynamics 365. Yeah. I've been pretty lucky. So my first scrum project was 2009 and I'm lucky enough to have been given the MVP award each year since 2010. So really honored to be part of that crew as well. Great. So Jeremy, do you want to give us a rundown on the types of topics that we're going to cover on the podcast?

Yeah today. I think we should start with an introduction of what agile is and so agile and we're Scrum fits in the agile world. And then later on, we'll look at the advantages of using Scrum for dynamics 365 and hold a contrast with the waterfall. So as a quick overview of agile, so agile refers to software development, methodologies, and frameworks that are based on an iterative approach.

So requirements and solutions evolve over time, as opposed to a waterfall approach where all the requirements are defined upfront. Way back in 2001 with 17 software developers got together and they developed the agile manifesto is what they produced. So this laid down four key values and 12 principles of what is an agile software development methodology or framework Scrum is then considered to be a subset of agile.

So it's a lightweight framework for agile development and it's the most widely and most popular use framework in the world for agile and. So Scrum theory, it's relatively easy. And the essence of scrum is a small team of people that are highly flexible and adaptive. So at a very high level, that's what agile is aware.

Scrum fits into the agile. Yeah, I think it's really interesting that Scrum isn't really a complete methodology. There's lots of practices that aren't described in Scrum. So to it's a framework, which you have to follow in order to say you're doing scrum, but you always compliment that with your own way.

Capturing requirements, new and way of estimating those Scrum. Doesn't really describe how you do that. And things like risk management. I find aren't really covered in scrum.org either. So maybe we can touch on some of those additional practices that you find useful to bring to your Scrum projects that compliment it and allow you to adapt it to dynamics 365.

Yeah. One of the phrases I like to use when people ask me about Scrum is freedom within boundaries. And it's like you said, the framework is quite lightweight. It has some rules to it, but once you stick to those rules, it's, you're quite free to do what you want and how you adapt it. So that's what I really like about Scrum.

Is that how lightweight. So there's a perception that scrums was invented for and is best suited to custom software development projects where you're, cutting minded code from scratch that it's not really suitable for the implementation of commercial off the shelf software, like platforms like dynamics 365.

What are your thoughts on that Dermot? Packaged software out of the box implementations. They're making up quite a large percentage of projects these days. And there may be that perception that because it's a package that you can like dynamics 365, you can just turn it on. And Hey, Presto CRM is up and running.

But as we all know on large dynamics, 365 projects, there's quite a lot of configuration and sometimes customization is acquired. So Scrum is actually really good for delivering these projects. We treat the sort of implementation. The very same as any other Scrum projects and that we run sprints of between one and four weeks in length.

We have a fully cross-functional dev team. We have a strong master and we have a product owner or their proxies  who will be present at the requirements evolve as the project progresses. And we do regular releases to production a lot. You don't have to do that. It's scrum dictates that at the end of the sprint, you have a potentially releasable product.

You don't have to release. So particularly at the end of the sprint, we try to release it. I've done several Microsoft that I'm exterior in projects using scrum and I'd find it works really well. Oh, so many questions there, but all the terminology you just used product owners and proxies, and hopefully we can dive into some of that on some future episodes.

Yeah. Apologies for that Nila of just joining in a few buzzwords. We can deep dive later on in later podcasts voting what each of those means, but the essence of what I'm trying to say is that yes, you can use Scrum for dynamics and it works really well. Good stuff. Maybe our next episode should be an introduction to all that terminology.

Make sure that people are familiar with the basics of scrum. Do you want to do want to highlight some of the differences between Scrum approach and a traditional waterfall approach? Because that's some of the key benefits that people get out of Scrum. I think it's worth highlighting. Yeah, there's actually quite a lot.

I'll just go through a few here. We could talk about this topic all day cause there's proponents of waterfall and proponents of agile out there and not every project would be suited to Scrum, just like not every product would be suited to waterfall, but some of the advantages I see is decreased time to markets.

With Scrum, you get quick delivery of high quality software in increments. So typically we will run. What's called a sprint of between one to four weeks in length. And what this means is if we're running a two week sprint and at the end of that two weeks, we have a piece of software that's potentially released.

And can go to market. So straight away that the customer's getting bang for their buck, they can see what's being delivered. And within two to four weeks articles to the market, if you can't trust that to waterfall, you do all the requirement gathering upfront that could take several months in some cases.

And the customer has to wait till the end of the project to get bang for their buck and get return on their investment. And. Allied to this is incremental funding of projects. Again, with waterfall, you need to get your requirements and get a high level scope and get your funding upfront, which Scrum you can get incremental release of funds.

I'll give an example of a project we did. It was an eight week proof of concept and we broke this down at the four, two week sprints. And at the end of this eight weeks, Loved it so much that they decided to turn it on and go live in production with it. And the next trench of funding was giving for three more months.

So that eight week proof of concept actually turned into a multimillion multi-year project with regular release of funds, rather than getting all the funds upfront. So that two of the business benefits as I would call them. But then you also have the soft skill of benefits with your team. So another great benefit of Scrum on the soft skills side is that there's greater teamwork.

A scrum can be very empowering for your dev team. So in a traditional waterfall project, a lot of times you see the team being told what to do by a project manager and when to do it in contrast, in a scrum team data side, what is going to be accepted into their stuff. So if it's a two week sprint, once the dev team accepts the work, it's up to them, how to deliver that.

But of course, with great power comes great responsibility that the flip side of this is that the dev team are now responsible for delivering the sprint. But I found that people really relish this. They're not being micromanaged and are being empowered to dictate how the work is going to be delivered.

And this really energizes the team as opposed to just turning up to work, doing the time and going home. Yeah, there are some of the benefits I see of Scrum. We could talk about this topic all day. Neil, there's quite a lot more, but yeah, there's three that I really find her. Good. I think that last one is really important for me.

I just I've really enjoyed working on some projects a lot more. There's just that sense of we're all in this together. We're here to solve problems and get the solution out the door really quickly. There isn't a, a requirements specification written by a solution architect that you never met that you've got to try and follow.

And be somewhat of a slave to you've got all that responsibility and authority to come up with a solution and implement it and prove that it's valuable. And you get really quick feedback from the users as well. So if you're on the right track they let you know and you can keep going. Or if you're not quite delivering what they'd expected, you get that feedback early and you can fix it before you get too far off course.

Yep. That's right. Neil. And another thing with Scrum is that it's tailored for sustainable delivery. One of the ideas with scrum is that you could work at this pace indefinitely. So I've worked on a lot of waterfall projects where coming up to the end of the project, the whole team has to work a whole lot of overtime because all the deadlines coming, we've got to get it done with Scrum, the requirements evolve.

And as you've just alluded to there, the business are with you every step of the way. So they know what's coming up in two weeks and they know what the deadline is. It's a sustainable delivery. The team don't have to work lots and lots of overtime like you sometimes have to do in waterfall projects.

I've also seen towards the end of those waterfall projects where the development's taken longer than expected. He ended up just having to cut budget from the testing fairs or from the training fairs. And then they'll just put your whole project at risk as well. So Neil, would you like to touch on maybe the role of debt management plays in Scrum?

There isn't a project manager role. So how does management fit into that aspect? Yeah, I think there's still an important role for governance in Scrum that isn't really described within the scrum guide. For example, risk management, resource management, managing budgets. Those are still things that need to get done.

We can't get away from them and. Working internally at a Microsoft customer deploying, then I'm actually 65 or we're part of a Microsoft partner consulting for our clients and implementing it that way. You still owe a duty to the people, sponsoring the project to manage risks and budgets and resources and those kinds of things.

So what I find is there's a need for that stuff to get done. And then it's up to the scrum team to decide how to do it. Do they have. Hey, somebody from a project management office who comes in and helps them with those things on some kind of part-time basis, not person wouldn't necessarily be a part of the scrum team because they're not doing the work of delivering dynamics, but it could be for example, a practice director or a practice manager of new Microsoft consultancy or a project manager from that PMO from your client's side, who helps out and manages those kinds of things.

Or I've seen some smaller teams where yeah. Those responsibilities are shared between the dev team, the scrum master and the product owner, so that they all get done as well. What kind of approaches have you seen used it? The role tends to be spread out across the team. When I say a role, a traditional project management role and on the larger projects, we tend to have a project manager or program manager.

Who's crossed several projects. So we're talking about things like you alluded to there governance budgeting, finance resourcing. Yeah. Utilization of the team. A lot of docs will fall on a PMO function. But within the team itself, within scrum, you have the scrum master and that's not the function of a scrum master, although they can carry some of that role.

And it's generally the PM function is spread across the team. Neil, do you have any thoughts on Scrum for when you're budgeting for a Scrum project via fixed price? So we get asked that question quite a lot. Traditionally clients sometimes want a fixed price implementation and fixed price can either mean I've got a certain scope in mind, and I want to fix the price for implementing that scope.

That tends to be quite challenging with Scrum, because clients do have that flexibility to change the priority during the course of the project. So the scope isn't necessarily fixed, but certainly fixing the budget, I think works really well in a Scrum project. The proof of concept that you mentioned. I bet that client had a budget in mind for that proof of concept project.

And you were able to work within that because you know what resources are going to be working in that for the eight week time period. You don't what the cost of those resources is. Whether they're external resources or internal resources, you know what they're going to cost you until, you know what the cost of that project.

What you don't know is exactly what you're going to be able to deliver within those. Although you should always go into your project with some idea of the type of thing you're going to be able to deliver. And that's where good estimation and planning comes in a Scrum project, but then just a couple of days or a few hours, you can get those kinds of plans put in place.

You don't need to spend weeks or months on some initiation or discovery and analysis. All right. So typically we're looking at a time and materials approach for a Scrum project as opposed to fixed price. Would that be a fair comment? I think you can do it time and materials, or you can do it fixed price, flexible scope.

Either of those two approaches works really well. What doesn't work so well is fixed scope and fixed price. So Dermot bringing this one home, what we'd like to cover in our next step. Yeah, Neil. As you pointed out at the start of the podcast, I was already deep diving into the terminology and people might be getting confused with what is a product on, or what is a scrum master water to ceremonies?

Like what is a sprint? So thinking on the next podcast that we introduced the characters on a scrum team, what, who are those people? What is their function? And also water to ceremonies that are involved in a scrum team. Basically explained them at a high level. And later in subsequent podcasts, we can deep dive into how to use them best in your project.

That sounds great. So like a Scrum 1 0 1 for beginners to get everybody on the same page and to make them go further after that. Absolutely. And we will as much as possible, even though Scrum is agnostic to projects, we'll try and keep it as relevant to dynamics 365 CRM as we can. Yeah. That's good.

I'm going to drop in some of my previous experience and some of my client projects I'd love you to do the same and we can go. Fantastic. Sounds great. Now, looking forward to it.

 Thanks so much for listening to the Amazing Apps podcast. 

You can visit the show's website at AmazingApps.Show. 

If you enjoy this podcast and find the content useful, please remember to sign up for the show's mailing list on the website. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode.

On the website, you can also follow the podcast on all the major podcast players. And while you're there, you can follow AmazingAppsShow on Twitter and on LinkedIn, you can send me a message, leave a voicemail if you'd like a question answered on a future episode, you can leave a review and support the show through BuyMeACoffee or buy an Amazing Apps t-shirt. Visit AmazingApps.Show. 

Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!