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 week’s episode features Marcelo Lopez, co-founder of UruIT and Software Engineer. Over the past few years, Lopez has worked in different roles including development, business analysis, project management and remote teams coordination. Lopez believes that creating software is an art that requires passion, dedication and teamwork, but when done the right way, it also delivers amazing technical value for people and organizations. In 2008 Lopez co-founded UruIT.
As we traveled through South America, we spoke with our Certified Partners - all of whom are masters of this technical landscape and excel in maneuvering the ever fluid world of Agile rituals. Listen this week as Jim and Marcelo give an account of the Agile Manifesto and how UruIT adheres to Agile methods. UruIT is a fast growing organization in Uruguay that shares the same passion for good code, agile, continuous improvement, quality, and most importantly, going the extra mile for customers every day.
Bobby: You're listening to "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority. Hello, and welcome to another episode of "The Software Outsourcing Show." My name is Bobby Dewrell and I am your host here on the show and I am happy to have you here with us again this week. We're now into part three of a five-part series that we've been doing on all things agility, mainly talking with some of our partners through the Latin American area, mostly in South America. And we recently sent Jim Marascio on assignment down there to get some interviews and have some chats with some people and that's the outcome. So welcome to another episode. Thank you much.
Jim: Hi, this is Jim Marascio with Accelerance, and today I am in Montevideo, Uruguay or Uruguay. Still trying to figure out how to say it right for the Americans. I flew in this morning and I'm sitting here today with co-founder and CEO of UruIT, Marcelo Lopez. So Marcelo, can you tell us a little bit about your background and maybe a little bit about UruIT?
Marcelo: Yes, sure. So, welcome to Uruguay.
Jim: Thank you. Thank you. It's beautiful. For those of you who haven't been here, the drive into Montevideo from the airport's beautiful.
Marcelo: Yeah. So, having a great time here. Well, I am co-founder of UruIT. I am a former software engineer, so that is my background. So I used to be a developer, then a project manager, then I used to lead distributed teams, and 11 years ago we decided with my business partner to start UruIT, a boutique development shop. Today we are a group of five divisions working from different countries in Latin America, Uruguay, Colombia, and distribute to developers in different countries. And we work for the U.S. market, so implementing digital solutions, web applications mostly for startups and also corporations in the States. And we have been working in this model, which we call the nearshoring and nearshore outsourcing model since the very beginning. So we have been tweaking our best practices to work with the clients and remote work and remote collaboration. So this is kind of what we are doing today.
Jim: Okay, great. And a majority of your clients are in the U.S. but you've got clients throughout Latin America and like you said, offices throughout Latin America as well as distributed team members. So you're really kind of leveraging everything you can do to grow this business and serve your clients better.
Marcelo: Yeah. Yeah. So we, yes, we have been growing like 30% every year and to do that, obviously, we need to rely on the talent available in our region. I think when we founded UruIT, we did believe a lot in the potential of South America and Central America as a destination for tech outsourcing. So we...and I think we made the right investment. So right now it's growing, it's booming, and, you know, there is a shortage of talent everywhere. So it's a good timing for us.
Jim: Good. Good. Well, let's talk about Agile a little bit today. And I think everybody in the software development world knows Agile or thinks they know Agile, but when I say Agile or the Agile Manifesto, what does that mean to you?
Marcelo: Well, I can recall my first days coding following a cascade or, you know, a very traditional phase-by-phase approach for software development. And I was part of those huge projects that started with two or three months, you know, writing a specification, and then going through the design, and then going for six months, one year through development, and then maybe eventually going to the users and going to the market.
Jim: Realizing that 30% of what you built wasn't relevant?
Marcelo: Exactly. Yeah. Well, or 80%, right? So sometimes, yeah. And I still remember those days and I remember I took...eventually as a project manager, I took this PMP training, so everything was about, you know, processes, everything was about documenting the processes, and so on. So, right now you think about Agile and it's kind of the norm or, you know, the usual thing you see, but it's good to go back and remember those days when you had deviations and you had, you know, scope creep and you had these negotiations over scope and change requests. Wow. It was...in most of the cases, I think, ended bad unless you had a great team and, you know, had nice clients. And I think Agile came to the rescue of that, right?
Jim: Sure, sure. It's funny you said scope creep because that's a term you almost never hear anymore. And we used to, you know, if it was 1998 or if it was 2005 you heard the term "scope creep" all the time, I guess by 2005 it was starting to go away. But yeah, no, that's the term we don't use a lot anymore because of Agile. So, talking about Agile, in the Agile Manifesto, there are 12 principles. And I guess my first question is, you mentioned Agile, it's been around for a while. It's been around 15 years or so. There's different implementations of it, but at its core, all the implementations kind of operate with the same objectives. What...you know, the 12 principles, are they still relevant today?
Marcelo: Yeah, yeah, for sure. And I think that, again, if you think about the manifesto how it came at that time was to basically change the way we were doing software and to think more about collaboration with the client instead of negotiating all the time, and working together to meet that product that actually could deliver value earlier and sooner and gather feedback sooner. So in that sense, I think that it still remains obviously kind of the basis for what we are doing today in software development. I think right now there are so many organizations implementing variations of Agile. In particular, I think that Scrum implementation is kind of the common thing, maybe some Kanban. But I think that right now we are thinking of Agile as, you know, other...not new values, but I think a new version of the Agile Manifesto and thinking more about trust and empowerments of the teams and true collaboration and fail fast, learn fast to improve.
I think that's kind of another thing that I think is the most important value of the Agile, is how you can measure and you can learn and you can improve over time. And when you implement something as Scrum, obviously, if you do it the right way, I think what the framework provides you is a way to learn and improve. But to do that you need to, you know, create this room or space for improvement. And that means trust, that means trusting the team, considering ideas for improvement, implementing, and measuring, and so on. So I think right now we are in a new era of how we think about Agile, but still, the values are so important and critical to follow, for sure.
Jim: Sure. You touched on the values a couple of times there, you specifically a minute ago or so throughout the negotiation versus collaboration. I think you actually said it the other direction. But the same thing. Let's talk about the principles. So there's 12 principles of Agile and it would take me about 3 minutes to read them out loud. So I don't want to burden the podcast listeners with that, but are there specific principles here that you like to focus on or are there specific ones that you find when you're working with your clients are most difficult to implement or most important to implement? Tell me little bit more about the implementation of these.
Marcelo: Sure. Sure. I think that, again, Scrum, it's a framework that you can use and implement. And you can start, you know, with light implementations of a Scrum Daily Board, then I think the basics is to iterate and deliver value incrementally. What we have found is that to implement Agile properly, you need different roles for sure. A scrum master that nowadays, you know, maybe the teams once they are mature, they can take care of the process itself and you don't need that specific role for the scrum master. The other role that I think is very important when you want to implement Agile is also the product owner. So, having a strong product owner that is able to think in an interactive way in terms of the product and in particular what we call today "the vertical slicing approach," when you need to deliver value on every sprint, right, every iteration. To do that, I think is not that easy.
Jim: Why is that?
Marcelo: Because you, you know, you need to have identified first what are the, you know, most important feature that you want to focus, you do that, you know, during the instances like grooming sessions, and you need to be in planning sessions, and you need to have some kind of good experience dealing with priorities and aligning the business priorities. And at the same time, what we have found is that clients, they don't always have expertise in managing the product. So, writing good user stories and at the same time, thinking of the feature in a vertical slice way so that when you end the screen, you have something is working software, you know, it's one of the values behind also the manifesto.
Creating those small incremental iterations of the working software, I think is kind of an art. So what we have seen is that sometimes our partners, our clients, they either need to train the product owners in this way of thinking, and eventually, they rely on us with what we call our "proxy product owners" to help them navigate all of these challenges. Because, again, thinking of the product as an incremental product that needs to deliver value and learn fast, I think that is kind of the tricky thing on the product management side. And then you have all the technical implementation of the Agile, where you need to rely a lot on things like continuous integration, continuous delivery, to have a truly iterative processing place where you need probably senior people and strong technical expertise, implementing DevOps, implementing tools to deliver that incremental value. So I think those are the challenges that I have seen the most in terms of implementing through Agile. But we are getting better and partners and clients are getting better at it.
Jim: It's amazing. As you're talking here, I'm looking at the 12 principles, and I literally checked off 9 of the 12 that you just talked about.
Marcelo: Oh, that's cool.
b: There were three that I wasn't quite sure if you did, so, yeah, I'm not going to read all nine that you talked about but you talked about support and trust and motivating people, you talked about customer satisfaction through early and continuous delivery, you talked about accommodating changing requirements, you talked about frequent delivery of working software that every strength or every iteration needs that dive. Anyway, so you've literally checked off 9 of the 12 there. So when you're doing that, I got some ideas based on my experiences, but from your perspective, which ones are the most difficult to get your clients on board with? What's the hardest thing in implementing...your team internally knows how to do it. But in my experience, clients that haven't sometimes fight parts of it. So looking at those principles, what was difficult to implement with a client that isn't familiar?
Marcelo: Good question. Earlier today, we were talking about the UX, remember?
Marcelo: And how you can, I think, UX and thinking about the user first before implementing is also a key component of the approach. And we need phase challenge to, you know, clients recognizing or partners recognizing the value of listening to the users, and in advance. So it's better to, you know, gather feedback in advance from the users, and understand what the goals are, the priorities, what they really...what is the true important thing they want to accomplish. And if you can do that in advance, and we do that through running some discovery sessions, you know, discovery workshops, and so on, but then we incorporate that within the iterative approach as well. So UX is a key component of the iterative, and delivering incremental value.
We do phase challenges trying to convince clients about the value of speaking to the users at the very beginning and I think that is something that we continue working with clients to, you know, show that value and how they can actually save money if they consider the users in advance and the feedback from the users in advance. And if they can test with the users incrementally, most likely, they will end up with a better product and not risking a lot of money neither.
Jim: Absolutely. And that's why that iterative feedback, that short feedback loop is so critical, how we provide value and validate and then adapt and potentially reprioritize based on what we know now.
Marcelo: Oh, for sure, because it changes all the time. Priorities change, and so on. And I think that is a key advantage, as I said, compared to 20 years ago, when we were, you know, sitting in a room together, trying to figure out what the product should be about getting...
Marcelo: It was impossible. Yeah. It was impossible. And then you come, you know, out to the market and say, "Oh, no, this is not what is actually needed." And to be honest, I have seen some of our clients at the very beginning following the same mistakes, and you know, literally wasting lots of dollars into products that don't have a market fit or, you know, users don't care about. So that is what I try to avoid with UruIT, I mean, and we are always thinking of how we can add value in that sense.
Jim: Sure. So you just talked actually in the last kind of two segments that you spoke, about number four, which is collaboration between business stakeholders and developers throughout the project. Effectively better decisions are made when the business and technical team are aligned. And I think in my experience, that's probably the number one biggest challenge, is understanding priorities and getting a client to really understand where the business value lies so that they can say, "Here's what comes next." So, do you experience that as well?
Marcelo: Yeah, for sure. So, this is why we put a lot of effort at the very beginning in the...we call it "the onboarding." And when you start a relationship with a new client, a new partner, imagine how you can do that, and I mean all the difficulties you have faced when you are remote, so we had to tweak all the processes to make sure that collaboration is possible and it's, you know, feasible, even when we are working remote. When we do these alignment workshops at the very beginning, we see a huge...and if we can, a client can come down here, visit us, or our teams can go to the States, we see a huge benefit for the project at the end. And that means about communication, collaboration, those are the two things that are the most important if you are even actually in this case an outsourcing vendor, right?
And if it is remote, even harder, and you need to put a lot of effort and focus into that and setting up the expectations, learning about the business, learning about the product goals, the user, the personas behind those products that you are building, I think that is critical, for sure. And yeah, I know I'm excited when I see sellers investing a lot on that in the very beginning and kicking off the project. And at the end, we save a lot of trouble and money also for the clients for sure.
Jim: So how do you facilitate or recommend the clients that they facilitate that effective knowledge transfer? Because it's important for the engineers to understand not only what they're building, but the context for the business with which they're building it within. So how do you best approach the...what has been, you know, most successful way with your clients that you've seen that happen?
Marcelo: Well, again, if we can have someone from the business spending time, investing time in meeting with the team, and I mean the entire team, not just, you know, a PM or a point of contact, we encode other teams to participate and collaborate with the clients and I think that is another advantage of the Agile, you know, to have every everyone in the same loop and everyone collaborating. We have seen that onsite visits are a great booster for that for sure. And then, you know, you have different type of workshops, different type of activities that can help to translate the business needs and the context to the development team.
And again, we call that discovery phases, only section phases that can take one week, maybe half of the day going through some activities and going through the product features and goals, going through the business context and creating the hypotheses together with the team, maybe role mapping the MVP, and so on, that are for sure several of the activities that we run that are helpful to achieve that in parallel with all the technical knowledge transfer that you need to do. And at the end I think it's what are the stakeholders that, you know, participate in those activities too? Do you have a subject matter expert or a product owner from the client side?
And, again, if you are building a software it is good if your product owner is trained is, you know, building these type of, or going through these type of activities. If your product owner is not trained or they don't have the skills because they come from some other field, I recommend you to ask your partner for help, and you know, ask if are there other roles within the partner. But at the end it's all about communication, I guess, right?
Jim: It's so funny you said that because I, literally, at the very beginning of this response was thinking it sounds like it's all about communication, but I didn't want to interrupt, and it's literally where you ended up. So you brought it all the way back in full circle so... Now this has been great. Well, I appreciate your time speaking with us today, Marcelo, and thank you for hosting us here at UruIT and are there any parting words or thoughts on Agile or the Agile Manifesto before we leave?
Marcelo: Oh, no, just, I mean, continue believing in Agile. And, again, I think at the end, what we are all trying to do is build trust, build trust within the teams and build trust with the partners, and collaborate with the partners. So everything we do is aimed at that. And if you can do that I think the result and the type of relationships you develop with your partners are much better.
Jim: Great. Great. Well, thank you very much. Thanks again for having us.
Marcelo: Oh, thank you and enjoy the rest of your stay here.
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 email@example.com, firstname.lastname@example.org. Show notes, links, and materials discussed on today's show may be found on our website at softwareoutsourcingshow.com. That's softwareoutsourcingshow.com.