Learn, do, earn with Dynamics 365 - Session 6

I started by speaking about the 2 most common methodologies we use in IT projects.

Waterfall, or the traditional way of doing projects meant you had a detailed speck on what you had to build, you then went away for like 6 months, one year or more, to build the thing. By the time you show the product to your client, time passed, things changed and sometimes you got this reaction:

Now, I'm not saying that all waterfall projects are like that. Some fixed price smaller projects can be in fact very successful in this approach, but I feel like a good business analyst and a strong project manager are crucial assets for this type of projects.

Agile is the most common used methodology today. If you click on the link I provided, you will find out more about the technicalities of Agile. So I won't bore you with those, you can just look it up.

But this is what I will mention - Agile software development means collaboration. It all starts with a big bucket of work the team has to do.

A product owner sets the priority and the team commits to a certain amount of work for the next 2-4 weeks(also known as a Sprint). At the end of this period, the software should now be packaged and in a releasable state, so the users come into scene as well.

As part of our Agile Sprint there should always be a demo step, where the users are briefed with what's coming.

In a Dynamics 365 project, the users are our customers and without their involvement, our projects will not be successful. I think this article's picture can be an accurate description of a project if we are not careful. When we develop in isolation and don't involve the actual users, not only will the functionality be unfamiliar to them, but we might develop things they don't even use, or we'll build in the wrong behavior.

Gone are the days where a project was considered a success if it was on time and on budget. Now, we take a real look at how many features are actually being used. About a month ago I gave a talk about the importance of user adoption and collaboration. This was a very popular slide:

We don't want users returning to their massive excel spreadsheets.

This brings me to the last subject we discussed in this session: BDD.

BDD, or Behavior Driven Development is a software development technique that I think can be successfully applied if you are a functional consultant as well.

I stole came up with this idea from Wael Hamze's articles on BDD for Dynamics 365 CE.

As you can see in Wael's articles, BDD is very user-centered, it defines the systems with scenarios and examples. All functionality is described in Gherkin language, using a Given - When - Then format.

There are many examples of how to build scenarios. As anything, it comes easier with practice. At my company, I am very lucky to work with great people and the test manager is working constantly to ensure Gherkin being used for most of our user stories.

Here's my example as well (very mature, as usual)

In the end, you'll find the best way, methodology and framework for your project, but keep your eyes open. Don't be fooled into believing technical skills are enough.