Agile Scrum Methodology
We use Agile Scrum Methodology. Why? Because with tight client communication and collaboration at its heart Agile Scrum is flexible, is fast and it gets better results than other approaches.
Extremely popular with both clients and developers Scrum Methodology shares a set of immutable, predetermined roles, responsibilities, and communication methods.
A methodology that not only enables clients to prioritise requirements, to include evolving ideas in even the most complex of requirements but also, with the right kind of expert input from the Kaleida team, deliver reliable, advanced problem solving software solutions.
Why Choose Scrum?
Scrum methodology supercharges the agile development philosophy by applying concrete processes, combined with project momentum, to plan and schedule releases.
Short development cycles, known as sprints, allow a project’s direction to be adjusted or reoriented based on completed work.
Stakeholders and team members meet at the end of each sprint cycle to assess progress and plan the next steps.
Scrum Development Roles
The Product Owner is responsible for communicating the client’s vision — their key requirements and priorities — to the development team.
The Scrum Master liaises between the Product Owner and the team, working to remove any impediments obstructing the goals of the sprint cycle.
A Scrum Team consists of cross-functional skills, typically a mix of software engineering, architecture, programming, testing, and UI design.
Development Practices
A Microsoft Partner for over a decade, our experience is extensive. And because we understand that business requirements continually evolve, that goalposts shift, we know how to deliver solutions to evolve, to shift, with them.
A proven development process. A process that sidesteps the typical pitfalls of bespoke software development with QA ensures that projects are meticulously specified, delivered on time and delivered to budget.
Versioning and Revisions
All new projects are set up with source code control in SubVersion and continuous build using CruiseControl. Unit and Integration Tests are created, and run each time the build is triggered by code check in.
An internal Test Environment is set up as standard and we frequently host the UAT and Live systems for our clients.
- C#
- .Net
- MVC
- SQL Server
- Once changes are tested and approved, the infrastructure team implements the change on UAT and updates the appropriate build/DR document.
- Once this has been approved the infrastructure team then rolls out the changes to Live and update the documentation.
- The development team does not make any changes to the UAT or Live infrastructure – all such changes are done by the infrastructure change control.
- In a similar way, software releases are done in a formal fashion. Each environment is only released once the changes have been signed off in the preceding environment.
- Releases are logged and automated as far as possible to minimise the potential for user error and to ensure that the same changes are made on all environments.
- All systems are therefore recoverable by following the server build documentation followed by a release of the latest software along with restoring any required data.
