Thoughts from a meetup on Agile Leadership

Hello, and welcome to the podcast I’m your host, Dave Albert. In the show, I talk about technology building a company as a CTO and co founder and have guests to discuss their roles in technology and entrepreneurship. Hey, folks, in this episode, I’m going to discuss a meetup that I went to regarding building effective teams and leadership. So there were a few things that really sparked some ideas in my mind. And I wanted to share those not necessarily that I have solutions, but at least some questions that I wanted to, you know, bring up to the audience so that maybe you can learn something from it for yourselves as well. Mine and also so I can kind of think through my own faults on the on the issues. The first talk was about Max Kotecha of Stay City. Now, I actually forgotten what his role was there, but it’ll be in the show notes along with a link to his LinkedIn profile. So actually, before I talk about the actual content, he does an interesting thing. Each year, he creates a new presentation and then throughout the year, we’re finds that presentation at different talks. So that not only is the talk getting better, but also his understanding is getting better. So initially, his initial presentation at the beginning of the year is more thought provoking than necessarily dictate on what you should necessarily do and I thought that was really interesting and for someone who, who may be thinks about wanting to be a presenter at at meetups or at conferences, that actually using this method might make a load of sense. So I know from my own experience, sometimes it, I thought about presenting it a meetup. But then I think, I don’t know, I don’t know if there is enough value here. But possibly reframing what you’re trying to accomplish by having basically a straw man to tear down and rebuild throughout the year is a really interesting way to to begin. So on to the content of his talk. So there were a few slides with some really interesting questions. So this was about agile. So building an agile team, I think, I think we really his focus was more within an enterprise a large enterprise, but some of the some of the questions were hit pretty close to home, for instance, the first one is, does your CEO have a backlog? If the answer is no, you are not an agile company. I thought that was interesting. I know, I can see within some of the work we do, but not operating from a single backlog that that makes it even harder to predict when something will be completed. Because there are other dependencies that are unrelated to the actual development of the product that you’re trying to build with agile methodology that interject uncertainty. So it still doesn’t necessarily always make sense for the entire company to operate, you know, speaking as a startup co founder here, so it doesn’t necessarily make sense for the entire backlog to contain everything that everyone in the company does. But if you don’t account for where there is impact, then, of course, that makes prediction, which is already a hard process impossible. Next was, are all the right people at the project kickoff meeting. If you answer No, there will be unexpected disruptions. Ya I know, shocking, right? That one? Yeah, I have no argument, disagreement with that.

Do you have an agile coach? If your answer is no, you are in for a disaster, maybe don’t know, I know that within our team, we definitely cannot rely on me to do all the agile, I don’t even know the right word for that. I mean, I guess coaching, but that’s not really what I mean. I mean, all the different roles that are needed for agile to work smoothly beyond just design development. So, you know, product and Scrum Master all that, so I don’t know, you know, necessarily, if an independent coach versus, a coach type who is a good, whatever the role may be Scrum Master PO I don’t know. Maybe I need to come back and think more on that one. So I guess within a larger organization where you have multiple agile teams that have interdependencies between the themes, they make sense. Yeah, I can see that. I don’t know in a start up love to hear if anybody has strong opinions on that. Is, are any of the scrum masters actually certified in Agile for answers? No. Will you know that right? So I’m not sure what he’s saying here. He didn’t go into detail. I suppose he saying if they’re not actually certified in Agile, are they really Scrum masters? Maybe? I don’t know. I’m not a big fan of certification. I mean, in some instances, yeah. You know, doctors, lawyers, architects, things where there’s, there’s significant danger. I mean, software development can imply significant danger in some instances, especially when you consider embedded systems. First, a life saving equipment but I digress. In technology, I’m not a big fan of certifications. I’ve seen too many boot camps that just push you through so that you have the knowledge in your head for the week and then you can regurgitate that information but then never apply it. So I don’t know about that one but here’s where we really start to get to it. These scrums, do scrums last more than 15 minutes. If the answer is bigger than 15, you’re not doing it right. Yeah, I know that for a fact, a number of our stand ups have run way longer than 15 minutes. They’re almost more like mini grooming sessions. And I think part of that is from not having an additional grooming session or actually not having a scrum master. So trying to do all of those things within the stand up. We’ve now, we have an agile intern who has project management and software development experience. So we’re going to see how that goes. And potentially having someone in that role can keep the hygiene of our backlog and work in progress at a much higher level, which should significantly speed up, st.and up. Then do you do retrospective meetings and other ceremonies? If your answer is No, you are not doing it right. Yep, we have failed to do retrospectives for quite some time. Now, we do sort of cram a little bit of that into our weekly team, weekly company meeting with what can we do better. But we have not done a good job of having retrospectives. And I think we’re going to try to start incorporating that in the proper way to drive forward some better practices within the team and maybe a little more contemplation of the individual week so we have more detail in the contemplation then in general, the general feeling of what we think should or could be improved. The second talk was by Helen Duffy of DXC Technology. Oh, actually, sorry. That’s right. Before we get into Helen Duffy of DXC, we actually want to look at a few more slides or one more slide anyway, that max presented.

Is your campaign board lacking detail. If your answer is yes, you’re better off a scrum. Perhaps, that actually, I mean, the statement makes loads of sense, my perhaps, is perhaps where we have tried to how we’re doing, we’re not really doing Kanban, we’re not really doing Scrum. We’re doing a Scrum Ban faster that is not as effective as it could be. We’re by no means a bad team. I just mean that I know that we’re at a seven or eight. And I know that this team could be at an 11. So we need to keep tightening up finding, practicing and improving so that we can get to where we should be and so we need to take a hard look at what our detailing process of deliverables are, which we know and figure out what the right format is. And that that’s a good maxim that just you know lacking details, better off with Scrum. Is your Scrum board full of details? If the answer is yes, you are better off with KanBan. Is your product owner, part of the DevOps team? If you If you say no, you probably picked a business person. Well done. Yeah. So definitely, I mean, the tech team, picking what to work on based on being, you know, a product owner with within part of the development team, your perspectives are never going to be quite the same. So I don’t know if we’re doing a disservice with that. Because we don’t really have product owner, the person best suited is our CEO. But she just is not available for the time to do that on a on a full time or even halftime basis. She still does have significant influence over what we work on. And that’s exactly what we need. But it’s really it’s a really good point that the product owner should be talking about value delivered versus features implemented. Do you use JIRA for Scrum or Trello for Kanban? Madness if you say No. We do use Trello, we also use product board, as I’ve mentioned before, product board for road mapping and planning. And actually, we’ve started to use it even a little bit more for the actual day to day tasks, because there’s not a load of overlap that we need between multiple people at the same time that isn’t already kind of handled through other channels. So I mentioned before I have the argument with myself, do we have the right tools? Should we go with JIRA? Not yet I don’t think it’s right now, this, this brought it back up again, you know, so I don’t know the right the right tooling for us, because we need to understand our longer term objectives and be able to implement them through the tools and track our tasks and the work. So I don’t know, it’s our intern, and, you know, obviously, a more experienced person would be better suited for the role. But we have what we have, but having someone totally focused on that with the entire team interested in making sure that we drive ourselves forward, we may be making changes in the future with tools that we use, I don’t know yet. I know, JIRA has some things that I wish we had, which product board covers a decent amount of. I prefer Trello sort of,I don’t know, it’s so hard. I wonder what would have happened had I just went with JIRA from the beginning. I wonder if I would have been at this point, trying to say, yeah, we don’t need JIRA how can we move all these over to Trello? You know, that’s, that is when you have choices, you never know what the right choices because you can only make one choice at a time

I mean, one for one concept that you’re trying to choose between.

Are your user stories short, if you answer yes you’re actually doing it right. Okay. I don’t have an opinion on that. I suppose if they were too detailed, then. Yeah, no, okay. Okay. Yes, that makes 100% sense. And I 100% agree now, because if they’re too long, then you’ve he must have gone into implementation details, as opposed to, as a user, I want to be able to do X, then there’s freedom within the team on how to implement that, as opposed to, as a user, I want to be able to go to this menu item, select this thing, do this bit, enter this text, and have this result, there’s no freedom there. I suppose in some cases that may be necessary for, say, compliance or other types of very detailed reasons. But then again, it could be based on these set of rules, I want to be able to do X. So But yeah, I can, I can, in general, I can see how that is, is is is a very important statement. Let me see quickly that I just take multiple pictures of that slide or an app. Okay, so now back to Helen, Helen Duffy of DXC technology. She had a few slides on leadership. And I will see if I can find her LinkedIn profile, or Twitter or some some link to who she is, so that I’m not trying to take credit for her thoughts. So one of the things that really stuck out for me from her talk was leadership challenges to number so motivating teams,set people stretch goals, and ensure that at least part of what they are working on is new and interesting. Absolutely, it’s, it’s hard when you have say, a junior person who is most suited to resolve small bugs, small UI changes, you can’t just leave them doing that all the time. If you do that going to get bored and eventually leave. So you have to try to make sure that they’re continually growing and enjoying what they do. And it’s the same for, you know, more senior people, if you’ve got, say, a large project like a data center move, it takes, you know, some experience and skill to do that. So you need to make sure that there’s something in there that’s of interest, and not just moving one set of bits from one box to another box that is not interesting or exciting. So, you know, people people like to grow, at least the people I like to work with, like to grow. So make sure that they’re able to encourage innovation. And that’s done by listening to new ideas and not punishing failure. That’s, I think, within tech industry in general, we have a really hard time with that building technology is so exacting, you know, you can’t you miss a semi colon and your programs broken, do you have a wrong capitalization, you may have issues where, you know, your program doesn’t work. So we’re already at risk of being in a negative mindset and so expecting perfection on top of that, and then being overly disappointed when trying to create something out of thin air, then punishing the failure that you’re just gonna have people stay on their boxes. So definitely agree with that, you know, recognizing people’s achievements publicly, for sure. Let people take responsibility for decision making in their area of expertise. Yes, don’t not dictating to others that are reporting to you when they may know more about the actual details, that that doesn’t make sense. So with people who know what they’re doing, do so and make the decisions based on that. Innovation, slide number four, give your team room to innovate, don’t just pay lip service to it innovation is the lifeblood of companies today, ensure that people’s workloads allows for self development, online research and training and new technology hundred percent. And I was that was I think that might have been the actual biggest thing that I wanted to talk about. Because slack time has been one of the big things that we’ve had issue with which anybody who knows me knows I’m a big fan of Eli gold rats work the goal and all the other books really as well as the Phoenix project. But you know, if if you don’t have slack time, if you’re 100% busy, then everything will be late. Always. Because there’s no room for error. There’s no room for surprise priorities, so everything must wait. And then when they’re interdependencies, that becomes an even bigger issue. So having slack time is eminently important to be able to move consistently move forward, what better time to make sure that they have room for growing. So I’m not saying that that should always be into, but if you ensure that they have the time to grow, then that also gives you that buffer. I’m not sure I’m not sure how to say how we would rate on that. I mean, we give people however much time to do things as they need. I mean, we do try to deliver in a reasonable amount of time. But it’s interesting, I have to think on that one little bit more. And the seed was that one more slide. No, that last slide was from a different meetup but not of interest to discuss in this podcast episode, which has gone beyond the quick take five to 10 minutes. so this was originally supposed to be a quick take. I’ll try to remember to chop off that first intro and add a new intro. But yeah, so I would love to hear others thoughts on this. As always, you can tweet me @Dave_Albert or email me [email protected]. Thanks for listening. Until next time, remember, any sufficiently advanced technology is indistinguishable from magic.