Custom Software Development
The Engagis Software Development team offers cost effective and efficient delivery of services due to a unique combination of expertise, skills, hardware knowledge and our in-house team. We have developed over 200 software applications for companies such as Telstra, Sheridan, Blackberry, Westpac, Bupa, Country Road, Amcal, Target, Bank of Queensland and Core Logic.
Engagis uses AGILE development methodology SCRUM as the preferred approach for delivering all software solutions.
In a world of constantly changing requirements SCRUM delivers the lowest risk, highest value and the fastest way to respond when developing software.
Download Engagis App Engine overview
Engagis App Engine & Agile approach
Our staff are trained in SCRUM and are passionate about delivering software the “Engagis way” through our App Engine. We use cloud based software, called JIRA, to manage the requirements for software projects. JIRA has been customised to support our AGILE development approach.
Agile development grew in response to challenges and limitations of traditional waterfall development practices. Traditional software development approaches have high failure rates and SCRUM counteracts this trend. It provides a framework for delivering requirements incrementally, whilst maintaining a focus on the rapid delivery of business value in a collaborative and customer focused approach.
Agile development accelerates the delivery of initial MVP (Minimum Viable Product) allowing customers to benefit from earlier product releases. A process of continuous planning and feedback ensures that the benefits from the lessons learned are continuously maximized throughout the development process. It also ensures that software teams can continuously align the delivered software with business needs. A key outcome for Agile is the ability to adapt to changing requirements.
Ultimately, Agile drives better business outcomes by developing features aligned with customer needs.
Benefits of Agile
Speed to market
At the end of each sprint a potentially shippable build is created. After the 80% of the sprints have been completed is may be decided that the project goals have been meet and the project can enter the release phases without delivering the remaining features, Allowing for the optional time to market. Projects may even run several release phases in between sprints
Response to change
In traditional development projects, we write a big functional specification. Changes become complex and expensive to administer. With agile development, change is accepted and assumed. With Agile the timescale is fixed and requirements emerge and evolve as the product is developed. Agile requires stakeholders who understand this concept and make the necessary tradeoff decisions, trading existing scope for new.
Agile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself. Agile helps to ensure that expectations are effectively managed.
Small incremental releases ensures that issues are visible early and make it easier to respond to change. The clear visibility ensures that decisions can be taken at the earliest possible opportunity, while there’s still time to make a material difference to the outcome.
Short feedback loop
A key characteristic of agile development is getting feedback on features as early as possible This allows additional improvements to be added to the scope if necessary, allow the quality of the product to be reviewed throughout the development process.
Better business engagement and customer satisfaction is achieved through: active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed. This is an important benefit that promotes positive and enduring working relationships.
With traditional software development processes the product does not always deliver the benefit that is expected. A Short feedback loop allows requirements to be updated in response to feedback during the sprint demo. In agile development, the emphasis is on building the right product.
The iterative nature of agile development means features are delivered incrementally. Benefits are realised early as the product continues to develop.
The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.
The Engagis App Engine Process
The success of a sprint is directly related to the quality of a project scoping. It consists of capturing customer requirements determining and documenting a list of specific project goals, deliverables, tasks and deadlines. The purpose of this activity is to define and describe elements within scope of the release in order to clearly understand what will be the area under the project control. Elements not described are considered to be out of scope of the release. Furthermore, the scope of the project provides a view of the number of sprints required to meet the requirements of the project. Outcome of the scoping session is a Functional Specification document (FSD), a formal Quote and JIRA backlog (all user stories).
Software Development Sprints are defined as a two week period, in which the Engagis Design & Development Team delivers, and makes ready for review, a specific set of work (Sprint Backlog).
Each sprint begins with a planning meeting (Scoping Session), defining the actions and criteria (User Stories) to be met at the completion of the sprint.
During a sprint, the team holds daily standup meetings to discuss progress and brainstorm solutions to challenges. This agile approach underpins the success of the Engagis Design & Development Team, by providing Engagis and the client a continual feedback loop, defined delivery times, and reducing upfront
The following are the ground rules:
1. Once the sprint begins, you cannot add requirements or stories to the sprint backlog.
2. User stories should be mature enough to describe the entire Scope before they are added to the backlog. The backlog is a set of mature / refined user stories.
3. The user stories do not need to be 100% complete before the sprint is started, but it needs to be detailed enough to describe the entire product scope.
4. The product backlog is created and prioritised with the customer.
5. The sprint duration is 2 weeks (as per the diagram).
6. Team capacity per Sprint is 40 points. That is an equivalent of one simple login form (full integration with front and backend). This is with a team of 2 x developers, 1 x tester, 25% x of the Business Analyst, 20% x of the Technical Lead.
We use the following tools throughout this process:
JIRA – for user stories and acceptance criteria, including Sprint management.
Confluence – documentation and wiki
Netsuite – cases related to deployed solution from the technical support team.