Agile Software Development Methodology
Discover how agile software development benefits our customers when it comes to quick delivery, adaptive planning and a flexible response to change.
By using agile software development, we can ensure that you get a flexible approach to planning, improvement via a continuously updated prototype, regular updates on status, and a quick response from us if circumstances change rapidly – for example, feedback from you that a certain feature isn’t quite right. This all ensures that we deliver your project on time and on budget.
Here’s what our agile methodology looks like in practice:
Project management practices
We employ Agile (Scrum), a process framework that has been used to manage complex product development. Our teams can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Our project management practices cover the development of customised software, designed meticulously from the ground up, requiring a blend of consistent, proven structure with project specific creativity.
We follow clear principles of quality software development and use common milestones as a basis for our software development processes. To ensure we get real world feedback as early as possible, we’ll split your project into a number of sub-projects so that you can “go live” in stages.
Keeping your project on schedule
Delivering software on time starts with a well-defined and realistic schedule. To ensure we’re on track we:
- set small, frequent milestones and deliverables so that we have regular, measurable updates on project status and can correct small slips quickly
- schedule the “big rocks first”, and aim to get the most important and potentially most risky features completed early in the project
- track progress diligently on a daily basis over a project extranet, and on a weekly basis in status meetings, so that both you and our team are in tune with the schedule
A concise functional specification
The key to keeping everyone in the loop and making sure the product is something stakeholders will actually buy into is creating a solid functional specification. This doesn’t mean a ton of technical documentation for you to wade through and digest, rather a living document and visual prototype that can change with your feedback or market demands.
The prototype and functional spec are kept up to date and made available to you through our secure project extranet.
Our experience of working with DCSL Software over the last 16 years has been consistently high. They have given us speed to market with exactly the right solution, and complete flexibility to mould this to the requirements of our customers. Read more.'
Neil Beard, Managing Director, i-Cert Ltd
Common development environment
For every project, we define a common environment, so that all members of the development team are using the same platform, the same tools, and a common set of coding standards.
Software quality starts with a comprehensive test plan that verifies functionality, performance, reliability and compliance with requirements. We believe quality is the responsibility of the entire development team, not just the Quality Assurance (QA) team.
We aim to have a working build (prototype) as early as possible in the project and keep it in a working state as we add features; this ensures that the software testers and our QA team can start verification early in the process. We use industry-standard issue tracking systems (Microsoft Team Foundation Server) to track change requests and defect reports throughout the life cycle of the project.
One of the biggest issues in software development is communication – or lack of it. To avoid this, from the very start of the project we:
- designate a single-point of contact
- use a secure project extranet so that everyone involved has access to the latest documentation and latest build for the project
- track project knowledge in a collaborative portal to help monitor the legacy of decisions, and ease the knowledge transfer at project delivery
We also see the importance of sharing knowledge, ideas and best practice internally:
- we make extensive use of our collaborative intranet – so the whole of DCSL can benefit from every team member’s knowledge and research
- our developers take centre stage in weekly meetings to share the latest in technology and innovation, share ideas and come up with new concepts
Meeting contractual commitments
We make sure a tight feedback loop is created between you and the project team to provide transparency in the development process. To ensure your project is on schedule and remains on budget, we:
- communicate the “big picture” to the team so that everyone is motivated towards the common goal
- have daily team meetings to coordinate activities of the team members and bring everyone up to speed on current project status
- use an automated web-based time sheet system so that project managers have daily status reports from team members
- will immediately flag-up if we see something going ‘out of bounds’ for whatever reason – changing requirements, slipping dates, etc.
Change and configuration management
Our Software Configuration Management (SCM) system is a combination of tools, process, and teamwork, ensuring the delivery of higher quality software. Whilst the functional specification is being used as the software project “bible”, in real life changes are needed during development and after release.
Software changes are thoroughly planned, coded, tested and released just like any other software project, whether it is part of a larger project in development, or a change to a live system.
Source code control and version control
For source code and version control we use Microsoft Team Foundation Server, a highly reliable and flexible source code and version control system. All inputs to the project that are not static are version controlled, including:
- source files
- test scripts
- design documentation and requirements documents
- end-user documentation
Our quality assurance strategies combine both black box (manual) testing performed by the Quality Assurance (QA) team, and white-box testing performed by the development team. Our process dictates that it is the responsibility of the developer to produce defect-free code, so that the QA team can focus on assessing the state of the product.
We perform both white box and black box testing because we believe that neither method will uncover all defects. For example, while unit testing and peer code reviews can discover potential vulnerabilities or performance bugs that would be nearly impossible to trace with black-box testing, black box testing can uncover defects such as inconsistencies in the user interface, compatibility bugs, unanticipated error conditions, and timing related bugs that can only be uncovered by manual human testing.