The Agile comedy: from hell to paradise
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Tymoshchuk, Anastasiia
Nowadays everyone wants to bring Agile Best Practices into all the teams, but it's a hard task to implement it and adapt based on different teams. Setting up all necessary Agile meetings and using buzz words is not enough for the team to be happy and successful while working in Agile environment. Inspired by the ""Divine Comedy"" by Dante Alighieri, I decided to create a short guide into Agile best practices. It will guide through Failures, Challenges to the Success in building a happy dream team! This talk is divided into three parts: 1. Failures in setting up Agile processes for a team. 2. Challenges on the way to happy and successful team. 3. Successful examples how to have happy and productive Agile team and constantly deliver a great product.
 Hello, everyone. Today we are going to have something really interesting, like a journey from hell to paradise. I am a software developer. I'm not a scrum master. I do Python. I love Python. And I still love Agile. I implemented successfully a few times in a few different teams as scrum and tried a little bit of Kanban and I would like to share my experience with you. How many of you are using scrum or any Agile technology at work? Raise your hand. Keep holding them if you like scrum or Agile. Oh, so many people almost. But who hates you? Nice. Nice to meet you. Just one person, to be honest. I am a bit surprised. So first we will go to the hell. Through me you pass into the city of woe. Through me you pass into eternal pain. Through me among the people lost for eye. I hope abandon you who enter here. This is the famous wording from Dante Alighieri from the Divine Comedy. And today we are going to have the same journey as he had, but together with our Agile's scrum to the paradise. Now we are starting our journey. So what do we all want here? We would like to be more productive. We would like to be helpful to all our projects and to our project managers to make them happy but also to be happier at work, to be happy with our technologies. So let's go through all the failures and challenges which we could meet on our way to paradise. We would like to be more productive. The question is how to do so? Here comes the manifesto for Agile software development with the key points. To satisfy customer welcome changing requirements. We all love changing requirements. Of course, why not? Let's change everything in the moment and deliver frequently. We all need agility in our projects. We want to be flexible and as fast as possible. Sounds great, yes? That's exactly what we are looking for here. And if we would like to go for it, there are so many frameworks, Agile frameworks. Scrum, Kanban, Xtreme programming, Crystal, dynamic systems, development method, feature driven development and many more. And when someone asks you, how do you keep the project on the schedule? How do you deliver on time? Basically the answer is like, oh, we have Agile and then the team or the team members, they start discussing Scrum. And I'm just wondering, is the Agile and Scrum the same? Is Agile Scrum or Scrum is Agile? It's like the same if you would say that the object is the same as a class. Do you agree? I don't. So the first of all, I would like to tell you that Agile is not a noun. It's an adjective. It's like he's. He's in Agile. He's very fast and flexible. Run as fast as you can. So Agile is a set of principles and Scrum is an Agile framework. And nowadays, to be honest, Agile became a buzzword and every company would like to implement that every, everyone is keen to start with all the principles of any of the frameworks and to be successful in the company. And they are really afraid to fail of not having them. So let our journey begin. Together with our Virgilio Scrum, we are going to paradise. We will continue our journey into success. And let's imagine that our company decided to implement Scrum, for example. But what does it mean to me as a person? To me as a team member? Let's imagine that our company has a goal. They want to be productive. They want to be fast. They want to deliver frequently. And they all have different requirements changing every week or maybe every day. And the meaning behind those words is usually whatever it takes. And the problem is here, whatever it takes part. Because then it takes all our inspiration or all our abilities to work. Then all the teams are frustrated. They don't really know how to deal with it. And this is the problem. Here comes the hell in the companies. We would like to be happy at work. We would like to apply all the best practices. And to be honest, to have any kind of options crafted for the teams. But that's not really possible. Because all the teams, they are different. Every personality is different. And also the projects, even with the same topic. For example, two different companies, but the same kind of product. The processes may be different, of course. So the possible solutions here is like the most exciting one to have a scrum master. It's very fancy, buzzy and nice to have a dedicated scrum master for one team who will set up all the sprints. But there are multiple more options. The first one is to have a team lead as a scrum master. But hey, you know that there is no team lead role in the scrum. There is the product owner, the team, and the scrum master. And where is the team lead? In this case, the team lead is becoming not a real scrum master. This person is more like a controller for the management. To control if the project is on time, if everything is on schedule, if everything is delivered. And it's kind of not the nice way to set up a scrum. Because then team is not really happy with the scrum. Everyone is not energetic and not willing to report to the same team lead. Because it's not a facilitator. It's just a person who has even more control. The second option is to have a dedicated scrum master, which is nice. It's always nice. The third one to hire one person or maybe a group of people, maybe a separate company to train the team to be agile or scrum, to deliver on time, to know which meetings do they need to set up, like to get a bit of a feeling how should it work. And there are even nice trainings ahead for the company, but the problem afterwards is that the team should set up it. And then the company who is running all the workshops, they're leaving the company in the same state as they were with some kind of knowledge. And then they need to implement a new framework. It's the same as development. You are reading a book and then you have to try it. Does it really work all the time? And then the other option is to have one scrum master for a few different teams. And there are so many open questions in those four different options. For example, do we really need a full-time scrum master? Is it a full-time job? Because the company would probably think that the scrum master will have not enough work to do. It's like 50-50 and maybe it's an option to share one scrum master between different teams. Why not? Yeah, for sure, that might work. But if one scrum master shares different teams and one team has impediments, they cannot really deliver on time because they don't have enough resources or maybe they don't have enough communications with the customer. And the other team has some issues with the scrum or they just cannot work together. They have arguments and they needed a solution. What to do? How scrum master will decide which team is more important? How to do so? It's kind of impossible. Then one team will succeed and then the second one will fail and who will be responsible for that? Manager or a team? Of course, the team. And for the scrum training, the question here is if one person is going to be a scrum master or they will share responsibilities. Then at the very beginning, it's a full-time job. I tried it. I was a developer. I entered the new team. Everyone was very frustrated with the job. They didn't talk with each other. And then I tried to bring them together with some team buildings and also explain them all the principles, how it works and what can they do with the scrum, which meetings can we have and how can we be happy and successful. And it really took a lot of time to adjust for the team and to bring a safe environment for the team so then they will open up and be able to speak up during the meetings. Do you agree that the scrum is about things developers do when they are not writing code? Anyone? That's nice. Maybe you have perfect scrum or agile principles in your companies. I heard that a lot from all the developers and they are not really happy because they have to do even more work at work. They have to write the code. They have to attend meetings. And also they have to fill all the forms for the... Sometimes for the daily, you have to really fill the form. What did you do yesterday and so on? And that's kind of time consuming. So that is the hell of agility principles, but sometimes after the hell, you can see a hope. For example, like this. That was our fastest stand-up ever, only 59 minutes, less than an hour. Great job. Seriously, I have something like that. And it was... Yeah, it was super exciting, right? So how to start? There is a hope. And Dave Thomas, one of the creators of agile methodology, gave us a hope. He crafted a way how to start with all the agile principles and how to implement that. First search for a solution, pick one most fitting one, but just one, then try it out and then review the results. Just stop for a moment, look back and then decide if it works or not. Then adjust and start over again. And here, the most important part is to try just one solution at a time, because if you will try multiple ones, then you will not see what is working and what is not. It may not work, and then you still need to adjust again and again. And it depends on the teams. Sometimes all the improvements, they just simply work. Sometimes nothing works, and you need to go outside of the box and see what is happening. So implementing agile principles is not a goal. The goal is to be more productive and to be happier at work, but that's not the goal of the company. Company wants to have more deliveries and better products, for sure. But for people and for the Scrum Master, the goal is to make the team so comfortable that they can share ideas, they can speak up, and they can craft a solution together. So the Scrum Master is more like a full-time job at the beginning, but then afterwards, the team is self-organized, and it should just simply work together. They're finding the solutions together without the Scrum Master. So if the company would go for the Scrum, then they would have all those meetings that they would stand up, the sprint review, the demo, the retrospective, and the sprint planning, and many more. So the daily stand up, it should be less than 15 minutes. Everyone should be standing to be as uncomfortable as possible, so to finish earlier than 59 minutes, and then answer three questions. And the three questions are usually, always, what I did yesterday, what am I going to do today, and which impediments I had. And usually the answer is, for the first one, for developers, yeah, I did some coding yesterday, yeah, I'm going to do some coding today. And from impediments, I had a meeting which prevented me from writing even more code yesterday. So usually it's the same every day. Isn't it boring, right? So how to change it? There is a way, because boring stuff prevents us from working and from inspiration. And if you are trying out a new technology and then you have to sit at the meeting for an hour or even worse for two hours, then you don't want to work anymore. So how to make it fun? There are multiple solutions. First, change the location. If you're standing up at the same place where you work every day, just go for a coffee. Why not? Meet up at the kitchen, or maybe while walking to take a coffee, just do the stand-up, answer the questions or talk with each other. Sometimes changing the question helps, because if you will answer the questions, what inspired me yesterday and what am I going to do today to bring up the energy into my product? It's a bit different. Or maybe you can answer those questions for a colleague of yours. You can just switch the order and then you share kind of understanding what everyone does in your team. Or even visualizing the progress helps in the way which you would like to have. For example, you can set up some kind of local currency. You earn like 100 points and then you got a coin for the team. And then the team member who got more coins can do some kind of review or something like that. Also making notes and making it visual helps a lot. And changing the order. You can, for example, bring a big bowl and then throw it to the person and say, like, you are the next one. That works. So the sprint retrospective. Nothing funny here. It's just reviewing the processes. It's not about the product, just about the team. You're sitting there listening to each other, sleeping. No, actually it's not. It could be even funny when the whole team interacts with each other. For example, what I did in the team, it was like the timeline. And every team member was able to use either green or red or the orange sticky notes. The green is like everything good happened and they would like to have it more. The red something bad happened and the orange is like, oh, I don't really know. It's something in the middle. And then if you will put it on the timeline, then you will see how the product was developed and how the processes went. For example, from the green to the red at some point and then to the green or orange. And you really can see the progress. At the very beginning, it was some kind of very funny because everyone would like to have more team buildings, more beers, more coffee. It's like green. And then from the red, we didn't have chocolate, for example, yesterday. Yeah, it was kind of red. We fixed that until the next sprint because somebody from the team brought a chocolate and it was improvement, of course, so it worked. And to make in your retrospectives even more fun, retrospective could have sort of a name. As a result of the work you did, how it went, it could have a story. For example, like this. If in our sprint, we were throwing out the stories, we were losing money and like just doing that and the name was Wolf of the Wall Street. And here is the paradise, almost so close. We are almost there, but there is one but. The overall knowledge about our scrum. The orange one is something that we don't know. The dark blue is something that we know about scrum. And the biggest part is something that we don't know that we don't know. But we don't really know that we don't really know it. It's a hard question. How to discover this part? It's a huge part and we don't even know what to do because we don't really know what is happening in there. And I would recommend one book about playing games at work. It's about developing the products and playing at work. It's not just about scrum or a gel or any methodology. It's about methods, how to fix up your products and how to deliver based on the customer. Because customer usually doesn't really know what they want. They are frustrated. Sometimes they really know like, we need these. But sometimes they are like, we want this product. No matter what and how we just need it. And with those games you can discover what you don't know about the product and about the customer. And one more thing to say. Sometimes on the way to paradise we meet zombies. Why are we talking about zombies and scrum? That's kind of weird. They appear to be human but in reality they are not. There is no beating heart. And the same is in scrum. There is a zombie scrum approach. It appears to be scrum but in reality there is no fun in it. There is no beating heart. I would highly recommend you to go to the link. Let me show it to you. To this one. They will suggest you how to discover if your scrum is a zombie scrum and how to fix it. It's zombie scrum resistance. And I would like to say from a small spark, great flame had risen. And I wish you all to all your projects and to all your teams. A small spark and inspiration and fun. Thank you. Thanks a lot Anastasia. I found myself and how I work in my team in many things you talk about. I'm happy. I'm a jive. And do you have a question? See. Hi. I have a question regarding external influences. So you want to improve your processes, maybe bring in more automation, more CI CD. But always the product owners or some senior business people, they always want more products. And they generally don't give you enough time to work on your technical debt and things like those. You have experiences with that and how do you influence those guys outside the team? I can see two questions. The first one about the processes, how to change them within the company. And the second how to deliver on time still with the changing processes. I got the question and the concern of yours. And the answer is sometimes you have to tell them how much will they get instead of just delivering the products all the time. Because if they will see at least one improvement within a week or two weeks, then they would believe you. So what we did, we asked for some extra time for one sprint and then we started. And then we showed like, hey, we committed for this and we delivered that. Let's try one more sprint. And in two sprints, it improved a lot and they really could see the progress. Or sometimes you can really lie for some big companies when they are not flexible at all. So for example, you have a scrum for the whole company and it's not flexible. You have to follow all the rules. And it's kind of hard and easy. It's easy because you can be one separated team and just don't show all the processes in your team. You can kind of lie. Yeah, we are following, but you're not. And afterwards when the scrum master or somebody from the team is showing the progress, then they are very happy and surprised. Another question? I think sometimes with stand-ups, when a manager is present, you sort of say things different when he's not present. Because you may be like, oh yeah, I did this yesterday. I did this yesterday. I did this yesterday. And when he's not there, you don't care about giving so much detail. Do you think there's some value in having different people at stand-ups on each day or not? Different people in the team? Different people with your manager and without your manager? I mean, you still have the same team. You cannot change team members. I mean, you can do. Yeah, that's possible. What we did in the current company, I recently started. And it was kind of a challenge for me to find the company where there are already kind of principles implemented. So I would be still happy joining them and not changing them completely as I did before. So what they do, they invited more people because it's a startup and we have more than 10 people. It's like 20 people standing around. And we still managed to finish in 15 minutes. We usually answer those questions, but it's more like playing around and having fun one of the other. But the thing is, we did wanted to have a change of opinions and be on the same track every day. So it's still possible. You can invite more people. You can uninvite them. If you don't like them, oh, just don't come, yes. Or change the location and they will not see the changing. Thanks for your talk. What is the difference between a scrum master and just a middle manager? And the manager? And a middle manager, yes. Just somebody who is above the team and is responsible for higher levels of management. I mean, they do management and the scrum master doesn't. Scrum master is responsible for the team's happiness. So it's kind of a facilitator between the teams. And the manager should trust the team and the team shouldn't be controlled, to be honest, because it's self-organized team and they can manage whatever they have, except impediments which are there to be resolved by the scrum master. And the scrum master could go to the management and ask for resolutions. But usually, yes, they do everything. Kind of. So the scrum master has to protect the team from the management. Good question. Thank you. Question? We have time for another couple of questions if you have. Okay. So thanks a lot again Anastasia and see you soon in Berlin.
 Hello, everyone.  Today we are going to have something really interesting, like a journey from hell to paradise.  I am a software developer.  I'm not a scrum master.  I do Python.  I love Python.  And I still love Agile.  I implemented successfully a few times in a few different teams as scrum and tried a little  bit of Kanban and I would like to share my experience with you.  How many of you are using scrum or any Agile technology at work?  Raise your hand.  Keep holding them if you like scrum or Agile.  Oh, so many people almost.  But who hates you?  Nice.  Nice to meet you.  Just one person, to be honest.  I am a bit surprised.  So first we will go to the hell.  Through me you pass into the city of woe.  Through me you pass into eternal pain.  Through me among the people lost for eye.  I hope abandon you who enter here.  This is the famous wording from Dante Alighieri from the Divine Comedy.  And today we are going to have the same journey as he had, but together with our Agile's  scrum to the paradise.  Now we are starting our journey.  So what do we all want here?  We would like to be more productive.  We would like to be helpful to all our projects and to our project managers to make them  happy but also to be happier at work, to be happy with our technologies.  So let's go through all the failures and challenges which we could meet on our way to paradise.  We would like to be more productive.  The question is how to do so?  Here comes the manifesto for Agile software development with the key points.  To satisfy customer welcome changing requirements.  We all love changing requirements.  Of course, why not?  Let's change everything in the moment and deliver frequently.  We all need agility in our projects.  We want to be flexible and as fast as possible.  Sounds great, yes?  That's exactly what we are looking for here.  And if we would like to go for it, there are so many frameworks, Agile frameworks.  Scrum, Kanban, Xtreme programming, Crystal, dynamic systems, development method, feature  driven development and many more.  And when someone asks you, how do you keep the project on the schedule?  How do you deliver on time?  Basically the answer is like, oh, we have Agile and then the team or the team members,  they start discussing Scrum.  And I'm just wondering, is the Agile and Scrum the same?  Is Agile Scrum or Scrum is Agile?  It's like the same if you would say that the object is the same as a class.  Do you agree?  I don't.  So the first of all, I would like to tell you that Agile is not a noun.  It's an adjective.  It's like he's.  He's in Agile.  He's very fast and flexible.  Run as fast as you can.  So Agile is a set of principles and Scrum is an Agile framework.  And nowadays, to be honest, Agile became a buzzword and every company would like to implement  that every, everyone is keen to start with all the principles of any of the frameworks  and to be successful in the company.  And they are really afraid to fail of not having them.  So let our journey begin.  Together with our Virgilio Scrum, we are going to paradise.  We will continue our journey into success.  And let's imagine that our company decided to implement Scrum, for example.  But what does it mean to me as a person?  To me as a team member?  Let's imagine that our company has a goal.  They want to be productive.  They want to be fast.  They want to deliver frequently.  And they all have different requirements changing every week or maybe every day.  And the meaning behind those words is usually whatever it takes.  And the problem is here, whatever it takes part.  Because then it takes all our inspiration or all our abilities to work.  Then all the teams are frustrated.  They don't really know how to deal with it.  And this is the problem.  Here comes the hell in the companies.  We would like to be happy at work.  We would like to apply all the best practices.  And to be honest, to have any kind of options crafted for the teams.  But that's not really possible.  Because all the teams, they are different.  Every personality is different.  And also the projects, even with the same topic.  For example, two different companies, but the same kind of product.  The processes may be different, of course.  So the possible solutions here is like the most exciting one to have a scrum master.  It's very fancy, buzzy and nice to have a dedicated scrum master for one team who will  set up all the sprints.  But there are multiple more options.  The first one is to have a team lead as a scrum master.  But hey, you know that there is no team lead role in the scrum.  There is the product owner, the team, and the scrum master.  And where is the team lead?  In this case, the team lead is becoming not a real scrum master.  This person is more like a controller for the management.  To control if the project is on time, if everything is on schedule, if everything is delivered.  And it's kind of not the nice way to set up a scrum.  Because then team is not really happy with the scrum.  Everyone is not energetic and not willing to report to the same team lead.  Because it's not a facilitator.  It's just a person who has even more control.  The second option is to have a dedicated scrum master, which is nice.  It's always nice.  The third one to hire one person or maybe a group of people, maybe a separate company  to train the team to be agile or scrum, to deliver on time, to know which meetings do  they need to set up, like to get a bit of a feeling how should it work.  And there are even nice trainings ahead for the company, but the problem afterwards is  that the team should set up it.  And then the company who is running all the workshops, they're leaving the company in  the same state as they were with some kind of knowledge.  And then they need to implement a new framework.  It's the same as development.  You are reading a book and then you have to try it.  Does it really work all the time?  And then the other option is to have one scrum master for a few different teams.  And there are so many open questions in those four different options.  For example, do we really need a full-time scrum master?  Is it a full-time job?  Because the company would probably think that the scrum master will have not enough work  to do.  It's like 50-50 and maybe it's an option to share one scrum master between different  teams.  Why not?  Yeah, for sure, that might work.  But if one scrum master shares different teams and one team has impediments, they cannot  really deliver on time because they don't have enough resources or maybe they don't have  enough communications with the customer.  And the other team has some issues with the scrum or they just cannot work together.  They have arguments and they needed a solution.  What to do?  How scrum master will decide which team is more important?  How to do so?  It's kind of impossible.  Then one team will succeed and then the second one will fail and who will be responsible  for that?  Manager or a team?  Of course, the team.  And for the scrum training, the question here is if one person is going to be a scrum master  or they will share responsibilities.  Then at the very beginning, it's a full-time job.  I tried it.  I was a developer.  I entered the new team.  Everyone was very frustrated with the job.  They didn't talk with each other.  And then I tried to bring them together with some team buildings and also explain them  all the principles, how it works and what can they do with the scrum, which meetings  can we have and how can we be happy and successful.  And it really took a lot of time to adjust for the team and to bring a safe environment  for the team so then they will open up and be able to speak up during the meetings.  Do you agree that the scrum is about things developers do when they are not writing code?  Anyone?  That's nice.  Maybe you have perfect scrum or agile principles in your companies.  I heard that a lot from all the developers and they are not really happy because they  have to do even more work at work.  They have to write the code.  They have to attend meetings.  And also they have to fill all the forms for the...  Sometimes for the daily, you have to really fill the form.  What did you do yesterday and so on?  And that's kind of time consuming.  So that is the hell of agility principles, but sometimes after the hell, you can see  a hope.  For example, like this.  That was our fastest stand-up ever, only 59 minutes, less than an hour.  Great job.  Seriously, I have something like that.  And it was...  Yeah, it was super exciting, right?  So how to start?  There is a hope.  And Dave Thomas, one of the creators of agile methodology, gave us a hope.  He crafted a way how to start with all the agile principles and how to implement that.  First search for a solution, pick one most fitting one, but just one, then try it out  and then review the results.  Just stop for a moment, look back and then decide if it works or not.  Then adjust and start over again.  And here, the most important part is to try just one solution at a time, because if you  will try multiple ones, then you will not see what is working and what is not.  It may not work, and then you still need to adjust again and again.  And it depends on the teams.  Sometimes all the improvements, they just simply work.  Sometimes nothing works, and you need to go outside of the box and see what is happening.  So implementing agile principles is not a goal.  The goal is to be more productive and to be happier at work, but that's not the goal  of the company.  Company wants to have more deliveries and better products, for sure.  But for people and for the Scrum Master, the goal is to make the team so comfortable that  they can share ideas, they can speak up, and they can craft a solution together.  So the Scrum Master is more like a full-time job at the beginning, but then afterwards,  the team is self-organized, and it should just simply work together.  They're finding the solutions together without the Scrum Master.  So if the company would go for the Scrum, then they would have all those meetings that  they would stand up, the sprint review, the demo, the retrospective, and the sprint planning,  and many more.  So the daily stand up, it should be less than 15 minutes.  Everyone should be standing to be as uncomfortable as possible, so to finish earlier than 59  minutes, and then answer three questions.  And the three questions are usually, always, what I did yesterday, what am I going to do  today, and which impediments I had.  And usually the answer is, for the first one, for developers, yeah, I did some coding yesterday,  yeah, I'm going to do some coding today.  And from impediments, I had a meeting which prevented me from writing even more code yesterday.  So usually it's the same every day.  Isn't it boring, right?  So how to change it?  There is a way, because boring stuff prevents us from working and from inspiration.  And if you are trying out a new technology and then you have to sit at the meeting for  an hour or even worse for two hours, then you don't want to work anymore.  So how to make it fun?  There are multiple solutions.  First, change the location.  If you're standing up at the same place where you work every day, just go for a coffee.  Why not?  Meet up at the kitchen, or maybe while walking to take a coffee, just do the stand-up, answer  the questions or talk with each other.  Sometimes changing the question helps, because if you will answer the questions, what inspired  me yesterday and what am I going to do today to bring up the energy into my product?  It's a bit different.  Or maybe you can answer those questions for a colleague of yours.  You can just switch the order and then you share kind of understanding what everyone  does in your team.  Or even visualizing the progress helps in the way which you would like to have.  For example, you can set up some kind of local currency.  You earn like 100 points and then you got a coin for the team.  And then the team member who got more coins can do some kind of review or something like  that.  Also making notes and making it visual helps a lot.  And changing the order.  You can, for example, bring a big bowl and then throw it to the person and say, like,  you are the next one.  That works.  So the sprint retrospective.  Nothing funny here.  It's just reviewing the processes.  It's not about the product, just about the team.  You're sitting there listening to each other, sleeping.  No, actually it's not.  It could be even funny when the whole team interacts with each other.  For example, what I did in the team, it was like the timeline.  And every team member was able to use either green or red or the orange sticky notes.  The green is like everything good happened and they would like to have it more.  The red something bad happened and the orange is like, oh, I don't really know.  It's something in the middle.  And then if you will put it on the timeline, then you will see how the product was developed  and how the processes went.  For example, from the green to the red at some point and then to the green or orange.  And you really can see the progress.  At the very beginning, it was some kind of very funny because everyone would like to  have more team buildings, more beers, more coffee.  It's like green.  And then from the red, we didn't have chocolate, for example, yesterday.  Yeah, it was kind of red.  We fixed that until the next sprint because somebody from the team brought a chocolate  and it was improvement, of course, so it worked.  And to make in your retrospectives even more fun, retrospective could have sort of a name.  As a result of the work you did, how it went, it could have a story.  For example, like this.  If in our sprint, we were throwing out the stories, we were losing money and like just  doing that and the name was Wolf of the Wall Street.  And here is the paradise, almost so close.  We are almost there, but there is one but.  The overall knowledge about our scrum.  The orange one is something that we don't know.  The dark blue is something that we know about scrum.  And the biggest part is something that we don't know that we don't know.  But we don't really know that we don't really know it.  It's a hard question.  How to discover this part?  It's a huge part and we don't even know what to do because we don't really know what is  happening in there.  And I would recommend one book about playing games at work.  It's about developing the products and playing at work.  It's not just about scrum or a gel or any methodology.  It's about methods, how to fix up your products and how to deliver based on the customer.  Because customer usually doesn't really know what they want.  They are frustrated.  Sometimes they really know like, we need these.  But sometimes they are like, we want this product.  No matter what and how we just need it.  And with those games you can discover what you don't know about the product and about  the customer.  And one more thing to say.  Sometimes on the way to paradise we meet zombies.  Why are we talking about zombies and scrum?  That's kind of weird.  They appear to be human but in reality they are not.  There is no beating heart.  And the same is in scrum.  There is a zombie scrum approach.  It appears to be scrum but in reality there is no fun in it.  There is no beating heart.  I would highly recommend you to go to the link.  Let me show it to you.  To this one.  They will suggest you how to discover if your scrum is a zombie scrum and how to fix  it.  It's zombie scrum resistance.  And I would like to say from a small spark, great flame had risen.  And I wish you all to all your projects and to all your teams.  A small spark and inspiration and fun.  Thank you.  Thanks a lot Anastasia.  I found myself and how I work in my team in many things you talk about.  I'm happy.  I'm a jive.  And do you have a question?  See.  Hi.  I have a question regarding external influences.  So you want to improve your processes, maybe bring in more automation, more CI CD.  But always the product owners or some senior business people, they always want more products.  And they generally don't give you enough time to work on your technical debt and things  like those.  You have experiences with that and how do you influence those guys outside the team?  I can see two questions.  The first one about the processes, how to change them within the company.  And the second how to deliver on time still with the changing processes.  I got the question and the concern of yours.  And the answer is sometimes you have to tell them how much will they get instead of just  delivering the products all the time.  Because if they will see at least one improvement within a week or two weeks, then they would  believe you.  So what we did, we asked for some extra time for one sprint and then we started.  And then we showed like, hey, we committed for this and we delivered that.  Let's try one more sprint.  And in two sprints, it improved a lot and they really could see the progress.  Or sometimes you can really lie for some big companies when they are not flexible at all.  So for example, you have a scrum for the whole company and it's not flexible.  You have to follow all the rules.  And it's kind of hard and easy.  It's easy because you can be one separated team and just don't show all the processes  in your team.  You can kind of lie.  Yeah, we are following, but you're not.  And afterwards when the scrum master or somebody from the team is showing the progress, then  they are very happy and surprised.  Another question?  I think sometimes with stand-ups, when a manager is present, you sort of say things different  when he's not present.  Because you may be like, oh yeah, I did this yesterday.  I did this yesterday.  I did this yesterday.  And when he's not there, you don't care about giving so much detail.  Do you think there's some value in having different people at stand-ups on each day  or not?  Different people in the team?  Different people with your manager and without your manager?  I mean, you still have the same team.  You cannot change team members.  I mean, you can do.  Yeah, that's possible.  What we did in the current company, I recently started.  And it was kind of a challenge for me to find the company where there are already kind of  principles implemented.  So I would be still happy joining them and not changing them completely as I did before.  So what they do, they invited more people because it's a startup and we have more than 10 people.  It's like 20 people standing around.  And we still managed to finish in 15 minutes.  We usually answer those questions, but it's more like playing around and having fun one  of the other.  But the thing is, we did wanted to have a change of opinions and be on the same track  every day.  So it's still possible.  You can invite more people.  You can uninvite them.  If you don't like them, oh, just don't come, yes.  Or change the location and they will not see the changing.  Thanks for your talk.  What is the difference between a scrum master and just a middle manager?  And the manager?  And a middle manager, yes.  Just somebody who is above the team and is responsible for higher levels of management.  I mean, they do management and the scrum master doesn't.  Scrum master is responsible for the team's happiness.  So it's kind of a facilitator between the teams.  And the manager should trust the team and the team shouldn't be controlled, to be honest,  because it's self-organized team and they can manage whatever they have, except impediments  which are there to be resolved by the scrum master.  And the scrum master could go to the management and ask for resolutions.  But usually, yes, they do everything.  Kind of.  So the scrum master has to protect the team from the management.  Good question.  Thank you.  Question?  We have time for another couple of questions if you have.  Okay.  So thanks a lot again Anastasia and see you soon in Berlin.
Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_0_335.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_336_1571.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_1572_2291.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_2292_3479.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_3480_5747.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_5748_5999.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_6000_15695.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_15696_16127.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_16128_17603.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_17604_18791.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_18792_19055.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_19056_19355.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_19356_20567.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_20568_23087.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_23088_25715.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_25716_26099.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_26100_26807.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_26808_29003.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_29004_29567.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_29568_29639.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_29640_30419.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_30420_30503.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_30504_31307.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_31308_35567.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_35568_35627.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_35628_35675.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_35676_35723.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_35724_35795.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_35796_35867.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_35868_36011.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_36012_36083.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_36084_36191.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_36192_36239.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_36240_36287.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_36288_37499.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_37500_37655.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_37656_37787.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_37788_38507.png Anastasiia_Tymoshchuk_-_The_Agile_comedy__from_hell_to_paradise_UmeK-yOc1Mo_38508_38571.png