How I was taught to work. Day Three
Two days ( first and second ) were a theoretical introduction.
It's time to see how all this is in practice.
Last week began with feature planning meetings. Ended directly with work.
In the beginning I will tell a little about XPlanner and the organization of the project.
XPlanner is an open-source tool for time tracking and drawing beautiful graphs for managers, quite simple.
Our project consists of three teams. Each should make about 10 features for the entire project and solve several internal problems, such as test automation.
XPlanner does not know how to keep track of time for teams, but for us it is important. Therefore, I had to create three separate projects for each. It gave:
The main disadvantage of XPlanner is its inflexible work with tasks: moving them from one sprint to another turns some things into a chaotic list. Before starting the project, you should study these tools and choose the right one.
Our team had to spend 2 days at plan meetings. As practice has shown, the more people, the more difficult it is to agree on a deadline: one believes that too much time is needed, the other - on the contrary, the third does not understand the meaning of the feature at all.
To avoid long disputes, SCRUM suggests using a card system with numbers.
We had these: 2, 4, 8, 12, 16, 20. Plus a card with the inscription "Too much." The time evaluation is as follows:
1. A feature is selected. Breaks down into tasks. An assessment is given for each of the tasks.
2. Each of the participants in the rally selects a card with the number of hours, sufficient, in his opinion, for the implementation of the task.
3. At the expense of 3, everyone shows their choice.
4. If the values diverge strongly - each one argues (briefly) their choice and selects the best estimate.
By the end of the rally, assessments become less objective due to the tiredness of the participants, so it’s worth taking breaks (it’s better to walk and not spread over the chair). The team may meet people who begin to breed a discussion on the topic: "What a fool came up with this feature." Such people, IMHO, should be deprived of a vote for 30 minutes or removed from the rally. Otherwise, time will be spent on empty evidence - the feature still has to be done. If you are a leader in a team, make everyone prepare, otherwise a bunch of questions may arise: “What is this ...?”.
On Wednesday, we had the first rally status. We had to tell on it what we did, what we will do and what problems there are. Participants: team, manager and tech. project coordinator.
In our case, the latter actively wedged into the conversation - forbid everyone to speak except the team. The task of managers at this meeting is to listen and record.
After the rally everyone went to work. Nothing special here. But there are several important points:
1. The manager must remember that the rally ALWAYS has a goal. You cannot assemble a team just for the sake of telling about the current status of the project - it is already known. If you want to chat with programmers, have them drink tea. This will give you a plus in trust.
Any rally without a useful purpose leads to a 30 minute loss of time - after a boring story about garbage, people go to drink tea and lose their mood to work.
2. Do not throw away features at the beginning of the sprint, even if you see that you do not have time. This is superfluous work. Also at the beginning (especially when the team has not yet worked out) it is not clear what the pace will be. Perhaps you can do it faster. Let these features be as a super-goal to do more and become better. It is good if there is a little spirit of competition between teams, but not in a team.
3. Communicate with colleagues. Everyone in the team should know about your problems - maybe someone already knows the answer. Well, if you are sitting in a common room.
It's time to see how all this is in practice.
Last week began with feature planning meetings. Ended directly with work.
In the beginning I will tell a little about XPlanner and the organization of the project.
XPlanner is an open-source tool for time tracking and drawing beautiful graphs for managers, quite simple.
Our project consists of three teams. Each should make about 10 features for the entire project and solve several internal problems, such as test automation.
XPlanner does not know how to keep track of time for teams, but for us it is important. Therefore, I had to create three separate projects for each. It gave:
- The ability to see the dynamics in each of the teams, and not the entire project
- Avoid “porridge” in the list of tasks (there are about 50 of them)
The main disadvantage of XPlanner is its inflexible work with tasks: moving them from one sprint to another turns some things into a chaotic list. Before starting the project, you should study these tools and choose the right one.
Planning (time evaluation)
Our team had to spend 2 days at plan meetings. As practice has shown, the more people, the more difficult it is to agree on a deadline: one believes that too much time is needed, the other - on the contrary, the third does not understand the meaning of the feature at all.
To avoid long disputes, SCRUM suggests using a card system with numbers.
We had these: 2, 4, 8, 12, 16, 20. Plus a card with the inscription "Too much." The time evaluation is as follows:
1. A feature is selected. Breaks down into tasks. An assessment is given for each of the tasks.
2. Each of the participants in the rally selects a card with the number of hours, sufficient, in his opinion, for the implementation of the task.
3. At the expense of 3, everyone shows their choice.
4. If the values diverge strongly - each one argues (briefly) their choice and selects the best estimate.
By the end of the rally, assessments become less objective due to the tiredness of the participants, so it’s worth taking breaks (it’s better to walk and not spread over the chair). The team may meet people who begin to breed a discussion on the topic: "What a fool came up with this feature." Such people, IMHO, should be deprived of a vote for 30 minutes or removed from the rally. Otherwise, time will be spent on empty evidence - the feature still has to be done. If you are a leader in a team, make everyone prepare, otherwise a bunch of questions may arise: “What is this ...?”.
First 15 minute SCRUM rally
On Wednesday, we had the first rally status. We had to tell on it what we did, what we will do and what problems there are. Participants: team, manager and tech. project coordinator.
In our case, the latter actively wedged into the conversation - forbid everyone to speak except the team. The task of managers at this meeting is to listen and record.
First lines of code
After the rally everyone went to work. Nothing special here. But there are several important points:
1. The manager must remember that the rally ALWAYS has a goal. You cannot assemble a team just for the sake of telling about the current status of the project - it is already known. If you want to chat with programmers, have them drink tea. This will give you a plus in trust.
Any rally without a useful purpose leads to a 30 minute loss of time - after a boring story about garbage, people go to drink tea and lose their mood to work.
2. Do not throw away features at the beginning of the sprint, even if you see that you do not have time. This is superfluous work. Also at the beginning (especially when the team has not yet worked out) it is not clear what the pace will be. Perhaps you can do it faster. Let these features be as a super-goal to do more and become better. It is good if there is a little spirit of competition between teams, but not in a team.
3. Communicate with colleagues. Everyone in the team should know about your problems - maybe someone already knows the answer. Well, if you are sitting in a common room.