Join Shane and Blair as they chat to Juan Dione on his experience as a new scrum master

Resources

Subscribe

| Apple Podcast | Spotify | Google Podcast  | Amazon Audible | TuneIn | iHeartRadio | PlayerFM | Listen Notes | Podchaser |

Read along you will

Blair Tempero: Good morning, folks. Well, today we’re joined by Juan Dione, who started working with me as a trainee scrum master. Juan has 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 status but welcome here.

Juan Dione: Thank you very much, Blair, for interaction. And thank you for congratulations. It’s been a pretty good month so far, and discussing impressions. Well, we’ve 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 we have a couple of people that are very technical people that get along and sometimes get into deep details and don’t favor the use of the stand up in actually the intended way. I guess that’s just the constant effort of the Scrum Master to maintain certain ground rules and making sure development team is able to go through them.

Blair Tempero: That’s right. And I think when you start to come along to retrospectives, we’ll talk about those things. I try and get something tangible for us to work on out of each retrospective. So in the past we’ve had, 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’re talking about to just keep it at a high level and take it offline after the standup.

Shane Gibson: So you guys finding that they’re starting to problem solve 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 gonna go work on it. But the team in the stand-up deciding to now actually discuss the issue and start to troubleshoot or problem solve as a group?

Blair Tempero: So, Shane, would really like you’re sort of expertise on this. Because sometimes it’s really good stuff that they’re discussing. And 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.

Shane Gibson: And look, we see it all the time. So people start off, they’re not used to the stand up. So you take them through all the steps about you tell them it’s 15 minutes, what you did today, what I’m doing tomorrow, any problems, and because they knew it’s all fresh, and then they kind of follow that process. And then after a while they get familiar and comfortable when they start regressing often to more of a grooming process or a troubleshooting process. Best thing I’ve ever found is this bring it back during the retrospective, we’ve seen this behavior, the suddenly get too long 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 in solve their problem. You might want to start a parking lot. So you might want to as they started deep diving to say, “Hold there, 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 behavior back to the behavior that a team should want.

Blair Tempero: 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, 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?

Shane Gibson: And the other one to obviously go and, and watch how those teams are behaving for a while because often people do just to stand up and they say they’re agile. But I bring into the other ceremonies any that have a processing of the team behaviors to the party, they just do a stand up. So either they’re a team that following an Agile process and have just regressed on the stand ups or their team following them or waterfall process and just doing a daily team meeting. If it’s the second one, then just carry on. So I’m hoping some coaching, maybe request to the use the word agile. It was fine, but go look and see if you can open.

Juan Dione: That sounds very good. And actually, Parkinson issues or subjects during the standards 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 scram to solve problems is also having an issue within team leads, for instance, sometimes we encounter 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 simple thing that it’s 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.

Shane Gibson: So with an agile, we don’t have a roll call team lead. We probably don’t assign product managers. We have stakeholders, we have developers or team members and we have a scrum master. There’s no roll call people manager, no roll call team lead. Now, that hierarchy is the thing that we remove. Often an organization will have a people leader or a people manager or custodian roles on pastoral care, somebody that looks after the leave and the performance reviews if that’s mandatory within the organization. But within agile team, there is no role of team lead. So when that rolls within the hierarchy, it’s difficult for them because they use to our traditional way of working and they have to become more of a servant leader rather than a micromanager. So the key thing is as a scrum master, somebody takes over any of the ceremonies for a purpose that they’re not designed for, you just got to shut it down, bringing 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 team’s talking about too many meetings, because they go from ceremonies that have value. 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 the 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 of the standup 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. 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 the purpose is, how they work, their way you’re kind of starting off on a positive way by saying, let’s just not talk we did a refresher and see if that behavior changes. And if not, then you have to put your scrum master boots on and start protecting the team.

Blair Tempero: 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 the morning stand up and haven’t gone through the ceremonies that Agile has, the backlog grooming. I’ve talked to people that have said, 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 a gentle that they have gone through all of the stuff that we do.

Juan Dione: So 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 scatter, and you always get to that dogfight for the resources. And that’s kind of another challenge that I see within the organization is that you have this 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’ve mentioned before that the team lead now, not from the scrum perspective, but from their hierarchy are taking resources away from you. And I guess it there’s also a need for anyone that wants to lotto or Scrum is that you need to be ready to be in a fight for resources, I guess.

Shane Gibson: 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 this sprint. If that’s not the way the organization’s behaving, then scrum probably isn’t the agile approach for them. You may want to move to more of a Kanban or 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’re going to hold people accountable for delivering something in a certain amount of time, once they’ve committed. But once they’ve made the commitment, you’re going to reserve to take 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, I start de-focusing that mental challenge of moving from “Task A” to “Task B” and back again, on these other one at a time which is why we’re scrum, you take one task off the sprint backlog and you bring it on to the board and you work on it till you’ve completed it. The second thing is, they’re probably not going to be part of the planning process for that those other projects. So they’re not gonna 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 task or the stories they need to do. And if they’re running a 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 actually develop from, because they used to defining the requirements and development is one guy. So typically the answer is if you say to somebody, I have a sprint team, and I’m going to leave half the time they’re 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 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.

Blair Tempero: It is hard. And we’ve found that out of the three or four things that we’re doing at the moment. There are a hybrid of Scrum, Waterfall and Kanban. So we’ve actually got waterfall projects that have come to us and ask for resources. And we said, only if we can run that as a scrum so that we will take the requirements from the agile, or from the waterfall project and build a team and deliver, deliver that and that seems to be working. It’s not ideal. We’ve also got a couple of things. We’re building a couple of quick apps that are being done as Kanban with ceremonies. So we’ve got a developer that cooped away in the corner building the app, we don’t talk to him every day. But we get together once a week and we will do the stand up. 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 hallelujah, I’m back to what I enjoy. So that will give me a chance to refresh, running a retrospective, doing the backlog grooming, keeping the product owner involved on a daily basis. So it’s a bit 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 will be so much easier if I didn’t have customers many times.

Shane Gibson: Famous words of agile?

Juan Dione: Everything you have 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, an art station where they are used to are 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 the direction. And I guess eventually we will have that kind of structure that we’re looking for and being more agile, efficient and effective. So that’s my perspective of the situation at the time and where we’re aiming to get eventually.

Blair Tempero: 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 he can. But we’re going to run out as a sprint. And we’re going to run a demo day. In the shock that I received, when I said that I’m not going to give a committee a full report of progress. The look of horror on the product owners face that 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 Agile that took a bit of getting used to from them. 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. 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 it the report says like, really believe it, I’m not going to get this progress report.

Shane Gibson: 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 of the organization has become difficult because of it. So what I tend to do now is to do kind of a product roadmap. 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. And we’ve given you as a guess, but it’s based on a bump on the series of releases, which are made up of a series of Sprint’s which we have done some very high level estimates of what the effects are features, may be able to deliver it in there. 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 that’s my fear. And as soon as they start asking you to tell you what’s changed. And the only answer you can ever give this 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 it will change. I’m just going to give you the updated version. I will not go back and actually tell you that what the differences are, because that doesn’t have value, or grab a spin value actually developing and delivering something that works but it was a hard one.

Blair Tempero: You’ve sort of given me an idea of where I could go with this and that. So we’re gonna have a demo date at the end of every sprint, and we’re going to produce the 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 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 trying to do next. And that might keep the people happy.

Shane Gibson: One of the techniques I’ve seen that look 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, this is what we’ve actually done. And this is what we think we plan to do next. With the proviso, it’s a future forward looking statement, and you can’t be held accountable for doing that. 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, good ways of communicating. So adopting some of those templates for agile means we’re having the 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 the head into estimates and guarantees of delivery with this many people. So again, with all the techniques we use to make ourselves belty and successful, they can all be used as hammers against us.

Blair Tempero: 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 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 works involved and found that really valuable.

Shane Gibson: Again, it’s one of the challenges of doing data projects. As if you’re doing a website development. There’s a bit of conflict, there’s a couple of web pages, there’s some text. You know what the patterns are, 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 have a lot of patterns that don’t exist. So often the team does have to sit down and work through together to say, if I’m going to produce that, what are the steps I need to take? And then once you get good at there, you can move into what’s the concept of basis of estimates where you actually start bringing out the patterns themselves and say, if we need to go and produce this report from a source system where we don’t actually have access to that sort of 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 hear us over time. But it takes a while for the team to get to that level.

Blair Tempero: 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, we know that we have to go to camp, 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 struggle because it’s the first time you’ve done a lot of this stuff, you struggle to actually give the business a good estimate of how long it’s gonna take. And that’s the challenge

Shane Gibson: That we all have when we do Agile with BI.

Juan Dione: That to me is not necessarily about the Agile is all about cutting a little bit of the anxiety. Because even if we look at project management, traditional basis, you always plan and then you are dancing the project you have new information, and you update that plan and that completely iterates on 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 that actual work. So no I completely agree and I would love a world where that’s not needed, but we were still going through the change.

Shane Gibson: It’s part of the journey.

Blair Tempero: Well, that’s great to talk to one. I know we talk every day, but it’s not every day you get recorded. And it gets used on your performance review.

Shane Gibson: Oh, that’ll be great.

Blair Tempero: Not only tracking. It’s been fun. We’ll catch up again and we’ll cover some other gritty agile topics.

Juan Dione: 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.

Shane Gibson: Thanks. Cheers.

Blair Tempero: Cheers.

PODCAST OUTRO: You’ve been listening to another podcast from Blair and Shane, where we discuss all things AgileBI. For more podcasts and resources, please go to agilebi.guru.