How Can We Adopt Scrum for Dynamics 365 Business Central?

How can you deliver Dynamics 365 business centre projects in a fully agile methodology when there are so many dependencies between the various modules?

Hi and welcome to the Amazing Apps show for Microsoft business applications makers who want to create amazing applications that everyone will love.

Hi, I'm your host, Neil Benson. My goal in this show is to help you slash your budget budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power Platform applications.

The question in this episode [00:01:00] comes from Anand Kushalanagar. He's a project manager at Nexon Asia Pacific in Sydney. Alexa, please read out Anand's question.

"At the moment, we are using a hybrid implementation approach for our projects. How can you deliver Dynamics 365 business central projects in a fully agile methodology when there are so many dependencies between the various modules?"

Thanks for your question, Anand. And by the way, congratulations on completing my Scrum for Microsoft Business Applications course and achieving your Professional Scrum Master certification. Whoo!

OK, back to your question about Scrum and ERP. So first of all, when it comes to adoption, I used to think that teams should adopt all of Scrum in one go. Immediately cut over from whatever you were doing before and use Scrum. I thought it was a really bad idea to gradually transition from a waterfall approach to using Scrum, but working [00:02:00] with other scrum masters and trainers and more recently with some of my own new teams, I've learnt that it is probably better for most teams to introduce Scrum practices over time.

Use the retrospective every sprint to find out where the pain points are and reflect on which component of the Scrum framework will work best and introduce that into your next sprint.

ERP practitioners are slowly learning how to embrace Scrum even when there are interdependent modules, and we can't always release small increments into production.

We can sequence our product backlog items to prioritise those items where there are dependencies between those and other items in your backlog. That's a great conversation for a development team to have with their product owner. 

Backlog management tools, like Azure DevOps, allow you to track all the interdependencies between your items. So it's not only business value that the product owner should take [00:03:00] into account when she is prioritising your backlog items, but it's also the dependencies between backlog items.

On a recent project, my Dynamics 365 delivery team were often waiting on integration services being developed by another team. Dozens of our user stories were dependent on APIs being developed by the integration team. We found it helpful to mock the API with a hard-coded response to prove that we could consume an API. And then we'd write another story to unlock that integration when the API became available.

Similarly, the data migration team was dependent upon us completing our user stories that impacted the Common Data Service data model. There would be requirements to migrate some customer data from one of the legacy systems into Dynamics 365. The data migration team was relying on us to design and build the entities and attributes to hold that data. So [00:04:00] they would develop their migration scripts incrementally as well. The first increment of their script would cover all of the system entities and fields and additional increments, later, would add more custom entities and fields as they were constructed.

Occasionally, there would be a significant change in our data model and this would be a breaking change for the data migration team. We try and consult with them ahead of making those kinds of changes. But we also updated our entity-relationship diagram and our data dictionary at the end of every sprint, and they were using frequent automated tests to test the integrity of their scripts against the various bills of the data model.

So automation is the key there and frequent communication.

A couple of times each week we had joint meetings with the other teams, including enterprise architecture, integration, data migration and anyone else who needed to know so we could have those conversations about the inter-team dependencies.

"I'm [00:05:00] blocked by this."

"We're going to work on that next sprint. That's OK."

"Well, I'm going to have to unmock my API.

"Great, that one is going to be delivered in the following sprint."

Those kinds of conversations.

It's a great forum to raise either proposed changes you're going to make or to discuss breaking changes somebody has already made.

Your Dynamics 365 Business Central projects might not have multiple scrum teams delivering different modules, you might just have, you know, a few consultants each working on different parts of the system. But I think the principles are the same.

Develop your features incrementally, build a little at a time and review them together as a team to check for impacts. Check-in with each other as often as required. If you're all working in one scrum team, then the daily scrum is the perfect opportunity to catch up and revise each other's plans otherwise of a nexus or scrum of scrums workshop to coordinate across different scrum teams.

The second principle I'd use is: document frequently using automated processes for [00:06:00] updating your data model documentation and the same goes for testing. Find ways of automating the functional testing and the integration testing so that you can run regression tests at least once a sprint, ideally several times a day.

Anand, I hope that answers your question and helps you adopt Scrum for your future ERP projects. Thanks for sending in your question.

Remember, you can add your question to the Agile Applications Q&A backlog by visiting the Customery.com website and clicking on the 'Send Voicemail' button, record a short message with your name, where you work and where you live, And, of course, your question. And we'll try and get you featured on a future episode.

Lastly, the show notes for this episode are available on Customery.com/011. Customery is the word customer with a Y on the end.

That's [00:07:00] it for now. Thanks for joining us. Until next time, keep sprinting.