• Home
  • Contact Us
  • Approach
  • Solutions
    • Software Services
    • Frameworks
  • More
    • Home
    • Contact Us
    • Approach
    • Solutions
      • Software Services
      • Frameworks
  • Home
  • Contact Us
  • Approach
  • Solutions

The approach we follow

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.  

Teams Collaboration

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 


Daily Stand-ups

 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.


Planning

 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. 

  • The PO defines the goal based on the value that they seek. 
  • The development team should attend the event to understand how they can or cannot deliver that goal.

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. 

Retrospective

 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. 

Test Driven Development

  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.

  • Contact Us
  • Privacy Policy
  • Approach
  • Software Services
  • Frameworks

This website uses cookies.

We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.

DeclineAccept