Implementing Microsoft Dynamics CRM 2011. Is Agility a good thing? Part 2

 

Back in May I wrote a blog about our first time decision to use an Agile approach to implementing MS Dynamics CRM at two BDO clients.  I wrote of the characteristics of these clients and why we felt they were good candidates for an Agile project.  Both projects are ongoing and the sponsors are pleased with the progress.  But we long ago abandoned our Sprint Plans and Backlogs and replaced them with Design Documents and Microsoft Project Schedules.  Here are some of the lessons we learned along the way:

  1. Allocate more time to upfront Design than you think you should.
  2. Ensure that the work to be done in each Sprint (a.k.a the Sprint “Backlog”) is easy to achieve.   Be conservative in your estimates of what can be accomplished in each Sprint.    If you are unable to complete all the requirements (a.k.a known as “user stories”) in your first Sprint then it is difficult to ever catch up.
  3. Managing a large Agile project requires the use of software tools that are designed to manage Agile projects.  Microsoft Project is not one of those tools and Excel can only take you so far.
  4. Agile takes longer and requires more project overhead to manage than a more waterfall implementation approach.
  5. Agile is not well suited to projects with fixed scope and tight timelines.  If the project requires that a specific amount of functionality be delivered by a particular date - – the team is better off to entirely design that functionality upfront and then, if necessary, talk about reducing scope at the beginning of the project.  With Agile there is too great a risk that you won’t know you can’t deliver until too late.
  6. Agile is not well suited to projects with fixed scope and tight budget.   Managing to a budget with an Agile Implementation is not hard as it is easy to estimate the cost of each Sprint.  The challenge is when the functionality is not complete within the estimated number of Sprints.
  7. Following a pure Agile methodology makes resource scheduling and management difficult. There is an implied assumption that the project team members are available full time for the duration of the project. This is not the reality of most Microsoft Dynamics partners who have specialized resources (eg Scribe developers, Report Writers) that may be involved in 3 or 4 projects at one time.

 

Having said all this, I’m not ready to completely remove the word “Agile” from my vocabulary.  Two elements that we will be carrying into all of our CRM projects are:

  • Daily Scrums.  We’ve gone to 3 mornings a week rather than 5 – but everyone agrees that the projects have benefited from daily 15 minute calls.  The scrums have served their purpose as a forum to clear obstacles on a daily basis, to unite the client and BDO team members in a common purpose and to provide constant and consistent communication.
  • Breaking the configuration and development effort into smaller pieces that are released on a regular basis to the client to test.  One of the core principles of the Agile methodology is to engage the client in testing early and often.  This is an undeniable benefit of the Agile development process and one that we will continue to use and follow no matter what project methodology we use.

 

Cathy Brown is a Senior Manager with BDO Solutions practice. She is also a certified Microsoft SureStep instructor and has sold and implemented at least one hundred CRM systems – mostly using a Standard waterfall implementation methodology.   These are her third & fourth Agile projects.

BDO Solutions is a national firm with local practices throughout Canada, including Ontario, Alberta, British Columbia, Manitoba and Saskatchewan. Microsoft Gold Certified Partner and Reseller of the Year in Canada for 2010, 2011 and 2012.

1 thought on “Implementing Microsoft Dynamics CRM 2011. Is Agility a good thing? Part 2”

  1. Thank you very much for sharing your experience

    I'm in a team where we are kicking off CRM work (very initial stage right now, playing around the tools) and I'm thinking of to adopting some agile and scrum methodologies to our process.

    Just wondering whether your team tried out practice of "User stories" to capture the requirement ? Or what your recommendation would be?

    Thanks in advance
    Much appreciated

Comments are closed.

Show Buttons
Hide Buttons