Back to Blog
An 'Agile' Visualfiles Development Team – What Does It Mean? article image

An 'Agile' Visualfiles Development Team – What Does It Mean?

Post by |

Software development is a weird and wonderful world – on the one hand we are working to innovate, excite and transform; on the other hand, we also need to develop a consistent, robust and stable product. The question is how do we make sure that we are doing justice to both imperatives? More importantly, how do we make sure that we are giving our customers what they need from the product?

A developer’s day typically consists of balancing several things – current work, requests for help from Support on behalf of customers, demands from the business including Professional services and other developers. There is also the outstanding backlog, which often is a long list of all the outstanding enhancements, defects, maintenance work and so on.

Many of these challenges have disappeared and the balancing act has become a lot easier since our adoption of an "Agile" approach to Visualfiles development and support. This methodology has enabled us to establish a structure such that everyone – especially customers – has a voice. Every stakeholder is part of the software development process and is continually involved, inputting and feeding back on developments to all relevant parties.

So, Support advises on customer priorities, Product Management on business priorities, and Quality Assurance and Development on team priorities. All perspectives are taken into equal consideration. Our Team Foundation Server (TFS) keeps track of all the decisions and priorities, which are dynamic, and all parties have visibility of the changes. The actions performed and feedback received then inform the next change to the list. The cycle of improvement continues. For example, recently a customer’s Visualfiles system went down following a server migration. Support needed Development assistance. Resolving a system that is down for a customer is the highest priority; the list in TFS was immediately adjusted with lower priority and general development items paused. We helped resolve the problem within hours, post which the lists returned to the previous version and any lessons learnt were already recorded in the Support knowledgebase ready to assist in the future.

And this approach is not just restricted to day-to-day activities. To continuously improve, we need to be trying new things, and to do this, we need to learn. Through "Agile" we are growing and forever improving the way we do things, and this goes for product, process, and even the team itself.

There's an abundance of online articles, books, seminars etc. on the "Agile" approach to software development, but our key take-aways at LexisNexis are:

  • Communication is a two-way street – ensure that you talk to your customers – both internal and external - and encourage them to do the same.
  • Your developing and working practice is your own – what works for your organisation might not for another.
  • To be "Agile" you need "continuous improvement" – always look for that next change.
  • Research and train – as knowledge improves, so will your Development team’s effectiveness.

If you are a customer or a Visualfiles developer and you are looking for more information on our "Agile" software development approach, please contact your account manager for more information. They’ll be happy to help. Also, for a QA perspective on "Agile", you may find this blog interesting: Building quality in software with Agile.

About the Author:

Stefan Leggett is a Software Engineer at LexisNexis Enterprise Solutions. With the company for over nine years, Stefan initially started in the Visualfiles Support team, progressed to become a Senior Support Analyst, and now works as a member of the Visualfiles Development team.

| See all our contributors
Back to Blog