 Okay, so hello everyone. Thank you for coming staying a little bit longer for us My name is Pavel Neymar. This is Fernando Cualone. We are both agile practitioners in Red Hat and Today we are going to speak about why processes are much more important than people and You may ask why we think that we think that because It's one of the values of agile manifesto. You see, right? or Or is actually other way around Of course, it's other way around. It's individuals and interactions over processes and tools and don't get us wrong We don't think that the processes are not important Of course every project or work needs our processes definition of done scope budget and cetera, etc but we should not forget that the people are Delivering the product people are defining the scope the definition who have done people are using the tools and infrastructure and People are defining the very processes. We are using every day So only if you develop if you focus on developing teams and individuals and you are paying interactions Paying paying attention to interactions. We are having every day Then this makes you set up the project for success much better but sometimes we don't do that sometimes as if we forgot that Individuals are over processes and sometimes we don't do that because it's not easy People are complex and sometimes the interactions are not comfortable. So we are avoiding this but luckily we have the agile manifesto Who helps us remind us that? individuals interactions are over processes and tools it was already mentioned in the finalist first presentation that The scrum and agile manifesto sometimes are used interchangeably, but obviously it's not true The manifesto of agile software development speaks about values and principles and the people who wrote it and sign it believe That when you follow the principles and when you leave the values that is the better way how to deliver software on the other hand we have a Frameworks like scrum and Kanban or XP and these are system with specific rules and roles Which helps us create environment in which we can leave the values and practice the principles easier But they are not the same thing obviously roles and rules are not the same as values and principles and we should keep that in mind so the implication of this is that you can leave a value of values without actually Using any specific rules. So there are teams which are not using scrum or Kanban and anything's particular But they can still pursue the agile software development Unfortunately, it can be true. So other way around You can follow order rules of any specific framework, but you can still do not living a value Right, you can have all the retrospectional the ceremonies, but if you don't understand what they are for You are not pursuing the agile software development. Anyway, oh very descriptive slide. So There are two typical mistakes we are doing with this pursue of agile software development So first we tend to impose the frameworks on teams and The second we impose that without giving them support so they understand how they use it and Then if such a things happens The framework is only administration for the team for the team and it's perceived as a as Something additional right and it's get a bad reputation and then your team fails and We're gonna blame The framework obviously and it makes sense because The framework is the thing which brought us all the meetings on the rules and on the rules. We do not understand So when we impose Framework on a team without additional support It's very likely that the framework the change we brought will get the bad reputation And of course I can ask I mean why are you blaming the framework the framework is only a tool You choose the tool But do not forget that unfortunately sometimes the people are Not the one who choose the tool someone choose the tool for them and didn't give them enough additional support to understand how to use the tool and Fernando is going to speak about the consequence so we work with a lot of people at Red Hat and We talked a lot to them about Adjo and It's very interesting that they always have some complaints or you know some not so nice feedback about it and I will show here some typical things that they say about scram about adjo in general and I will go Quickly on maybe what's behind on those things or those complaints So the first one from from software engineers in general at the Red Hat that we Talk to is that we have too many meetings, right? They are saying we have too many meetings or you know the the meetings are just too long Why is scram is telling us to know we have Planings and retrospectives and they listen why why we have so many meetings But the fact is that if a team is doing working with scram, for example If they are working in a two-week sprint They should be spending around I don't know two weeks 40 hours a week 80 hours They should be being this is chrome meetings for seven hours eight hours, so 10% if They are having these more meetings Then the problem is not with the scrum. This is not with the meetings or the things that scrum is saying that they should do Maybe maybe the problem is elsewhere. Maybe the problem is with that Very messy product backlog. Maybe the problem is the team does not know Why they are doing the things that they are doing. They don't know the goal So it's elsewhere. So this is one of the things that one of the software software engineers tend to talk about when we Are working with scrum specifically The other thing that some of the software engineers thing is like micromanagement, right? it's like you are always Asking for things, but don't confuse micromanagement with Transparency, right when we want everyone to talk to each other show the results and When we have the scrum meetings the scrum ceremonies It's not for the scrum master. It's not for the product owner, right? It's really for the team to communicate and understand Where they are right for my teams When I I don't know sometimes I don't go to a daily stand up and They say you didn't go. I said, yeah, I don't need to did you go? Yes I don't need to be there. I need just make sure that the team is having those Stand-ups and communicating with each other. So that's another thing that they say Another thing is that all of this is too complex for me. Oh my god. I just want to code Right leaving the dream Right. I just want to code. I don't want to think about value I don't want to think about, you know Other things I don't want you. Oh my god. Talk to other people. I don't want this I just want to code and this environment seems to be so complex and you know what? the agile software environment agile is more it's Healthier in in the complex environment, right? It works best in a complex environment And software development is a complex environment. So, you know These are the things that software engineers would have to to deal with you are in a very complex environment The other thing that it's a kind of complaint is that frameworks and methodologies are not flexible enough, right? So you think about Scrum. Oh my god 15 minutes stand up if you have a two-week spring everything is Timeboxed, but the thing is is that with this Frameworks with these methodologies What you are getting is you're getting the short feedback cycle if you were here in the previous sessions you saw Stuart talking about it other people talk about it because it's very important, right? The short feedback cycle is very important. So you have the time box because it also give brings Consistency to what you are doing and if it brings Consistency in the long-term will reduce the complexity of what you're doing The next one is like we don't have the opportunity to fail at all and Well That's right, right? You don't have the opportunity to fail if you fail we the scrum police We're gonna get you and you are in big trouble. No, that's not the case in fact You can fail and If you fail you just should learn young is not here young There was a great talk this morning about Product owner and he mentioned this it's okay to fail right if you learn Something and as I just mentioned you have the short feedback cycle, right? So if you fail you can learn and recover fast Maybe in in a two-week sprint three-week sprint and not in a two-year cycle when you are just delivering your product, right? And the last one is that it doesn't work with distributed teams. Well We have challenges. Yes time zones, you know lack of personal Relationships, but we are in a global environment and it really it can work and It is and there are ways to to make it happen. So You know, these are the complaints that some of the complaints that we Seen and we talked to people about and the thing is is that we need we as adju practitioners We need to work with the people with the teams to let them define their own way how to be agile, right? So not as Pavel said, we are not imposing anything. We are just working with them to make them better So they are defining their way how to be agile and always with those 12 principles in mind, right? To satisfy the customer, you don't need scram You just need to have in your mind that what you want to do when you're doing whatever that you're doing That you are satisfying someone or it's your customer. So Let them work in their own way to be how to be agile, but always keeping this in mind and I have an example This is one of my teams. They are working with scram. They are working in two-week sprints They have their reviews. They have their retrospectives But when I joined, you know the first planning meeting that I went there Two-week sprints, I think they were in the room for five hours, right five hours. Don't remember It's like the morning and the afternoon and what was the problem there It was not that the scrum meeting the planning meeting that this scrum was the problem it was because The the backlog was not prioritized or they didn't have any goals To achieve and so it's just long discussions about nothing that is related to the planning, right? So and We at your practitioners, we work with them and we try to see these problems and with incremental changes, we try to improve them and now Pavel is gonna talk about one of his things Okay, okay, so Another team from my from my experience, so they don't use any specific framework It's like combination of everything they heard I think and But they have kind of a monthly planning We can say this and they have a weekly synchronization meeting when they check Regulary when they are on the track with the plan and one day that they thought that maybe this weekly meeting is too much You know, it's a one hour for everyone very difficult conversation And maybe it's not fragment enough. Maybe we would like to have two meetings half an hour each during the week And we have a discussion and we came to the conclusion then we have any heavy have no idea What's better because we couldn't foresee all the implications which it may have So we made experiment we tried for a month and after a month we can together again and decided whether it works for us or not The decision was that it doesn't work. So we went back for The one weekly meeting what we are trying to say is that we are borrowing this stuff from Stuart. So thank you So you should pursue incremental improvements. What does it mean that you should always try to be better? But only small steps do not change everything at once because then you will first go right in the hairs And the second you will have no idea which change brought you the benefit and which change make situation worse and Yes, please experiment You have to admit that you are not going always to see all the implications of the change you are proposing So it's always safe to try for some time days weeks months depending on the change and Revered back if that doesn't make sense Make your own way how to achieve what you want to achieve and the last thing is Please revisit if what you do currently still make sense because sometimes you forget that The environment around those changes and the people are changes that we are still keeping doing the same thing over and over again Because we always did it So revisit what you did what you do whether it still applies for the situation and The last thing before we end a gel has no brain. So please use your own and Keep in mind that the frameworks are not here to solve the problems for you They are here only to make the problems more visible so that you can solve it Okay, not every time it's a comfortable thing, you know, not it's not easy to look at ourselves and see our Priorities are unclear. Our scope is unclear. We don't have no vision but otherwise how else we are going to improve and So this is our the key takeaways from the presentation if you forget already so you can leave values without any specific rules Let people define their own way how to pursue a job software development pursue incremental improvement experiment and Revisit if the practice you are using still makes sense for you now Thank you. Thank you. Thank you For a team that has no Basically any kind of framework Well, what would you suggest? Where would you suggest to start with? Because you said to do something incrementally so where to start from so If you want to pursue a job software development start for example with the principles Start with the values and take a look at what you are doing now whether it's reflects there or not and If you have some stuff which you think don't reflect there pick one and try to change stuff And that's all Important is to have the discussion about it with your team so that you have the buy-in from the team Then they would like to experiment especially if you are new and you don't have any, you know a job practitioner or anything Most likely you are going to make some bad choices But that's normal, but you just still need to try to make things different so that you see what fits for you Okay, was helpful Okay, so thank you again and