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 lady stand up 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 stand up in actually the intended way. And 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. 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 the team in the stand up are starting to now actually discuss the issue and start to troubleshoot or problem solve as a group.

Yeah, yeah. So Shane would 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 behaviour, 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 behaviour back to the behaviour that the team should want.

Yeah, that's good because especially in our organisation, 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 noticed 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 other team behaviours 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, their 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.

Ask them if they'd like some help and some coaching. Maybe request that they use the word agile. Yeah, river 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've 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 stand up, not for the stand up intention, but for team meeting. So we have a team lead that's trying to do everything and micromanage instead of just trying to do a simple thing that is ahead. And 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 call team lead. That hierarchy is the thing that we remove. Often an organisation will have a people leader or people manager or a custodian, some pastoral care, somebody that looks after their leave and their performance reviews, if that's mandatory within the organisation. 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 a purpose at they're not designed for, you just gotta shut it down. Bring back the kind of bring the team back to what the ceremony is 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. The 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 and start complaining about it purely because they've been hijacked. So my suggestion is 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. Yep. 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 behaviour 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 dog fight 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 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 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 over 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 more than one task, 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 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 those other projects, 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 upfront, 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 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 business agility. 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 behaviour happen. And again, that's hard.

It is hard. And we've found that out of the three or four things that we're doing at the moment, they're a hybrid of Scrum, Waterfall, Kanban. Yes. 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 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, 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 it. 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?

Yeah, that's right. Famous words of Edge of.

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 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 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 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. 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 or we're giving you as a guess, any guess, but it's based on a bunch, 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 delivered in that. And then that way at least you're communicating with them, this roadmap and it moves when you do that. You got to be really careful that they don't baseline the roadmap.

Yeah.

And they start asking.

That's my fear.

Yeah. And as soon as they start asking you to tell you why it's changed and the only answer you can ever give is change is constant. Every time I give you the next roadmap with the plan, it's probably going to change because 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 going to give you the updated version. I will not go back and actually tell you what the differences are because that doesn't have value. Right. We'd 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 three 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 at 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, Apple, when you're launching the latest iPhone, this idea that 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.

With the proviso, as they always have, 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. 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 using the poker cards.

And I think 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 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, 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. 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 estimates where you actually start bringing out the patents 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 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, 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, the wireframes that we, we know kind of how long they take and how much effort they, they, they involve. And we 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 green fields 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, you know, 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, when we do agile with bi.

Yeah.

But to me, it's not only about the agile, it's 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 a 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, 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.

Yeah.

So part of the journey.

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.

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.