Over the past few years the company that I work for has shifted to more of an agile approach to Dynamics 365 Finance and Operations Projects. I was a little skeptical when I first started studying the methodology, but as I’ve learned the different ceremonies and techniques I’m really sold on it. I am even a certified scrum master now.
Below are 5 ways in which I think and agile approach to D365 F&O projects work very well.
5. Agile acknowledges change in a project during the project lifecycle
How many times as consultants have we said “This project will never go live. The requirements keep changing”? I know that I have said that many times on projects. The fact is during any implementation the consultant learns more about the client’s business and the client learns more about the system they are implementing. That makes change inevitable.
One of the things that agile does very we is, well, it’s agile. The changing requirements are captured in the backlog, prioritized and worked.
In the past as a consultant I knew that things had changed considerably, but could never really quantify to leadership or project managers how much change there had been. With the product backlog that is used in agile it’s very easy to look at the various PBIs that have been completed over many sprints and see where you started off as a requirement, what direction you have gone, as well as where you are headed in the future.
4. The ability to show constant steady progress
I know that we’ve all been on projects where we are working hard and feeling like we have made a lot of progress, but it seems like we’re not really getting much feedback from the client until after we have fully configured/developed the solution.
One of the really nice features of agile is the product owner/development team symbiotic relationship. For those not familiar with agile the product owner is the client representative that is responsible for delivering the solution on the client side. The product owner owns the backlog and determines what features are most important to the client’s business. The product owner at the end of each sprint demonstrates the functionality to the business stakeholders based on what the development team was able to configure/develop.
Sprints are small chunks of time (think 2-4 weeks) that are predetermined by the team. During the sprint the development team is showing the product owner what is being done and at the end of the sprint the product owner is showing the finished product.
This provides an almost constant feedback loop to and from the client for what is being developed. I’ve noticed that since starting to work this way there are very few what I would call major misses on functionality. This is because if the development team is getting off the road any where the reviews happen so often that they are minor fixes not major redo’s.
3. The ability to estimate time to complete
When I first started looking at the agile methodology there’s a lot of guessing as to how long it’s going to take to do a piece of functionality. I really struggled with being asked to estimate every product backlog item. Think of a backlog item as a piece of system functionality.
As I started working through projects using this functionality I understand now I was probably making a bigger deal out of the estimation than I needed to.
One of the side affects to this estimation process is that after a few sprints you really get a good sense as to how much work the team can do in a particular sprint. Once you have a fairly good read on that value you can fairly easily look at the rest of the backlog and determine how many sprints it will take to complete the backlog or if the goal isn’t to complete the backlog get to the point of where you have enough functionality developed/configured in order to go live. This is referred to as MVP or Minimum Viable Product.
2. Daily standups keep the work moving
One of the ceremonies used in Agile/Scrum is the daily standup meeting. This is strictly timeboxed to a 15 minute meeting that is held every morning. The meeting is used to identify any blockers that anyone on the team might have. Oftentimes after the stand up anyone with a blocker will hang on along with anyone that can help relieve the block to determine the best way to remove the impediment to the work.
I don’t know how many times on projects where I was waiting on something from someone and all the emails that went back and fort etc.. These types of issues can be brought up in the daily scrum and quickly resolved with some conversation.
1. Keeps the team focused on the work that needs to be done.
The number one effect of using an agile approach on a D365 project is that it keeps the entire team working on the correct things and working in the same direction.
On past projects it seemed like the whole team was working on completely different things on the implementation. Often this led to misalignment on the items being worked on.
With Agile/Scrum each sprint consists of a set of product backlog items that need to be completed during the sprint. This focuses the team on completing those items. This also causes the items to be completed faster than what you would normally do because the entire team is focused on the one goal of completing the individual items.
I will say that agile does have it’s flaws and can be onerous to some people, but overall I’ve been very happy with the projects that I’ve worked that are using this methodology. These projects feel like they are more under control because of the communication that the process forces.
