This is a great question..!

Here at DMS Navigator, we develop Dealer Management Software which will run most of the core functions of a car, van, motorhome or caravan dealership.  It is highly complex and has a large no of features.    

But how do we actually develop our software?

Software developers use various phrases such as waterfall, agile, scrum, sprint etc...

But what does that all mean?

How do we develop software at Navigator?

‍

What is the process?

Let Simon Verona, our Managing Director, explain.

The development process begins with something called a "backlog". This is actually just an ordered list of things to do. It is constantly reprioritised and shuffled.

The backlog takes input from

Helpdesk - bugs generally

• Customers - user requests and statements of work (a specific request to do something for that customer only)
• Partners - interfaces with their systems and processes
• Franchise Oems - oem dealer interfaces
• Internal  Product Teams- items driven by our research of customer requirements.
  

Every two weeks we define what we call a Sprint. This is simply a process of generating a list of work for the next 2 weeks, defining how long each takes and allocating to developers.

The developers then get down to work!

At the end of the two weeks we see what we've done and build a software release. Each release is given a number scheme such as 22.21.0 which is the results of sprint 21 in 2022,the zero is the initial release. This may change if we put in minor big fixes.

The release is then put into a two week test phase.

We test specific updates and also what we call a regression test. This is a process where we test about 100 key daily functions to check they work as expected... It's not exhaustive - it's impossible to test everything!

Once the test team sign off the release, any documentation is done and we pass the release to be distributed to customers

It's sent to a handful of customers to check there are no major issues. Any bugs at any point that are "critical" are fixed immediately in the current sprint and a new minor release may be created eg 22.21.1 22.21.3 etc.

After that, the release is pushed to all customers on a two week timeline.

Meanwhile by then we have 2 more releases that have been completed and in the test/release pot.

So software ripples out in a two weekly cycle.

At the customer end, the update is pretty boring. The new software installs whilst it's being used and a note appears on screen that an update is required. The user can choose to restart to run the new release or can simply wait till he next logs on when the new version updates.

The benefits here are that we can deliver updates from request to a customer in 4-6 weeks if there is an urgent requirement.

Bugs can be fixed and those distributed in a 24-48 hour cycle if needed.

It also means that most critical bug reports (yes there is no denying we get them!) relate to software developments done in the prior month which makes them easier to track down and fix!

The development cycle means that our customers get new software updates quickly, and are kept up to date with the break-neck speed of development nowadays.

‍