Monthly Archives: June 2012

The marriage of Microsoft Team Foundation Server and Microsoft Dynamics NAV

I think the time is there to share the core concept of this blog. Like mentioned in earlier posts the goal of this blog is to  inspire Microsoft Dynamics NAV professionals to adopt Agile in their development processes. Agile is a popular topic these days. Most information, however, is focused on other platforms, like .Net development. We noticed there is still a gap between those platforms and Microsoft Dynamics NAV. That is the goal of this blog in a nutshell.

As you may expect from good software developers we have an architecture for the articles posted on this blog. We are very much in favor of eating our own dog food which means we use real  examples with live code. In previous posts you probably saw some screenshots of Team Foundation Server provided Microsoft Dynamics NAV artifacts. The time has come to share this architecture with you.

The concept is simple: we want to apply the standard process template for MSF for Agile Software Development v5.0  to our organization. This template has been created by seasoned  experts and its current version is 5.0. One of the authors of this template (Jeff Sutherland) wrote an excellent article about the details of Agile Principles and Values. What if we try to apply these principles on our Microsoft Dynamics NAV domain? Obviously we want to achieve the same goals, even though we have different tools.

So far so good but we have our Microsoft Dynamics NAV Development Environment with its whims. How realistic is it to apply these principles on Microsoft Dynamics NAV? This question has been on our mind for a while. After researching and discussions we ended up with the following solution: we follow the standard Agile template  and adapt it with Microsoft Dynamics NAV by using the extensions of Team Foundation Server. This effectively means we adapted Team Explorer and Team Foundation Build System with Microsoft Dynamics NAV. As a result we are able to unleash the full power of Team Foundation Server, without requiring any customization of the process or Microsoft Dynamics NAV.

Because of this concept we are able to have one process for both .Net and NAV and AX development. Which is no luxury these days since more and more Microsoft Dynamics NAV solutions depend on .Net components.

I hope I did not scare you by sharing this concept. Remember it took us two years to implement this. The organizational change is the most difficult one. Agile is not the magic word which solves all issues but it surely identifies them. Another  good aspects of agile is that you can take small steps to improve. That is exactly what we did: we started with version control, then build management and after that we implemented scrum. Recently we integrated the Microsoft Dynamics NAV builds with Microsoft Dynamics NAV Testability Framework. Yes we are in the process of continuous improvement right now. In fact, it only just begun :).

Good article about applying test automation on legacy system. Sounds familiar as it is quite complex to write automated tests for existing NAV solutions. An article which translates this article to a Microsoft Dynamics NAV scenario would be nice.

Technical Software Testing

Within one of the LinkedIn groups (sorry, you need to be a member of the “QA Automation Architect” group to be able to read it fully) we started talking about the difference the state of project or product can make for test automation. In this post I will make a distinction between 2 states: new where no code has been written yet and existing  where application code has been written, but no test automation has been implemented.

Cutting edge

New So when creating a totally new product, life for the testers can be made easier by design, that at least is the thought. This does imply that testers, and not just the “manual” testers but all testers, including automation testers if these are a separate breed as some people seem to think, need to actively participate in the requirements phase of a product. With actively participating I do not mean…

View original post 912 more words

Poll: What is your Microsoft Dynamics NAV Development Environment?

As mentioned our post about developer isolation and team development isolation of runtime is an important aspect of agile software development. I would like to show you how you can achieve this for Microsoft Dynamics NAV. Before writing this article I would like to know how most of you are currently developing your Dynamics NAV solutions.

 Feel free to comment on this post.


Many teams believe they are Agile because they are following the prescribed Agile practices. E.g. A team may think they are Agile because they are doing daily stand up meetings, sprint planning meetings, retrospectives etc.


The mistake that teams often make is that they tend to treat these practices as ‘ceremonies’, thereby focusing more on getting the ‘ceremony’ done, and not so much on doing it right so as to derive the benefit that the practice is intended to provide. Take, for instance, daily stand up meetings. A team can be said to ‘be’ Agile if they can achieve the following benefits through these meetings:


  • Instilling a clear sense of purpose about what needs to get done
  • Focus on efficiently moving the work forward
  • Early identification of risks and blockers
  • Team members helping each other with share obstacles


However, many teams think they are Agile, just because…

View original post 129 more words