Why do so many implementations proceed without an accepted industry best practice software development lifecycle when the implications of doing this are well-known and all bad (e.g. very, very expensive)?

The reason is a little more complicated than at first glance. In traditional software development we have business analysts who are responsible for gathering requirements and doing a lot of the bridging between technical and functional ends. On the ERP implementation, we still need the business analysts(BA) but they go by another name “Functional Expert” because they are expected to primarily have a deep understanding of how to apply the product to an industry related process. The industry related process is complicated enough to where it often requires deep expertise in a particular field; thus, industry level expertise is often prioritized over the traditional BA skills with the caveat that traditional BA skills are often a part of the job. The net-net of this is often a broken software lifecycle process as you essentially often see untrained BA’s with SME knowledge carrying out key components of the development lifecycle. Smaller implementations can often (not always) get away with a lack of a true lifecycle process though (if the amount of development is extremely small) they usually benefit from one if it is there. Bigger implementations often lead to failures or severe budget overruns as problems compound from improper lifecycle management practices.

The good news is that it is never too late to change broken development methodologies and get Agile. Properly setup and administered, our TFS will greatly aid us in maintaining compliance. TFS does this for us out of the box if we are just willing to accept it and use it. To understand how we can utilize TFS to unify the Technical and Functional ends, we need to familiarize ourselves with 2 pivotal concepts – the Team and the Backlog.

Let’s start with the concept of the Team. Notice how easy it is to create one. What I do here is create a new team through the Portal.

And I make another here. Again, a little simplified as this team may need to be broken out. My quick rule of thumb is to break things down further when I have a team above 5 Functional SME’s around the process working on the project for 2 months or greater. That usually indicates specialized focus which may be better reported as a different team. Again, I’m very careful to ensure that I don’t go to too many teams. As you will see teams are fundamental to our accurate reporting but overkill is overkill.

Depending on whether or not the implementation prefers their own ticketing portal or TFS, I make a separate team for the AX Administrators to manage the support queue which doesn’t involve development or functional tasks. Here I haven’t done that.

Notice that I create a new area for the team. Then, I go about assigning the Areas that the functional team will be responsible for handling. Note, this is a simplified list based on a small implementation. First, all of these modules may not apply and we would leave them out if not in use on an implementation. Second, remember that the best classification systems often require reorganization. I don’t think that I’ve ever had one TFS classification system that I setup where I didn’t end up adding or removing something per user requests about 3 months later. That’s fine. TFS is about real world issues and having the flexibility to intelligently manage them.

So, you should now understand the first part of what it means to be a team. To understand the second part, you need to know about a Backlog. So, the backlog is a very famous concept. The simple definition is the amount of work needed to be done, represented as tasks. Those tasks are classified by numerous names that I’ll talk about later in these series. But for now, you just need to understand that the backlog represents our total repository of work. When we talk about workflows and workitems later, I’ll clarify how to integrate this in AX. But right now, I just want you to understand that all activity is quantified by the backlog, which represents the work that has not yet been completed but needs to be completed. We break the backlog down by using Categories (what type of work we are performing), Iterations (when the work is expected to be completed), and Teams (who is responsible for the work).

There is however one other concept that we need before we can finish this post. You now understand how to create teams and why you want to do this. You haven’t see the powerful reporting yet or work automation, but you can guess that it is coming. You also see where we can categorically link our functional and technical teams. But something else is needed. Our team members need to be classified themselves – that way we can give the appropriate workflows and permissions. For example, someone who is responsible for approving work needs an alert when it is time for approval. We need to be able to create a default rule when a task is assigned to this person or autoassign a task. Furthermore, many places have security constraints where the SME’s shouldn’t be able to see everything that is going on. For example, what business does a financial SME have with Production routes? All of these complicated answers can be handled by TFS quit easily. Or, the act of requirement gathering is very different from the act of developing – who is responsible for which?

In Team Foundation Server, we have the ability to easily create our own Team Foundation Server Groups.

Now, take a look at the groups that I created and notice a very pivotal concept. Notice that both functional members and Technical members are on the same team (Developers, Financial Approvers, Functional Financial, Functional Supply Chain, Internal SMEs, Supply Chain Approvers). This will prove pivotal for simplification purposes and to manage both process while unifying them.

That’s it for this post. There are a lot more to go for this series. I’ve only shown setup thus far and why you do certain steps. . You should already begin seeing the first benefits in that we have a unified reporting process for both the Technical and the Functional domains. But it gets a lot better. After a few more posts, we’ll begin to see the immense benefits with better reporting and real-time financial tracking, historical development and a code repository, ease of use through templates and repeatable process, major work efficiency boosts through automation and workflows.. In other words, we are just getting started.. Till next time!