Agile Methodology approach
The area of process engineering in Temperies is formed by people with extensive professional experience in diverse projects both in private and public environments, as well as an extensive academia experience in the area of software development methodology. In Temperies we seek two premises based on the experience:
-
It is necessary to define a process shared by all members of the organization in such a way as to ensure the proper development of projects regardless of technical, human and environmental characteristics of it.
-
There is not a perfect methodology, there are methodologies which are appropriate to particular projects.
Motivated by these premises Temperies staff decided to use the agile methodology, SCRUM, as working framework because it provides a structure without adding unnecessary work. For each project it outlines which documents and process activities are necessary and add value to our work.
Our daily work is defined by the activities of scheduling, executing, reflection, and the basis of the methodological strategy: self-organization, collaboration, prioritization, time boxing.
Self-organization concerns the team finding the best way to carry out the project successfully and in consideration of the result of the reflection process making the necessary adjustments to improve. The rules are not enforced but the team finds them and defines them accordingly to the best productivity.
Collaboration indicates that all the project participants shall make the effort to collaborate with the rest of the team as to avoid possible impediments in the development.
Prioritization refers to all the efforts carried out in the project must be prioritized by the Product Owner and the working team, considering the different points of view according to the value of business and technical needs.
Time Boxing, a duration is defined for each of the sprint (in Scrum fixed time spots are called sprints, which performs the tasks involved at the beginning of the process) and the corresponding deadlines, even though the committed functionality could not have been delivered.
learn more about our
quality
At the beginning of the project the "vision" and Product Backlog is defined, this is the master list of the features within the product. It contains both user focused requirements and technical focused requirements.
During the Story Time the Product Backlog, the approximate User Stories (requirements, both functional and nonfunctional ones are described through assertions involving the role, functionality, and the acceptance status) the "vision" of the project are taken into account and as a result of the activity more defined user stories are obtained and a more accurate Product Backlog.
At the beginning of each "sprint" the Sprint Planning Meeting is carried out and the user stories set in the product backlog are prioritized and selected for the next sprint. The objective of the sprint is defined by the product owner and team
During the Sprint a Daily meeting takes place in which in 15 minutes and standing up the staff shall answer three questions:
- - What have I done since the previous meeting?
- - What will I do from now on to the next meeting?
- - What impediments do I have?
The Scrum Master is who manages the list of impediments, and administrates their solution.
At the end of the Sprint, a flashback is done to analyze its results. The process is inspected and adapted, the team and scrum master discuss what works and what can be improved.
Follow Us
