The Agile comedy: from hell to paradise
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 118 | |
| Author | ||
| License | 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 | |
| Identifiers | 10.5446/44772 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
EuroPython 201999 / 118
2
7
8
15
20
30
33
36
39
40
45
49
51
55
57
58
63
64
66
68
69
71
74
77
78
80
82
96
98
105
107
108
110
113
115
00:00
GoogolPoint cloudScalable Coherent InterfacePoint (geometry)Different (Kate Ryan album)Data managementSoftware frameworkExtreme programmingProjective planeObject (grammar)Computer configurationBitWave packetSet (mathematics)Multiplication signMereologyImplementationArithmetic meanReal numberGame controllerShared memoryKanban <Informatik>WordLattice (order)Integrated development environmentProcess (computing)BuildingSoftware developerState of matterProduct (business)TelecommunicationParameter (computer programming)Scheduling (computing)CodeCASE <Informatik>Social classMathematicsDependent and independent variablesMixed realityGroup actionDynamical systemLecture/ConferenceComputer animation
09:47
Demo (music)MathematicsPoint (geometry)Group actionElectronic program guideGame theorySurfaceSimilarity (geometry)Product (business)Link (knot theory)Process (computing)Lattice (order)Game theoryMereologySoftware developerFood energySpring (hydrology)Green's functionPerfect groupOnline helpPoint (geometry)Multiplication signDifferent (Kate Ryan album)Order (biology)Arithmetic progressionQuicksortResultantForm (programming)Local ringInteractive televisionMoment (mathematics)Touchscreen1 (number)Beat (acoustics)Right angleMultiplicationBuildingDemo (music)Uniform resource locatorMathematicsFormal grammarPlanningInternet forumCodeCodeComputer animation
19:20
MathematicsComputer animation
19:43
InformationTwitterProjective planeHorizonComputer animation
20:17
InformationTwitterMultiplication signProduct (business)Process (computing)Lecture/ConferenceComputer animation
20:52
MathematicsProduct (business)Data managementMultiplication signNP-hardDifferent (Kate Ryan album)Level (video gaming)Uniform resource locatorImage resolutionProcess (computing)Arithmetic progressionTrailQuicksortSelf-organizationRule of inferenceGoodness of fitStandard deviationLecture/Conference
Transcript: English(auto-generated)
00:04
Hello, everyone. Today, we are going to have something really interesting, like a journey from hell to paradise. I am a software developer. I am not a Scrum master. I do Python. I love Python. And I still love Agile.
00:24
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?
00:41
Raise a 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.
01:01
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 I, all hope abandons 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
01:21
as he had, but together with our Virgilius 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,
01:42
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?
02:00
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 a moment. And deliver frequently.
02:20
We all need agility in our projects. We want to be flexible and we want to be 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, Extreme Programming, Crystal, Dynamic Systems Development Method,
02:41
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? Usually 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?
03:04
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, first of all, I would like to tell you
03:22
that agile is not a noun. It's an adjective. It's like he is. He is an agile. He is 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,
03:41
agile became a buzzword and every company would like to implement it. 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.
04:01
So let our journey begin. Together with our agile 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,
04:20
to me as a team member? Let's imagine that our company has a goal. They want to be productive.
04:40
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.
05:02
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
05:21
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
05:42
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.
06:03
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
06:22
to control if the project is on time, if everything is on schedule, if everything is delivered. And it's kind of not a 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.
06:41
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,
07:02
to deliver on time, to know which meetings do they need to set up, to get a bit of feeling how should it work. And there are even nice trainings I had that for the company, but the problem afterwards that the team should set up it. And then the company who is running all the workshops,
07:21
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.
07:42
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.
08:00
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
08:20
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
08:41
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 as a full-time job,
09:01
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,
09:22
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.
09:42
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
10:00
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. 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.
10:21
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?
10:43
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.
11:02
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.
11:22
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 team. 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.
11:46
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
12:02
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,
12:20
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, the daily stand-up, the sprint review, the demo, the retrospective, and the sprint planning, and many more.
12:41
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,
13:00
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.
13:22
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 the 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.
13:44
So how to make it fun? There are multiple solutions. First, change the location. If you are 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,
14:03
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?
14:21
That'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 and the way which you would like to have.
14:41
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.
15:01
And changing the order. You can, for example, bring the big bowl and then throw 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.
15:23
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.
15:43
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.
16:01
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.
16:22
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 spring because somebody from the team brought a chocolate and it was improvement, of course, so it worked. And to making your retrospectives even more fun,
16:43
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,
17:00
we were losing money and like just doing that and the name was Wolf of the Wall Street. And here's the paradise, almost so close. We are almost there, but there is one but. The overall knowledge about our scrum.
17:25
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 it and that we don't really know it. It's a hard question, how to discover this part?
17:43
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
18:01
and playing at work. It's not just about scrum or agile or any methodology. It's about methods, how to sex up your products and how to deliver based on the customer because customer usually doesn't really know what they want.
18:21
They are frustrated. Sometimes they really know like we need these but sometimes they like, oh, 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.
18:41
Sometimes on the way to paradise, we meet zombies. Why are we talking about zombies in 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,
19:03
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.
19:25
They will suggest to you how to discover if your scrum is a zombie scrum and how to fix it. It's zombie scrum resistance.
19:48
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.
20:01
Thank you. Thanks a lot Anastasia. I found myself and how I work in my team in many things you talk about.
20:22
I'm happy. I'm enjoying it. Thank you. And do you have question? See? Hi. I have a question regarding external influences. So you want to improve your processes,
20:40
maybe bring in more automation, more CICD but always the product owners or some senior business people, they always want more products, right? And they generally don't give you enough time to work on your technical debt and things like those. Do you have experiences with that and how do you influence those guys who are outside the team?
21:00
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
21:21
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,
21:41
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, for some big companies when they are not flexible at all.
22:02
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
22:21
but you're not. And afterwards, when the scrum master or somebody from the team is showing the progress, then they're very happy and surprised. Another question? I think like sometimes with stand-ups,
22:43
when a manager's 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?
23:01
Different people in the team? Different people as in, I'd say like 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 current company, I recently started and it was kind of a challenge for me to find
23:21
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,
23:41
it's like 20 people standing around and we still manage 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 want it to have a change of opinions and be on the same track every day.
24:02
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 change in.
24:21
Thanks for your talk. What is the difference between a scrum master and just a middle manager? And the manager. And the middle manager, yes. Just somebody who is sort of above the team and is responsible for higher levels of management. I mean they do management and the scrum master doesn't.
24:41
Scrum master is responsible for the team's happiness. So it's kind of 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
25:02
to be resolved by the scrum master. And the scrum master could go to the management and ask for resolutions. But usually, yeah, they do everything. So the scrum master has to protect the team from the management. Good question, thank you.
25:22
Question? We have time for another couple of question if you have. So thanks a lot again, Anastasia. And see you soon in Berlin. Okay.