Using Scrum in the context of D365

In my 14+ yrs of consulting I have seen many Dynamics 365/AX projects take longer than they should, cost more than was planned and deliver less than was expected. > hindsight is a wonderful & sometimes painful thing!

In recent years I have become more convinced than ever that the traditional methods (SureStep & Prince2) of implementing Dynamics AX/365 projects, in which I am well versed, are no longer a good fit for the application family that it has evolved into.

In 2018 I saw a talk given by a ‘Change Manager’ who was instilling the virtues of how using an ‘Agile’ methodology to develop software allowed his customer to gain benefit from the efforts of the team long before the whole product had been completed, manage the cost directly against the ‘value’ produced to date and finally delivering the product in a timeline that was quicker than perhaps another method would enable. I was curious….. but not sold… – when reading this please remember I am learning too, so if you see any mistake’s please let me know 🙂

So in early 2019 I started researching and undertaking training to see if I felt I could use an Agile approach with Scrum, for future D365 implementations.

So what is Agile?

The best and most succinct definition of Agile that I have seen is:

Agile is a continuous iteration of development and testing in the software development process. Agile breaks the product into smaller builds

In real terms to me, this means that when looking at a D365 project I should identify the elements of the project that can be dealt with on an iterative basis. e.g. don’t implement all scope/functionality in a single big layer, but like a good wall put in solid foundations then add each layer of bricks 1 by one, maintaining the straightness of the edges and the line of the wall!

There is a wall from day 1, it just gets more substantial as we add another layer of bricks to it.

Is there more to Agile than that?

Yes, here are the 12 recognised Principles of ‘Agile’ and my own translation of them! (source

  1. Satisfy the customer through continuous delivery = frequently deliver new/improved business processes to the business , either through code, configuration or training
  2. Welcome change in requirements = accept the goal posts will change!
  3. Deliver working software frequently = deliver production ready code improvements to D365 at the end of each sprint
  4. Business people and developers work together daily = obtain commitment from both parties that this will happen, and make sure it does
  5. Build projects around motivated individuals = identify motivated people and ensure they are part of the scrum team
  6. Face to Face Conversations between the teams = ensure that the teams talk face to face and just don’t communicate through email, even a video call allows facial expressions and emotions to be shown/read and reacted to.
  7. Working software is the primary measure of progress = its no use being ‘nearly there’, judge your performance on the true usable output.
  8. Agile process promotes sustainable development at a constant pace = in Sprint Planning don’t make some sprints much bigger than others, aim for a balance over time, whilst keeping in mind velocity.
  9. Attention to technical excellence = avoid shortcuts, do the right thing the right way.
  10. Simplicity – maximise the amount of work not done = do only what you need to do, to deliver a great product.
  11. Self-organising teams deliver the best architecture, requirements and designs = ensure the development team acts as a team, leveraging all their combined skills and experience to deliver the solution.
  12. Reflect and adjust regularlykeep looking at what your team has achieved, and what it hasn’t and what the challenges/blockers were – focus on how to improve

The above is only a taster of what it is to be agile though, there are far better reference materials elsewhere online to give you a wider understanding than this blog, they are just a google search away.

How does Scrum fit into that?

Well ‘Scrum’ itself was created by Jeff & Ken to provide us with “a framework for developing, delivering, and sustaining complex products“. This framework is entirely compatible with ‘Agile’ and I see this as being the framework to be used to deliver each ‘iteration’ mentioned in the definition of Agile above.

If you have time I highly recommend you invest in Neil Benson’s Scrum/Agile courses delivered through his Customery Academy. Click on the image below to visit his site.

Essentially combining Agile with Scrum provides us as D365 implementer’s a clear set of roles, events and outputs to help us deliver value safely and rapidly.

The full definition of Scrum is available in a FREE 20 page PDF available for download from:

So what are the roles in Scrum?

  • Scrum Master – responsible for coaching the team in scrum and facilitating scrum events. Each scrum team needs 1 x Scrum Master but a single Scrum Master can run many scrum teams.
  • Product Owner – as in the film ‘Highlander’ – there can be only 1. This role is responsible for collecting and defining the requirements of the product. It’s done by 1 person and not a committee or team – this person becomes responsible and accountable. (I ask them to create Epics or Features in DevOps for each key requirement, then breakdown that requirement further using related User Stories)
  • Stakeholders – anyone with an interest in the product including end users. They should feed into the Product Owners any requirements they have.
  • Development Team – the team of people who will take the requirement from the Product Backlog and produce the ‘increment’ that delivers it. Usually includes developers, business analysts, architects and functional consultants.
  • Scrum Team – this is made up of the Scrum Master, Product Owner and Development Team

What are the events that happen when using Scrum?

The Scrum Guide defines these events and all are mandatory – drop them at your peril!

  • Sprint Planning Workshop
    • Time fenced to 8 hours for a month long sprint. No sprint should last longer than 1 month.
    • This is attended by Product Owner, Development Team and Scrum Master
    • This is a collaborative workshop aimed to deliver a Sprint Backlog, which is a subset of the items on the Product Backlog
    • Product Backlog Items are re-estimated at a high level by the Development Team. to aid their selection into a sprint.
  • The Sprint
    • A time fenced period where the Sprint Backlog is worked upon to deliver only the items within that Sprint backlog
    • Maximum length of 1 month
    • Sprints cannot be extended (I admit I have made this mistake before)
    • Once the Sprint backlog is set, then from that point it’s owned and managed only by the Development Team
  • Daily Scrum – attended by the Development Team & Scrum Master its focus is 3 questions
    • What did we achieve yesterday?
    • What impediments/blockers/challenges do we have?
    • What we will each do today, towards the Sprint Goal?
  • Sprint Review Workshop
    • Demonstrating the completed items to the stakeholders
    • Usually held on the last day of the sprint
  • Sprint Retrospective – this is the final act of a sprint, its target is to reflect on the scrum teams ways of working, what worked and what didn’t so changes can be made, or not, in subsequent sprints.

Tell me about the outputs in Scrum?

In typical D365 projects I have seen much effort put into the creation of lengthy Functional Requirements Documents and Functional Design Documents to be used by developers to then create the product. The problem has always been that the length of time it takes to write these documents, to the level of detail really needed – is very rarely available, the customer very rarely wants to pay for that and in all honestly I haven’t come across a developer yet that has told me ‘good FDD – it told me all I needed to know – here’s your product!

The good news is that these documents don’t exist when using a Scrum approach, instead the following Outputs are key

  • Product Backlog > The first output is the Product Backlog, the list of all the requirements to be delivered by the product. I use a Backlog in DevOps to record these using the ‘Scrum Process’ suggested by Microsoft here:
  • Sprint Backlog > The 2nd output is the Sprint Backlog. the list of what will be delivered by a given sprint. I use a Sprint in DevOps to record the Product Backlog items to be delivered by a given sprint
  • Increment – The final output is an increment of usable software. It doesn’t have to be deployed to production, but it needs to be fully completed and ready to be deployed
    • The contents of an Increment are the sprint backlog items that were ‘done’ during the sprint. Therefore the ‘Definition of Done‘ needs to be at the heart of the project teams consciousness. There needs to be understanding between Scrum teams of the definition of done, and in some cases different teams can have a different definition as long as the other teams are aware of it.

How do I use Scrum in D365 Projects?

Dynamics projects are almost always a mixture of the following components:

  • Data
  • Configuration
  • Training
  • Customisation
  • Testing
  • Executing

At first glance I thought about using Scrum only for the ‘Customisation’ element, because that’s where we are developing software…..right?

No, our projects are about delivering a ‘working increment’ of a solution and to me a solution involves not just the software functionality but the human, non-system interactions and activities as well. With that in mind I believe we should include data, configuration and testing. I draw the line at ‘training’ and ‘executing’ myself – these are elements that I think should sit outside of Scrum.

However, I do keep Training topics on the Product Backlog though – mainly for visibility. – am I wrong? – please let me know your thoughts:

How do I use DevOps for Scrum with D365?

This I have learnt by trial and error, but in researching this blog post I did come across this useful post on Microsoft Docs – luckily I have been using mostly the same approach 🙂 –

One thing I learnt early on was that investing time in the setup of DevOps to hold all the information needed by the Product Owners, Stakeholders, Development Teams and Scrum Master – saved me even more time thereafter.

  1. I create User Teams inside DevOps to match each of the Scrum Teams.
  2. I create Iterations for each Sprint, so to quickly assign an item to a sprint, either drag/drop or change the iteration of the DevOps work item and your done.
  3. I number each sprint – 01, 01 > 99. When I have multiple teams, its usual to have 2 numbered sprints running concurrently – hence why I use Numbers.
  4. I use Epics or Features in DevOps (Work Item Types) for the higher level requirements, then get more details of those using related User Stories.
    1. The more information that I can get ‘documented‘ on the DevOps User Story work item – then the easier it will be for the Scrum Team to understand what they need to create.
  5. At the end of each sprint, I move any items not delivered in the sprint back to the Master Backlog. This then allows me to easily look back at each sprint and see what was achieved within it

Microsoft are actually quite switched on when it comes to providing us guides on how to use DevOps with Agile methodologies. This is a useful link that you can use as a reference guide for your next scrum D365 project:

Why aren’t all D365 Projects run this way?

I believe this question has a few different answers that combine to provide a picture, from which you can draw your own conculsions:

  • 1 project methodology doesn’t fit all projects, they all have their strengths and weaknesses – more appropriate to 1 project engagement then another.
  • When using Scrum, how do you go about ‘estimating’ the cost & duration of the project when by its nature you done have a set of fully scoped requirements defined. Therefore the ability to estimate costs and timeline is different but not impossible. Its worth reading this e-book on the topic:
  • User training in Agile/Scrum has lagged behind ‘waterfall’ style approaches in the last 10years, but is accelerating now.

When to Use Scrum for D365?

I bought a new car a few years ago that was a V8 Twin Turbo monster – it did 18mpg, but like everything ‘New’ I tended to use it for everything – even though we had a sensible MPV as well that did 60mpg! I soon learnt that it wasn’t the right decision and actually it was more beneficial for the family if I saved the money and took the MPV instead. To me SCRUM is like that – while I am finding it fabulous and enjoyable to use, I wont use it for everything:

Times I would use Scrum for implementing D365 are:

  • when the customer recognises that the business requirements are either not fully defined or simply expected to change.
  • when my customer says to me they have a Fixed budget, but want some flexibility in what that delivers
  • when the customer is in agreement that the ‘Project’ will design the solutions within the same activity as developing them. There will not be time for long design review activities.
  • when the Scrum team can be physically onsite with the product owners. – Now this one I am beginning to waiver from, since Covoid-19 we have all seen that amazing things can be done through effective communication and physical co-location is not always possible. So this now is rather a strong consideration rather than a ‘must’ for me.

Typically I wouldn’t look to use Scrum when:

  • when my customer says to me they have a Fixed budget AND they know exactly what they want that budget to deliver (so a fixed scope).
  • when the customer wants to hold design reviews between the design and development activities.

How do I become better at Scrum?

If you have the time and enthusiasm then learning to become a Certified Scrum Master or Product Owner is a great place to start. I have really enjoyed learning about scrum using the following resources:

Related Post