Software Development has been traditionally managed in the Waterfall model or spiral/iterative models. In the Waterfall model, each stage of the development had to be completed before the next stage could be initiated.
First Design, then development, then testing. At the end of each stage, an evaluation process had been conducted. If needed, the process would go back to previous stage to fix the issues.
These evaluation points were kind of debriefings and reviews for what happened up to that point.
However, the lengthy stages were met with dissatisfaction from stakeholders. When the first products of development arrive, after months, the stakeholders would have had opinions for re-design.
With the spread of other iterative methods, the Agile method got its grasp on the high-tech industry. The idea behind the Agile development process is that "control points" are set and fixed all along the process in short-time periods.
This way, stakeholders can provide feedback and the developers or the people who work on the product can respond more quickly, with more agility. One of the most popular implementations of Agile is the Scrum method.
I won't go into full detail of the Scrum method but I'll focus on the ceremonies. Each team that implements Scrum conducts some ceremonies that assist with planning, daily review of status and retrospective meetings.
At the end of each development sprint, which usually takes 2 weeks and includes design, planning, developing and testing of small subset of the product specs, the retrospective ceremony takes place. In this ceremony, the team members perform a debriefing of the past 2 weeks:
- What went well?
- What went wrong?
The major focus is on the team's work, The review does take into account external influences ("the deign team made a lot of errors, the DevOps didn't give us enough servers"). But, the real deal is reviewing the team's internal work, co-workers communication, adherence to procedures, etc.
Team members are asked to raise problems and solutions.
The retrospective is a crucial part of the process and without it, same issues and problem re-occur again and again. In IBM XIV GUI team, at stressful times, such as prior to product launch, some of the scrum ceremonies were postponed in order to give people all the time they need to work.
However, we would have never skipped the retrospective, especially in stressful times. This debrief is important in keeping the team's work efficient and to allow quick solutions for one-time and recurring issues.
First Design, then development, then testing. At the end of each stage, an evaluation process had been conducted. If needed, the process would go back to previous stage to fix the issues.
These evaluation points were kind of debriefings and reviews for what happened up to that point.
However, the lengthy stages were met with dissatisfaction from stakeholders. When the first products of development arrive, after months, the stakeholders would have had opinions for re-design.
With the spread of other iterative methods, the Agile method got its grasp on the high-tech industry. The idea behind the Agile development process is that "control points" are set and fixed all along the process in short-time periods.
This way, stakeholders can provide feedback and the developers or the people who work on the product can respond more quickly, with more agility. One of the most popular implementations of Agile is the Scrum method.
I won't go into full detail of the Scrum method but I'll focus on the ceremonies. Each team that implements Scrum conducts some ceremonies that assist with planning, daily review of status and retrospective meetings.
At the end of each development sprint, which usually takes 2 weeks and includes design, planning, developing and testing of small subset of the product specs, the retrospective ceremony takes place. In this ceremony, the team members perform a debriefing of the past 2 weeks:
- What went well?
- What went wrong?
The major focus is on the team's work, The review does take into account external influences ("the deign team made a lot of errors, the DevOps didn't give us enough servers"). But, the real deal is reviewing the team's internal work, co-workers communication, adherence to procedures, etc.
Team members are asked to raise problems and solutions.
The retrospective is a crucial part of the process and without it, same issues and problem re-occur again and again. In IBM XIV GUI team, at stressful times, such as prior to product launch, some of the scrum ceremonies were postponed in order to give people all the time they need to work.
However, we would have never skipped the retrospective, especially in stressful times. This debrief is important in keeping the team's work efficient and to allow quick solutions for one-time and recurring issues.
אין תגובות:
הוסף רשומת תגובה