AgileData #1 - Thoughts of a new scrum master with Juan Dione

Welcome to the Agile BI Podcast, where we chat with guests, or sometimes just to ourselves, about being agile with teams who are delivering data analytics and visualizations.

Good morning, folks. Well, today we're joined by Juan Dion, who started working with me as a trainee Scrum Master. So Juan's been with me for about a month now, and I just want to find out his first impressions of Agile. How we deal with Agile, what things we can actually improve on, and what things we're doing really well. So we'll start off by saying congratulations for getting the job for starters, but welcome here.

Thank you very much, Blair, for the introduction, and thank you for the congratulations. It's been a pretty good month so far. And discussing impressions, well, we already had a few conversations along the few instances of Scrum that we've seen throughout this time. I guess that we mentioned, for instance, yesterday about the daily standup and that we have a couple of people that are very technical people that get along and sometimes kind of get into deep details and don't favor the use of the standup in actually the intended way. I guess that that's just the constant effort of the Scrum Master to maintain certain ground rules and making sure the development team is able to go through them.

That's right. And I think when you start to come along to retrospectives, we'll talk about those things. You know, like I try and get something tangible for us to work on out of each retrospective. So in the past we've had you know, let's try and make the stand-ups no more than 15 minutes and have some sort of signal to the technical people that you talk about to just, you know, keep it at a high level and take it offline after the stand-up.

So you guys finding that they're starting to problem solve? So rather than just giving a status update of where they're at, are they starting to deep dive into actually, here's a problem and I'm going to go work on it, but at the the team in the standup are starting to now actually discuss the issue and start to troubleshoot or problem solve as a group.

Yeah.

Yeah. So Shane, we'd really like your sort of expertise on this. Because sometimes it's really good stuff that they're discussing and you sort of, you've got some team members that start to, their eyes start to glaze over because it's not actually anything that they know about or anything that's their sort of expertise. But then again, you're actually solving proper problems, so it's finding that balance, I suppose.

Yeah, and look, we see it all the time. So, you know, people start off, they're not used to the stand-up, so you take them through what a stand-up's about, you tell them it's 15 minutes, what I did today, what I'm doing tomorrow, any problems. And because they're new, you know, it's all fresh and they kind of follow that process. And then after a while, you know, they get familiar and comfortable and they start regressing off into more of a grooming process or a troubleshooting process. Best thing I've ever found is just bring it back during the retrospective, right? Say, hey, look, we've seen this behavior. You know, they're starting to get too long. They're not for the purpose of problem solving. So remind the team, bring them back to cut it off, and then let them go straight after for the people that are interested and solve that problem. You might want to start a parking lot, right? So you might want to, as they start deep diving, just say, hold that, I'll just put a sticky up here as a parking lot so you guys at the end can discuss it and see if that just brings the behavior back to the behavior that the team should want.

Yeah, that's good because especially in our organization, I see a lot of other teams starting to do stand-ups, and it's not agile at all because they can drag on for quite a bit. And as an agile practitioner, I'm wondering if I can sort of bring that discipline to them and just say, hey, I notice that your stand-ups are going for half an hour. And especially when you're talking with developers and testers, they just want to get shit done, don't they?

Yeah, and the other one, obviously, is go and watch how those teams are behaving for a while. Because often people do just a stand-up, and they say they're agile. They don't bring any of the other ceremonies, any of the other process, any of the team behaviors to the party. They just do a stand-up. So, you know, either they're a team that are following an Agile process and have just requested their stand-ups, or, you know, they're a team following a more Waterfall process and just doing a daily team meeting. If it's the second one, then, you know, just let them carry on.

Let them carry on thinking about their job.

Ask them if they'd like some help and some coaching. Maybe request that they use the the word agile. Yeah, iterative is fine.

Don't tarnish our good name.

Yeah, that's right. But yeah, go have a look and see if you can help them.

That sounds very good. And actually, parking some issues or subjects during the standups will definitely be of help. Another thing that I have noticed so far is that this change that we are trying to take on people and adapt to Scrum to solve problems is Also having an issue within team leads, for instance. Sometimes we've encountered situations where a team lead uses a standup not for the standup intention but for a team meeting. So we have a team lead that's trying to do everything and micromanage instead of just trying to do the simple thing that is ahead. I guess that my perspective there, or the issue that I see there, is that the change to take effect has to come from high to low. It cannot go from the developer to the team lead, and that's not the way to Scrum to me.

Yeah, so within Agile, we don't have a role called team lead. We have product owners/product managers, we have stakeholders, we have developers or team members, and we have a Scrum Master. There's no role called people manager, no role called team lead, no, no, that hierarchy is the thing that we remove. Often an organization will have a people leader or a people manager or a custodian, right, some pastoral care, somebody that looks after their leave and their, you know, their performance reviews if that's mandatory within the organization. But within an agile team, there is no role of team lead. So when that role's within the hierarchy, it's difficult for them because they're used to a traditional way of working and they have to become more of a servient leader rather than a micromanager. So yeah, the key thing is, as a Scrum Master, if somebody takes over any of the ceremonies for purpose, they're not designed for, you just got to shut it down, bring back the, kind of bring the team back to what the ceremony's about. Because if you don't, what happens is you'll start hearing the teams talking about too many meetings, because they go from ceremonies that have value, you know, they're not getting feedback because it's not really a retrospective, they're not improving their process because it's not really a retrospective, they're not making their planning processes faster when they go into the sprint planning because their backlog grooming is not actually grooming the stories. Their demo day is not showing the value they've added because it's been hijacked. So the team will start to find those ceremonies don't have value, right, and start complaining about it purely because they've been hijacked. So my suggestion is, yeah, get the team leads to understand two things. They can run their own team meetings for pastoral care, and when the sprint, the stand-up happens, they're in the second row of the circle because they're not part of the development team. They're not part of the Scrum team. They stand at the back and they listen. They're not at the front and they don't talk. Yeah. I mean, the other thing is you've obviously had a turnover across the different people in the organization. So the new people that come on haven't been through any of the training. So maybe actually put together some more refresher modules and take the new people as a group through and just reiterate what the ceremonies are, what their purposes are, how they work. That way you're kind of starting off in a positive way by saying, hey, let's just— about time we did a refresher and then see if the behavior changes. And if not, then you have to put your Scrum Master boots on and start protecting the team.

Yeah, and it's also easy to assume that when people say that they've already worked in Agile, that they haven't just been a part of a morning stand-up and haven't gone through these ceremonies that Agile has, the backlog grooming. You know, I've talked to people that have said, yeah, I'm doing Agile at the moment, but they're actually just having that morning stand-up. And that's the kind of misconception that's out there, I think, that Agile is just that morning stand-up. So it's easy to assume that when people say that they've got experience in Agile that that they have gone through all of the stuff that we do.

Another interesting thing that I've noticed so far is that what you mentioned already, that we were trying to work in sprints, but there are also waterfall projects around and resources are scattered and you always get to that dogfight, right, for the resources. And that's kind of another challenge that I see within the organization is that You have this very, very important thing that needs to get done, but this waterfall project keeps taking people away from you. And then there's also the hierarchy that we mentioned before, that the team lead, now not from the Scrum perspective, but from actually from their hierarchy, are taking resources away from you. And I guess that there's also a need for anyone that wants to do Agile or Scrum is that You need to be ready to be in a fight for resources, I guess.

So one of the core behaviors for Scrum is there's a team and the team are doing a sprint of a certain period of time and that team is dedicated to that sprint. If that's not the way the organization's behaving, then Scrum probably isn't the right agile approach for them. You may want to move to more of a Kanban or a Lean type probably actually a Kanban approach, but still retaining some of the ceremonies from Scrum that add value. But it becomes difficult because what you're saying is, you know, you're going to hold people accountable for delivering something in a certain, you know, amount of time once they've committed. But once they've made their commitment, you're going to reserve the right to take, you know, half their time off them and give it to somebody else. And that causes two problems. First of all, there's the whole time switching. What people don't understand or don't recognize, and what Scrum helps to fix, is this idea that if I'm doing thing more than one task, you know, I start defocusing. That mental challenge of moving from Task A to Task B and back again means I'll lose a hell of a lot of time, which is why with Scrum, you know, you take one task off the sprint backlog and you bring it onto the board and you work on it until you've completed it. The second thing is then they're probably not going to be part of the planning process for that, those other projects, right? So they're not going to understand the vision or the intent of the project. They're not forming a team. They're not seeing the estimations and the dependencies across the tasks or the stories they need to do. And if they're running in waterfall behavior, they're going to spend a hell of a lot of time up front doing a whole lot of requirements gathering, which they would have forgotten by the time they finally get to a development, or they'll be handed requirements that they can't actually develop from from because they're used to defining the requirements and the development as one go. So, you know, typically the answer is if you say to somebody, I have a sprint team and I'm going to let half their time be given to a waterfall project as well as running the sprint, the answer typically is just no. However, you need to actually have a business agility, you know, you need the business and the senior people within the organization to actually commit to behaving in an agile way and not let that waterfall and agile behavior happen. And again, that's hard.

It is hard. And we've found that out of the 3 or 4 things that we're doing at the moment, they're a hybrid of Scrum, waterfall, Kanban. Yeah, so we've actually got waterfall projects that have come to us and asked for resources, and we've said, well, only if we can run that as a Scrum. So that we will take the requirements from the Agile, from the waterfall project and build a team and deliver that. And that seems to be working okay, it's not ideal. We've also got a couple of things we're building, a couple of Click Apps that are being done as Kanban with ceremonies. So we've got a developer that's cooped away in the corner building the app, we don't talk to him every every day, but we get together once a week and we will do the stand-up, you know, the what are you doing, what have you done this week, what are you doing next week, that sort of thing. And regular contact with the product owner is really important if you're going to have that sort of a hybrid setup. And happy to say that we've got a proper sprint up and running, which is almost like, you know, it's like hallelujah, I'm back, I'm back to what I enjoy. So that will give me a chance to refresh running a retrospective, you know, doing the backlog grooming, keeping the product owner involved on a daily basis. So yeah, it's a little bit of a best fit scenario that we're running. It's not an agile house, 100%, but I guess it's a small shop as well, so we have to accept that. And we've got demanding customers. Who needs customers? My job would be so much easier if I didn't have customers. How many times has that been said?

Famous words of Ed Joel. Yes, and I guess that everything you have said so far applies perfectly to our situation, and I guess that tying everything together, it's all about not losing your mind through the process, because if you look at the big picture, we are working in a government organization where they are used to other things, and this is part of a bigger change, and you need to be constant and help people throughout that change. And it won't be overnight, it probably will take more than a few years, but at least, I guess, in my mind, I can rest in peace in terms that we're going in the right direction. And I guess eventually we will have that kind of structure that we are looking for and, and being more agile, efficient, and effective. So that's my perspective of what's the situation at the time and where we're aiming to get eventually.

So I'll just tell a quick story about— I'll elaborate more on the waterfall project coming to us and asking for resources and us saying, "Yes, you can, but we're going to run it as a sprint. We're going to run a demo day." And the shock that I received when I said that I'm not going to give a committee a full report of progress and almost a Gantt chart. The look of horror on the product owner's face that they couldn't, they didn't have this bit of paper with tasks that would be meaningless to high management, but looks good. They're not going to have that in their arsenal to go to their manager to justify us doing it agile. Yeah, that, that took a bit of getting used to from then, but I think that that's part of the learning process, that if you're going to come and engage with us and ask for things to be built quickly and properly, that, hey, you're not going to get this progress reporting in a PowerPoint presentation. We're going to do a demo day for you. We're going to show you the stuff we've done, and you're going to bring along the stakeholders that you think need to know, and we're going to show you. We're not going to fill out the report. So it's like, wow, really, Blair? I'm not going to get this progress report?

Yep. Yeah, and that's the hard one when you're working in a project-orientated organization. One thing I've found is that often I've tried that same approach and the adoption in the organization has become difficult because of it. So what I tend to do now is to do kind of a product roadmap, yeah, so maybe taking the epics and mapping those out for, with some t-shirt size estimation of what a release might look like. So starting to introduce the concept of release planning to say, we're going to do a release on this date, this is what we think may make it into that release in terms of epics or maybe features. We're not going to commit to any lower level of detail because as we all know, it's not until we've done the work that we know how long it's actually taking. But we're giving them more of a, some form of map that gives them some confidence we're working towards. What will happen is, especially when there's no business agility, becomes a hammer, right? They will start using that as a Gantt chart with milestones that you're promised, and you will run into that, but again, then you just hold the line, which is, that's not the way we work. What we've given you is a guess, like, any guess, but it's based on a bunch, you know, on a series of releases which are made up of a series of sprints, which we have done some very high-level estimates of what the epics or features may be able to deliver in there. And then that way at least you're communicating with them this roadmap and it moves. When you do that, you've got to be really careful that they don't baseline the roadmap.

Yeah, yeah, yeah.

And then start asking you to tell you why it's changed and you know, the only answer you can ever give is change is constant. Every time I give you the next roadmap with, you know, the plan, it's probably gonna change 'cause we've learned a whole lot and we've done some things that we expected to do and we have not done some things that we'd hoped to do. So yes, it will change. I'm just gonna give you the updated version. I'm never, you know, I will not go back and actually tell you what the differences are because that doesn't have value. Rather spend value actually developing and delivering something that works.

Yeah.

But it is a hard one.

Yeah, you've sort of given me an idea of where I could go with this, and that's— so we're going to have a demo day at the end of every sprint, and we're going to show what we've produced during that 3-week time block. I could present that as a PowerPoint and then throw it to the guys to present what You know, I could have bullet points on what we've achieved so far in this sprint, show them the actual documentation artifacts, data warehouse tables, testing scripts, actually show them that, and then have a slide on what we're going to do, what we're trying to do next.

Yeah.

Yeah. And that might keep the people happy.

I mean, one of the techniques I've seen that looked successful was this idea of a press release. So think of yourself as a product company, you know, Apple, when you're launching the latest iPhone. This idea that, you know, at the end of the iteration, you produce a very short press release that says, hey, this is what we've actually done, and this is what we think we plan to do next. You know, with the proviso, as they always have, that, you know, it's a future forward-looking statement and you can't be held accountable for doing that if another priority turns up. But if you treat it like that, it becomes a way of communicating. I often think of marketing material, press releases are good ways of communicating, so adopting some of those templates for Agile means we're having the right kind of communication rather than a project plan or a task list or an estimate. And again, as we all know, as soon as you start publishing velocity, any kind of concept of points and velocity, people will start using that into estimates and guarantees of delivery with this many people. Yeah. So again, with all the techniques we use to make ourselves healthy and successful, they can all be used as hammers against us.

Yeah. So I introduced some new product owners to the concept of points. So we went around and we sized up a lot of these jobs with using the poker cards. And I think that the great value out of that exercise is actually when you get a disparity between scoring, and we found that you actually delve into the, into the actual task, and someone might not understand how much work's involved, and found that really valuable.

Yeah, and again, it's one of the challenges of doing data projects is if you're doing a website development, you know, there's a bit of config, you know, there's a couple of web pages, there's some text, you know what the patterns are, right? You can repeat them, you can estimate them because you're pretty much rinse and repeating the same pattern every time. With data, we're not at that stage yet, you know, we're still, we have a lot of patterns that don't exist, so often the team just have to sit down and work through together to say, well, if I'm going to produce that, what are the steps I need to take? And then once you get good at that, you can move into what's the concept of basis design, of estimates where you actually start bringing out the patterns themselves and say, well, if we need to go and produce this report from a source system where we don't actually have access to that source system, here's the standard things we need to do. We need to get access to the system, we know that takes a period of time, we need to actually import the metadata. So there's a whole bunch of series of patterns that they can reuse over time, but it takes a while for the team to get to that level.

Yeah, so we found that we do have repeatable tasks at the start and at the end of each development. So you've got the vision workshop, you've got the wireframes that we know kind of how long they take and how much effort they involve. And we know the deployment process, you know, we know that we have to go to CAB, we have to get this signed off, it has to go into each environment and get tested. So it's that, those greenfields in between that really you struggle because it's the first time you've done a lot of this stuff, struggle to actually give the business a good estimate of how long it's going to take. And that's the challenge.

Yep, it's a challenge that we all have when we do agile with BI.

Yeah.

But to me, it's not only about the agile It's also about cutting a little bit of the anxiety because even if we look at project management traditional basis, you always plan and then you advance in the project, you have new information and you update that plan and that completely iterates all along the project and that will change tasks, that will change critical paths, that will change dates. So to me, the whole fixation on having a nice plan in a sheet of paper always is more in some people's minds than actual work. So no, I completely agree, and I would love a world where that's not needed, but we're still going through that change.

It's all part of the journey.

Yep.

Yeah, okay, well, that's great to talk to you I know we talk every day, but it's not every day you get recorded and it gets used in your performance review.

Oh, that would be great.

No, only joking. Hey, it's been fun. We'll catch up again and we'll cover some other gritty agile topics.

That sounds great. Thank you a lot for having me. This has been really fun and I hope to be here again. Thank you both.

All right.

Talk soon. Cheers.

Cheers.

You've been listening to another podcast from Blair and Shane, where we discuss all things Agile BI. For more podcasts and resources, please go to agilebi.guru.