Who we are
Xelleron was founded to address a growing need for stable, secure, easily customisable enterprise business software. In an ever changing world businesses need to be nimble and they need the right tools to take advantage of these new opportunities.
We created the Xelleron Framework to meet exactly these needs. Our framework allows for easy transition of your business processes from legacy spreadsheets and documents or other out-dated solutions. Transforming these processes into a modern and agile framework which scales, is secure, which can reduce your risk as well as bringing efficiency benefits and potentially expanding your market reach.
Our Mission
To enable businesses to transition to a modern economy in a fast, practical and cost efficient way. To enable them to grow their business and give them more control over their own business processes.
Our Vision
No one knows your business the way you do. Our vision is to enable you to implement your visions! To provide a framework upon which businesses can rely and one which is easy for them to extend themselves.
Our Values
Xelleron is a equal opportunity company which fully respects the rights of every individual. We hold ourselves to the highest professional, ethical and moral standards. We take great pride in delivering high quality products and giving responsive, informed and friendly customer support.
A few of the faces behind Xelleron
Mark Jeacocke
Mark has over 25 years of experience in software development and design of business solutions. After graduating with an Honours degree in Electrical Engineering and a Bachelor degree in Science, he was a co-founder, senior developer and architect for Avand before its sale to Technology One in 2007. There he was instrumental in developing their leading document and information management system which was used widely throughout local government.
He also authored CANDi, a program developed for Thesis which gained recognition when it was nominated for an Asia Pacific IT&T award, and a lane management System for Vic Roads which was used on their M1 and M80 upgrade projects. More recently he was a co-founder and lead architect on a market segmentation analysis tool for Sales Miner.
Stefan Slomka
Stefan has completed a PhD in Electrical Engineering where he researched machine learning and statistical pattern recognition, specialising in speaker verification. In addition to a number of technical papers he has authored in this domain, he is also a published researcher on the application of image processing for identifying potential cancer targets.
Stefan brings over 20 years of business software development experience. Along with his experience in the machine learning and high performance computing areas, he has spent the last 10 years building enterprise grade budgeting, data quality and workflow automation solutions. The products he has worked on are in use by enterprises ranging from small businesses right up to the largest global resource companies.
What to expect next?
Our projects typically have at least two phases: Initial Scoping Activities followed by Solution Development.
It is common that an initial release of the Minimum Viable Product (MVP) be made as quickly as possible so that you can start to obtain value from the solution.
Example Activities:
- Set up a Trello board with a series of cards where each card contains 1 or more requirements/features you would like in your solution.
- Setup a communications channel with discord or a mechanism on your choice (e.g. MS Teams/Slack) so that our teams can communicate with each other.
- Use the Trello board to develop some initial estimates and an initial execution plan.
Outcomes
Initial estimates and an initial execution (Sprint) plan at least up to the MVP release. After phase 1, you should have a better documented understanding of your requirements.
Once the initial plan is created, we will develop the solution using an agile methodology working closely with your team to deliver a solution to suit your priorities and budget. Using this methodology your solution will be build using a series of sprints aimed at completing Trello cards until you are happy that the solution is ready.
At the beginning of a sprint we will work with you to select cards for development in that sprint. Each sprint will then aim to implement the cards selected for development. If there is additional time (tasks are done faster) additional cards may be added to the sprint. If there are technical issues with cards in a sprint then this will be discussed with you to work out how best to proceed. At the end of each sprint we will aim to demonstrate to you some of the features implemented in that sprint. We will also aim to put updates on the test server for you and your team to try out as features are implemented.
Sprints (Typically 1-2 weeks in duration)
- Prioritization & Card Assignment
- Development
- Demonstration
This agile methodology is aimed at giving you a high degree of visibility into progress, control over your priorities and spend as well as making the overall build efficient and fit for your purpose. It does require active participation from your team however for it to work effectively.
If your solution is a portal, we typically aim to have a solution with at least a subset of the features ready for you and selected team members to log into early on (typically after the first or second sprint). This is to allow you to try the implemented features and provide feedback as soon as possible.
It is quite common that as the solution is being created and you start to try it out you may want to add extra cards, deprioritise modify or remove some cards etc with the aim of producing a better outcome.
Once you are happy with the progress of the solution, your team will need to do acceptance testing to ensure you are happy with what is contained in your solution and are ok for the solution and to be released to production (go live).
After this initial solution (MVP) release, additional functionality can be added as desired in subsequent sprint – acceptance test – release cycles.
Notes
We will produce initial estimates as part of the Phase 1 Scoping activities. In the event we detect that the estimates are likely to change (e.g. unexpected technical issues, additional requirements, client feedback etc) we will notify you promptly and work with you on the best way to proceed.
We try and reuse as much as we can from our existing library and components.