Enterprise CRM with scaled Scrum at RACQ

[00:00:00] For this special birthday episode of Amazing Applications I've brought back an old friend of the show for a special interview episode. Dani Kahil is going to be interviewing me about the Jupiter project at the Royal Automobile Club of Queensland. 

 G'day, business apps builders. This is Neil Benson. Welcome to Amazing Applications. 

Today is Neil Diamond's birthday. He's 81 today. And did you know I'm named after Neil Diamond? Sweet Caroline was practically a family anthem in our house with my dad playing it on guitar at parties when I was growing up. And I always remember his birthday because when I was 16, I discovered that he shares the same birthday as... me. I didn't even remember it was my birthday today until my wife wished me a happy birthday this morning. 

For this special birthday episode of Amazing Applications I've brought back an old friend of the show for a special interview episode. Dani Kahil is going to be interviewing me about the Jupiter project at the Royal Automobile Club of Queensland. 

 We're flipping the mic and Dani's interviewing me for the CRM MVP Podcast.

Dani's a fellow Microsoft MVP and also runs his own business apps consultancy just down the road from me in Gold Coast.

Dani's an expert in requirements management and solution envisioning for business applications. And he's also launched his first online course to help us learn from his expertise and I have to say, Dani, you've done an amazing job. I'm halfway through the course and learning lots of great tips that will help me in business analysis and architect roles in the future.

You'll find Dani's links and a transcript of this [00:02:00] episode at AmazingApps.Show/109. While you're there, don't forget to subscribe to the Amazing Apps mailing list. You'll get a personalized welcome video from me and notification as soon as a new episode is published. Go on! It's my birthday!

Just before we get started, I'd like to congratulate a few Customery Academy students for completing my Scrum for Microsoft Business Apps course recently. Fiona Barr at Incremental Group in the UK, Pieter Cornelius at Vox by Braintree in South Africa, Christian Goergen at Bohnen IT in Germany. Well done to all of you. Fiona is the 35th person at Incremental Group to join Customery Academy and Peter's development team at Vox all joined the Scrum for Microsoft Business Apps - Team Plan too. You can find out more about the course at Customery.com/Scrum.

Here's Dani Kahil and I discussing the Jupiter project at RACQ. Enjoy. 

I'm sure most of the audience knows you, Neil, but for the ones that don't, would you mind give us a quick introduction of yourself?

 Sure. So hi everybody. My name is Neil Benson from Customery and I am a Microsoft MVP for Business Applications. had that award every year since 2010. And I've been working with business applications since around 2006 when I started a Microsoft CRM hosting company, and I've been working with Dynamics 365 since then.

And today I'm a delivery lead, solution architect, agile coach, and online trainer, podcaster, and a wannabe YouTube r as well. So it's nice to see you. Nice to be on the show, Dani. Thanks for having me. 

Thank you, what a nice intro. Well, lots of you know, hats, I guess. Amazing. I remember one question you ask and you and my previous when I was your guest, I'm sure the audience would be really keen to hear your answer as well on this one. Neil, what did you [00:04:00] have for breakfast this morning?

I went out for a run this morning and, I ran past a local cafe on my way home. My wife was there with her parents, so I had an iced coffee. And then when I got back in, she made me one of her amazing green smoothies. So it's kale, cashew, ginger, some vanilla, all mixed up in the blender of some ice. And I have that every morning and it's amazing. So that was my breakfast this morning. 

Oh, wow. Amazing. Very healthy. 

All right. Let's get started, Neil, look, I believe you had an interesting project that you would like to share with us and the audience today. Would you mind just giving us, you know, a bit of the project context, so you know, what, what it is about, the solution landscape what apps were involved and so on.

Thanks for the invitation, Dani, like I said, it's it's great to be on the CRM MVP podcast with you. The project I wanted to talk about was one I completed last year for a client called the Royal Automobile Club of Queensland, better known as RACQ. They are a motoring organization that offers roadside assistance, and insurance, and banking services to just over 2 million people here in Queensland. In the great state of Queensland in Australia. 

Their project was called Jupiter, and I started an up project in the middle of 2018 and finished are we two and a half, nearly three years later. And it was a big enterprise business applications replacement project. 

Wow, amazing. Two and a half years. That's a massive program of work, amazing. Jupiter, that's kind of an interesting name. Where does it come from?

Well, it worked really well for us. So we had all sorts of space themes, especially the change management team picked it up whenever they're doing all the project communications had astronauts, and had games that they would involve all the users in. 

Yeah.

It's actually a really mundane name because the legacy system that we were replacing, it's called Mars. I don't know what Mars stood for. Mars was an abbreviation, the [00:06:00] membership and 

Yeah, yeah, yeah. 

very banal. And what planet comes after Mars. It's Jupiter. So 

Yeah, right. Okay. 

that's where the project got its name from. 

Yeah. Yeah. Okay. Very interesting. I've seen, yeah, I've, I've worked with clients and some clients are more keen than others to have, you know, their project kind of named. I'm also quite keen to advise my clients to name their systems. Instead of calling it CRM or case management to name it something a little bit more, you know, funny and meaningful, meaningful for them.

I've remembered some projects in, in Belgium. Some very funny names, like one project I did the project was called MARYLIN. Another one, another one was Twix and I remember it was true walls into transformation or something like that. And, and they were, they were organizing internal games to find the name between stakeholders to drive adoption and also, you know, to involve user into something a little bit more funny. Come up with a name for our new platform that will, you know help you and so forth.

So, yeah. Interesting.

And so RACQ called the project Jupiter, but then they come up with a competition towards the end of the project to name the system that Jupiter was building. So the Dynamics 365 application got called something else. And the winner of that competition was CONNECT. 

Yeah. Yeah. Okay. Yeah. Nice, nice story about the names. So can you describe as well? So, so what was the system about, right. So, yeah, it's for RACQ what, what is the solution landscape? What kind of apps did you ended up implementing?

So they project was really there to replace two legacy applications, Mars, which was an AS/400 mid range or mainframe application. That was the organization's membership platform. It had all the roadside products were built and sold from there. And then on top of that, there was a custom CRM system, called MRM, which was really a graphical user [00:08:00] interface on top of MARS. And MARS was a green screen application. MRM was a web browser based application, but the legacy technology that it was based on, there's at least 10 years old for MRM and 30 years or 25 years old. In the case of Mars, some of that underlying technology was end of life and no longer supported by its vendors.

 Although they'd been talking about getting off Mars for 10 years, RACQ had never managed to get a business case to stand up. Eventually in 2018 or 2017, the business case was approved. In 2018, the project started. So it had a very technology focused to replace those two legacy systems. The business interest was there because if they wanted to build a new product, like a b undle of roadside assistance and car insurance, bundling those two things together was a multimillion dollar project because a lot of custom code involved in stitching the insurance system and the membership system together with the assistance system. So launching new products and bundling things was horrendously expensive for the organization and they wanted to improve the member, experience, the product development life cycle, as well as replace the existing technology. 

 So what was the solution landscape that you ended up implementing? So. The Power Platform. What kind of apps? Azure. SharePoint. Can you describe it a bit? Well,

So the technology vendor selection was done before I arrived and they had already selected Microsoft Dynamics 365 Customer Engagement, really focused around the Customer Service application. And a third party software vendor called Apttus who provided a CPQ or configuration price and quoting system.

Because if you can imagine online, if you want to buy roadside assistance, there's various tiers of the product you can buy. It also depends on your vehicle. What size of vehicle you have? Do you have a caravan? How far do you want to be towed? All this kind of stuff. So there's a lot of configuration in the product.

And so they bolted on a CPQ and pricing engine called Apttus onto Dynamics 365. We did a lot of custom development in Azure and there was a [00:10:00] few other apps that we built on the Power Platform, but really it was a heavy focus on the, on the Customer Service application for case management. 

So you were on the project for the whole duration, I guess since the start to almost the end is 

I was, I was actually working at RACQ on another adjacent project to help them implement Adobe Campaign. They had chosen Adobe because they knew that it could integrate with Dynamics. And so I was running slightly ahead on that as a solution architect on that project. The actual Jupiter program was going to run with a Microsoft partner who had been selected, but at the last moment the contract didn't materialize.

The Microsoft partner was really being asked to stand in front of the Apttus product and be responsible for its implementation. But this Microsoft partner had never heard of Apttus. Never pitched it. Never been part of it and didn't feel comfortable being responsible for its successful implementation.

But that was something that RACQ really wanted. So that contract never materialized. And I was asked at the last minute, really, Jupiter is about to launch, could you build a team of independent dynamics consultants and get this thing going? It's like, well, okay, sure. I've done that before. 

There were six work streams in the overall program. There was the project management office, the business and change team. I ran the dynamics team. There was an Apttus team that ended up being run directly by the vendor. There was an internal team of integration experts. And then another internal team doing data and analytics responsible for data migration, and also at the other end building all the analytics and BI.

Well, a lot of different teams. So you were the Dynamics lead, kind of architect? Does what kind of role did you play during the project then?

So I was the delivery lead. I was heavily involved in the architecture and I sat on the architecture steering group. There were some dedicated solution architects as well. Interestingly, they didn't form part of our Dynamics team. So the solution architects sat outside. [00:12:00] Two or three of them. And they kind of just oversaw the decisions that we were making as a Dynamics team and make sure those lined up with technology strategy made sure they were documented to the right kind of governance standards and we'd run kind of major decisions past them. But a lot of the day-to-day solution design decisions was left up to me and the, and the team in the Dynamics workspace. 

Let's move on to the implementation, how that went?

Well, as you can imagine, Dani, I was a big fan of using the Scrum approach and I got a chance to do that, of course. So we had enough developers in the Dynamics team to split into two scrum teams. 

Oh yeah. Okay.

Each scrum team had analysts, app makers or functional consultants or low code developers, whatever you wanna call them. And couple of pro code developers and some testers. So there was a overall testing team and I borrowed a testers from that team into my Dynamics 365 scrum teams. As we expanded, we actually ended up with three scrum teams at one point and then came back down to two.

So the team kind of flexed depending upon how much work we needed to get done in each of the major releases. And it worked really well. We ran Scrum pretty much by the Scrum Guide we added in some extra technical practices. We did some pair programming. We did story point estimation and planning poker. We used user stories. You know, these are things that are not in the Scrum Guide 

They are technical practices that we enjoyed bringing into our teams. And I think we were very successful. And Jupiter was a great success. So we had a small part to play in it. The project was about 120 people at its peak and they Dynamics workstream probably had about 20, 25 people at its peak. So we're just a small part of the overall program. 

Yeah, right? Yeah. Cause my next question was about asking you, you know, about what was, I was almost afraid to ask that question, but once the methodology used. Right. But thank you. Thank you for clarifying that. So two scrum teams. So how did you divide [00:14:00] work? I guess, to, to the team they were, were they working on the same projects?

Yeah.

so we had one backlog, we had one scrum master, and this is maybe one of the challenges of Jupiter. We had one product owner team, not a single person, like I like to have, but so we had you know, a shared product owner committee, if you like. 

Really the team just divided the work up themselves. So we'd have joint sprint planning. We would have separate daily scrums and we'd have a joint sprint review and a joint sprint retrospective. 

Obviously we're working to the same sprint cadence. All of the technology work streams, all had all were working in sprints. They weren't all using Scrum, but they were all working in the same two week sprints. So that was good. In terms of the division of the work, it tended to be fairly stable. So there was modules within what we were building, like the membership features or the insurance features or the roadside assistance integrations, and a team within the Dynamics work stream would tend to stick within that lane.

Occasionally, we'd swap over cause I wanted people to be multi-disciplinary. So we weren't relying on one team or one person had all the experience of building all the plugins for the insurance integration. I wanted more than one team to be able to do that work. So occasionally we'd, we'd swap around a little bit. But most of the time it there'd be a clear division of labor within the teams and they were pretty happy with that. But every now and again, we swapped the team membership around and new people came in and some people left and everybody got a chance to work on a bit of everything. 

Let's jump into that first challenge that, that you just raised now. It's often that we have, I mean, it's happened mostly on those biggest, biggest one, right? Where you have a committee of, of people making decisions. As you call the committee of productivity owners.

Can you, can you drill down a bit to the challenges that you faced?

Yeah.

You know, when I was reflecting on some of the challenges that we faced in this project, the committee of product owners, wasn't one of them. It wasn't ideal. We didn't have a real [00:16:00] issue with it. So we had three product owners, each representing a pillar within RACQ. So the way the organization is set up, there was an insurance pillar and assistance pillar, a membership pillar, and a banking pillar. Banking came in scope later for us, but really we had one product owner representing each of those pillars.

And this is such an enterprise wide application. So there isn't really one person we could go to who could make decisions on behalf of all three or four pillars. So we're always going to end up with some kind of team structure or committee. However, they worked really well together. They were supported by some business analysts. things like process mapping and standard operating procedures.

And they had some subject matter experts who knew exactly how the contact center worked or how we handled it whenever members passed away and how we handled enclosures and these kinds of things. And so they had a great team supporting them. And the three of them just work really well together. 

I've been in similar projects where there's been a clash of priorities. Nobody can make the final decision about what's in the sprint backlog or what's at the top of the product backlog. But these three product owners, take my hat off to them, they were a really close team and they made life pretty simple for us as a Dynamics team. They made our priorities very clear and couldn't have asked for a better really. It could have been an issue and maybe it was a risk for us, but it turned out never to eventuate. So that wasn't one of the challenges that we really faced. Thank goodness. 

So indeed Neil. Having multiple product owners. This is something that I have seen as a challenge in my previous project. Right. And especially when you have product owners that don't know each other, that well from the beginning that they also need to learn to work together. Towards the middle and the end of the project, that collaboration is really kind of getting way better, but the beginning are often are quite challenging where decision other, another meeting time. Sometimes also I'm the chief you face dad, but sometimes no one can, can make a proper decision. It has to go to you know, resolve a group or a kind of [00:18:00] a committee of, of higher stakeholders to make a call because the product owner simply cannot agree.

Did you face that the on your 

yeah, sure. So, so the product owners that we worked with, they reported to business owners. One again, one from each pillar, they were part of the overall governance board, which included a CIO who was the project sponsor and some more general managers and directors within the organization. So yeah, there was definitely some decisions that had to go up a couple of levels and then the decision would come back down again.

What we find worked for us was a decision log or a decision register. So we knew in sprint two that by sprint five, we're going to need to start implementing this feature. And by then, we need to have this decision made. How are we going to treat members who come back to us after a two year absence or whatever the decision is?

And we don't know what the answer is today. The product owners probably don't have sufficient authority to make that decision themselves. So they've got to run that up their governance committees, and then bring the decision back down. So we had that documented in a decision register and we'd meet a couple of times a week to review those decisions.

How are we doing the right people on board? Have you had those workshops outside of the project to get those decisions made? And so we knew in advance what the decisions were and how they were progressing. 

Some agilists tell you that a decision to register is overkill. It's too much documentation. It's bureaucracy. We found it worked really well. Not just for streamlining the decisions that we had to make, but also in hindsight, you can always say, well, when did we make that decision? What was the decision? Who made it? Who had a participation in it? What were the other alternatives we evaluated? And, you know, you've got that institutional knowledge now recorded and our case in probably, or in JIRA, and anybody can look back on it at any time.

So we found that really useful. Maybe a bit of bureaucracy for small projects, but for a big enterprise program like this, it was a really useful practice. 

Yeah, absolutely. I guess it's also because of the length and the size of the predict where no one can really, no one knows everything. And also the length. I presume people going away [00:20:00] and you, new member coming in, you kind of need a place to look for key decisions, right?

So how was analysis done? I mean, gathering the requirements, you know, working with understanding then backlog refinement and so forth. Can you tell us a bit more about that?

Before the rest of the Dynamics developers were hired, I led a couple of workshops to come up with a high level product backlog, kind of an epic or a feature level. We had a lot of requirements at that stage, probably a hundred, let's say a hundred high level requirements. And we estimated those using some big story point numbers. Somewhere between 13 and 100 points. If somebody felt that a high level requirement was bigger than a hundred and it was twice the size, we'd just split it up. And so we had, yeah, probably in the range of a hundred high level requirements, but by the end of the project, we had decomposed those and split them up into thousands of more implementable user stories.

But we started out with a hundred high-level requirements and we split those up into what we called traunches or major releases. And that was how we started. And then as the Dynamics team were hired, we had some business analysts within the Dynamics scrum teams who were then responsible for taking this high level of requirements, highest priority ones and breaking those down into more implementable user stories. 

So we're using a combination of Confluence and JIRA to record that. The teams were heavily involved in the elaboration workshops. So we work with the product owner, the subject matter experts, the business analyst would facilitate those elaboration workshops and then at the end of that, we're estimating those new user stories.

At that stage, the user story has a c lear title, we know the persona, we have some scenarios, we have some acceptance criteria and that's met our definition of ready. So that was another practice we brought in. Definition of ready isn't for every team, but we find it a really useful practice for us. So we're not going to estimate until some criteria are met [00:22:00] and the story has been approved 

At that stage would estimate it. We're trying to do that maybe a sprint or two before we need to start work on the development of that feature. So that's always a bit of contention, you know, can we do this just in time elaboration? Have we got enough work ready for the development teams?

We're coming up to sprint five. How does our backlog look. There's not a lot of work in there that's been approved and ready to go. So the analyst having to scramble and work a bit harder. So always that contention between the speed of the analysis that you can do and the speed that the development team can get through the work. 

The business analyst where they did, they knew Dynamics a bit at all, or they had some, some knowledge of the tools.

The first two business analysts we had, one was recommended to me because he had been at RACQ before and had good knowledge of the organization. And so we recruited Rob onto the team. He was brilliant, really a very empathetic soul. He really knew that you knew the users knew their processes, knew how they wanted to work and had a lot of hands-on experience in the organization.

He was great. Didn't know Dynamics, but experienced business analyst, working with complex applications and he turned out great. Didn't need a lot of Dynamics experience to get started. And he probably knows more now. He's been here three and a half years. 

The other business analyst we hired had worked as a business analyst on a couple of Dynamics 365 projects before. Unfortunately I reckon that business analyst just didn't fit our culture and we had to make a change after probably three or four months. And we got in another business analyst. And later as the project team grew, we probably had three or four on lists on the team at one point because we just, the developers were now working at real pace and we had to feed them with you know, elaborated user stories that were ready to go. So we scaled out that business analysis group. 

 So tell me a bit about the challenges that you faced in general on the project. You know, the methodology, the approach. Do you face anything major? 

Yeah,

So I touched on resourcing there. 

yeah, 

It's a long running project, a large group of [00:24:00] people, and we had a large team had never worked together before. So we'd recruited them all at the start of the project. And over a year or two in the project, I reckon I probably hired 30 people in total. I must've interviewed a hundred and most of them were brilliant.

And in fact, some of them, I enjoyed working with so much, we've gone and formed a new business together. And the other is we meet up at reunions every three months. So yeah, we ended up with a really tight team. But there were a few people who just didn't fit our culture or people who just moved interstate or had another opportunity somewhere else. And we had to make some changes. 

And like I said, we had that balancing act of, are we doing the analysis fast enough to feed the developers. Are the developers working at the right pace for the testers. Do we need more testing resources to test everything that the developers are producing? 

So it was like three little levers of analysis, development and testing. And I was always tweaking those levers. And yeah, that was a lot of fun. So just typical resource management for a project of that size. 

Yeah, yeah. yeah.

A couple of other challenges.

And you might've seen this as well, Dani, in complex projects. We were building a lot of integrations with existing systems and with the new Apttus system. And that led to a lot of dependencies where we're waiting on an API that was going to give us access to create an insurance policy in Guidewire, which is the insurance platform.

Is that API ready yet? No. The developers are still making some adjustments to it, or, you know, they're developing an API in an integration layer and it wasn't ready. So we had to mock our API requests. And later we had to unmock those once the API was ready and it would turn out that the contract or the specification that we were given didn't quite match the reality. So we had to make some changes. 

And so we're constantly running slightly ahead of the integration team. And who were put under oath, like they had just a thousand interfaces to develop and they weren't always coordinating their work well with us, we were always demanding, this has gotta be ready, this has gotta be ready, but so were the other teams. 

We didn't always get what we wanted when we wanted. That [00:26:00] led to a little bit of rework and just a lot of delays on our side. We had to defer stories and put those back in the backlog until the interfaces were ready. Working through all of those dependencies was a really tough challenge and we try and do that work as early as possible.

 Given the chance to do it again, I would have focused more energy in identifying those dependencies, mapping them out and coordinating our work together better. And we started to do that towards the end of the project, but we could have done that better from the outset. 

And then some changing requirements as well. I don't mind people changing the requirements or modifying the order in the backlog, but it's when requirements change after you've built the feature that it's very disheartening.

It's not impossible to redevelop the feature. It's not even unusual to hear that request. But it's just expensive. And like I said, it's disheartening. You think you're done with that feature and now it's come back again. The business have changed their mind and what they had agreed on earlier. Somebody else's has made a different decision and we're going to have to rework it.

I have to say, working with the Apttus team was lightly challenging. They're off shore. They're using some kind of hybrid agile methodology. One of the big downsides is their estimation scale was completely different to ours. So we're estimating a story points. They're estimating in hours and the integration team is not really doing any estimates at all. So when the business owners say, how long will this feature take? And, you know, Apttus has got to do some work, the Dynamics team has got to do some work, and the integration teams got to do some work. It's really hard to give them a straight answer. You got three different units of measure. That drove the business owners nuts. 

Apttus had a strategic relationship with Microsoft that broke down during this project and they abandoned their Azure hosted CPQ product. And they're forcing their customers to switch to Force.com, which is where the legacy technology, where they came from. And they were acquired by a private equity firm. Then they got acquired by Conga. There was some good people there. I enjoyed working with them, but I probably wouldn't jump at the chance to work with that product, if I had an opportunity [00:28:00] in the future. 

Just before you continue on some of your challenges, I wanted to ask you on the previous one about changing requirements, right? I mean, W what? Cause I feel I phased up very often as well, especially on those bigger ones where, you know, you have very challenging timelines and, and kind of this change is kind of distracting as well, the team and, and, and in some, in some case frustrating that the men and the moral goes down because you're getting pushed to deliver on time.

But then, so the need, the requirements change. And sometimes, unfortunately, It's not only the building time, but it's the analysis time, the discussions, the building, the testing, the deployment, everything, even if it's a small thing, everything adds up. And then when there is a change, of course yeah, as, as we said, right, it's, it's, it's quite quite frustrating.

From your point of view, is there any way you could have done things differently or now looking back at what happened? What have you, what would you have done differently?

Yeah. It's a good question. In a perfect world, we'd have a single, senior, accountable product owner who was able to make all the decisions and who wouldn't second guess themselves, or have their mind changed by a senior executive. And so we wouldn't face a lot of changing requirements. The reality of this project and many others is that we don't live in a perfect world and that's not the situation.

So we did some things to mitigate the chances of changing requirements. We had alot of socialization sessions to walk through the requirements, walk through the backlog, get things approved by lots of people. That's a bit bureaucratic, but we have this decision to register those requirements, being verbalized by the product owners to their stakeholders. So trying to get as many people aware of the decisions that we've made and the requirements that are coming up, that we're going to start building. We had the definition of ready. So we're, we're sure that those requirements are good and they've been approved. 

we're building it and we're, you know, we're taking just a [00:30:00] sprint to build it. We tried to do some feature previews. There's a lot of things have to happen to build a feature. Once we've got some kind of user interface ready, maybe there's just a form design or a view is ready. We show that to the product owner and maybe some of the subject matter experts. We haven't tested this, we haven't built all the plugins. There's some flows that are going to need to be built, but here's how it looks right now. Is this what you were expecting? And before we do a lot of development work to finish off that feature that can really give us some early feedback. 

Oh, well, you know, there's a misspelling in the label for starters, but also I wasn't imagining it would be a drop down. It needs to be a multi-select list because of X Y said, oh, how did we miss that? Okay. Right. Let's quickly work that in. That helped us to be nimble, even within the constraints of a two week time box and, and respond to feedback. 

Then we have the traditional sprint review. Trying to get a lot of feedback from a lot of diverse stakeholders at the sprint review wasn't great. And I think it was more of lip service. People would come along to the sprint review that nod their head and go, yep, that looks great. We didn't get a lot of detailed feedback until later, and we had subject matter experts and users acceptance testing, maybe a sprint or two after a feature has been built. And then we'd start to get the feedback.

Yup.

Which was minor most of the time. And that would get triaged by the product owners. And sometimes those feedback items would get converted into product backlog items or rolled up into something for later. 

Those are the kinds of the practices that we used it to deal with changing requirements. Have you had to use something similar? 

Yeah.

Yeah. I'm very keen on using prototypes. We usually always have kind of a sandbox environment of Dynamics or the Power Platform and just play around with that sandbox and just, you know, show it's, it's more a show and a smoke and mirrors kind of demo just to, as you said, stimulate their thinking process.

Have I missed something? Does that make sense? Because as you said, it's easier and more effective to catch those exceptions early on. Then once it's [00:32:00] built. And as you said, right, sometimes you know showing it and explaining the whole process using something visual to your product owners will make more sense to them then talking about a specific feature. If they see the end to end process, if we see your journey from A to Z, they can empathize better with the end user or the end client that would be using the system. And we have seen that often doing that suddenly sparked some ideas to drop some of the requirements or clarify some of the missing pieces that they completely forgot because they were so focused on specifics, right. So I'm very, I'm also very for using prototypes and showcasing and so forth early on. 

I'm just wondering why we didn't make more use of prototypes in this project. And I'm just trying to cast my mind back and around 2018, 2019, I think Microsoft still charged you per instance, or per environment. Now you just pay for storage and that makes it far easier to go, 'I just need a copy of development and I'll do some prototyping in there and I'll throw it away after I'm finished.' We didn't have that luxury or that model available to us back then. And I think it would be a great practice if that had it been available. So yeah, definitely something that I'd encouraged teams today to take a look at is, ' Can I just develop the user interface really quickly in a prototype environment and then throw it away?'

It's not going to become part of my development platform. I'm going to start again once I get some feedback on the prototype. Yep. Good idea. 

Another one I had, and I think it's something you mentioned is, so I was doing the same for another client where I was prototyping a lot with my other of my team members. And then we had showcases, and then we had also social cases after, after two week sprints with the sprint review, but we also had small demos in between.

Yeah, 

And I think we had three or four sprints. It was not a massive project. And then we were going live and I have to say the [00:34:00] users and the product owners were very involved always through the showcases and the demos, but then comes UAT and yeah, and UAT went well. But one of the first feedback from the client at the end was, 'Dani, I wished we would have done UAT after each of the sprints, because going to the application you showing us was great, but us going and having our users go through the application and play with the tool, really add that extra layer of, we feel the application, we use the application'. 

So that was a feedback. I took and whenever possible, and I will encourage my user to really, after a showcase or a demo, go and play with it. And on my current project, for example. I'm very I'm always encouraging my product owners and user to do their demos to higher stakeholders.

Sometimes look, they asked me and they tell me, 'Dani, I really feel more comfortable if you do it because reason X, right.' But I always try to tell them, look, you have seen the demo, this, the recording of what we discussed login and do it because you will gain better, you would feel the tool better, and that you will provide me that a feedback anyway down to track and learning how demo it will also cause you can be kind of then a champion in that feature and then train the other users.

So that was a very valuable feedback I got from another client that I'm trying to put in place now. So 

yeah. 

Yeah, 

We did exactly same on this project. Within this sprint review, it was one of the, a couple of the developers would demonstrate the features that we just built. The product owners or subject matter experts would have already seen those features. A demo to the product owner for acceptance during the sprint was one of our definitions of done.

And then we'd be demonstrating again, largely to just the [00:36:00] product owner and the subject matter experts. Then they, maybe once a month, were doing a Jupiter showcase as a part of their change management to of their users, people would dial in and the product owners were then doing the demo in that case. The developers, a few of us, would sit in the back of the room to listen for feedback. But we're, we're hands off at that stage. The product owners now on the feature, which is great. Yeah, recommend that as well. 

Yeah. Yeah, yeah. Perfect. So I cut you in the middle of you listing your challenges. Did you have any other one you wanted to share with us? 

So I think we talked about the dependencies.

We've talked about resource management, which I think a lot of people empathize with. The changing requirements. The final one was not really a challenge, but it was maybe a little frustration of mine because this was, this program took 10 years to get approved. But at that time it had become very expensive, right?

There's a lot of legacy technology to replace all at once. And the project was sponsored by the CIO. That meant that it was a very technology focused program. And our mission was to retire the legacy technology. There was very little scope to do business process changes or modernizing our customer experience.

And I think both the business and I got a little bit frustrated at some time that we were. We were digitizing the old way of working. And we were told this is the baseline. We've got to do this technology replacement. Later, there's going to be future projects that are going to come along and fix that stuff. That's a decision I had to live with. Somebody else had made that decision. That was the strategy. Just made a little bit frustrating at times that I felt that we were working in a little bit of an old fashioned way and maybe missing a trick. But it kept us on the straight and narrow with a very clear focus. 

Yeah. 

You must have faced that in projects as well. 

Oh, yeah, absolutely. And it's funny you say that, I mean goes the, cause the other extreme is also very dangerous, right? Where, and, and I will tell you what I, what I mean with that, where I had faced project where the product owners or the [00:38:00] user were not sure they were getting enhancements after the project was live.

So...

The mythical 'phase two', right?

So they know they replacing an Excel, kind of a manual process and management have said, look, we replacing your old way of working and we want to have a, like to like with small enhancements and you will get new features down the track.

But the challenge I had on some of my previous project is the product owner and the user never believed that there will be a second phase, because again, it took so long to get approved and they have past history of project, not, you know, not, not evolving. And then the other extreme where happening where my mission was to replace a legacy system with some small tweaks, but then the product owners and the users wanted to add so many new features and so many new automation. And what if you can automate this piece of our work or what if you get automate that, and the challenge then is that what I've seen at least is that all this change is, is too much to absorb almost, Cause it's a new app. 

Yeah. 

And if you introduce to a new app that is already a change, new ways of working on top of that, from start, from the go-live, the product owners were getting lost themselves sometimes in the process because they will not sure about the process to be, or how would that work yet, right? So we had to work very hard to, and work with higher stakeholders of that client to convince the product owners, let replace the old system, put some small enhancements. That's our MVP. And then the future phases will bring more automation. So that was a very big challenge we had. So yeah, that's kind of the other extreme, 

Yeah.

I've only been involved in one or two of those kind of complete business process reengineering projects, where you're not just putting in new applications, but changing business [00:40:00] processes, changing the organization structure, changing the customer journey. And the people come in on day one and it's almost like they've started work for a new company.

Everything's changed. The reporting lines, their roles, their responsibilities, and that's a lot to deal with. You used to see that maybe 10 or 20 years ago, these kind of classic business process reengineering programs, you don't see as much of that anymore. I do wish more customers looked at their business application as a product that needs continual enhancement, not just a project.

I don't know how RACQ is going today with Jupiter and the Connect application. I hope they still have a team that's continually funded and making enhancements all the time based on feedback from the users. And that it didn't just wrap up and they, they cut off all funding for it. I hope they're continually feeding and watering it.

They deserve to. The application deserves that. Their users deserve that today. 

Yeah. Yeah, absolutely. All right, Neil that was a great conversation about the challenges. Do you want to share with us what went well?

Sure. So the was a resounding success, so let's spend a couple of hours talking about what went well. 

I'm very proud of the way that we follow the Scrum framework. We followed every practice in the Scrum Guide. And like I said, we added a few of our own. We invented a few of our own as well. So hats off to the team. We created some new practices that I'm going to take forward into future projects. Later we added the nexus scaling framework. Our second scrum master saw some of the challenges we had with coordinating some of the dependencies, wanted to introduce some concepts from Nexus, which is one of several different kind of agile scaling frameworks. It's based on Scrum. And it just adds a couple of extra kind of events and parts to the framework. That worked really well for us. 

We also had a dedicated DevOps engineer and a relentless focus on automation. So our developers, our DevOps engineer and our testers worked hand in hand to automate everything from development into production, through a rigorous testing cycle.

Again, I've taken that forward to future projects as well. It's getting easier and easier today with [00:42:00] Microsoft Dynamics 365 and the Power Platform and Azure DevOps and GitHub and third-party tools. We didn't just use a Microsoft stack here to achieve that. We've got the DevOps build tools and things that are great, so I would encourage everybody to do that. When you're doing a release to production every couple of weeks, or a couple of times a sprint, you really need everything automated as far as possible. 

Looking back, a decision that worked out well for us, it could have gone either way. We were launching this in the middle of 2018. Right about then the unified interface was just being released and teams were starting to think about how to plan, or defer, switching from the classic UI to the unified interface. And we made a pretty brave decision to go early with the unified interface, because we knew our first major release to production wasn't going to be for 18 months. 

We probably uncovered almost all of the bugs in the unified interface on your behalf and reported those to Microsoft and got them triaged and fixed. And thankfully we didn't have to then do a big transition from the classic UI to the unified interface later. So our users went live on the unified interface and we saved ourselves a lot of time there.

I think we always see this, you know, whenever we're just about to release to production, Microsoft makes a major change. Do you jump on board? Are you one of the early adopters of that new set of features or the new capability? Or are you going to wait until later and do some kind of upgrade? And I think everybody needs to make that decision for themselves, document it, consider it carefully, consult with their Microsoft partner on it. In this case being a bit bold, it paid off well for us. 

 I think that was part of another thing that worked really well was the project culture that we had. Our leadership team instilled a great team culture. Really led by our project director who give us, as technical teams, a lot of latitude to take some calculated risks, to try new things, to celebrate success when it worked and never to blame individuals when it didn't.[00:44:00] I think the leadership team that he built up around him give us a lot of leeway to try those things. And it was an amazing place to work. 

I would say it's quite an old building, Dani, if you know Brisbane well, it's in Fortitude Valley, so it's probably not the most desirable part of the city to work in. But I loved going to work every day because of the team that we had and the culture that we had there. 

Take my hat off to the leadership team who, who give us that culture to work in. 

Such an important thing, right? How the team works and the culture and everything.

You've worked for people who are very command and control and everything has to be their way. And this place wasn't like that. There were clear guidelines, guardrails, and, you know, we would've got steered in the right direction if we went off the path of what was acceptable, but you know, very open and celebratory culture. As contractors that RACQ, we were really lucky. I requested and got approval to send all of our team to the RACQ cultural onboarding, about once a quarter for new permanent staff, they get to meet the senior leadership team, the chair of the board of governors, and they get immersed in the RACQ culture.

I think for the first time they took contractors through that process as well. So we had a real deep understanding of the mission and vision and values of the organization, and that helped us empathize with our members and with their users. And yeah, it was wonderful. I'm very grateful to the RACQ leadership team for sending us along on that. 

 And we also were allowed to do something quite novel, O-week, which is orientation week.

If you're a fresher or year one at university, there's a week of celebrations and social events. So we had that at RACQ when we onboarded the Dynamics developers. I started them all on the same day. And we held this orientation week to get everybody up to speed on the context of the project, what our goals were, and some of the high level of business processes. Some good technical workshops and some nice social events in the evening as well, not just with the Dynamics team, but with the wider kind of project team. A lot of people all starting at around the same time. And that was great. If you can [00:46:00] schedule that and get some approval, cause there's some hard cost involved in that, but it worked really well. Everybody felt really up to speed very quickly and we got to know each other really quickly as well. So it helped with the team bonding. 

Oh, it seems like a great idea. Yeah, absolutely. And yeah, you feel welcome as well, I guess, as as a contractor or even as an external partner, right. You really feel welcome. Yeah. Definitely.

And then we had a good engagement with Microsoft and we're very fortunate to have a good architect from the Microsoft FastTrack team. Later on, we had our application reviewed by Microsoft Consulting Services, who went through our design, all of our code, all the components. We had been doing, what's it called, solution checker at least once a sprint. We knew we were on the right lines and they never give you a formal tick or approval or a score, but they mentioned that we had built an application that was at a standard that most established partners don't build to. So really pleased with that feedback. The only criticism we got from Microsoft, as you might expect is, 'Hey, why didn't you use managed solutions in production?' We never did use managed solutions in production at RACQ. I have subsequently, but I didn't at that time.

But we had a pretty close relationship with our Microsoft account team, with the customer success team, FastTrack and Consulting Services. I'd encourage everybody doing an enterprise deployment to keep Microsoft close and can only lead to your success.

Yeah, Amazing.

So, yeah, that was, that was my recollection, Dani. I have to say to anybody listening to this podcast, I hope some of the Jupiter team will get a chance to hear it. These are my personal recollections. They're just my personal opinions about what happened on a project that started at two or three years ago. I have very, very fond memories of the project and everybody we worked with on the team. So, thanks to everybody who I got a chance to work with there. 

Thank you, Neil. Yeah, it sounds like a very successful, also very enjoyable project that you worked on. And the size of the project and, you know, the length [00:48:00] of it definitely brings some challenges that you guys overcome. So, well done.

Well, I would echo the sentiment, the feedback that I got from my team, which was professionally speaking, this is one of the highlights of my career. I haven't worked on many projects as much fun as this one and, and rewarding as this one. Yeah, it was a lot of fun. I'm looking forward to working with a lot of that same team on future projects, Dani we're we're coming up to the end of another project. Hopefully we can have a podcast about that one, at a future date. It's just ended its development phase and we're going into release right now. I'm working together with a lot of the same team and we're coming available, Dani. So if you know anybody in Brisbane or the Queensland area who is looking for a project team to drop in and build more amazing applications, we'd love to have a chat with them. 

Perfect. Thank you. Thank you for your time again, Neil, and yeah, to the next one, I guess

My pleasure, Dani.

 Thanks so much for listening to the Amazing Apps podcast. 

Amazing Applications is a Customery production. 

You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and then notification when there's a new episode available. There are also shortcuts so you can follow the show on all major podcast players, leave a review, and you can send me a message or leave a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.

Visit https://AmazingApps.Show. 

You can also follow the Amazing Apps show on Twitter and LinkedIn, and subscribe to my YouTube channel at Youtube.com/CustomeryAcademy. 

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