Wednesday, January 10, 2018

How NOT to fail your NAV offshore development?

How NOT to fail your NAV offshore development?

Many a times we require some helping hands to complete a project on time. Sometimes it is only for short term and sometimes it is due to a large project where we need to scale up the team really fast. This is where we think about getting the development done with the offshore development team. Cost is of course another factor as we want to increase the project profitability.

Have you ever worked on such project where the development team is sitting miles away? How was it working on such projects? Was it always as smooth experience as with the onsite development team. I have been part of many offshore development projects and have seen some of the deliveries going through a lot of pain. On the other hand, many of the deliveries were so smooth that the testing team faced difficulty in finding even a single defect. So, what should be kept in mind to ensure the successful and smooth off-shore development experience.


Most common Issues faced in Off-shore Development -


  1. Frequent change in requirements and designs resulting in a lot of rework and sometimes leads to conflict between onsite and offshore team
  2. The development team is not able to move further due to the input required from onsite team
  3. Just before the delivery date, you get the surprise that the work is not complete
  4. The customization done by the developer are not as per the best practices
  5. Documentation / In-Line comments are missing. The onsite development team is not able to figure out the customized code
  6. Customization done by development team has a lot of defects
  7. The developer has not tested his development before sending
  8. The objects released by the development teams are from different base and creating a lot of confusion




What should NOT be done?


1.      Assume anything
“Assumptions are killers” is what I learnt by working on the multiple development projects. Please be specific as much as possible while preparing the technical design document. The technical design document should cover the field level details to be created in case of a Table / Field creation. The Functional Design should also provide the test scenarios to be tested.

2.      Starting without freezing the scope

This is one of the biggest reason why the offshore development go-through a lot of pain. Not freezing the scope / requirements results in a lot of rework and affect the quality of the development. So, let’s not send an incomplete Technical / Functional design to the offshore development team.

3.      Delegate and forget

Don’t just handover the Technical Design and forget about the development until the release date. You need to monitor the progress on day-to-day basis otherwise you might get unpleasant surprise just before release.

4.      Outsourcing tasks other than development

This is my suggestion when you start a project with a new team, you should outsource only the development work. The tasks apart from development for e.g. Functional Design and Technical Design requires a close coordination with Solution Architect and the client hence it is better to do them onsite. 

You might outsource technical designs later if the person has been on the project for more than 6 months or so as he will be very much comfortable with the development process and functional  process flow. 

What should be done?

1.      Agreeing on the Standards / Development Process to be followed

a.       Communicate the Best Practices, Commenting / In-Line Documentation standard for MS Dynamics NAV
b.       Finalize the development process and the documentation required

2.      How should the development environment be setup?

a.       Create a development environment to be used by the Off-shore development team
b.       Setup a Source Code Management software like GitHub or TFS. The NAV Objects can be exported in txt format and stored on GitHub or TFS.
c.       The Offshore development team should put their changes on TFS / GitHub 
d.       The onsite development team should pick the changes from TFS and put it on onsite Testing Environment

3.   How to handover the requirement to the developer?

a.       Share the Functional Design, Technical Design and Test Scenarios with the development team to study
b.       Development team should go-through the document and prepare the list of their queries
c.       Arrange a walk-through session with the Functional Designer, Technical Designer and the development team to discuss these queries

4.   How to ensure the Development is going in right direction?

a.       Daily Skype Meeting - Arrange a daily skype meeting with the development lead for discussing the progress and challenges
b.       Peer Review - After the development, the off-shore development team should do the Peer Review to ensure that the standards / best practices have been followed. The reviews feedback should be documented in Peer Review Log 
c.       Random Code Review – The onsite Development Lead should do the random code reviews to ensure the quality of the deliveries. 
d.       The Developer should prepare the Release note with Unit Test Evidence. This helps to ensure that the developer has done the unit testing before releasing it for testing.


5.   How to handover the development to onsite team for the testing?

a.       The developer should check-in his changes to the Git-Hub / TFS
b.       He should prepare the Release note with Unit Test Evidence with the scenarios tested


6.   Sharing the Testing Feedback and tracking the process?

a.       If we have the Incident Management System, nothing like it otherwise the Issue Tracker in excel must be created. There should not be one email for each incident. Complete the testing and put it in Issue Tracker and share with the off-shore development team
b.       The offshore development team should update the status with the action taken


7.   Team composition and responsibilities (In the context of offshore Development) -


Onsite
·         Solution Architect
-          Responsible for overall solution design on macro level
·         Functional Designer
-          Responsible for providing Functional Design for the Gaps
-          Testing the release and maintaining Issue Tracker
·         Development Lead
-          Preparing Development and Testing Environment
-          Finalizing the Coding Standard, Best Practices, Commenting Formats
-          Responsible for providing Technical Design for the Gaps
-          Answer queries raised by the off-shore development team
-          Conducting random Code Review
-          Deploying the changes from TFS to Test Environment
Off-shore
·         Offshore Development Lead
-          Track overall progress of Development and the quality of work
-          Ensure that the Development Standard set are being followed
-          Participate in daily scrum for the development progress
-          Helping / guiding the offshore development team with design or development issues
-          Peer Reviews
-          Release Notes Preparation
·         Developers
-          Study Technical Design and prepare the queries
-          Development
-          Peer Reviews
-          Unit Testing
-          Unit Test Evidence Preparation
-          Check-In the changes to TFS


8.   Documents to be prepared -

10 comments:

  1. Good one.. really helpful for the people who are working on ERP projects...

    ReplyDelete
  2. Indeed a very good blog.It is written in such a detailed and clear manner. Thanks for sharing your experience with us.

    ReplyDelete
  3. A very good and thorough study..Being in ERP i can relate to all the points listed above..Thanks for sharing dis one.

    ReplyDelete