Navigating the role of an architect in a Dynamics 365 Scrum team with Allan de Castro

Allan De Castro [00:00:00]:

The goal is to allow you to test your product whenever it's possible. That's the value for you. And so based on that, you will be able to maybe perform some back and forth before the end of the sprint because you will be able to test continuously during the sprint and not just after the sprint when the next one will begin.

Neil Benson [00:00:24]:

Today. Welcome to Amazing Applications from Customery. I'm Neil Benson. Thanks for joining me. Amazing Apps is here to help Microsoft customers and partners build amazing Dynamics 365 and Power Platform applications, especially if your team is using an agile approach. Congratulations to a couple of recent Customery Academy students who've achieved their Scrum certification. Well done to Riley Sanders at IBM, Danielle Craig and Stephen Leonard at Incremental Group. We're fast approaching 200 certified Scrum professionals from Customery Academy. If you want to find out more about adopting Scrum, getting certified, and applying it to your Dynamics 365 or Power Platform projects, visit Customery.com/Scrum. That's customer with a y on the end.com Scrum. Today I'm joined by Alan de Castro. Alan has been building Dynamics 365 Apps for the past seven or eight years and is today a senior technical consultant for the Power Platform at Avenad in France. You might know him from the French Biz Apps Community or the wonderfully detailed blog articles he publishes at AllanDeCastro.com. Check out that link in the show notes. Allan shares with us what his team at Avanade has learned while applying Scrum to one of their recent projects. This is episode 141. You'll find the summary, resources, and a transcript at AmazingApps.Show/141. Here's Allan.

Neil Benson [00:01:52]:

Allan, welcome to the Amazing Applications Podcast. It's great to have you on the show. Welcome from France. Well, it's nighttime here in Brisbane, Australia. You're joining us from Paris, is that right?

Allan De Castro [00:02:04]:

Exactly. Exactly, yeah.

Neil Benson [00:02:07]:

Well, a very special welcome to you. Bienvenue. Welcome to the show.

Allan De Castro [00:02:10]:

Thanks a lot.

Neil Benson [00:02:11]:

I wonder if you could just start with a quick introduction, let us know who you are, where you're from, where you work, and what type of business applications stuff you love doing.

Allan De Castro [00:02:19]:

Yeah, sure. So my name is Allan De Castro and I'm working at Avanade France, especially in the Dynamic 365 world since like seven years, I would say, with some Azure stuff, too. And so basically, I'm working — as especially on Dynamics 365 project. I would say not a lot of Power Platform but, I mean, it's the same as you know. So I work on some huge projects, especially on sales model, customer services, etc. Today, I'm acting as a solution architect in each project where we decided to use the Scrum framework. So it was quite news for us but also for me, basically. So it was quite interesting, I would say.

Neil Benson [00:03:04]:

Yeah. Oh, great. Well, we'll get into that. Interested to find out that you work in big enterprise Dynamics 365 sales and service projects. I have a similar background doing D ynamics deployments in contact centers with hundreds or thousands of users. It sounds like your current situation is very similar.

Allan De Castro [00:03:21]:

Yeah, exactly. But at Avanade, we are like — I don't know how much we are right now, but it's a huge team in France. So, I mean, all the big project, I mean, come to us, I would say. So we are often working on huge project of this kind with a lot of user, with worldwide deployment, etc. etc.

Neil Benson [00:03:42]:

How long have you been working with Avanade? Is it all seven years that you've been in Business Applications you've been at Avanade?

Allan De Castro [00:03:46]:

No, no, no. It's — I'm working at Avanade since five years right now.

Neil Benson [00:03:51]:

Okay, great.

Allan De Castro [00:03:52]:

Yeah.

Neil Benson [00:03:52]:

And how did you get started with Business Applications?

Allan De Castro [00:03:55]:

Oh, it's I would say a long story because when I was a student, I started to work and basically to follow some course in IT. But then, I wanted to maybe switch to something quite parallel, maybe some management in the IT world, etc. And so then I followed my master's degree in this kind of courses, this management in the IT world. And then, I started like internships, I would say, in the CRM world. And so I started like this. And then, I decided that it was quite interesting because it's not just about technical stuff, but also about business because we're implementing some applications that will be used by a real user so we must definitely understand what we are going to do and what we are going to achieve to basically provide some added value.

Neil Benson [00:04:45]:

Yeah, I completely agree. It's bringing together that business domain expertise, knowledge of processes, and cultures, and politics, and how organizations work, as well as how the technology can be adapted to support them as well. So good combination.

Allan De Castro [00:04:59]:

Yeah, exactly. It's not about technical.

Neil Benson [00:05:02]:

You said you're a solution architect today. How did you progress into that position?

Allan De Castro [00:05:06]:

Basically, so I started to work on several projects before as, I would say, basic developers, learning all the basic stuff regarding the platform, the traverse path, the event framework, this kind of thing, etc. And then started to work on building interfaces, etc. And so then, I started maybe four years ago to work with Azure component, meaning some service boost, Azure function, etc. So in this kind of stuff, we are always wondering about the architecture part, meaning the ecosystem around Dynamics and not just what we are going to achieve inside the Dynamics. And so just so as a project, my main goal today is to act as an architect.

Neil Benson [00:05:51]:

Tell me about adopting Scrum on a business applications project. I'm really interested. You say you love doing system or solution architecture work. In Scrum, for example, we don't have a job title called a solution architect. Everybody who builds the application is called a developer. It's a slightly awkward word because we use developer in a very specific way, whether you're low code or pro code. We think of developers separate from testers, separate from analysts, separate from architects. So how does your role play in a Scrum team?

Allan De Castro [00:06:23]:

It's basically a good question because if we look into the Scrum guide, architect talks about the product owners, the development team, the Scrum master, and the stakeholders, I would say. And so an architect acts finally as a stakeholder, as some employees, as the organization, etc. as this kind of stuff. So yup, it was a challenge, basically, because we must find the good place. And on my project, I was the architect but also the technical lead, I will say, inside the dev team, okay? And as I said, it was the first time for us and to deliver a project like this using the Scrum framework. So at first, it was like quite maybe ambiguous, finding our place in the whole team. And so for the architecture part it's quite ambiguous because we must find normally everything, I would say. There is some design phases quite before the first print, I would say. But yeah, the technical requirement part is complicated to address because we are focused mainly on the added value, on the business requirement, etc. So when we talk about architecture, meaning, okay, maybe we'll attack with this system or maybe it's not a good approach. Maybe we must build something new next to Dynamics. So it's some discussion that sometime not in the Agile Stream, I would say, because on my side, I did have, you know, the Agile Stream using the framework and then some V-cycle brings integration parts. So I was part of, I would say, two teams. And so on the Agile Stream I was, I would say, the technical lead. But in the V-cycle, the solution architect. So my aim was to ensure too when we talk about interface in the Agile Stream that it will normally in the roadmap on the V-cycle and to ensure that it will work correctly, I mean, as expected based on the business segment of the Agile Stream, based on the user story, and ensure that technically, it will not be too complicated to be done, and if it's the case, to ensure that we not have some technical depth or anything, etc.

Neil Benson [00:08:31]:

So are you doing a lot of sequencing and making sure dependencies are handled so that the Agile workstream isn't held up by the integration work that needs to be done?

Allan De Castro [00:08:40]:

Yup, exactly. That was a complex part time because it's always — there is this sentence saying that in complex environments, what will happen is fully unknown, I would say. So basically, it means that normally we do not define the architecture, I would say, during or along the sprints. And we do not have any Sprint Zero, I would say, to prepare some stuff because as we are working in Agile, we must follow the definition of Done, for example. And for us, it means that we must for sure build it, build the PBI, but then deploy it to some target environments to ensure that it's tested along this point. So this kind of step because we are talking about technical requirements to set up all the environments, all the ALM process, to deliver each increment, each artifact. And so yeah, it was a little bit complex because when we work with some project owners, etc. they are mainly focused on the business value. But to achieve this, you have some step before, I would say.

Neil Benson [00:09:45]:

Yeah, the way I handle that in most of my teams is we take a Chore, which is an unestimated product backlog item that the developers want to do, like build a new pipeline or automate a step in our existing pipeline and it's not a user story because the users didn't request it. T he stakeholders don't care about it very much. But as developers, we want to do it because we think it'll improve our velocity and improve the quality of the products that we can build later. It sounds like you're taking a similar approach.

Allan De Castro [00:10:15]:

Yup, exactly, because I would say that at least your team want to build a working project. And so sometime, saying that, okay, we'll maybe have some effort on this sprint regarding the deployment process. So it means that at the end, I mean, what is the sprint goals if we are only talking about architecture, meaning that we'll maybe not deliver some real value, some new process, etc. but we will ensure that we'll be able to deliver maybe every days in your UAT environment. That's the value, I would say. But not — I mean, from a business value point of view, it's complicated to negotiate, but it's something that we have to discuss basically with the project owner saying that, okay, we can maybe, I would say, try to implement this kind of thing right now, so like that it will be done. And then, I would say, the goal is to allow you to test your product whenever it's possible. That's the value for you. And so based on that, you will be able to maybe perform some back and forth before the end of the sprint because you will be able to test continuously during the sprint and not just after the sprint when the next one will begin.

Neil Benson [00:11:28]:

Yes. Yeah, I love trying to keep that testing inside the sprint where we can. I'm going through some challenges in some of my projects to try and do that, make sure there's business people available to conduct the testing, verify the increments. But it's not always easy, for sure.

Allan De Castro [00:11:44]:

Yup.

Neil Benson [00:11:45]:

I'm thinking back to when this project started, Allan. Was it Avanade's usual approach to adopt the Scrum framework for a project like this or was this quite a new project for the use of Scrum?

Allan De Castro [00:11:56]:

Basically, it depends, I would say, because for this project — so it was a project from scratch replacing two different tools. And so the build phase's MVP was using the Scrum framework. And so usually, we always do, I would say, a basic V-cycle. So like that we have all the functional team that can perform some workshop to get all the business equipment, etc. On our side from the technical part, we can ensure to define all the pattern of the integration pattern of the different systems, the capabilities, doing some integration, etc. And so normally, we do in a V-cycle and then we iterate in the Agile mode, I will say. So that was the first time to start a project from scratch like this. So it was quite valuable, I mean, at least for the business application part. We have some other project, more traditional, I will say, using full custom dev that sometimes are fully implemented like this. But it depends also you know about your customer, if your customer is quite familiar with Agile because Agile is a big world, I would say, because everyone wants to do it but I will show that you can do it. Are you familiar with it? Do you have the mindset for this?

Neil Benson [00:13:08]:

Right. And everybody has a different definition of what Agile means as well.

Allan De Castro [00:13:12]:

Yup, exactly. And we often think about flexibility, etc. But we think also, I would, say out of the box, meaning that if you have — we know that in this kind of framework, the project owner is, I would say, responsible about the backlog, etc. to create all the PBI. And so sometimes, when we are not going to do some workshop, I would say, some functional workshop to ensure that everything is clear, etc. But it's something that can absolutely be done by just, I would say, creating a PBI. Okay, we'll create this one. And so the aim is to perform workshop regarding this topic, this functional case, to ensure that we have everything in mind. So like that we can write all the user story for the next print, meaning allowing the product owner to write correctly all the user story for the next print. And so the next print, the development team can just, I would say, implement technically all the process. And so like that, we are sure that at least in two sprints it will work. But if we wait too much, I would say, it can be really complicated.

Neil Benson [00:14:20]:

Yeah, it sounds like a customer is providing the product owner accountability in this project. Avanade's providing the developers and the Scrum master, is that right?

Allan De Castro [00:14:30]:

Yes, exactly. That was exactly the initial team. So that's why normally, we just manage to build the PBI with the user stories. But sometimes, it's quite convenient to help the customer because, I mean, the main goals for us, meaning that we did a lot of project with different customer, so we have another way of thinking. We can have some, I would say, similar stuff for another project so we can add them also to sync differently because the added value is not just to, I would say, to implement the current process. It's maybe to challenge this. Maybe it's okay. It's a way of working right now. But maybe there is another way, and that's where we must match this with some, I would say, Dynamics 365 functionality because sometimes you have some quick win also. So it's sometimes that kind of stuff that can be set up and so like that we have some added value out of the box without any developments and it's quite great.

Neil Benson [00:15:30]:

Do you end up writing user stories for — does your product owner write user stories for what is actually standard functionality? Because it's a little bit of a waste of time and I quite often find that we provide a business analyst to work with the product owner who knows Dynamics quite a bit, so that they can avoid writing a lot of — spend a lot of time writing user stories for basic functionality that comes out of the box. Do your developers have a business analyst in the team or is the product owner doing all the business analysis work?

Allan De Castro [00:15:59]:

Basically, the development team is composed by, I would say some technical person, I would say some traditional developers and some functional person. Yep. But it's the development team. So it means that together we are at the sprint planning, I mean, at the s print refinements, etc. etc. altogether. So in this kind of scenario, the project do have, I would say, a proxy project owner. I know that it's normally not usual roles in the Scrum framework.

Neil Benson [00:16:33]:

Yeah, I've been there, too.

Allan De Castro [00:16:36]:

Yep. It's sometimes something that we call business analyst, I would say. But yep, someone is present to help the product owner. But it depends meaning about your knowledge in a general way of how we are building application because there are some basic questions that a business analyst can ask. Meaning that when you talk about a new object, I will say, there are some basic stuff to ask. For example, what is the lifecycle of this object? Okay, we are talking about, okay, for example, okay, but the first stage is what is in progress or waiting to be handled by someone. Then, okay. So we have the flow to define some type, etc. It's some basic stuff because if we are building any other application, it's the same way of thinking, I would say. And then, we have the added value of Dynamics. We're getting some out of the box feature. Meaning that no, we will not develop a bulk edit mode because you can just select some records and click on edit and it's already implemented. If you do not have, I would say, the knowledge about Dynamics, you will not be able to, I would say, to put this kind of functionality in front of the product owner. So maybe they would write a user story saying, okay, we want to perform some bulk update, okay, basically for us, it's out of the box and sometimes it will be better to say that, okay, that's all the functionality of the project. Let's perform demo. You can see that you can do it. Maybe it's something that can be shown during the demo, I would say, and not maybe quite a dedicated user story for that because it's fully out of the box or at least you can watch it by saying that it will be the standard of Dynamics. That's all. There is no development on this. So it's based on the standard feature. So like that you do not have maybe some test based on that. Oh, no, we expect this. Yeah, but it's not implemented natively. So if you want to do it, we must, you know.

Neil Benson [00:18:30]:

It's going to be a customization or something.

Allan De Castro [00:18:33]:

Yeah, exactly.

Neil Benson [00:18:35]:

I was meeting with a pretty senior director at Microsoft recently who said that Agile approaches don't work with business applications. It's great for custom development, where, you know, you're writing everything in custom code. That's where the Scrum framework was based. That's where most Agile approaches are based on custom development work, not composing or configuring business applications. And yet here you and I are with, you know, lots of Scrum experience under our belts building business applications. What do you say to somebody who says, you know, Scrum's not the right approach for a business applications project?

Allan De Castro [00:19:10]:

I think it depends about a lot of things because some things that can work on a project can't work on another one. So we must ensure some — I talk about mistake at first time when we get in touch and there is some stuff to ensure to start properly. Dynamic 365 project using Scrum framework I think some are quite basic for all the project, meaning reading the backlog, for example. As an architect, for example, all technical requirements must be in the backlog. It's quite better for us, I would say. And to ensure that we have all the dependencies. When you talk about some integration, you must have all the dependencies. So like that you can plan everything in one map. Even if it's in the Scrum framework, you must have a run map, you know, because you will have maybe, I don't know, ten sprints. But maybe the sprint goal of the first one will be A but it will be the same for three different sprints because we have some dependency, etc. So we are building stuff to allowing us to build everything on the fifth sprint, for example. That's the first thing to ensure that the backlog is quite — it must not be ambiguous, I would say. And so I think that it's quite important the customer has some knowledge about Dynamics. So I think that the best way to start it is maybe to train the customer regarding the solution because we are not starting from a custom development. So the aim is to leverage the Dynamics 365 capabilities, the Power Platform capabilities and it's quite important. If we talk about, for example, the security model, I mean, we can implement some custom dev, etc. But the aim is to fit into the security models that will normally answer to 90% of your requirements. So if we explain this how it works, it's quite easier when we talk about security in those points. So there's some knowledge to be achieved by the customer, I think, and by the business analyst, if he doesn't know well Dynamics. And I think that's the first thing because we often talk about the Sprint Zero but I think that it's something that can be done before as the architecture part. I think so like that we must focus as a sprint only on the priorization, I would say, and that's all. Meaning that we know where we are going and we just split into different sprints and we'll just manage when we want it to be released. But that's all. But everything is, I would say, clear. I mean, 80 90% for sure. There is some unknown thing every time or new business requirements, etc. and so we must refine it. Maybe plan a workshop, etc. But I think there's two points. First, the backlog. We must definitely ensure that the technical requirements are included; that it is fully estimated; and that the customer or the person who are working with the product owner are aware of Dynamics because in custom dev it's work because we can do what we want.

Neil Benson [00:22:21]:

Yeah, it can do anything. You've made a great point, a great example there of the security model. If your requirements fit within the security model, you can meet everything with configuration. It's quite fast and rapid to meet those requirements, deploy those security roles and business units and everything into production. But if your product owner doesn't understand that the dataverse security options that are available, they may well come up with requirements that are crazy and very difficult to implement, require a lot of custom code. And so there's some negotiation there, which is easier if your customer understands what's available out of the box, for sure. I'd have to say, a lot of my projects, we don't know the product backlog up front, and a lot of it emerges during the course of the project. We try and define it at a very high level, so we break it up into epics and we know roughly what the relative size of those epics are because if we don't know that, we can't give you any kind of estimate, and most customers need an estimate before they approve a project. So I agree with you to some extent that it's good to know roughly what you're going to do with some kind of roadmap or a blueprint before you start Sprint One. I don't like calling it Sprint Zero because it's not really a sprint and it might take longer than one sprint. It might take a couple of days or it might take a couple of weeks to do that kind of discovery roadmapping. People like to call it different things, you know, initiation. Lots of different words for that stuff you do before the project really starts. Coming towards the end of your projects, how do you handle testing with the users? Are they doing testing during the course of your Sprint or you're reserving the effort for a UAT phase? What happens in your projects?

Allan De Castro [00:24:06]:

Basically both. Meaning that we have a quality insurance, I would say, person testing along the project, along the sprint by basically delivering into a target environment, UAT environments. So like that normally at least every day we are delivering the solution except if we have no PBI ready for it. But basically, we are trying to deliver at least every day every two days in this target environment. So like that they can test it continuously and so it's done by a dedicated person. And then, it's — we have a dual check, I would say. First, the quality insurance person is testing based on the user stories, based on the test case because we are also writing some test case by the development team, I mean, the unit test case and then the customer. So this person is testing also on his side. And after that, we have the project owner or the business analyst that will put this one as done. So we have the tested state, I would say, and then the done state. So we have this double check. That is along the project, along the sprint. And then, we do have a UAT phase because it was an MVP, I would say. So it will be quite different now because we are in phases. But at first, yep, we had UAT phases to coverage all the scope by some end user in this case. We wanted to bring them basically to test everything. We had UAT phases with a lot of functional scenario to be tested by end user, some key user, I would say. But now as we are in a run, we're just testing continuously but without UAT phases.

Neil Benson [00:25:59]:

So the application is live in production right now so.

Allan De Castro [00:26:02]:

Exactly.

Neil Benson [00:26:03]:

You're just in continuous testing. Yeah. Very good. Tell me about some of the challenges you've had either with this particular project or because of S crum. What kind of issues did you have to overcome?

Allan De Castro [00:26:13]:

Basically, if you talk about the architecture point of view, it was something that sometimes quite complicated because I worked with an ecosystem quite moving, I would say, because all the master data source was not really, I would say, clear for everyone. Some system were currently under construction so it was a little bit complicated. And that the problem, that the architecture should not emerge every sprint, I would say. Normally, you must figure it out quite before. So we had some change meant on the fly, so we definitely adapted some stuff on our side. So it was a little bit complicated. But like the first point we discussed before, meaning that the architecture must be quite clear at first if you want to use it as this framework and the values that you can provide. And then, we have had encountered some other problem regarding basically the functional parts, I would say, the requirements that were not very clear, I would say, for the customer. And that was also the part we discussed before that. I mean, in Agile mode, it can be really fast, but you must ensure that everything is defined before. And it's also maybe some cultural stuff because, for example, I think it's my own opinion, but in France, we definitely want to build. We want to develop. We want to build some plugin. We want to build some JavaScript, some projects, etc. But I think that if you go maybe in Asia, I know that there are some quite more long analysis phases because they must ensure where they are going. And so sometime we must make care about that. Okay, let's take a step back, analyze everything, design maybe a little bit, not everything, but at least where we think that there is a risk or at least identify this kind of risk. So like that we know that, okay, maybe in two weeks we are going to work a little bit because we have some huge dark, I would say, requirements. So we must, I think, keep in mind that we'll maybe have to perform some workshop. Maybe the velocity will not be great because we'll maybe do some back and forth every time. And we encounter this kind of problem on this project, especially regarding, I would say, traditional problem but quite complicated for this customer regarding how to manage the sales territory. It's always quite interesting, but it was the main concern of this project.

Neil Benson [00:28:44]:

How did things go with your customer? Were they able to keep up? Were they happy with the Scrum framework? Are they going to continue using Scrum for other projects in the future, do you think?

Allan De Castro [00:28:53]:

Basically, this customer is already implementing a lot of project internally using Scrum framework.

Neil Benson [00:29:00]:

Okay. S o quite a mature customer when it comes to Agile.

Allan De Castro [00:29:04]:

Yep. Maybe not in the best way, I would say, but at least they are trying to do some iteration, etc. on their way, I would say. But with this project, the first time that they do a project with some external contractor, I would say. So with maybe a more consistency about the application of the framework, I would say, more discipline. So it was more rigorous. So I think that is also learned a lot of stuff and some comparison was made, you know, between some project owner saying that oh, you are doing this. Okay. Oh, no. We are not doing this on our side. It's quite strange because it's all the framework works. I mean, oh, we are superior to it. So it was not so bad on this point. And yep, the aim is to continue like this and they will continue like this for sure.

Neil Benson [00:29:53]:

That's great that they have a community of product owners who are sharing practices and lessons that they've learned from their projects amongst each other. So that's really encouraging. What's the feeling like amongst the Avanade developers? Are they enjoying using the Scrum framework? Do they care much whether it's a traditional approach or an agile approach? What do you think the feedback is like from your colleagues and your team?

Allan De Castro [00:30:16]:

It's a good question. I think it depends also about the person, meaning the personality. I think that some of them definitely loved it because it's quite moving, I would say. So it can also be more fun, I would say. And I think that some other prefer to have something quite stable, ensure that everything is clear on the table, etc. So where you are going, what you are going to achieve, etc. etc. So I think it depends, but I think that's the way — I mean, the goal is to try to do some other project like this, I would say, and by learning what we did on this project and so like that, we can be better for the next one for sure.

Neil Benson [00:31:03]:

Yeah, great. What are the top one or two things two lessons that you'll take on to your next project that you hope never to repeat again? Any mistakes that you're going to try and avoid next time?

Allan De Castro [00:31:14]:

First thing, I think, backlog management, ensuring that everything is, I would say, clear, estimated, and that the technical requirements are included. Then, to ensure that the customer and the business analyst, I think, are aware about Dynamics, what is the main goal, why we decide to choose Dynamics to avoid all the functionalities. And then, that about the Sprint Zero we talked about. To ensure that to define this kind of process before, I would say, and to keep in mind that the architect must have like an advisory role and as a stakeholder of the Scrum team and that's all. Do not try to influence because I did it basically in my project to influence the sprints to ensure that, okay, I know how it's going in the integration part. Okay, let's do it this sprint instead of the next one because I know that we can do it right now. But this one, this PBI, we can do it right now because I know it. So let's do it. Maybe next s print, it will be easier for us.

Neil Benson [00:32:22]:

One final question for you, Allan. What kind of tools did your team find useful? What were you using to manage your backlog? And were there any other tools that you'd like to recommend to the community that they should evaluate and explore?

Allan De Castro [00:32:34]:

Basically, we used Azure DevOps for sure regarding the backlog. So first they started on a basic Excel Excel sheet and then we imported it in Azure DevOps before the project started to ensure that everything is linked correctly, etc. etc. And I think that it's quite great but I think that we can wait also extension. Meaning that for example, if you want to perform the road map, you have some extension available to add your epics and the different, I would say, sprints. Also to define the dependencies, quite important. And the good point is that if you have your ALM process, including the tool you are using to manage your backlog, it's quite easier for us because you can link all work item to your pull request. So then to your build, etc. For example, here we are working to automatically generate notes based on what we did on the build because all work are now linked, etc. So like that it's automatically generated, displayed on the dashboard. So like that we have all really not displayed. It's quite clear and so we can communicate it to the end user whenever we do a production delivery and this kind of stuff. I think that you can implement also some other stuff. Like for example on a basic PBI work, we do have some basic steps saying that we'll have the functional part, the customization to update the documentation, then to perform the build task, then the testing phases, etc. And I think that it's also something that can be created automatically to help, I mean, the dev team to ensure that, okay, we'll take this PBI because we move to statues or to an iteration to a sprint, then automatically the task are generated. And so like that, we follow always the same pattern. And as sometimes, you have some post deployment, for example, step you can also generate a task automatically saying okay, maybe we'll have it and at least we'll maybe delete it or just keep it at the end of the sprint because like that, you have a full task career of post-deployment tasks that must be done after delivery, etc.

Neil Benson [00:34:45]:

Yeah, I'm not a big fan of using tasks. I know they work for a lot of teams so I'm always interested and curious. So it sounds like you are using sub-tasks under your product backlog items, which is great to hear. You know, there's lots of different ways of applying Scrum and the Scrum guide doesn't tell us — used to tell us about sub-tasks but some things do, some things don't. So you won't find any guidance or rules in the Scrum guide anymore about sub-tasks. So glad you're having fun with those.

Allan De Castro [00:35:14]:

Yep.

Neil Benson [00:35:15]:

Alright, Allan, anything else you'd like to share with the Amazing Apps and Business A pps community before we wrap it up?

Allan De Castro [00:35:20]:

I think that basically you can first keep in mind to have the Scrum guide on your desktop first. Feel free to consult it whenever you have a thought about it. Then, you can follow some course. I followed yours some years ago because, I mean, quite easy. But basically, it's a free course. So congrats to you, to your contribution for this. A lot of stuff quite valuable, meaning even how you are writing some user stories, etc. to ensure that the definition of ready and definition of done is correctly defined and understood by everyone. It's something quite important.

Neil Benson [00:36:03]:

Allan, how can people get hold of you, follow your content, and keep in touch with you online? Are there preferred social media channels or anything that you'd like to share with us?

Allan De Castro [00:36:15]:

Basically, you can follow me on LinkedIn for sure. I try to post some good stuff. But also on Twitter, which is a common way in the MVP world to communicate quite easily by tweeting everything we have in mind. And also my personal blog, blog.allandecastro.com. Try to do some blog posts sometime, I would say. So for sure you can reach me from LinkedIn, Twitter, or my personal advice for my blog.

Neil Benson [00:36:41]:

Yeah, great. Well, we'll make sure we include links to those in our show notes. You can check those out at AmazingApps.Show/141. Allan De Castro, thank you so much for joining us. Appreciate you sharing your agile story, building sounds like a pretty complex enterprise Dynamics 365 apps for Avanade's customers in France. I really appreciate you coming on. Thanks so much.

Allan De Castro [00:37:02]:

And thanks to you, Neil.