Recently, the Accelerance team traveled South America to reassess and visit our Certified partners. During these visits, Jim Marascio, CDO at Accelerance, conducted on site podcast recordings about the validity of the Agile Manifesto, the ever changing landscape of technology and how our partners are navigating challenges, changes and the future of agile work.
This weeks guest is Nicolas Rossello, a Scrum Master & Project Manager at Santex. Rossello is skilled in leading not only software development teams, but also other Scrum Masters. With a vast understanding of the big-picture impact of Agile methodologies and organizational processes. A strong programming knowledge contributes to his overall understanding of the project lifecycle and technical needs; this makes him a strong asset to the Santex team.
As we come to the close of the Agile Manifesto podcast series, we found that when something as culturally important as the Manifesto exists, you might be able to rework it, but there’s nothing like the original. So, instead of an official change or update to the Manifesto, experts suggest you find the best way to apply it to your company, your team and yourself. If we apply this mindset to our individual situations and maintain an agile mindset instead of a strict code, perhaps the possibilities are limitless.
Bobby: You're listening to "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority. Hello, and welcome to "The Software Outsourcing Show." My name's Bobby Dewrell and I am your host and as always, I am excited to have you here with us today. For those of you just joining, you may not know, we're in the midst of a five-part series talking about all things Agile. We are now actually on our fourth part in that getting ready to kind of wrap up the series. But we had Jim Marascio on assignment through Latin America, actually down in South America speaking with a lot of our partners there and this is what we've come up with, some Agile best practices and thoughts for how some of our partners in Latin America run their organization. So I hope you've been enjoying the series and I hope you enjoy this week as well.
Jim: Hi, this is Jim Oracio with Accelerance and I'm here today with Nico Rosello, Agile coach and scrum master with Santex in Cordoba, Argentina. How are you doing today, Nico?
Nico: I'm doing really good. How are you doing, sir?
Jim: I'm doing really well. Thank you for asking. I just flew in about an hour ago. So I came straight from the airport to the hotel but here, it's really hot. We're starting summer here and it's warm. It's exact opposite of the States because we're other side of the equators so it's good to be here, get some vitamin D and see the sun, and it's nice and warm. So today we're going to talk a little bit about Agile. I know I said I introduced you as an Agile coach. Can you give me a little bit about your background, why are you qualified to talk about this?
Nico: Okay, great. Okay. So I am a software engineer. I studied a couple of years of university and I got a degree. When I started to work, actually, I started to work as a developer, as a software developer, like, a lot of time. But in the past, like 15 years ago, more or less I used to do that then, it would be a technical thing. So one of the things there back on that time was that it was really hard to plan. We used to have this XL file in order to say when we need to deliver things and always the customer complaining a little bit about when you get my stuff and why this is different, things like that, you know. So I had that experience. And so to that way of working wasn't really good. So I started to research, you know, there should be something else, you know, at that time.
So Agile came and that research and I started to look and to read books and to take some courses and without even wanting to be that, I became, like, coach and scrum master for the teams. That was like 10 years ago. So step by step, I started becoming that person that start training the teams, making sure that they deliver the work, making sure that we can show the stuff that we bill or delivering the work that we commit, things like that. And the last two, three years, I started to do that, but at company levels, now most of the times, I got hired to go to a company, try to see the company's goal, the teams as a goal. I'm trying to understand where they are regarding the Agile journey and try to help them, you know, to...
Jim: Great, great. Sounds I'm talking to the right guy though. It sounds like you established it for the whole company here. That's wonderful. That's wonderful. So can you give me an example maybe it's something this week related to that, that you've been involved with that you can explain?
Nico: For sure. Yeah. I'm working right now in a company, a customer from Santex where, you know, we have six teams there. And the coolest thing about that is that this customer collaboration over contract negotiation, it's one of the values of Agile. Well, the cool thing about this company that we are working is that our employees work together with the customer employees and we mix the teams. I am a scrum master of some of those teams and where I have people from Santex, people from customer, people from other contractors that work for this customer. And it's really interesting because we forgot about all those paperwork when we work. We work as a team, we try to deliver things, and we finished this last Friday. We did the planning, today we're having the demos of these six teams. We do a two-hour meeting on where each team goes there, you know, and show the staff they bill, and then by the end of this spring, we deployed two programs that we did in the past spring. So it's pretty interesting.
Jim: Great. So let's say you're in the depth of that every day it sounds like...
Jim: Okay, good, good. So today, I want to talk a little bit about the four values of Agile. We're really talking from the Agile manifesto. And part of my goal today is to understand how relevant is this? It's been around for a little while. If you are doing this in the late '90s, early 2000s, to your point, you were likely using a waterfall methodology and defining very strict requirements and planning things out for a long run, and Agile kind of turn that on its head in the early 2000s. And I want to understand, you know, 15 years later-ish, we're going into 2020 in a month or 2 months, how relevant is this?
So specifically looking at the four values, they are, for anybody listening today that isn't familiar with us or with what we're talking about here, is individuals and interactions over processes and tools is the first. The second is working software over comprehensive documentation. The third is customer collaboration over contract negotiation. And the last one is responding to change over following a plan. So can you speak a little bit to those, what's still relevant? Is it all still relevant? Why? Tell me your thoughts on this as somebody who implements this every day and every week within a company with 300 software developers, 200-and-something software engineers.
Nico: Yeah, no, to me, I think they are still relevant. The core thing about Agile didn't change...actually, it wasn't Agile the ones who invented this game long way go. So to me, they are still very relevant. Actually, one of the first things I do when I go to companies, try to look at those, you know, because over the time, practices change because new technologies, new approaches, new ideas to solve problems. But the things that kind of never change are the principles and values. And the cool thing about knowing exactly the values, I'm trying to pursue these, is that if you follow the values, should the practices, A, can work under this environment. But maybe tomorrow it stopped working because something changed in the middle, or something new appeared, or new technique, or technology change. So if you stick to the values and you stick to the principles, practices can change.
Jim: Can you give me an example? Maybe one of those values?
Nico: Yes. For example, you know automation that is something pretty straightforward right now. Most of the teams try to...when you do coding, you try to do an automated code so that you can test what you do.
Nico: And that is something that maybe 10 years ago, it wasn't very familiar. The QAs or testers were doing manual work all the time. But now if you are saying, okay...
Jim: Why does that matter?
Nico: That matter because it's aligning to the working software principle of value and where you try to deliver things that work. But 10 years ago, in order for you to do that, probably you were doing a lot of manual work ahead of the team. Sorry, not ahead of the team. After the team finish, you have a little bit of a cascade there, when the team finish doing development, now you can test. Right now, there are new techniques that let you do better the working software because you can start writing your test cases that will automate the testing process right at the same moment that the developer is working.
Jim: Sure. So you have test-driven development, you kind of touched on there. If you're writing the test cases prior to, then you can start planning for the automated testing, but you can also tell the engineers, "Here's exactly the tests that needed to be passed."
Nico: Right, right. So you find a way or a new technique or new practice that will let you improve over the value that maybe 10 years ago, it wasn't there. But the value is still the same. So the team should be improving the way they work with new practices and new techniques over the time. If you are doing the same thing that you did last year, then you are not improved.
Jim: Okay, Good. So how about the another one? There's four of them there, I'll let you choose before I start diving into specific ones, but I'm curious what were you thinking?
Nico: I have another one that is pretty much related to one example that I have that I had to...I was there, you know, I work...Here at Santex, we give consulting, we get consulting to a company that wanted to implement, they wanted to implement SAFe, you know what is SAFe?
Jim: Yeah, Scaled Agile Framework.
Nico: Yes, it's a framework with a lot of practices that lets you scale Agile. Let's you scale, actually, scrum.
Jim: So yeah. Can you explain that in a little more detail again? I know what you mean, but somebody listening to us might not, so what is SAFe exactly? I mean, you sorta went there, but...
Nico: Yes, it's...you know when you have, I don't know, two, three, four, five teams sat [SP] and you want those teams to collaborate and work together? Maybe with wanting, you can do maybe scrum and run the processes that you have in that framework, but when you start collecting more and more teams, some micro-organization should happen, you know, for those teams to work together as a bigger group so that they can deliver more work.
Jim: That's the S in Scale.
Jim: How do we scale multiple teams?
Nico: Right. That's how you scale. So there are several frameworks out there that tells you that you can scale to a bigger group of people working. One of those is SAFe. So in here, processes and tools over individuals' interaction is a good example because this company, what they tried to do was to implement SAFe, they put 50 people in their room, they say, "From now on, we are starting with this SAFe thing, here is the training, start working." So there were no pillars, you know, where you can put SAFe on top of. So now we were having teams trying to fulfill with the processes, the tools, and all that stuff without knowing or without...yes, without knowing the core value on delivery. So instead of letting people to work and then run, this company wanted the whole team to start running without even work.
Jim: Sure. And then if someone group is running faster than the other, there's no coordination between, so that helps reconcile that. Okay, good. Another good example. Good example. So what about something like customer collaboration over contract negotiation? What does that mean and is it still relevant?
Nico: Yes. It's very relevant, you know, because one of the things right now that you need to make sure is that you keep your customer happy. And while ago, the way in where you make customer happy was to achieve exactly what he was reading and that came from all industry or with every contract that you can think of it's, "Okay, they do what they wrote in the paper, I am going to be happy." What is the problem with software? Is that the desire that makes you happy, change over.
Jim: For sure.
Nico: And you discover things as you go. So if you try to put what you want in the paper and try to a team to deliver that, probably they will deliver that most of the times. The thing is, is that still relevant?
Jim: Yeah, that goes back to that old waterfall model where if I documented out what I thought and I knew it was going to take nine months to build when I'm three months in, a lot of the things that we're building now probably aren't important anymore because...
Nico: Right. So to me is the constant seek of happiness is this value, you know, we try all the time to deliver what is more important for the customer at every moment. So think about scrum, every two weeks, the people that decides what makes them happy has the opportunity to pick whatever they want from the list of features to say, "Okay, right now, work on this. Right now, work on that. Right now, work on that," every two weeks.
Jim: So you're collaborating with the end-user, with the customer to understand what has the greatest value today, not because what has value today may be different from what did six months ago.
Jim: Okay. And so that sort of plays into the fourth value, which is responding to change over following a plan. I mean they're really very interrelated. Is that fair?
Nico: Yes, they are. Yes, yes. They are very interrelated. Not only for the things that the customer decide, but also from the technical things. Sometimes over the time, you discover, as I said before, new techniques, new ways of doing things. And instead of saying, "Okay, let's keep doing this because it's what we know," you still say, "Hey, wait, there's new ways to do things, we can take new approaches that will let us deliver even more value if we do this change. Instead of doing this practice, we want to be solid practice and if we do that, we will gain this, this, and that, then let's do the change." The key thing here is if you go back to the first principle is individuals' interaction, the whole team need to decide.
Jim: Over processes and tools.
Nico: But for example, for responding to the change, the whole team needs to agree that that change is beneficial for the team. I don't want...or it's not a very good thing if manager or the boss come and say, "Hey guys, you need to go that direction."
Jim: Because they're not going to do it either well or they're going to fight it.
Nico: Yeah. So the connection is also with value. We know that the people executing the work will have a lot more knowledge than anybody else. So they should be the ones saying, "Okay, changing the path from here to here is the right thing."
Jim: So that sounds kind of like negotiation versus collaboration. Coming back to principle three, that sounds like you're talking about collaboration. So let's close the loop on that one because I think people can become confused by it. So if you're supposed to be negotiating, not collaborating, what does that mean?
Nico: Yes. Remember that when you say customer collaboration over contract negotiation.
Nico: It's not that we will never do any contract negotiation. You know, it's that in the balance...
Jim: Yeah, and I said it backward a minute ago. I flipped them. Sorry if I confused you. I said negotiation versus collaboration, but yeah, yeah, yeah, yeah, collaboration versus...
Nico: One thing that confused more or I saw a lot of things, a lot of times people getting confused out of this is that there's this belief that when we say our own individual interactions over processes and tools is that we're not going to use processes and tools. That is not the case. But if we need to put weigh on things, the individual and how they work will weigh a lot more than the process.
Jim: Than the process. So they're working kind of within a process to some degree.
Nico: Yes. Some degree...
Jim: But the process is sort of freeing them to do that.
Nico: Yes. And the thing is that you will need some tools, you need some processes, but those should not interfere with the people around the work. And the same with the contract negotiation, some shape on the content, you will have to have. By the way, we love blank spaces or blank dots that we can fill over the time as we do these collaborations with the customer. Sometimes you will see type of contracts on where it says, "Okay, I will, I don't know, by this amount of hours for this amount of developers." And that's the whole contract, "I'll pay you this monthly." Which are the things that this team is going to deliver? We don't know. We will fill the dots as we go. But there is some sort of light contract that you put in place so that you keep, you know, things sweet, some sorts of agreements, and that's the type of what contracts that Agile can prefer. Some things are set in stone in the contract. But a lot of things are as we go.
Jim: Okay, great, great. This has been wonderful. So let's just kinda wrap things up a little bit here and say...everything I'm hearing from you is telling me that the values of the Agile Manifesto and the Agile Manifesto is relevant today as they ever were. Is that fair?
Jim: Okay, good. Good. So any closing thoughts? Anything else around actually you want to tell us?
Nico: One thing that happens a lot is that we have a lot of customers saying, "Hey, we do Agile." "Ah, really? Let me see." And when you sit and see how they do planning, how they dailies, how they deliver work, if they deliver work every other week as the idea, you know, you start seeing that they say they do Agile, but when you go to the principles and you go to the values, you don't see those, you see the practices that they are meeting to do the planning. They are doing the daily, you see a lot of practices.
Jim: They are doing Agile fall.
Nico: Yeah. They're not doing or you don't see the expected outcomes out of those practices. And that is even harder, you know, for us, the people that tried to train them, because you say, "Okay, I'm doing Agile but I am not getting results. Okay, I am not getting the results. Why? "I don't know. I'm doing the practices and when you see the practices you say, "Okay, you are doing but you are not having this, not having that, that's why you are not getting the results."
Jim: So it's like in almost every sport, probably in every sport, there's...you can work really hard, but if you don't have good technique, you're not gonna kick the ball or throw something or whatever as well. And it's the same thing here. If you're implementing it but you're not implementing it correctly or you're not using the right techniques or you're trying to blend things, it's going to prohibit you from really reaching the efficiencies that you should get from Agile, correct?
Jim: Okay. Great. Good, good, good. Thank you. Thank you. Okay, well, I really appreciate your time today, Nico. It's been great to chat. It's good to be, like I said, in Cordoba, and thank you so much for your time, your input. I look forward to chatting some more.
Nico: Okay, great. Thanks for inviting me and enjoy Cordoba.
Jim: Thank you.
Bobby: Thank you for listening to "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority. Do you have a topic you'd like covered in a future show? Then send us an email at firstname.lastname@example.org, email@example.com. Show notes, links, and materials discussed on today's show may be found on our website at softwareoutsourcingshow.com, that's softwareoutsourcingshow.com.