We strictly follow Agile in the way we deliver to guarantee we are people and results oriented. And being cloud-native means that we can build and demonstrate as we go, to add value to our customers forward.
Our model encourages your business analysts, product owners and team members pair with SSR team members, work along-side to collectively build a great product. We follow test-driven development, short development sprints, and continuous verification and integration of code. The end result is high quality, flexible software delivered cost-effectively.
A flexible platform for seamless collaboration.
Create the team's with perfect high-level overview on a no-code platform to see all of your ongoing work at a glance.
Every assignation is run and delivered by hybrid, multidisciplinary teams. Subject matter experts with balancing skills working together, in collaboration with you, to deliver the best outcome for your business.
We constantly work as a team with our clients, making it our business to know and understand your organisation so we can deliver you the best possible solution
Each workday begins with a brief team stand-up meeting to discuss what you did yesterday, and what you plan to do today, if any impediments, how and who will be dealing etc.
The meetings are usually timeboxed to between 5 and 15 minutes, and take place with participants standing up to remind people to keep the meeting short and to-the-point. The stand-up meeting is sometimes also referred to as the "stand-up" when doing Extreme Programming, "morning rollcall" or "daily scrum" when following the scrum framework.
We follow standard 2 weeks sprint plan. The scrum master leads the team through the backlog items during the Iteration sprint planning session. Business analysts or Product owners explain the tickets, Team members collaborate to clarify items and ensure consistency and provide story points. Scrum master sets up a sprint goal.
What. The team decides what can be done in the coming sprint and the goal of the product owner is to describe the objective of the sprint and define backlog items that contribute to that goal. How. It is about planning the work necessary to deliver the sprint goal. The final sprint plan is the result of negotiations between developers and the product owner. This result should be based on value and effort.
Who. Agile Spring planning cannot be carried out without the participation of the product owner and the development team.
Inputs. This is about a product backlog that is a good starting point for any sprint plan. It provides a list of items that could potentially be part of the current sprint. Outputs. The most valuable outcome of the planning meeting is describing the goal of the sprint and how the team will start working toward that goal.
The Scrum Master encourages the rest of the Scrum Team to improve its process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with product or organizational standards.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
As we begin to build a product, we employ Test-Driven Development (TDD): we write tests that assert the application can do what we want it to do. We do this before we build the functionality. A piece of code or functionality isn’t done until it passes the test.
Copyright © 2021 SSR Technologies - All Rights Reserved.