Scrum - how to work effectively without a project manager

    Instead of introducing


    Over the past 3 years of work, I have been able to work in a wide variety of roles: researcher, developer and project manager. There are various management styles: western (when a lot of freedom is provided in the team and much is built on trust, respect, personal organization of an individual individual) and eastern (when each delay is fined, the terms are rigidly fixed, the team’s iron discipline is at the forefront and if the person has failed with goals - parting comes). The project manager must combine these two elements: an apple and a whip, to let people in to you, so that the developers trust you, but also to observe subordination, since attitude is relationship, and focus on results should always be.

    But much more important: how do you move towards your goal, how do you organize your workflow ... In this article I would like to share with the honorable public one of our unprofessional video lectures, which we shot for ourselves. I think that in every team there comes a moment when something may not go exactly as we would like. I want some changes, and it is better to start them first with yourself. As they say - if you want to change the world, then it is worth starting first of all with yourself and your immediate environment.

    For convenience, I made subtitles for the video to make it easier to watch. I only note that this is not a professional video lecture and the lecturer does not read this methodology on purpose. Dina Nasyrova (Tim Leader from Fujitsu) came to us as a token of respect to help establish the team work process and at the same time shared her own rich experience. The meeting took place a year ago - since then much water has flowed. But after a while I still remember her, since the information presented in it was very useful to me.

    image

    Decoding of the video lecture in full (subtitles)


    Dina: Where did it all go. We sat drinking tea and found out that you need a project manager. Right?

    Team: Yes!

    Dina: So I asked: “I definitely need it, right?” And I promised to come and give a lecture. As I see myself, what is Scrum and how can I develop it without a boss. Do any of you know what Scrum is?

    Team: I read. Victor threw off the link. Notes with advanced

    Dean:Here, in short, and here I also posted a link to this book. From my point of view - this is one of the best such books, without unnecessary such introductions - why this Scrum, blah blah blah. It’s just that you take, like a tool, yes, and apply it. That's what I like about her. On its basis, I made just such a small presentation. I myself, of course, also read Henry Kniberg and this book only. This book is really enough to start. Why development without a boss, yes? Because - as a matter of fact, such an understanding as a team leader or project manager or someone in such a role that is up there, yes, and with such a stick there. And now this, (shows) does how it is motivated, yes. Can you imagine what will be the motivation? I will show in the picture (draws). Such an employee, donkey. Like a donkey not? How can he be motivated? You can add such a carrot. Will he run forward? Probably he will run? You can motivate in another way. Such a magical pendell. Run forward? Will run. There is another type of motivation when such a carrot from the inside motivates him. Inside a man burns. From my point of view, the most correct motivation.

    But I was distracted, in fact, it's not about that at all. The thing is that if the programmers are mature enough, the team has developed, then this thing from above with a stick is needed optionally in fact. And now I will tell you how it is possible to distribute responsibility from within the team in such a way that the development goes as quickly as possible and, accordingly, everyone was happy. So Robert Cheldini talks about who scrum master and just a team. By the way, how many people are you now?

    Team: Us. Well 9. And there are 5 of them programmers.

    Dean:5-6 programmers. This is basically a team - the most ideal option for Scrum. Because 4 is somehow incomprehensible, yes. 4 people can always agree. And no methodology is needed. And 10 is already a lot. Because I know by myself. The person who is close - you can no longer see. Do not keep in the spotlight.

    You need to register everything, to the last letter how you will develop. Why - it will take just that much and say - look - here is the customer. Will it work like that? This is what you need, right? The customer will say - well, probably - this is what I need, and you sit down to develop. Come to your room and develop. Six months later, come and say “on.” Worked, developed and tested. The customer says - well, of course it's cool, but I don’t really need it, I guess. Already not quite right. And you say - well, look. Have we agreed? That’s what they agreed to — they did it. This is a waterfall model. First the requirements are collected. Then you mean approve them. Do you guys have any English? Should I translate? Requirements - coordination with the customer. Then development means
    Moreover, what happened to the customer during these six months? Maybe he’s changed everything - doesn’t it concern you at all? He paid, gave a good advance - normal. There is such a thing as Scrum, right? Why is he? It seems to me in your case - this is the optimal model. Because it is an iterative development. This whole crap (shows), right? It happens many, many, many, many times during the life and time of development. Why - because, in fact, everything can change - especially with you. Yes, the customer scratched his turnip, he came and said - bliiiin, so I found such a cool thing. Let's implement it. Rate here. And Scrum - it is for such teams and for such rapidly developing and changing projects. When the customer can, in principle, play with the price of the project. Yes? That is, he can understand ... now I’ll better show. Let's start yes. Where does Scrum start? Scrum begins by creating a Product backlog. This is essentially a list of customer requirements. Plant it in front of you and say - let's tell you what you need. Of course, in this book it is written differently, but - from my point of view, the requirements should look just like this. The user does something and the system reacts somehow. That is, the user logs in and enters the login password. The system authenticates it or says that the login password is not correct. This one is like a user story. And it should be formulated precisely from the point of view of the customer - this is a business story, it should not be that to connect to the database and use such a temple - this is not right - this is about a business hotel, here is a classic product. Smiles cunningly - screaming loudly that he is in command, but actually (points to the project manager). User story. After these user story are recorded. It is necessary to make a standard identifier for each of them. Each of them should have a name, in such a way that the user logs in, and the system responds somehow ... Importance, initial estimate - initial assessment, let's say yes. That is, how much it can take about, very approximately. How to demonstrate. The user logs in, logs in and sees the result and all sorts of notes are different. And it will look something like this. I took it from the book. I don’t really like it (draws). But this, too, can be better that way - than nothing. Yes, what are we doing to recreate. We plant a product owner in front of us, write out every single Wishlist. Then we sit down together. We make an approximate assessment of our problem and then ask him - put importance. Importance 50 to 150, each task: which is the most important and which is not the most important. Why - in order to tear out only the most important. That is, at first we do only the most important. And then everything else is not important, and then it can be completely thrown out. Clear? Any questions? And so we formed a product backlog. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. and which is not the most important. Why - in order to tear out only the most important. That is, at first we do only the most important. And then everything else is not important, and then it can be completely thrown out. Clear? Any questions? And so we formed a product backlog. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. and which is not the most important. Why - in order to tear out only the most important. That is, at first we do only the most important. And then everything else is not important, and then it can be completely thrown out. Clear? Any questions? And so we formed a product backlog. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. That is, at first we do only the most important. And then everything else is not important, and then it can be completely thrown out. Clear? Any questions? And so we formed a product backlog. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. That is, at first we do only the most important. And then everything else is not important, and then it can be completely thrown out. Clear? Any questions? And so we formed a product backlog. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. Spent a few days - all the juices from the customer survived. What he did to us - put down the importance. What do we do next. We need to talk about the first sprint. But I want to talk, know what? Where should, how should the team sit - what do you think? That is, can she sit anywhere? Do you need to sit in departments? It is necessary to put everyone together, to be killed, but to put everyone together. That is, people should see each other. Scrum master, in principle, may not come to work at all. That is, people should see each other. Scrum master, in principle, may not come to work at all. That is, people should see each other. Scrum master, in principle, may not come to work at all.

    Team : And the question is - if I work remotely.

    Dina: Well, you can work with that too. In the book, by the way, there is such a case. Well, it’s clear that there is no perfect world. But in general it would be cool for everyone to see each other. I just had and have experience - I see how teams are formed. That is, the first stage is completely different people. They planted them together - they begin to joke. Six months will pass - they will eat together to walk. From this moment, the team begins. This affects and affects, unfortunately, you need to understand that yes - I want to work remotely, I want to work from home.

    Team: Yes, no, it's just not the point. I live in another city. In a different way, it doesn’t work.

    Dina:You can live with this, I'm talking about an ideal case, this is not fatal. Where should the product owner sit?
    Team: On the dais, watch everyone.
    Dina: Actually, he has to work with the team every day. It should be within walking distance. But not there. That is, he should not be able to come and say - what are you doing here? It should not be. He is somewhere nearby. But not to say that with the team sits in the same place. So. We have formed our product backlog. Here are our tasks. That is, for example, it takes 50 importance (hours, huh?) But this is not a clock - but a user story. What is user story? More precisely, story point. When you start the estimate product backlog you get together and determine how long it will take to implement this in an ideal world. In an ideal world, it was as soon as you arrived at 8 in the morning, left at 6 in the evening, and all this time: I didn’t go to eat, I didn’t go to drink tea, I didn’t go to talk, I just worked. It's called a Story Point, and this thing is being evaluated like this. This is say 30, this is 10. This is very important, this is not very. Well and so on. Now we need to form such a thing called sprint backlog. This is what you take in the first iteration. Remember, we are doing iterative development. One iteration is one sprint. You can vary the length of the sprint, that is, the sprint can be weekly. It can be monthly, three-month - it basically depends on the team. That's what a long sprint is good - what do you think? three-month - it basically depends on the team. That's what a long sprint is good - what do you think? three-month - it basically depends on the team. That's what a long sprint is good - what do you think?

    Team: You can stir up something big.

    Dina: Why is he bad?

    Team: This big one may be too krizyamuchi.

    Dina: Because we may not have understood what the customer wants from us. We have been doing this for a month, but it turned out to be wrong. Well, that's right - you need to find the most convenient position for yourself. It also happens that people do not work for 2 weeks - so he just swayed - and the sprint ended. What to do?

    Team: Can I save the task if he did not finish it? Let it continue. But look yes. What is Scrum for?

    Dina: He's in order to get it after every iteration. There was some kind of buildt. Any new thing? What can be shown. And what was not completed - it is believed that it does not work.

    Team: But everything happens. A person, for example, fell ill or simply did not have time. What to do? Surely there have been such cases?

    Dina:There are such cases. It happens that people change. But. We say that in the end we have to show something to the product owner. Well, we will show a little less. No one will die. Another question is that we will have some statistics, which we usually completed in 1 sprint. 1 sprint, for example, took us - for example, 280 hours. We thought we would do it for 200. Let’s say for 160. And the next we wanted 180 - and we did 160 again. Next time we plan 160. We have a story. And this gives us the opportunity quite seriously, much more seriously than to plan in the waterfall model. But just about knowing. What 160, yes. We divide 160 by 200. And we get a certain focus factor. This is the percentage, that is how we go. Then we multiply this number in the Sprint Backlog. And we find out that we will finish in a couple of years. Add us developers - something like this. So Sprint Backlog and we take this story and this story (shows) there. For us, this is like the beginning of the formation of the Sprint Backlog. We do this on a special meeting held at the beginning of each sprint. This is called planning. We all get together, we look at what priorities. And we take these tasks here. What do you think product owner should call? He already put everything here. Need to call? Still not showing anything? In fact, I had the opportunity to try this way and that. We had a product owner, who was not at all with us, and he said - well, okay, I will come to the demo - what you want from me is too much. So there was one who was with us. The one that was with us really - we asked him to come to this rally and at this rally these things are being revised (shows). That is, backlogs are very approximate. And here they can be reviewed. For example, here it’s 50, and 60 actually. And when he saw this. And he said: guys, we didn’t agree so - why is this so. And you begin to explain here, here. And he sits and thinks. Maybe it's not now then. And takes away, for example, this thing. Down (shows). So what are we doing yet. On the same planning, we determine the purpose of the sprint itself. That is, when we take these things - the matter is actually very complicated. For me, perhaps the most difficult thing was. Because you rip off all these user stories. They may not be very connected with each other. there must still be a goal. But this is just the main goal of the sprint. we didn’t agree - why is this so. And you begin to explain here, here. And he sits and thinks. Maybe it's not now then. And takes away, for example, this thing. Down (shows). So what are we doing yet. On the same planning, we determine the purpose of the sprint itself. That is, when we take these things - the matter is actually very complicated. For me, perhaps the most difficult thing was. Because you rip off all these user stories. They may not be very connected with each other. there must still be a goal. But this is just the main goal of the sprint. we didn’t agree - why is this so. And you begin to explain here, here. And he sits and thinks. Maybe it's not now then. And takes away, for example, this thing. Down (shows). So what are we doing yet. On the same planning, we determine the purpose of the sprint itself. That is, when we take these things - the matter is actually very complicated. For me, perhaps the most difficult thing was. Because you rip off all these user stories. They may not be very connected with each other. there must still be a goal. But this is just the main goal of the sprint. For me, perhaps the most difficult thing was. Because you rip off all these user stories. They may not be very connected with each other. there must still be a goal. But this is just the main goal of the sprint. For me, perhaps the most difficult thing was. Because you rip off all these user stories. They may not be very connected with each other. there must still be a goal. But this is just the main goal of the sprint.

    Team: And how to divide the goals into small ones?

    Dina: I 'll tell you now. A little later, good. After we have determined the goal, we need the goal, the length of the sprint, as we all show in 2 weeks, in 3 weeks. Then you need to determine the time of the daily rally. In general, do you have a daily rally?

    Team: Planers once a week. But they are not Dean's technical plan

    :What is a daily rally. In fact, now yes, I have very little development - I have a service. Nevertheless, we are doing a daily rally. I just don’t know how to explain it to you - but it works. People are gathering. The best thing that happens is that people begin to boil in their own juice. Each of them very quickly answers several questions. What did you do? What are you going to do? And what problems do you have? And with problems it happens very enchantingly. When a person cooks in his own juice, he may run into a problem when someone on the team knows how to solve it. And then it turns out that the question is addressed to the team - someone necessarily raises his hand and says - listen, but this is very simple. And everything revolves, seriously, much faster. And the effect is that people simply do not boil in their own juice. And I often saw how one half of the team after this meeting gathers and animates so gesticulously. How it really needs to be done. This is a very important factor. I just insistently recommend looking at each other every day. And answer these questions. It helps quite a lot. And besides, programmers like to sit down. And do not communicate with anyone. If you have new ones, you will feel how much faster he enters, as he looks in your face every day, rather than sitting there. When is it better to make a rally: in the morning, or in the evening, or at lunch? It's not the same for everybody And besides, programmers like to sit down. And do not communicate with anyone. If you have new ones, you will feel how much faster he enters, as he looks in your face every day, rather than sitting there. When is it better to make a rally: in the morning, or in the evening, or at lunch? It's not the same for everybody And besides, programmers like to sit down. And do not communicate with anyone. If you have new ones, you will feel how much faster he enters, as he looks in your face every day, rather than sitting there. When is it better to make a rally: in the morning, or in the evening, or at lunch? It's not the same for everybody

    Team: is it worth discussing some problems there? If you couldn’t do anything there all day? And in the evening you say - I sat all day. You’ll do something tomorrow.

    Dina: We will explain now. Many people say what to do in the morning. But we do at lunch. There are downsides that people remember very hard what they did yesterday.

    Team: Well, in the morning. For example, come to work in an hour. And a rally so that the brains are razrulilis.

    Dina: We personally came up with a better lunch, although the book says that in the morning. Since my people come to dinner.

    Team: Morning time is really loose. We also have a slightly floating Dean chart

    :I have no desire to make them come to eight. What for? If, for example, he comes and suffers garbage for 4 hours. I’ll do it better at 12. There is a concept late, which is the most characteristic. But there are people who are late by 12. What do you think I'm doing. So that people are not late? What can be done so that people are not late?

    Team: Deprive him of a prize. The trend, however. Show carrots. Do you remember the back approach. For special occasions or put the jar of

    Dean:In fact, the approach is presented in the books when they make a common piggy bank and a person who is late arrives and silently puts money. And at the end of the week they get drunk for the money raised. This does not work for us. He calmly puts money, he is late again the next day, he is late again the next day. I don’t know, it will help you no. Personally, I bought ears - pigs. And all day you have to go with these ears. 2 times was enough.

    That actually formed the backlog. These are cards that are designed for poker, do you know? (shows). That is, after we collected the tasks. We need to re-evaluate them - since we could be wrong here. What we do, the team gathers like you. Imagine that each of you has a deck of cards. We will make rulers, who does what. And everyone silently puts out a card. And I, for example, look - one laid out a hundred. Another laid out an hour - and I have a question in honor of what? Why unit? Well, for example, I know how to do it, since I already did it. There are blanks. I ask - why 100? I did not know how to do it. Then we ask someone who knows to explain. And we do one more round - everyone again lay out the cards. The second time, usually the same numbers. But I take more - just in case. So this is planning - sprint backlog. Yet, what can be done. Usually the user story is still pretty superficial. Therefore, the book says that they do it too. We come to the fact that these stories, they are divided into small tasks. That is, there, for example, the admin panel, or 3 tables in the database. This is a business story. These are stories for programmers. What to do? And with such small tasks.

    Team: And who is setting this weight? Ticket and generally the story itself? What time is it?

    Dina: So you sit and do it yourself. No one is around. There is only scrum master, but he is not the boss. He can come from outside. The process just helps you. It has no more features. If someone, for example, sabotages, he identifies this person. For example, the one who sits and speaks - but I don’t know how it all works. The star is like that. He just talks to him - why are you doing this? In principle, there is no boss.

    Team: It turns out this will work if all
    people are motivated.

    Dina: Well, what do you mean motivated?

    Command:Well, as I mean, someone comes to work just to sit out, well, there are the same ones - plankton.

    Dina: Scrum does not tolerate these people, I say that all this will be immediately visible. Just the work will immediately rise. Well, if, for example, he said yesterday that he was making 3 tables, he said the day before. Today he says it again. It is necessary to turn on the brain and think whether he is a man. What is he doing here. Tables? Here are actually these small yellow pieces of paper (shows). This is the broken task. Tasks can be taken by completely different people.

    Team: It 's still not clear. Who breaks tasks into tasks. Do programmers themselves break tasks into tasks? And they also evaluate it themselves, that is, if they’re not broken correctly? Neither those director, nobody?

    Dina:And who besides you - am I also interested in this question? How does the director know what is inside the development. Who except you knows what's inside the development? Those director showed that outside. I say product owner. If you know that you need to do this task - you will appreciate it normally.

    Team: Are disputes welcome? Yes, you are many. On the basis of several cards, everything adds up? And if it happened, what did you say you would do quickly, but in the end did you run into some kind of jamb?

    Dina: And it always does. I told you about the trick. That is, it always turns out that we say 160 story point. And we do the first sprint never more than 80. A good figure is when we took 160 and made 120, it’s fine, in general. People always value more. He always considers himself the best

    Team:Yes, and not all pitfalls are not always visible simply

    Dean: And I mean the same thing - well, anything can happen. Sitting - not thinking about that in the morning. There the wife screamed. This also happens. You won’t get anywhere from this. Actually, are we going further or are there any other questions?

    Team: I do not understand to the end. Well, someone thinks. What task can be divided into 2 subtasks, another can be 5? Who is right?

    Dina: Talking. Are disputes welcome there? Scrum master why? to guide you a little. He will not be involved in the dispute. But if he sees that the argument is off topic, then someone out there expresses his ambitions. That is, in this case, he will stop this dispute.

    Team: That is, as it turns out, he somehow manages the process - and he says that we will put 5 sub-tasks to put an end to it?

    Dina: He leads the processes. If you have a competent Scrum master, then he will never say - we will do 5. No, he just, well, will see what people say and decide what to do 5 or will vote or will be somehow different, or will talk somehow. He himself will not say that 5. He is not responsible for the result. He answers that your process is going well. all.

    Team: No, but he didn’t invent it himself. On the basis of opinions, he said to

    Dean: This is decided by the process. If you have been talking for 2 hours, he will stop you. But he will not decide for you anyway

    Team: by type, like managing people, Dean's processes

    :therein lies the fact that there is a person who decides for you what task to do for you, how long it will take and when you will do it - there simply is no such person. That is, it is a kind of collective mind. But actually he is. You are urged to get seriously enough to take responsibility. Not every team is ready for this. But since you have been working together for a long time, you should already have it. That is, the responsibility she rests with you. No one will do it for you, no one has told you this. You yourself brought all this out and are responsible for the result.

    Team: Sorry, but you can ask another question: did you say that at first one said there did 10 ratings or 100, and should the product owner
    wait until the ratings are equal or can he choose?

    Dina:no, you need to align the grades. Even in my practice it was - if the argument goes on for too long, if one speaks 5 hours, the other 100. Personal ambitions. I say - and who will take it? That is - if you take it - leave 5 hours. This is not good to do, since mallets should be formed on a different principle. But if there’s nowhere to completely disappear, then let’s leave it like this. Now that we have formed the product backlog. We have a bunch of tasks, they are appreciated, we know what to do, and then we do such a thing. There is such a grid (draws) and it all sticks here and after that everything happens. That is, the board plan is ready, and we must start, somehow a sprint, we must start to do something. There is a very important thing here - we assign all these tasks. But we do not assign all the tasks for people at once. We look at the top of the most important tasks. Below are not very important. There is a task which we can take. If we have time, most likely not. Here is a bunch of tasks (shows). And everyone should know that first you need to take the task, which has the highest priority?

    Team: Do people take the tasks themselves?

    Dina:Yes, that’s the cimus. Everyone has the right to take a task. I actually, when I read it was the worst moment. Suddenly, if someone says that I will not do this. And some kind of task will just hang completely. What to do? In reality, never in all the time has this happened. I do not know what I will do? Probably I will appeal the guys to the fact that - the team Where are you? Why is this happening? Are we not responsible for the result? In reality, this never happened. Apparently, when the team has developed and it has responsibility for the result, then there is an understanding of what someone should do. There is another such trick here. By 5 or 6 sprints. If a team is large enough, it becomes clear that one person is constantly doing the same thing, because he knows well how it all works from the inside. That is, he began to make the admin panel, and he picks it there. He began to make some kind of big request. And next to a bunch of small queries. So he does it all - because I know how to do it faster, yes. Here it is necessary if there is a scrum, a smart master - he will say no, you are not doing it, because the day after tomorrow he will get sick, and no one knows what he was doing inside. It will be better longer, but everyone will try a little. That is, here the master’s skarm has a veto. Why aren't you doing - naturally with explanations. but everyone will try a little. That is, here the master’s skarm has a veto. Why aren't you doing - naturally with explanations. but everyone will try a little. That is, here the master’s skarm has a veto. Why aren't you doing - naturally with explanations.

    Team: Sorry, but you can ask a question, it seems to me that for us this stage will not work for our project. Because, for example, we have some people engaged in a valid audio core, others with a video core and it makes no sense to yank them - since these are very different areas,

    Dina has her own specificity : there really is no panacea. Even with waterfall, no matter how I love waterfall, right?

    Team: I'm not talking about waterfall, I'm not about changing people because of tasks. For example, he makes a piece, successfully does it, then let him do it. There is no one to replace it yet, but on the other hand - He quickly does it qualitatively, why not?

    Dina: But maybe in reality it will not be Scrum

    Team: But I'm just saying maybe some kind of hybrid will suit us for the first time at least?

    Dina: I think so too. You watch yourself. I say there is no panacea, there is no silver bullet, you always need to change something. Take something and quietly adapt something for yourself. Now, if you think that you do not need to change people, then this is your decision in fact.

    Team: It just seems to me that your scrum. In general, all this is from Java development. But not such projects. We have a heterogeneous project, roughly speaking. And it should be like this: there is a website, let's say you make a database. And any people web sites can do and database. Just here is a custom development to make a website, for example, a store. People make it and this scrum is perfect. We have a breakthrough R&D development. We don’t really ...

    Dina: But Scrum is just on R&D

    Team:I speak of completely different areas of audio and video. In general, completely different areas. A person can be in audio for 10 years. He has a degree there. And in the video, he doesn’t understand a belmez. If you change it like that in a week. It will be just some kind of mess. And the overall vector will be a zero gain. To between audio, here is the task. Also, far from a monolith can happen. No, no, I don’t speak globally, maybe they just don’t shove them globally, with smaller tasks. This I agree if two people on the audio. They can, let each other duplicate. But do not switch them on the video, as there will be no sense. It turns out such a limited scrum. We are not doing this for the sake of scream? But it’s interesting for me to apply it, and not to just listen to it all.

    Dina:This can be done on the board, but we did it all on a workspace scrum. There is such a thing. And there is still a jaira. In the jair, it seemed to me not so convenient. Because the jaira is still not about that. And because there is a jaira - you roll a thing that makes a jrum board for scrum. But I liked Scrum Works more. But this is a matter of taste in fact. In principle, you can do all this on the board. Stupidly take the stickers and sculpt on the board. It's better on the board because you see it. All the same, Scrum Work must be opened. This is laziness, yes.

    Sprint is over. What do we do next? We show the customer and everyone who is interested in this matter what we have done. The customer is required, the product is required. We show him all that. In general, it’s good to invite someone from the outside to the demo. Because immediately such a jerk - and what we show. It whips people enough enough that we can show that this is not a shame. After the demonstration has ended, you need to make another magical rally. It is called a retrospective and goes somewhere around 1.5 hours. That is, we all get together and look at our focus of textures. How many points did. We look at our bucklag and say what could have been done differently. What could be done better, where did we screw up, what did we screw up, why did it happen? And this thing here - this is perhaps the most important of all the rallies. How does this happen.

    I also wanted to tell you, I do not know about you. But when we start the project
    There is always a technical task, which is difficult to design as a user story. These are such things as deploying an environment, doing some research. How will it work? How can this be explained to the product by ouner? But you have it seems sensible. He will probably understand. I personally had problems with this. I personally came to the conclusion that I have the first sprint, always technical, I just need to give it as a given and explain, understand what is happening, try a couple of options. And there are always technical tasks in which you always need to accustom your product to the ouner, that there is a technical task and we put it here, that you can’t live without testing. This is what we are currently sitting in and testing, and it will take so many story points. Well, actually testing. Do you have any non-automatic testing? Not unit tests? What to do with testing - there are several approaches. You can do testing inside the sprint. That is, the task is completed. Give it to the tester. And he is testing. In the meantime, there’s nothing to test - he sits and writes task cases. We tried so and we didn’t succeed. What did we do? That is, some developers, they pull everything until the last day, almost everything. And then it all falls on the tester dead weight huh? Sorry, what should I do? Here are the iterations and what have we come up with, I don’t know if all this will work for you or not? We are developing, but is the tester doing something yet? He doesn’t work with us at all. We give him this buildt and start the next one. In this case, some part of this build is painted over with bugs. That is, we know that there will be a bug fixing in the story point. They’ll definitely fly here, while it is testing, it is rolling out bugs, we are fixing them right there, actually we lived like that. It didn’t work out differently. Maybe you can do it somehow?

    Team: How much interest do you put on bugs?

    Dina: First more - then less.

    Team: Interests 30-20?

    Dina: At first, even closer to 40, and then the quality improves and is already smaller.

    Team: And can I ask such a question? To ask? But what should one do if a person goes on vacation for a month, and he drops out of this system?

    Dina: That is, how many people do one hundred points make an average sprint in one sprint and subtract it - it turns out crooked of course, but at least somehow. That is, we took on this number of story points, but already less.

    Team: And for each statistics was carried out individually?

    Dina:Not at all simple. If you keep on each - it will be scatter and reel. Someone will say that I have 50 story points, and you have 10 there, you need the same for the team.

    Team: Yes, I agree. Competition kills a team huh? Yes?

    Dina: Unfortunately, this is so, in fact, what can be done if 2 teams, then you can post the results. In general, the board clearly shows - how many story points have taken, how many have done, and if 2 boards are standing, then everything is clearly visible, everything is visible, you understand what starts?

    Team: This is called a carrot hang. Actual for us. It is possible for video and audio. Well, when the team becomes thicker.

    Dina:You know the Ford factory - you know what he did? He had shift workings and once a night shift started working. He came and listened to everyone. He nodded and asked how much you did per shift? He is told, for example, 9 cars. He took the chalk and painted 10 large and sweeping and left. The next shift came and says that this is generally - they explained to us how many pieces we made. In short, the next day there were 10, then 11 - this carrot just needs to be able to. Actually, that's all. I forgot to introduce myself. My name is Dina. I work in Fujitsu, beginners need to be trained this way, actually it works and by the way I can tell. I read a wonderful book by Robert Cialdini about carrots, various configurations from there.

    Command:And another question - that is, about general statistics. Acceptable for each programmer? For example, one programmer has so many points to motivate another. This is all very visible in fact

    Dina: Here again I say that the team should already be mature enough. And then one fine moment she should have the right that this particular person is here, that messes up every time and that something else is needed. It should be possible, otherwise you have no rights - so there is no responsibility. In general, significant savings are obtained on the product manager. Everyone does everything. You can increase your salary. To say that we work without a product manager. If 2-3 sprints pass with a bang, then you can actually not come

    Team:And here is a question: here in your Fujitsu, what kind of projects are you using for scrum?

    Dina: I have a service. Here is such a service - this is support, that is, I have 60 different-sized applications and I need them to live. That is, if they fall, the customer will have quite serious monetary losses. Therefore, everything is done like that. For the most part, we use this little thing (draws). IITL is a thing that tells you how to support science applications. There are 1,2,3,4,5 line of support. 1 line
    This is an SD test, the girls who are responsible for the call center, then task 2 fly in, what is done - what does not work. For the most part, girls also sit on 2 lines, because from 4 lines instructions come to them. A ticket comes to them, they know where to get it and what to do. Or a very simple task to solve, which does not require any strong knowledge there, here for the most part the incidents are resolved. It goes to the third line, something that has not been decided here, or something crazy - the incident repeats itself 20 million times and it leaves here = this is already a problem. That is, the problem comes here - why does our application fall from time to time. You decide. If the task first takes 2-3 hours, then from 5 to 16. If something is absolutely critical and it is not clear what to do, then it goes to line 4 - usually it’s a vendor - the person who did all this, who knows, what's inside, what kind of architecture. These people, of course, also know what kind of architecture, but they have no way to fix it. It usually comes here. But if 1000 comes here, 200 comes here, and 20 comes here, this is how it all works. That is, you don’t hold, not a bunch of the same specialists who are expensive for you, there are 500 girls here, there are 20 women who are wise by experience, here are 15 men, and here there are those with beards. But it's actually about how to do it all, what kind of people to choose. We use this thing. But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line but they have no way to fix it. It usually comes here. But if 1000 comes here, 200 comes here, and 20 comes here, this is how it all works. That is, you don’t hold, not a bunch of the same specialists who are expensive for you, there are 500 girls here, there are 20 women who are wise by experience, here are 15 men, and here there are those with beards. But it's actually about how to do it all, what kind of people to choose. We use this thing. But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line but they have no way to fix it. It usually comes here. But if 1000 comes here, 200 comes here, and 20 comes here, this is how it all works. That is, you don’t hold, not a bunch of the same specialists who are expensive for you, there are 500 girls here, there are 20 women who are wise by experience, here are 15 men, and here there are those with beards. But it's actually about how to do it all, what kind of people to choose. We use this thing. But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line That is, you don’t hold, not a bunch of the same specialists who are expensive for you, there are 500 girls here, there are 20 women who are wise by experience, here are 15 men, and here there are those with beards. But it's actually about how to do it all, what kind of people to choose. We use this thing. But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line That is, you don’t hold, not a bunch of the same specialists who are expensive for you, there are 500 girls here, there are 20 women who are wise by experience, here are 15 men, and here there are those with beards. But it's actually about how to do it all, what kind of people to choose. We use this thing. But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line But since we all do this, development flies to us. But she is not like that. She is 3-4-5 months old. We have support for 60 projects. And the whole team all 60 support. There are actually already 2 teams. More than 8 people can not be kept in attention. Therefore, already 2. 12-13 people. And each one has this 4 line

    Team: How long? How old are they together in a team? Are they worked out?

    Dina: There will simply be major changes. We will recruit people. But now they are worked out. True, here are teams of 2-3 people. We make a scrum, but it turns out so fast. It turns out very fast, everyone knows each other and the rally, for example, did it, did it, well - well done, but because - they have been sitting together for a long time. We have a big scrum, but it’s not often when I worked on development — it was more often.

    Team: On development, probably, more interesting is the scrum? Support is simple - do you solve any bugs?

    Dina:you perform some Wishlist. Yes, yes, sometimes the truth is from scratch. He’s not so funny there isn’t one, they know each other’s team and sometimes I don’t even go - they themselves. I only see the board. Moreover, we are all doing Scrum Work. Not ripened to a normal board. Can you ripen? Maybe we are lazy because? It is necessary to move it.

    Team: but there you need to have shared access in a scrum workshop? Yes?

    Dina: This is such a thing that organizes all this virtually. In general, it may be better to use it for the first time - because it leads you - you can make a mistake - and she says - now create tasks, come on. That is, it is such an application. It is ancient, but nothing has changed in scrum (wrote). He is there for free - in fact, he is insanely expensive.

    Team:Dina, tell me, I don’t understand, some points, 10 points, how are they calculated?

    Dina: What do you think? Do you have any tasks alive?

    Team: Yes, I do not know. You can tell on your own. How does this even compare with time? But I, for example, need 2 hours. I do it in 2 hours. All. Point.

    Dina: Here are 2 story points. This is the perfect time. We just tell ourselves that they are perfect and that's just me doing them.

    Team: but I understood that I sat down cleanly for 2 hours and you work - you do not distract and give a result. Disconnected skype - yes exactly?

    Dina: of course, there are other definitions in the network - this has taken root with us. You can, for example, measure in parrots. But it’s pure here to switch hard.

    Command:why then didn’t they call Auers, but story point? working auers?

    Dina: good question, I’ll definitely ask Ken Schweiber.

    Team: just a matter of habit, right?

    Dina: But I say that everything is online. For example, Ken has parrots. I’m used to it myself - because I value it in hours. How long does it take. Somehow strange huh? That is, you need to come up with a metric so that everyone understands it and everyone in it is guided. Therefore, I still prefer the perfect watch

    Team: Thank you! It was very interesting!

    Dina: Always happy!


    Video lecture



    Lecturer - Dina Nasyrova, software & solution team leader, FUJITSU Global Delivery Center, Russia.
    She let me use the video materials of the lecture and presentation

    Presentation




    Instead of a conclusion


    The lecture presented caused a great discussion among us. And for a long time I remembered in my memory. We began to apply some elements, some - no. But this is not about that. The fact is that for the first time we got the opportunity to get acquainted with the presented model of conducting development from the practice of our business. And all the more useful it was to hear the expert opinion. Whether to use Scrum or not is up to everyone. But its presence cannot be denied. I will be glad if the material presented is useful to someone and allows you to change the development process in a new direction.

    Also popular now: