There is much discussion regarding whether agile implementation is possible with a package such as Dynamics 365. Unlike a tailored application where all the options are open, a package comes with many predefined functions. The customer’s needs often are adapted to the package instead of the other way around. This is also why you regularly hear that you should avoid agile package implementations. However, we believe an agile approach can be applied to all projects, including D365. Of course, there are certainly a number of recommendations that must be considered.
First things first: why agile?
There is a number of reasons for this: an important one is the short feedback cycle. In a traditional project, e.g. based on the waterfall method, everything is set up and configured before the customer gets to see the system for the first time. If any misunderstandings are revealed at this point, a great deal of reworking is required. There is also a good chance that the customer’s requirements and wishes have changed in the meantime, meaning that the finished product no longer meets their actual needs. A more flexible approach is necessary to avoid these kinds of risk. The agile method is highly suitable for dealing with constantly changing conditions. It allows for interactive working in short sprints of 2 to 4 weeks with regular feedback loops and offers room for changes and progressive insight. The agile approach inherently assumes that business needs can change during an implementation process. With each sprint, the users get to see a demo of the application, and they can provide direct feedback on whether everything meets their expectations. They also have access to a user acceptance testing (UAT) environment, so they can personally check how the functions work. This simplifies user adoption, which is a second reason for using agile. The users get a feel for the application right from the start, and they feel involved in the project. Their participation increases their engagement, making them more inclined to accept and use the application. A third reason is a strong focus on value creation: offering added value to the customer. As a result of continuous prioritization and the focus on intrinsic business value, the effort only goes into important and relevant functions.
Agile coach: focusing on the soft side of change and drawing on knowledge and support
Agile working has many benefits, but it is not a magic wand that everyone can wave just like that. If you have never done an agile project in D365 or are relatively new to the agile method, it’s a good idea to employ an agile coach. The coach can answer all your questions about the best way to tackle an agile project and help the team members learn to deal with practical matters. The coach will also assist you when it comes to interaction with the customer and support them in working with agile. An important basic condition for agile is effective, close cooperation between people and teams, which is decisive for the success of a project, and this is only possible when everyone is pulling in the same direction. An agile coach does not necessarily need to have specific experience with D365 projects, but they should of course have experience in working with agile.
Sprint 0: go for solid foundations
It is advisable to start with sprint 0. This sprint is actually a preparatory sprint that lays the foundations for all following sprints, in which the team is given time to get to know each other and learn to work together. Through workshops, the initial requirements and wishes of the end-users are identified and transformed into user stories. These user stories are then collected in a product backlog and prioritized based on their business value. The items with the most value for the users are configured and implemented first. The objective is to form a product backlog containing enough user stories to fill the first sprint. User stories may certainly be split up into small enough elements. With a tailored project, the only consideration is the business value for the customer, which is taken into account as part of prioritization. With a D365 project, you can create business value through the built-in functions of the package. The solution consultant plays an important role in this. They must determine the fit/gap between the built-in functions and the required business value. During sprint 0 it is important to also give attention to the technical aspects of – and basic requirements placed on – the system, such as the architecture, especially if it is to be integrated with other systems.
Product owner: ensures there is a bond between the stakeholders
A good product owner is essential for the success of an agile project. This is also true for D365 projects. A good product owner is preferably not a manager, since a manager often does not have enough time to properly follow up on a project. The role of project owner is not something you can simply do on the side. Ideally, the product owner is a person who comes from the business and has experience in the business. In the case of sales implementation, for example, the product owner should preferably be an account manager or former account manager. The product owner must have good contact with all project stakeholders and be connected to the various interests of business and IT. They should also ensure that the vision determined before the start of the project is maintained as the project progresses. It is also crucial for the success of the project that the product owner is unanimously authorized to make decisions. Otherwise, the project runs the risk of incurring delays due to waiting for decisions to be made.
Minimum viable product: launch the essentials to accelerate quickly
A basic principle of agile is that a minimum viable product (MVP) – a minimal functional product made with minimal investment – can be delivered at the end of each sprint. These short iterations reduce the risks of failure, with immediate feedback serving to reduce turnaround times and avoid unnecessary complexity. It should be noted that as part of a well-conceived launch (which is the intention), “minimum viable” does not mean “mediocre.” A minimum viable product is a functionality that can be used effectively and forms the basis for further development. With D365 it is actually easier to deliver something after 2 weeks than with a tailored application. However, the challenge here is that the project approach and the knowledge of the teams must be aligned to such sort-delivery sprints. Agile and (automated) releases – in the spirit of DevOps – go hand in hand here. In this respect, you can regard D365 as a set of building blocks from which blocks that are important for the project and are used to build the rest of the project, are jointly chosen.
Sprinting, measuring, and learning: implement based on progressive insight
During project implementation, it is especially important that the business priority and the technical sequence of implementation are properly discussed in the sprint planning meetings. On occasion, specific units have to be created before other items can be built. This can have an impact on the number of story points assigned to a specific user story, or on the necessary implementation sequence. The sprint review meetings and retros are crucial during this phase of the project. The users get to see the result for the first time during the sprint review meetings. It is important to listen carefully to their feedback and to take this opportunity to let them get acquainted with D365 themselves. This works best if you give them access (as soon as possible after the sprint) to an environment where they can test and validate the operation of a specific development or configuration. If necessary, a number of adaptations are included that are treated in a subsequent iteration on the basis of priority. One of the major advantages is that everyone has a better understanding of the project’s progress and that business and IT are also geared to each other on a more effective and productive basis.
