ScrumBut in the analytics team: before takeoff
Hi, Habr! My name is Zhenia. I am a systems analyst at NORBIT and a novice Scrum-master. I have been eyeing Scrum for a long time in order to study, try and evaluate its capabilities in our team of analysts. And so, after a light kick of an inspiring conversation with the RP, I understood: stop thinking, it's time to do it.
In this article I will tell you about our experience of preparing to use limited Scrum on behalf of the Scrum master: what we did to start. At the time of this writing, the 15th sprint has been completed. Flight is normal!
I often heard about the use of the Scrum framework in teams whose members are not developers. Teams of different expertise actively join Agile. I thought that Scrum was originally created for development teams of the full cycle, and therefore there are a number of difficulties or interesting points that you should pay attention to if the team differs from the reference one, the one that the creators thought about. I highlight the teams in the direction of expertise and the degree of participation in the product development cycle. The direction of expertise, in my opinion, does not limit the use of Scrum. But the degree of participation in product development may limit. Some may perform a full cycle of work on the product, being responsible for the final result available to the customer - and in my opinion, you can use a full-fledged Scrum in such teams. And others - perform only part of the full cycle, being part of the work chain. In this case, there may be issues and difficulties with a full Scrum. Such a project situation may require a compromise approach.
In this article we will discuss the team responsible for the part of the product development cycle and the preparation for the launch of ScrumBut in it.
Our action plan for the launch was:
At first I googled and got:
Those. ScrumBut is a limited scrum. This variation of the framework allows you to take everything you need from Scrum and not take what we think is not required. Of course, this is a slippery track, because To understand what is necessary and what is not required, it is important to have an idea of the classic Scrum, it was important for me to understand why this is included in the full version.
Useful for me in the hardware turned out to be:
To begin with, I took advantage of my vision and made a few points for evaluation by managers.
Collected the opinions of team members and recorded them.
We have two lists: what we have at the entrance and what we want to get.
This will make consolidated and generalized lists.
At the stage of modeling, we distributed team roles: we identified the owners of the product, team members and me as a scram master, the duration of the sprint, the process of filling and prioritizing the backlog.
Mandatory task attributes, tracking flow for tracking, tracking tool, assignment of estimates in man hours for each type of task and total hours per week for each analyst were taken into account, taking into account the implementation of the team plan for the sprint, time and regularity of daily meetings and retrospectives.
The head of the group of analysts has become the owner of the product and the person who sets backlog. The teams were decided to make 2-7 people, satisfying the requirement of 7 ± 2. These were two teams, conventionally divided by the functional basis of the tasks to be solved, which was closer to the original model, but farther from the intended goal - cross-functionality.
For tracking, we decided to use the existing TFS, in which it is convenient to display tasks according to the “New”, “In Work”, “Completed” statuses on the board and it is possible to collect small statistics on the results for discussion at a retrospective meeting at the end of the sprint. The TFS board simulates a physical Scrum board, but we also had a physical board.
The planning stage ended with a demonstration to the presentation team based on the results of the “Getting to work in a new way together” simulation, discussion and correction of the fact that the guys did not find a response.
Scrum and ScrumBut in particular are teamwork, coherence, transparency, and general acceptance. It was an important moment from which we started our inspirational start.
A source
When you work on a large project, there is no way to go into the pool with your head, so you cannot do without planning. It is important to understand how it will be and what results it will bring, but we have met with the need to be prepared for the fact that the plan in some aspects will remain a plan. When planning, we painted with large strokes, and already at the implementation stage we were able to add the details that the team and the project situation brought.
Our team is responsible only for part of the software development cycle, so there were difficulties with what to call a product and what to receive as a gain. We knew that it must be complete and complete. We agreed that we on the part of the team of analysts are preparing several types of documents for interacting with the customer and creating tasks for the developers for their backlog. Thus, the tasks get into the sprints to the developers. In my opinion, such a compromise path can be suitable for projects in which individual teams of analysts, developers, testers, support, and for projects where the number of people requires division into several teams. In this decision, there is also a minus - the members of our team cannot influence the timing of readiness to increase the functionality of the product, we can only influence the performance of their part of the work. There are pluses - the continuity of the tasks of analysts for developers. This decision made it possible to avoid attempts to become one cross-functional team (analysts = developers = testers, etc.), which in our case at this stage would be impossible, while maintaining the product development cycle with a compromise refraction at the interface of teams.
At the presentation stage, our guys from NORBIT reacted quite actively and with interest. But I assume that the positive emotional response of the team is a merit of working out the goals and their connectedness with actual and obvious problems.
The steps described above (the study of the theory, modeling and presentation), have done their job: we have successfully launched.
But starting up is only the first step. What happened after the launch and what results were achieved, I will tell in my next article.
In this article I will tell you about our experience of preparing to use limited Scrum on behalf of the Scrum master: what we did to start. At the time of this writing, the 15th sprint has been completed. Flight is normal!
I often heard about the use of the Scrum framework in teams whose members are not developers. Teams of different expertise actively join Agile. I thought that Scrum was originally created for development teams of the full cycle, and therefore there are a number of difficulties or interesting points that you should pay attention to if the team differs from the reference one, the one that the creators thought about. I highlight the teams in the direction of expertise and the degree of participation in the product development cycle. The direction of expertise, in my opinion, does not limit the use of Scrum. But the degree of participation in product development may limit. Some may perform a full cycle of work on the product, being responsible for the final result available to the customer - and in my opinion, you can use a full-fledged Scrum in such teams. And others - perform only part of the full cycle, being part of the work chain. In this case, there may be issues and difficulties with a full Scrum. Such a project situation may require a compromise approach.
In this article we will discuss the team responsible for the part of the product development cycle and the preparation for the launch of ScrumBut in it.
Our action plan for the launch was:
- examine and evaluate the current situation and the desired,
- build a model as is and to be in the terminology of ScrumBut,
- present and inspire the team
How I studied what ScrumBut is
At first I googled and got:
A ScrumBut has a particular syntax: (ScrumBut) (Reason) (Workaround). ScrumBut Examples: "(We use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so we only have one per week.)" "(We use Scrum, but) (retrospectives are a waste of time () (so we don't do them.) "
Those. ScrumBut is a limited scrum. This variation of the framework allows you to take everything you need from Scrum and not take what we think is not required. Of course, this is a slippery track, because To understand what is necessary and what is not required, it is important to have an idea of the classic Scrum, it was important for me to understand why this is included in the full version.
Useful for me in the hardware turned out to be:
- study of literature: Agile software development manifest , SCRUM is a revolutionary project management method (Joseph Sutherland), Agile team coaching (Lissa Adkins);
- a series of lengthy and interesting consultations with the current certified scram master practicing the classics.
How I evaluated the current situation
To begin with, I took advantage of my vision and made a few points for evaluation by managers.
Collected the opinions of team members and recorded them.
We have two lists: what we have at the entrance and what we want to get.
This will make consolidated and generalized lists.
What had at the entrance
- A large project on the development of the privatization system.
- Separate teams of developers, support and analysts.
- A cool team of analysts (about 14 people).
- Ability to act only within the team of analysts.
- Release version of the system.
- Waterfall software lifecycle management model.
- The impossibility of hard planning, as the tasks from the customer come at any time.
- Uneven workload of analysts.
- The functional distribution of the areas of expertise of analysts.
What we want to get
- Be able to respond quickly to business changes.
- Take into account and prioritize tasks in the work
- Have feasible product growth predictions.
- Short sprints can allow you to track, fix and perform tasks and more accurately predict the release of tasks.
- Create backlog tasks for analysts.
- At any time, the analyst knows what to do.
- Share experiences in solving complex problems.
- To establish teamwork in such a way that sharing knowledge was pleasant, comfortable and mutually beneficial.
- Organize your Scrum with Black Jack, etc. :)
- Try new, increase team spirit. The guys are great. Why not?
Modeling
At the stage of modeling, we distributed team roles: we identified the owners of the product, team members and me as a scram master, the duration of the sprint, the process of filling and prioritizing the backlog.
Mandatory task attributes, tracking flow for tracking, tracking tool, assignment of estimates in man hours for each type of task and total hours per week for each analyst were taken into account, taking into account the implementation of the team plan for the sprint, time and regularity of daily meetings and retrospectives.
The head of the group of analysts has become the owner of the product and the person who sets backlog. The teams were decided to make 2-7 people, satisfying the requirement of 7 ± 2. These were two teams, conventionally divided by the functional basis of the tasks to be solved, which was closer to the original model, but farther from the intended goal - cross-functionality.
For tracking, we decided to use the existing TFS, in which it is convenient to display tasks according to the “New”, “In Work”, “Completed” statuses on the board and it is possible to collect small statistics on the results for discussion at a retrospective meeting at the end of the sprint. The TFS board simulates a physical Scrum board, but we also had a physical board.
Presentation
The planning stage ended with a demonstration to the presentation team based on the results of the “Getting to work in a new way together” simulation, discussion and correction of the fact that the guys did not find a response.
Scrum and ScrumBut in particular are teamwork, coherence, transparency, and general acceptance. It was an important moment from which we started our inspirational start.
Conclusions from the preparations for the launch
When you work on a large project, there is no way to go into the pool with your head, so you cannot do without planning. It is important to understand how it will be and what results it will bring, but we have met with the need to be prepared for the fact that the plan in some aspects will remain a plan. When planning, we painted with large strokes, and already at the implementation stage we were able to add the details that the team and the project situation brought.
Our team is responsible only for part of the software development cycle, so there were difficulties with what to call a product and what to receive as a gain. We knew that it must be complete and complete. We agreed that we on the part of the team of analysts are preparing several types of documents for interacting with the customer and creating tasks for the developers for their backlog. Thus, the tasks get into the sprints to the developers. In my opinion, such a compromise path can be suitable for projects in which individual teams of analysts, developers, testers, support, and for projects where the number of people requires division into several teams. In this decision, there is also a minus - the members of our team cannot influence the timing of readiness to increase the functionality of the product, we can only influence the performance of their part of the work. There are pluses - the continuity of the tasks of analysts for developers. This decision made it possible to avoid attempts to become one cross-functional team (analysts = developers = testers, etc.), which in our case at this stage would be impossible, while maintaining the product development cycle with a compromise refraction at the interface of teams.
At the presentation stage, our guys from NORBIT reacted quite actively and with interest. But I assume that the positive emotional response of the team is a merit of working out the goals and their connectedness with actual and obvious problems.
The steps described above (the study of the theory, modeling and presentation), have done their job: we have successfully launched.
But starting up is only the first step. What happened after the launch and what results were achieved, I will tell in my next article.
Source: https://habr.com/ru/post/437800/