If I had to pick the most common reason for ERP Projects failing or going over budget, it is pretty easy to identify a poor development lifecycle process as the usual culprit.  Our villains (scope creep and rework) are always present and exceptionally good at escalating spending on those implementations without a proper development methodology.  When we look at development on an ERP project, we can’t just approach it from a technical perspective of branching and source control.  We need a methodology that covers everything from requirements and FDD’s to testing and change of scope.  My personal preference is to implement an Agile based methodology for unifying the technical development and a functional requirements process.  Let’s get started with that here.

1st, we need to have TFS and Visual Studio installed.  At present, on January of 2016, I still find advantages to having the on-premise TFS version because of the options for customizing templates and work items that are not in the online version yet.  However, keep checking this link Visual Studio Online Features because they could be there in the future.

2nd, we need a couple of important enhancements for Visual Studio.  You want to download the TFS Power Tools and the Scrum Power Tools for Visual Studio 2013.

The Power Tools will provide the ability to do critical customizations that you can report on. The Scrum Power Tools will provide some nice aides to the development process.

3rd, Having played with virtually every TFS template I could get my hands on, I’ve found that there is no substitute for the Agile template. It captures everything needed within your software development lifecycle from planning to rework while still maintaining the flexibility necessary to adjust to today’s implementations. For a Dynamics AX ERP implementation, I haven’t found a way to consistently go pure scrum as of yet.

Okay, so at this point, you’ve picked a TFS template and you have the tools, but now you need to start adapting your TFS Implementation so that it actually serves you (and your precious ERP budget).

It’s time to begin customizing but first you need to pick up some definitions. Remember, an Agile based ERP implementation involves everyone taking responsibility from the major stake holder to the person who uses the system. The concept of a disconnect between development and functional is not allowed and we enforce that through following our principles. On the bottom of your TFS dashboard, you will notice a section called “other links”.

You will want to start by customizing two sections — Iterations and Areas.

4th, Areas are used to categorize where the activity is taking place. You create logical groupings. So, for example, in AX, I personally like to setup my areas so that I get all the modules in there as classifications plus an “other” category. That way I can carefully track development by module and show the project manager where the major time and spending is taking place. Plus, it helps during upgrades to get a quick idea of where the work will be at.

Notice, how I go through and add an Area for each and every module plus an “other” to capture activity that may not correlate with just one module or is something else.

Don’t underestimate the importance of what you just done. You just created a classification system that will allow you tie requirements, testing, planning, and development into well classified buckets for all kinds of helpful analytics (later in this series).

5th, lets address one of the most important parts of any implementation, an “iteration”.. An iteration is a fancy name for a period of time. Think of it as a named “To Do” list for an interval of time where you want to accomplish something.  How you name the iteration depends on the circumstances. For big, large Implementations, I like to name each Iteration after the build number of a planned code move. So, say that we are moving code every two weeks, I just include the build number. For smaller implementations, I like to name the Iteration after the critical tasks in some sort of summarized way. For example, see how I coined the iteration here for an example of how I would do a small implementation.  Project manages love to have me name the iterations in phases like “Phase 1” but I usually debate with them about it (personal preference because the word “Phase” means very little to me).

If you look carefully, you will notice a few things. Small Implementations often involve very focused minor code moves, so it’s easy to classify the schedules with names rather than build numbers. But look at the first option and observe. Notice how I made a dedicated iteration for configuration and setup. This is mostly a functional activity but in the Agile world we don’t segregate functional and technical. Yes, we have roles but the two should be integrated fully subject to the reporting of our software lifecycle process.

This is good the first part of our TFS Customization but we have several posts to go. Don’t underestimate what you’ve learned here and the competitive advantages it will give to your implementation to go Agile. You now know how to properly group your implementation activities in AX by both subject matter and time — a key advantage that will pay dividends.

Till the next post..