Software development is an unknown process for many of our customers. It occurs in the dark rooms of our company, where mysterious people with job titles such as "Software Engineer" do strange things on computer screens and talk in acronyms.
So, how is great software actually produced ? How does the sausage machine we call Software Development work ? Let's look under the hood at DMS Navigator....
Software Development is a constant shuffle of what we call "Product Backlog Planning". Everything that requires one of our developers to do something is represented by a Product Backlog Item.
These may come from a variety of sources.
They may be in the form of bug reports from our helpdesk, enhancement suggestions from users, more specific requests from customers (we call them Statement of Works), generated internally (for example a new sub module) or from our franchise and supplier partners.
We work using an "Agile" methodology, which means that our software team plan in short "sprints" - which in our case last 3 weeks.
At the beginning of each Sprint, we pick a number of Product Backlog items in current priority order- all of which have had time estimations and priorities attached to them - and allocate them to the development team for the next 3 weeks work.
Time Estimation in software development is very much similar to time estimation in a car workshop. There may be a request to repair a rattle when going over bumps. This may be a 5 min job to tighten a bolt or a whole day to strip down and repair the suspension - or anything in between.
Like loading a car workshop we work on the basis of averages - "When we estimate something will take an hour, on average we may find that hours estimate actually takes a shorter or longer time ". Even so, getting the loading correct is difficult and in reality we overload, simply reallocating incomplete items to the next Sprint when it is scheduled. This explains why sometimes an item can be scheduled for a Sprint but not delivered at the end.
At the end of the Sprint, we build a new version of software which we decide whether we will release or not. Only about one in two sprints ends up with a release that is sent to customers in bulk. Many are optional releases, sent only to customers who will benefit. In either case, there is a lag whilst the software is tested and any user documentation is created.
Any specific software release will contain probably about 40% of bug fixing (any software company that claims not to have any bugs is lying!!) , 40% of enhancements and 20% of customer specific statement of works. By definition, any customer who gets the release will likely not notice most of the bug fixing (unless they have a critical issue which is fixed by the release) or Customer Specific items (unless they are one of the customers who have some work done for this). Of the enhancements, many of these will be specific to certain customer environments - eg franchise specific, or specific to certain use cases.
Therefore, to any customer, the software doesn't appear to change much from week to week and month to month. Every now and then though, there will be major updates or new add-ons which benefit all customers.
However, the key is that over time, these accumulate. Customers have short spells of learning new features and implementing new developments but they can have the satisfaction that they are keeping up with other dealers who are buying "new" versions of systems.
In the past year, we have had less bug reports as the use of our software has been significantly reduced. The same goes for Statement of Works. This has meant we have been able to focus the whole development team 100% on creating enhancements to our software and this has enabled our customer's in turn to deliver great service and sell both online, and in person through the lockdown process and as we re-open.
Find out whether Navigator is a good fit for your dealership. Spend 30 mins with one of our Consultants in a no pressure environment. Click the button to book a Zoom Call
Book a Discovery Call
.jpg)
