Workflow single sprint agile development team
I will not claim freshness or uniqueness, I wanted to tell in my own words simple material from the side of the description of the benefits of concepts and actions. The thoughtless cargo cult, which is planted on top rarely brings 100% benefit.
Perhaps many who came to IT on their own, and not in their student days through an internship in a large company, became acquainted with various styles of managing a team, or rather, their absence. When left-wing people rush right past the manager with their requests to do a simple task. When the bosses set the task and deadline, completely ignoring the estimates of the developers. When the boss starts yelling, accepting the task, he didn’t ask for it. When you are forced to attend meetings all in a row. When an important part of a task to be developed by another department, it is pushed under the carpet. When the manager begins to look for who is to blame, the deadline for completing the task was 10 times exceeded. etc.
I hope the text will be useful to novice developers, those who are stuck in a stream of random tasks and processes, or small teams without PM, when all functions of PM are shoved onto Timlid, who wants to introduce a little discipline into their working chaos. And they don’t want to read a ton of literature at all.
If you want to calmly develop, then you need to get together, agree and write down transparent rules for interacting with each other. At least the most basic.
Any processes and agreements should be drawn up with the participation of all interested parties, and negatively affecting processes should be destroyed.
I want to paint an example of the basic workflow of one sprint. On the part of the benefits of each element: what actions are performed, what artifacts are present, and why each of them is needed.
Sprint N-1 : Preparatory. Which is not really a sprint.
Before the start of sprint N of the development itself, part of the team is engaged in preparatory work: testing, approval, development, visualization, etc.
Meaning : In order for developers to be able to carry out the task in a qualitative manner, to achieve the required parameters or solve someone's problem, before the development itself begins:
but. thoroughly do all the preparatory work,
b. reduce discrepancies,
at. test on users or get approval from stakeholders,
d. create a detailed visualization.
Output : A set of artifacts and data that satisfy the Definition Of Ready checklist.
If you want to improve the interaction between coders and all other direct participants in the development process, it will be useful to familiarize and explain the basic functions and processes of all participants. Among the coders, there are enough introverts who do not like it when they disrupt their process, but they also need to understand how the rest work so that they do not get the opposite effect. Getting started:
Sprint N-1 start :
OKR, KPI, Stakeholder Requirements , etc. - A set of incoming external conditions that guide development.
Sprint goal N.
Depending on the incoming conditions, where development should move, what parameters need to be achieved, to whom and why to help, the goal of the upcoming development sprint is formed.
Meaning : the goal of the sprint acts as a motivation for the team, an explanation of the meaning of their activities, setting indicators.
In the absence : non-motivated coders are mainly controlled with a whip, mat, fines.
Any team needs motivation so that development does not turn into an endless series of meaningless tasks that it is unclear whether anyone needs. Especially in companies where development is not the basis of the business, a problem often arises when the department is not appreciated, which is why their self-esteem and motivation drop. We need a transparent and understandable goal - to help someone solve the problem, improve some parameters of the business, improve someone’s life. Even in the most wretched company, it’s good to have an awareness of the meaning of their activities.
Backlog grooming - rally or continuous activity. Management of backlog of a limited part of the team.
Meaning : Each sprint has a meeting with a limited composition for cleaning, basic study, initial assessment of complexity and feasibility, decomposition, and prioritization of tasks in the backlog.
Exit : A list of relevant and feasible tasks.
If not : A huge list of Wishlist in the backlog, which no one reads, where the tasks lie forgotten for years.
Sprint planning N-1 - a rally at which part of the training team, based on the purpose and scope of the upcoming sprint N, selects, pre-evaluates and prioritizes tasks.
Meaning : preparation for sprint also requires some order. Resource management is simplified.
Output : sprint N. backlog
Test development
Depends on the style of development and the presence of testers in the team.
Meaning : It is worth having ready-made plans for verifying the health of the code.
I suggest considering 2 options:
In the absence of testers, there is an option to transfer the creation of tests to the development team. In this case, this activity is carried out as part of the development of tasks in the sprint N. According to some reviews, this approach improves the quality of the code written by the developers.
If you have testers, you can use the approach when tests are written before the code. One of the usefulness is that task development ends at the developer, and reduces the chance of returning the finished task from testers when the developer has already switched to another task.
Study Use Case 's - detailed study of interaction scenarios and results within the task.
Meaning : a description of the scenarios of task interaction with text or diagrams improves the understanding of the problem by all interested parties. The low-cost solution can be used to create test cases and prototyping.
In the absence : a low elaboration leads to a divergence of understanding of what is really required of the task; alternative options for use are possible.
Wireframing, mockuping, and prototyping are, by and large, one iterative process for developing an interface visualization, with consistently increasing detail. Starting with the simplest and cheapest option, users / stakeholders are tested to see if the proposed option meets the expectation of solving the problem. Visual testing is so useful in reducing the inconsistency of textual descriptions and very cheap compared to coding that in companies with a strong design and product lobby they began to separate it into a separate methodology with their own processes, artifacts and timetables.
Wireframing - rough sketch of interface elements. A pen on a piece of paper or in software without any frills.
Sense : fast and cheap testing / approval by stakeholders of the task. An additional demonstration of visualization dramatically improves perception than just descriptive text.
In the absence : a divergence of understanding of what is actually being created. Increased development costs.
In the absence of approval : obtain documentary approval when developing for a stakeholder, to minimize the chance of “but I didn’t ask for it.”
Output : Approved / tested draft wireframe.
Mockuping is the second step in developing the visualization of your interface. The increase in detail.
Meaning and Absence : similar to wireframing. Preparation of content for layout.
Exit : approved / tested mockup and layout.
Prototyping is the third step in developing the visualization of your interface. To high detail visualization is added a demonstration of imitation of user interaction with the product.
Meaning and Absence : similar to wireframing and mockuping.
Output : we have a detailed prototype of the product and visualization of the interaction. Plus documentary approval by stakeholders or the result of testing on users.
DoReady = Definition of Ready - a checklist of the conditions agreed upon by the development and pre-training team that will be checked: does the study of the tasks have a sufficient level, the presence of all the required artifacts, so that the task can be accepted into development.
Meaning : the presence of a formal checklist agreed by all interested parties improves understanding and interaction within the team. Everyone knows what and how to pass. You can poke your nose at the checklist and send to finish the negligent workers.
In the absence : “Oh, I almost finished it, it's 95% done.” and ... it will never be completed.
IMHO this is the most important artifact to resolve basic conflicts between encoders and everyone else. It is immediately clear who and how did not finish their work, what they violated, and how it will affect others. It is much more difficult to argue with the written rules than in the case when there is a dispute based on opinions or pressure by authority / position. Although the PM moderator who pokes at the desired item is still useful.
Passed all further:
Sprint N. We begin development.
Sprint Start N :
Definition of Ready, Sprint Goal, List of Initially Assessed Tasks - the conditions (and artifacts) required to start the sprint.
Sprint N planning - a rally at which the development team, based on the goal and scope of sprint N, selects, evaluates, prioritizes and decomposes tasks. Depending on the average speed of the team, a certain amount of tasks is gained.
Sense : the main meeting at which the team checks if the tasks are satisfactorily worked out. Do they correctly understand the tasks set, acceptance criteria. Developers finally evaluate the cost of tasks.
In the absence of : chaos, tasks will be set at any time, by any incomprehensible people, even in the midst of other tasks.
Output : sprint N. backlog
Note: depending on the speed of the team, sprints often take 70-80% of tasks for the sprint goal, and 20-30% of tasks for bugs, technical debt or sudden critical tasks.
Decomposition and assignment of tasks is often a mini-meeting for a development team without extra people.
Meaning : a team with a team lead decomposes the sprint tasks into sub-tasks for a period of no more than 1 day (edge 2). Sub-tasks are assigned by developers depending on their specialization or preferences.
In the absence : it depends on the participation of the team in the process whether the developers will receive interesting tasks that contribute to their development.
Exit : detailing the backlog of the sprint N to 1 day sub-tasks.
Daily meeting - daily short meeting of the development team.
Meaning : Every day, developers must synchronize with each other: who did what and what on the previous day, what they plan to accomplish on the current day, and what problems interfere with the task.
In the absence : no one knows what others are working on, their problems with implementation. Development deadlines are being disrupted.
Output : progress is recorded in the burn down chart - the schedule for completing tasks.
My opinion is that one of the main meanings in the existence of daily rallies is the introduction of discipline. Coders have many introverts who do not want to communicate, do not want to know what others are doing, do not want to spend time on rallies. Hence the rules to stand standing short.
In fact, if the team worked well together, communicates well in a chat and immediately shares any problems, the number of meetings can be reduced by restructuring the meetings in an ongoing process. But do not cut off at all.
The decision of blockers is a direct continuation of the daily meeting.
Meaning : after the developers voiced problems with the implementation of tasks, a discussion is held of the tasks that the team can solve internally, then it goes to the participants, and the blockers with an external solution go to PM.
If not : implementation problems should be resolved together, as quickly as possible so that no one artificially drags out progress.
When the introverts fled in their corners, here you can already discuss the problems and their solutions.
Commits / Code Review - code verification by other team members.
Meaning : 1-2 other team members should look at the new code and approve the quality, style, etc.
If not : increasing the number of errors in the code, low quality and style.
They offer to conduct code review 2 by other developers with different levels, even for juniors this is a good way to learn. One way or another, the team gets an acceptable style, who knows when and who will have to return to the working code.
Deploy to Development server / pre-demonstration - upload code to the development environment / server.
Meaning : any implementation of the task can be uploaded to the development environment and invite interested persons for testing and preliminary approval of the work performed.
If not : at the final demo sprint, you can get into an uncomfortable position by demonstrating a broken or incorrect implementation.
Exit : informal approval of the task.
Anyway, incorrect interpretations of the assignment, or the read criteria of the task, diagonally sometimes get to this stage. The sooner the task is verified and verified, the less often it will be necessary to return to it.
Definition of Done - Similar to Definition of Ready, this is a checklist of the principles by which PM / PO accepts completed tasks.
Sense : created by the development team in conjunction with PM / PO for the predictability of job acceptance parameters. Everyone knows what is the criterion of the task performed and what is not.
In the absence : without clear criteria, “refinement” of tasks appears after attempts to pass them. Or the tasks remain unfinished until the final requirements.
A documentary agreement by which the PM / PO accepts the task and its criteria, approved by both parties. Well reduces the amount of controversial points.
Prevents PM / PO from impudently crushing a post. Cuts off “completed” tasks by 95%. Developers should not finish the completed tasks after the sprint, if the task does not clearly meet the checklist, then it should not be considered accepted, and goes to the future sprint.
Review and demonstration of the product increment - a rally at which developers demonstrate to interested parties the implementation of the sprint goal.
Meaning : developers themselves demonstrate a workable new product increment. PM / PO formally verifies task performance criteria and DoD compliance. Stakeholders decide whether the new product increment matches the Sprint Goals.
In the absence : the absence of a formal demonstration and acceptance of the work performed reduces the value of the acceptance criteria, the quality of the work performed.
Exit : The work of the team is completed. Stakeholders decide whether the next sprint will be at all.
The demonstration by the developer of the completed task is more useful and understandable than impersonating the provision of new functionality to a stakeholder for self-analysis. And the stakeholder sees who did the work for him, and the developers see for whom they were solving the problem.
Collection of reviews - continued Review of the rally.
Meaning : the presence in one place of all interested parties, the team and the product itself allows for informal communication, to collect ideas, suggestions, etc. Get feedback on the quality of the team.
In the absence : the allocated formal time reduces unnecessary contacts between the team and stakeholders during other working hours.
Output : new data, feedback.
Feedback is generally a useful thing, even feedback from stakeholders on their experience with developers. Reason for modifying the processes of interaction with external actors. Improving relations with current and future stakeholders can always be exploited - orders, budget, concessions, etc.
Sprint Retrospective N - A meeting for the development team and PM / PO.
Meaning : discussion of the processes and problems of the team during the last sprint, an attempt to change the processes of work to improve the team. What processes were successful, which did not bring benefits or damaged, what new problems arose and how they can be fixed.
Output : The plan of the process experiment. Processes are modified at the next sprint to evaluate which modifications are useful and which ones should be discarded.
In the absence : planting team development processes from above or lacking them reduces team usability, productivity, and development predictability.
In addition to the banal discussion of problems and how they should be solved, I want to pay attention to the “Plan of the process experiment." Do not treat the recorded processes as carved into stone - unchanging and constant. Add new - test, did not like it - cut it off.
Sprint N + 1 . Pour a new increment into production
Meaning : due to the frequent completion of the sprint at the end of the work week, deploy to the production server and access to users occurs already in the next sprint, so that potential problems do not come out on the weekend.
The increment went to monitor parameters.
If you care about at least some useful things:
but. basic discipline
b. the formation of agreed processes of interaction with each other and allies
at. an explanation of what and how subcontractors do
d. flexibility in process management
e. timely response to emerging problems
then they will improve the working climate in the development team.
Perhaps many who came to IT on their own, and not in their student days through an internship in a large company, became acquainted with various styles of managing a team, or rather, their absence. When left-wing people rush right past the manager with their requests to do a simple task. When the bosses set the task and deadline, completely ignoring the estimates of the developers. When the boss starts yelling, accepting the task, he didn’t ask for it. When you are forced to attend meetings all in a row. When an important part of a task to be developed by another department, it is pushed under the carpet. When the manager begins to look for who is to blame, the deadline for completing the task was 10 times exceeded. etc.
I hope the text will be useful to novice developers, those who are stuck in a stream of random tasks and processes, or small teams without PM, when all functions of PM are shoved onto Timlid, who wants to introduce a little discipline into their working chaos. And they don’t want to read a ton of literature at all.
If you want to calmly develop, then you need to get together, agree and write down transparent rules for interacting with each other. At least the most basic.
Any processes and agreements should be drawn up with the participation of all interested parties, and negatively affecting processes should be destroyed.
I want to paint an example of the basic workflow of one sprint. On the part of the benefits of each element: what actions are performed, what artifacts are present, and why each of them is needed.
Sprint N-1 : Preparatory. Which is not really a sprint.
Before the start of sprint N of the development itself, part of the team is engaged in preparatory work: testing, approval, development, visualization, etc.
Meaning : In order for developers to be able to carry out the task in a qualitative manner, to achieve the required parameters or solve someone's problem, before the development itself begins:
but. thoroughly do all the preparatory work,
b. reduce discrepancies,
at. test on users or get approval from stakeholders,
d. create a detailed visualization.
Output : A set of artifacts and data that satisfy the Definition Of Ready checklist.
If you want to improve the interaction between coders and all other direct participants in the development process, it will be useful to familiarize and explain the basic functions and processes of all participants. Among the coders, there are enough introverts who do not like it when they disrupt their process, but they also need to understand how the rest work so that they do not get the opposite effect. Getting started:
Sprint N-1 start :
OKR, KPI, Stakeholder Requirements , etc. - A set of incoming external conditions that guide development.
Sprint goal N.
Depending on the incoming conditions, where development should move, what parameters need to be achieved, to whom and why to help, the goal of the upcoming development sprint is formed.
Meaning : the goal of the sprint acts as a motivation for the team, an explanation of the meaning of their activities, setting indicators.
In the absence : non-motivated coders are mainly controlled with a whip, mat, fines.
Any team needs motivation so that development does not turn into an endless series of meaningless tasks that it is unclear whether anyone needs. Especially in companies where development is not the basis of the business, a problem often arises when the department is not appreciated, which is why their self-esteem and motivation drop. We need a transparent and understandable goal - to help someone solve the problem, improve some parameters of the business, improve someone’s life. Even in the most wretched company, it’s good to have an awareness of the meaning of their activities.
Backlog grooming - rally or continuous activity. Management of backlog of a limited part of the team.
Meaning : Each sprint has a meeting with a limited composition for cleaning, basic study, initial assessment of complexity and feasibility, decomposition, and prioritization of tasks in the backlog.
Exit : A list of relevant and feasible tasks.
If not : A huge list of Wishlist in the backlog, which no one reads, where the tasks lie forgotten for years.
Sprint planning N-1 - a rally at which part of the training team, based on the purpose and scope of the upcoming sprint N, selects, pre-evaluates and prioritizes tasks.
Meaning : preparation for sprint also requires some order. Resource management is simplified.
Output : sprint N. backlog
Test development
Depends on the style of development and the presence of testers in the team.
Meaning : It is worth having ready-made plans for verifying the health of the code.
I suggest considering 2 options:
In the absence of testers, there is an option to transfer the creation of tests to the development team. In this case, this activity is carried out as part of the development of tasks in the sprint N. According to some reviews, this approach improves the quality of the code written by the developers.
If you have testers, you can use the approach when tests are written before the code. One of the usefulness is that task development ends at the developer, and reduces the chance of returning the finished task from testers when the developer has already switched to another task.
Study Use Case 's - detailed study of interaction scenarios and results within the task.
Meaning : a description of the scenarios of task interaction with text or diagrams improves the understanding of the problem by all interested parties. The low-cost solution can be used to create test cases and prototyping.
In the absence : a low elaboration leads to a divergence of understanding of what is really required of the task; alternative options for use are possible.
Wireframing, mockuping, and prototyping are, by and large, one iterative process for developing an interface visualization, with consistently increasing detail. Starting with the simplest and cheapest option, users / stakeholders are tested to see if the proposed option meets the expectation of solving the problem. Visual testing is so useful in reducing the inconsistency of textual descriptions and very cheap compared to coding that in companies with a strong design and product lobby they began to separate it into a separate methodology with their own processes, artifacts and timetables.
Wireframing - rough sketch of interface elements. A pen on a piece of paper or in software without any frills.
Sense : fast and cheap testing / approval by stakeholders of the task. An additional demonstration of visualization dramatically improves perception than just descriptive text.
In the absence : a divergence of understanding of what is actually being created. Increased development costs.
In the absence of approval : obtain documentary approval when developing for a stakeholder, to minimize the chance of “but I didn’t ask for it.”
Output : Approved / tested draft wireframe.
Mockuping is the second step in developing the visualization of your interface. The increase in detail.
Meaning and Absence : similar to wireframing. Preparation of content for layout.
Exit : approved / tested mockup and layout.
Prototyping is the third step in developing the visualization of your interface. To high detail visualization is added a demonstration of imitation of user interaction with the product.
Meaning and Absence : similar to wireframing and mockuping.
Output : we have a detailed prototype of the product and visualization of the interaction. Plus documentary approval by stakeholders or the result of testing on users.
DoReady = Definition of Ready - a checklist of the conditions agreed upon by the development and pre-training team that will be checked: does the study of the tasks have a sufficient level, the presence of all the required artifacts, so that the task can be accepted into development.
Meaning : the presence of a formal checklist agreed by all interested parties improves understanding and interaction within the team. Everyone knows what and how to pass. You can poke your nose at the checklist and send to finish the negligent workers.
In the absence : “Oh, I almost finished it, it's 95% done.” and ... it will never be completed.
IMHO this is the most important artifact to resolve basic conflicts between encoders and everyone else. It is immediately clear who and how did not finish their work, what they violated, and how it will affect others. It is much more difficult to argue with the written rules than in the case when there is a dispute based on opinions or pressure by authority / position. Although the PM moderator who pokes at the desired item is still useful.
Passed all further:
Sprint N. We begin development.
Sprint Start N :
Definition of Ready, Sprint Goal, List of Initially Assessed Tasks - the conditions (and artifacts) required to start the sprint.
Sprint N planning - a rally at which the development team, based on the goal and scope of sprint N, selects, evaluates, prioritizes and decomposes tasks. Depending on the average speed of the team, a certain amount of tasks is gained.
Sense : the main meeting at which the team checks if the tasks are satisfactorily worked out. Do they correctly understand the tasks set, acceptance criteria. Developers finally evaluate the cost of tasks.
In the absence of : chaos, tasks will be set at any time, by any incomprehensible people, even in the midst of other tasks.
Output : sprint N. backlog
Note: depending on the speed of the team, sprints often take 70-80% of tasks for the sprint goal, and 20-30% of tasks for bugs, technical debt or sudden critical tasks.
Decomposition and assignment of tasks is often a mini-meeting for a development team without extra people.
Meaning : a team with a team lead decomposes the sprint tasks into sub-tasks for a period of no more than 1 day (edge 2). Sub-tasks are assigned by developers depending on their specialization or preferences.
In the absence : it depends on the participation of the team in the process whether the developers will receive interesting tasks that contribute to their development.
Exit : detailing the backlog of the sprint N to 1 day sub-tasks.
Daily meeting - daily short meeting of the development team.
Meaning : Every day, developers must synchronize with each other: who did what and what on the previous day, what they plan to accomplish on the current day, and what problems interfere with the task.
In the absence : no one knows what others are working on, their problems with implementation. Development deadlines are being disrupted.
Output : progress is recorded in the burn down chart - the schedule for completing tasks.
My opinion is that one of the main meanings in the existence of daily rallies is the introduction of discipline. Coders have many introverts who do not want to communicate, do not want to know what others are doing, do not want to spend time on rallies. Hence the rules to stand standing short.
In fact, if the team worked well together, communicates well in a chat and immediately shares any problems, the number of meetings can be reduced by restructuring the meetings in an ongoing process. But do not cut off at all.
The decision of blockers is a direct continuation of the daily meeting.
Meaning : after the developers voiced problems with the implementation of tasks, a discussion is held of the tasks that the team can solve internally, then it goes to the participants, and the blockers with an external solution go to PM.
If not : implementation problems should be resolved together, as quickly as possible so that no one artificially drags out progress.
When the introverts fled in their corners, here you can already discuss the problems and their solutions.
Commits / Code Review - code verification by other team members.
Meaning : 1-2 other team members should look at the new code and approve the quality, style, etc.
If not : increasing the number of errors in the code, low quality and style.
They offer to conduct code review 2 by other developers with different levels, even for juniors this is a good way to learn. One way or another, the team gets an acceptable style, who knows when and who will have to return to the working code.
Deploy to Development server / pre-demonstration - upload code to the development environment / server.
Meaning : any implementation of the task can be uploaded to the development environment and invite interested persons for testing and preliminary approval of the work performed.
If not : at the final demo sprint, you can get into an uncomfortable position by demonstrating a broken or incorrect implementation.
Exit : informal approval of the task.
Anyway, incorrect interpretations of the assignment, or the read criteria of the task, diagonally sometimes get to this stage. The sooner the task is verified and verified, the less often it will be necessary to return to it.
Definition of Done - Similar to Definition of Ready, this is a checklist of the principles by which PM / PO accepts completed tasks.
Sense : created by the development team in conjunction with PM / PO for the predictability of job acceptance parameters. Everyone knows what is the criterion of the task performed and what is not.
In the absence : without clear criteria, “refinement” of tasks appears after attempts to pass them. Or the tasks remain unfinished until the final requirements.
A documentary agreement by which the PM / PO accepts the task and its criteria, approved by both parties. Well reduces the amount of controversial points.
Prevents PM / PO from impudently crushing a post. Cuts off “completed” tasks by 95%. Developers should not finish the completed tasks after the sprint, if the task does not clearly meet the checklist, then it should not be considered accepted, and goes to the future sprint.
Review and demonstration of the product increment - a rally at which developers demonstrate to interested parties the implementation of the sprint goal.
Meaning : developers themselves demonstrate a workable new product increment. PM / PO formally verifies task performance criteria and DoD compliance. Stakeholders decide whether the new product increment matches the Sprint Goals.
In the absence : the absence of a formal demonstration and acceptance of the work performed reduces the value of the acceptance criteria, the quality of the work performed.
Exit : The work of the team is completed. Stakeholders decide whether the next sprint will be at all.
The demonstration by the developer of the completed task is more useful and understandable than impersonating the provision of new functionality to a stakeholder for self-analysis. And the stakeholder sees who did the work for him, and the developers see for whom they were solving the problem.
Collection of reviews - continued Review of the rally.
Meaning : the presence in one place of all interested parties, the team and the product itself allows for informal communication, to collect ideas, suggestions, etc. Get feedback on the quality of the team.
In the absence : the allocated formal time reduces unnecessary contacts between the team and stakeholders during other working hours.
Output : new data, feedback.
Feedback is generally a useful thing, even feedback from stakeholders on their experience with developers. Reason for modifying the processes of interaction with external actors. Improving relations with current and future stakeholders can always be exploited - orders, budget, concessions, etc.
Sprint Retrospective N - A meeting for the development team and PM / PO.
Meaning : discussion of the processes and problems of the team during the last sprint, an attempt to change the processes of work to improve the team. What processes were successful, which did not bring benefits or damaged, what new problems arose and how they can be fixed.
Output : The plan of the process experiment. Processes are modified at the next sprint to evaluate which modifications are useful and which ones should be discarded.
In the absence : planting team development processes from above or lacking them reduces team usability, productivity, and development predictability.
In addition to the banal discussion of problems and how they should be solved, I want to pay attention to the “Plan of the process experiment." Do not treat the recorded processes as carved into stone - unchanging and constant. Add new - test, did not like it - cut it off.
End of Sprint N
Sprint N + 1 . Pour a new increment into production
Meaning : due to the frequent completion of the sprint at the end of the work week, deploy to the production server and access to users occurs already in the next sprint, so that potential problems do not come out on the weekend.
The increment went to monitor parameters.
Conclusion (TL; DR)
If you care about at least some useful things:
but. basic discipline
b. the formation of agreed processes of interaction with each other and allies
at. an explanation of what and how subcontractors do
d. flexibility in process management
e. timely response to emerging problems
then they will improve the working climate in the development team.
All Articles