The past 15 years I have been involved in software development projects for ERP systems. The last 10 years I have been working with Microsoft Dynamics NAV. During the years I have seen all kinds of approaches to get software delivered on time, preferably without any bug. These approaches vary from the classical waterfall approach to ad-hoc development without any design and documentation.
Several years ago we were maintaining a large variety of components without any version control. In fact, the only version control was the fob on the file system. This was giving all sorts of problems, especially in multi-developer projects. At that moment in time each self-respecting ISV or VAR was creating their own developer tools, and so did we. Actually the chosen solution was quite nice: we used Microsoft Visual Source Safe as the source code repository and we built a ASP.Net web service on top of it. We made a sophisticated NAV component which was interacting the these web services. It was now possible to use source control operations, like checkout and getting versions, straight from the Microsoft Dynamics NAV classic client. We even enhanced this with a build system, using the same technology. Wow, these were happy days without thinking about development processes and other technologies. Of course our nav solution was fully optimized for the Microsoft Dynamics NAV developer. You just had to press one button and the complete rocket was launched
This was all working quite nice until Microsoft announced that SourceSafe was discontinued and we had to look for an alternative. Since we are a Microsoft gold partner the choice was easy: Team Foundation Server. We only had to replace our source safe connector by a TFS connector and we are ready to rock. That was at my impression at that moment in time. I didn’t realize the power of TFS and what it was all about. Since I am not a .Net expert (I try hard to become one these days) one of my colleagues from our .Net team was charged to assist me with the job. The job was simple: create a TFS connector for Microsoft Dynamics NAV, which implements the same functionality as we already had for Visual SourceSafe.
During this project my colleague really scared me off and got me out of my comfort zone. We had a tough battle for each single feature. Each specific Dynamics NAV feature which I used to have was under discussion. Can you imagine: a Dynamics NAV developer with his own tools have to convince a senior .net developer that Microsoft Dynamics NAV is soo special that it justifies our own developer tools. After some time it became clear we had to reconsider this job and we took a complete different approach: try to apply the agile practices on Microsoft Dynamics NAV development instead of doing the opposite. That was a really breakthrough! We started with an integration with the TFS Build System which made it possible to do automated builds for our Microsoft Dynamics NAV solutions.
The next step was version control by integrating the Microsoft Visual Studio Team Explorer with Microsoft Dynamics NAV. The next step is process related: we implemented the scrum practices provided by TFS in our own organization.
This is where the journey started; the journey to Agile Software Development for Microsoft Dynamics NAV by Breaking boundaries, learning new practices and technologies and try to follow agile software development in it’s most pure form, without allowing exceptions for Microsoft Dynamics NAV unless there is a real, real good reason. Hmm I’d better stop because it because this post looks like a sales story now.
The point is that I became so enthusiastic about agile software development that I want to share this knowledge with the rest of the world. I have created this blog to post information about how agile practices can be implemented in a Microsoft Dynamics NAV environment. With these posts I hope to contribute to the Dynamics NAV community and inspire you with new ideas for your Dynamics NAV software development process.