What I've learned about Scrum from being a Product Manager

Hello there! Today, I want to talk about some of the things I've discovered about scrum and agile from my experience, working as a product manager full time over the past six months. Long story short, as you probably know if you've listened to my podcast, I've learned about scrum seven years ago. I got to see it being implemented in a very talented strong engineering team. Now, that I look back I realized why I was so impressed and the reason why I was so impressed is that it was used well, it was used by the right people in the right organization with the right mission, right attitudes, and priorities coming from leadership. But back then, I just thought that it was the power of scrum. I got to work with the engineering team on building some of the functionality for some of the operational tools. I loved it. I loved the idea of sprints, stories, user journeys. I love the idea of sprint planning, sprint reviews. Then, I want to just study in a more official way so I became a scrum master. I got my certification from the scrum Institute and during my studies, I was also very impressed by some of the philosophy behind it, by some of the examples given to us. Yeah, so without a doubt, I knew that in my next job, I definitely want to use scrum. I want to continue working with engineering teams on building amazing things. The job description that matches my desires was a product manager. I became a product manager and they have another episode on how I went about changing my career from being in operations to now being a product manager using some of the scrum principles. Long story short, I'd been a product manager for the past six months. I work ed in a tech startup. We have several engineering teams and I get to work with all of them. I think the most important part is I get to observe scrum being used in different teams, by different people with different engineering managers. I think what I've discovered is that scrum is a great and powerful tool, but it's not the magic wand. It still depends on the team culture, on the leadership team, the individuals to make sure that this tool is being used in the right way. So, one of the things I've also discovered is that there is such a thing as a short sprint. Our sprints are two weeks and I was told that it's pretty much an industry standard. It's very common to have sprints two to three weeks, but I think given the small teams that we have and therefore small velocity. A velocity means how much work like units of work a team can do in a sprint. When you have a small team with a small velocity and that's another topic for why the velocity is small, but with a small velocity, two weeks sprint. Too short, of the first print, in my opinion. Every other week is booked with a bunch of scrum-related ceremonies, meaning sprint planning, sprint review, technical planning, and some other stuff. A lot of the time is eaten up by all these meetings, and then you have only one week and a half to get some work done, and then it's not enough time. So in my opinion, when you have small velocity, it's better to have three weeks of a sprint, maybe more, but I think even having this one extra week is better. If your sprint is too short, then a lot of them, as we call them stories, migrate to the next sprint, right? Because they can't be completed in two weeks, some of them. In order to avoid a lot of this few over, I think it's useful to increase the duration of a sprint. Another thing that I've learned is that if done incorrectly, scrum can still require a lot of meetings, and some people, all of us push for more meetings because meetings are a great place to hide. In the ideal world, in the ideal engineering team, you would have a daily standup, which lasts for 15 minutes and that's the only meeting you will have for a day. Before the sprint, you would have your sprint planning meetings. Then at the end of the sprint, you’ll have your sprint review. And these meetings are supposed to eliminate the need for any other meetings. So, you can have more free time to actually dive deep into your work and code and produce something. But I feel like we live in not so perfect world where some individuals don't "like to" code or they don't "want to" code and they would always push for more meetings to discuss some stuff, that's because meetings are a great place to hide. You're not producing anything during this meeting. And so, scrum, yes theoretically it should get rid of a lot of the meetings, but if you have some individuals on your team who are pushing for more meetings, scrum is not gonna resolve this issue. You need to resolve the issue with the individuals and realize why they’re always pushing for more meetings and maybe come up with some other ideas, but scrum is not going to solve. On the topic of the individual, I think scrum works really well in the teams that consist of individuals with high personal ownership. That's what I got to observe from like working with different than engineering team working with different than engineering team in my previous jobs. And now in this job, I work with multiple engineering teams. The teams where people are volunteering for doing some work, so, during sprint review, you would have like, let's say 10 tickets that you want to complete 10 units of work. And then when you have individuals saying, hey, I want to take on ticket 1, 2, 3, and then another individual says, okay, I want to focus on ticket 5, 6, 7, and then there are proactive in assigning these tickets to themselves because while maybe they are passionate about it, or maybe they want to learn more about this new language that they're using or the new tool or whatever. I find that a lot of the engineers, love to learn and that's also what motivates them and that they would like to work on the tickets that are new and that will give them an opportunity to expand their skillset. So, they would definitely volunteer to take on this job. But there are some teams that are very reluctant to assign tickets to individuals. These are the teams that are usually struggling with velocity, that usually have a lot of spills over into the next sprint. Yes, under a scrum, you work as a team, you don't really have individuals and your velocity is measured on the team level and not on the individual level. And that's fine, but here at team velocity cannot be high unless you have individuals with strong personal ownership of their work and who are willing to proactively take on more work or at least, you know, the normal amount of work. So, scrum is not gonna be this magical solution unless you have people, who are excited about the project, who want to learn more, who want to expand their knowledge and skillset. And if you have these individuals, then yes, scrum is going to be so smooth, so beautiful you're going to love it. Another thing that I've learned is that scrum is often being advertised as. Uh, solution for companies to be inflexible, assist solution to pivot very quickly if needed and on average, that is true. But again, it all depends on individuals. If you have individuals on your team who are very outspoken, but at the same time they resist change a lot. Then these few individuals can affect the culture of the entire team, just because they express their opinion very loudly. They talk more than anyone else. And if those individuals do not want to change, if they ask a lot of questions, if they complain that the pivot is going to take too much of the time of their work or whatever. This person can ruin agile for everyone else because then the pivoting becomes very difficult, even though you're using agile and scrum. because It takes a lot of effort to convince these individuals to change. Yep, So, if you're thinking of implementing agile in your team hoping that it will make your team more flexible, dynamic and excited for change overnight, it's not going to happen. You really need to look at each individual and kind of see into their personality. See, if they will be able to adapt to change and who will be excited about change? But the change brings a chance of failure and people should be okay with it and not all people are okay with it. And Another thing that I've learned is that perfectionism is still an enemy. When I learned about scrum and how I personally implemented in my life and what they teach within the monthly method, is the power of the definition of done. For every goal that you set for yourself, you should have a very clear definition of done. It helped me with perfectionism. Let's say you have a sprint goal of making your office look nice, right? Or setting up your office. So, what's the definition of done, given that you only have one sprint to do it. And The definition of done is the concept that once you have a defined, another person can look at the result of your work and read the definition of done and say, yeah, this is done because this was the definition of done. So, it's very objective. There is not much subjectivity going on. The definition of done for an office might be the walls are painted. I have one to two plants, like green plants in my office. I have at least one painting. I have a desk and a bookshelf. If you didn't have the definition of done, then how do you define if your office is complete? It becomes very subjective. For you, it might be one painting on the wall. For someone else, it might be three. And for you have the rug on the floor is a part of the definition of done for someone not so much. Right? 15 min So usually the definition of done helps you to limit the scope of a project and not to go over. But when you have individuals who are still suffering from perfectionism. If the two managers not paying attention and not being a bit tough, they can still spend too much time on one ticket, even though the definition of done does not require. The perfectionism in the engineering team can be writing too many tests, thinking too much about validation, thinking too much about UI, playing too much with different angels, colors and all of that. So, there's all this a place to hide, even though you might have a clear definition of done. Yes, it helps, I think it helps for 80% of people, but you'll still have 20% of people on your team who are suffering from perfectionism disease. You still need to spend a little bit more time, in the beginning, mentoring them and teaching them that it's okay, you know, to ship the work, even if it's not perfect, as long as we can move to the next tickets. Also, scrum can be a place of calm or the place of chaos, often based on the higher leadership team and their skills of prioritization and strategy. If everything is urgent and important, then your sprint planning will be chaos and it's going to be very stressful. So, if you don't have this clear prioritization coming down the pipeline from the leadership that will help you to say, okay, those are the most important things. those are the second next most important things. This third group of things can wait until one and two are done. And Then, your sprint planning sessions become very stressful because you're trying to squeeze everything into one sprint and that's impossible, it's stressful for everyone. It's just a leadership team being impatient or not having a clear vision or not having a clear list of priorities and unrealistic expectations on the timeline. This often trickles down to the engineering team, to the product team, and then the entire scrum, like all this scrum ceremonies become very stressful. So, if you're in leadership and thinking about implementing agile in your teams, you still need to understand that you as a leader will have to provide this clear vision and clear sense of priority and different levels of urgency on different projects. If everything is urgent and important, then nothing is truly urgent and important. But if you have everything organized in some document or whatever, then it becomes easier for the engineering and product team to run these meetings, to plan accordingly and then they can have a justification for why they had to say no, to some of the tickets, to some of the work, because it didn't fit inside this sprint. So, it becomes a calm place to be, to run your teams and manage the projects and the work that has been passed down. I think the last thing that I've learned was about sprint reviews. As you probably know, under the monthly method, they have this concept of a sprint review. That's where you review your sprint and you look at what went well, what didn't go so well and what can be improved going for. You can divide it into three columns, such as stop, start, and continue different things. But basically, this is a regular ceremony that you have where you can quickly reflect on your mistakes, learn your lessons, and move forward with this new way of doing things. In my experience, sprint reviews are only useful when you create the tickets and you schedule them for the next few sprints. If you don't create any actionable points, then it just becomes a negative place where people just come to complain. In my opinion, if I was running the sprint review sessions, which I'm not. I would impose the rule that for every negative thing that you put, you have to put the corresponding item in the next column where it says how we can improve going forward. I think that's the rule that must be implemented. Otherwise, again, it becomes a very toxic place to be. I've had this experience myself, where we had teams that went through this toxic cycle of sprint reviews and it was a very miserable meeting to be and because everyone was focusing on what didn't go well and how everything sucks, but no one was offering solutions. And it's draining for everyone, for the person who's complaining, for people who are listening to that person complain, it's not a good place to be. It's important to discuss things that didn't go well, I'm not saying that you should hide from all the failures and not acknowledge them, but when you do, you shouldn't spend too much time complaining. You should always spend more time on saying, yeah, okay, this happened, didn't work, it sucked, but what did we learn from it, and how we can improve? If it's an actionable item, create the ticket right away. Put it on the schedule for the next sprint or the sprint after, but at least, you know, kind of make it actionable, right away. So, that's all that I've learned so far, I think when you have a great team or at least when you have a team consisting of individuals who are proactive or who are willing to be taught to be proactive because sometimes you have junior developers who are just shy and that's okay. You can teach them, you can mentor them, you can empower them. The fact that they're not proactive right now doesn't mean they "can't" become proactive down the line. You can change people and I've seen it happen with the right engineering managers. I've seen the teams being completely transformed. It is definitely possible. But again, scrum will not work if you have individuals who are not excited about doing the work, who would rather hide in meetings and complain. It works great for people who are willing to change, willing to fail, and learn quickly. For people who embrace new things. When you implement agile and scrum as a leader, you also need to think about how you can help individual contributors to shift their personalities, shift their mindset. You need to spend as much if not more time working and mentoring individuals to embrace scrum philosophy and core scrum principles. If you have this new concept, this new framework of how you do work, but people still have the mindset of a old way of doing things and the fears that were imposed on them. Fears of failure, fears of the work not being perfect, fears of blame and all of that. Then the fact that this new framework of agile is not going to change anything. I just wanted to share, in case you are thinking of bringing agile into your workplace, and also I just confirmed one more time that some of the things that we have inside the monthly method, works really well on the individual level because people who decide to work with me and who decide to embrace the monthly method, they have all these core personality traits that guarantee scrum being successful. So, they're already proactive, they have personal ownership, they're willing to work. They're willing to find their perfectionism. They're excited about the definition of done. They see some benefits. People who find this podcast, people who find monthly methods, are the people who have the right personality and the right mindset. So, without a doubt, it works for them. But when we're talking about team management, teams consist of different personalities and that's where you have to be a lot more careful and you can really assume that it's just going to work overnight. Please subscribe if you want to have a freshly baked episode delivered to you, next Monday. And that sets for today, have a fantastic week. I'll talk to you next Monday. Bye.