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 Wzorek is a professional with more than 18 years of experience in the IT market, strong technical background in system engineering, worked as a developer and system analyst, project manager, SW development manager and currently heads the Software Delivery Organization at CINQ with 200+ IT professionals. Marcelo is experienced in large and complex projects focused on offshore customers with extensive international experience.
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 CINQ adheres to Agile methods.
Bobby: You're listening to the software outsourcing show, brought to you by Accelerance, the global Software Outsourcing Authority.
Bobby: Hello, and welcome to the Software Outsourcing Show. This is your host, Bobby Dewrell, and I am glad that you could join us again on another week of the Software Outsourcing Show. Now, if you were listening last week, we introduced a little series that we're putting together, probably about five parts in total. But talking all things Agile, we want to go over the Agile Manifesto and the principles of Agile with some of our Latin American partners from a recent trip. So, as you may recall, we've got Jim Marascio on assignment traveling through South America and speaking with those partners there. So, this is the first installment in that. I hope you enjoy it. And I look forward to seeing you again soon.
Jim: Hi, this is Jim Marascio with Accelerance, and today I am in Curitiba, Brazil with Marcello Zorich, head of software delivery at Sync. How are you doing today?
Marcelo: Hey, hello Jim. I'm great. How about you? How was your trip down here?
Jim: It was good. I'm a little tired and a little jet lagged from the flight down but it's good to be here back again 11 months after I was here the first time. So...
Jim: ...it's good to be here. Thanks for having us. So, Marcello, I want to talk a little bit about the Agile Manifesto and Agile applications and how that works with your clients today. But before that, can you tell me a little bit about your background?
Marcelo: Sure. Okay, yeah, I started as a software developer several years ago, almost 20 years ago, and I'm within Sync for 13 years already. So, again, most of our leaders here have a technical background, which helps. For starters, I'm developer and Project Manager and Delivery Manager, and today I had the software delivery organization which involves 20 people, sorry, not 20 people, 200 people in my organization. So, that's basically, yeah.
Jim: Okay, great. And so Sync's based here and Curitiba, Brazil. And for those who aren't familiar with Brazilian geography, where's Curitiba?
Marcelo: Yeah, we are a bit South of San Paulo. So it's, probably the main known cities in Brazil are San Paulo in Rio de Janeiro. So it's a one hour flight from San Paulo, Rio de Janeiro. That's a great city and you have a lot of resources here like good universities. So it's a good area for IT companies I would say. It's the best capital to live here in Brazil, I mean, there's some research on that and every year in a row, we're elected as the best city or the best capital to live in Brazil, which is great. Even when we bring people on, we bring people from several different areas or states in Brazil that they enjoy living here. So yeah.
Jim: Yeah, I know it's a good-sized city, it's about 2 million people. So by Brazilian standards, it's not huge. But it's still a good-sized city and it's attracting talent from all over the rest of the country and probably a little bit of the continent as well, right?
Marcelo: Yeah, yeah. That's correct.
Jim: Okay, cool. Cool. I know where I've worked with you with an American client, one that's got a couple of development centers around the U.S. and they've got a growing team here. And you actually have somebody new, I learned earlier today, that's moving from North-Eastern Brazil in the next couple of weeks to Curitiba to work on that team. So you're obviously attracting talent from all over the country which is cool.
Marcelo: Yeah. That's really common, to be honest. Yeah.
Jim: Cool. Cool. So let's talk about the Agile Manifesto. And so, for people who have probably heard of Agile, but the word manifesto might scare them, what are your thoughts or can you explain a little bit about what that means?
Marcelo: Yeah, I think when we started with, you know, doing Agile then that was like several years ago. We started in 2008, 2009. We got it wrong to be very honest with you. I mean, we went too much through Scrum, which is a kind of framework, but...
Jim: It's a type of Agile.
Marcelo: Yes, it's like type of Agile but Agile has, you know, the principles on customer collaboration, software delivery has been the main measure of success. So this is something we encourage the teams to actually go and read the manifesto every now and then, make sure you don't, you know, move too much away from the actual manifesto and the core values of that, because if you go too much into the framework details, and that's kind of...what I personally think is kind of a dangerous thing. Go look at the manifesto every now and then, make sure you try to stick to the principles. I think that's good advice.
Jim: Okay, good, good. So, you said the values of the manifesto, and there's four values and so I'm going to go ahead and read them and then we can talk a little bit about it. So the first one is individuals and interaction over process and tools. 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 let's talk about that first one, individuals and interactions over process and tools. What does that mean and how does Sync, your team here or teams here implement that?
Marcelo: Okay. Yeah, I think that really connects to the third one on customer collaboration. And it is a challenge for us eventually, or sometimes we, you know, most of our customers are remote in North America or Europe, and so basic things like face to face meetings, direct channel to people, so, avoid too many hops on the communication. So developers will find their time of meeting. Developers will talk directly with the customers, with the, you know, customers architect or even the product owner or the Product Manager. For us, this is the big thing, you know, make sure you have open communication and proper channel for communication. Not too many layers or hops on the communication, I think that's key. And if we can have face to face interactions, even if that's through, you know, video conference and things like that, but I think those are the main things.
Jim: So, it's really about understanding the customer or the end-user and the individual that's going to be interfacing and not trying to take specific strict requirements and interpret them separately. It's really reaching out, understanding what the individual's doing?
Marcelo: Yeah, and sometimes we work only with the IT department, so, if we can, you know, get interaction with end-users, that's usually really beneficial as well. Not just IT area, but, you know, everyone that's involved within the process. I think that's the key.
Jim: Okay, good, good. So, the second one is working software over comprehensive documentation. And as a guy who early on did a lot of waterfall, which probably speaks a little bit to my age, but Ted did a lot of waterfall application development, you know, working software over comprehensive documentation kind of jumps out at me as kind of the opposite of the way my career started, but certainly the way things are going. So, can you speak to that a little bit?
Marcelo: Sure. Yeah. This is...I see some failures in a few companies and even customers have to understand that properly. Working software is not doing a review at the end of two weeks and show the customer how the product is going. It's actually working software, so you need to make sure you put that in, you know, for people to use and test in production. So, that was one of the pitfalls that, I don't know, a decade ago. Where we would do sprint reviews and every team was okay and then after eight months, we would deliver the software in productions and then we'll have, you know...
Jim: So the feedback loop was way too long.
Jim: So, what you're talking about here is really how do we contract that and get feedback faster?
Marcelo: I think, for those that are familiar with the terms, like, the key is, go from definition of them needs to be the closer as you can to shippable product increment. That's the key. I mean, we need to have working software in production with people using that, and not just do sprint reviews and, you know, do a demo and say, "Okay, that's okay." Have the software in production running in the proper environment. I think that's something we learned at the last years as well. Working software is people using the software and not doing just sprint reviews on Sync.
Jim: Okay, great, great. And, you know, the manifesto though does value documentation. But one of the things it talks about doing is actually valuing working software more. So I think that's kind of what you're speaking to there, is it's important to document things and it's important to, you know, to build to spec. But what's more important is that feedback and how do we get something from concept to function as fast as possible so that we can get feedback and adapt to that feedback. Is that right?
Marcelo: Yeah, true. And that's another point that sometimes people get it wrong, it's not that we don't do documentation, we value our software, working software but of course we need documentation that should be properly planned for as well.
Jim: Perfect, perfect. So, the third value is customer collaboration over contract negotiation. So negotiation versus collaboration. What does that mean?
Marcelo: Yeah, I mean, in the old days, not so old, you were just talking about waterfall methodology and then, you know, customers were trying to protect themselves with a lot of contract rule clause, and, you know, performance clause, and whatever that is, and that doesn't, it won't guarantee that you have a working software at the end. So, it's really that, for me, is more of a mutual trust and collaboration. So we need to have the same goals as the customer. Everyone's goals is to have a working software that, you know, works for what it was meant for. But I think that's kind of that in the past, there was a lot of contract negotiation. If there was a change, we need to discuss change requests, and, you know, discussing the budgets and things like that. And nowadays, I mean, I think we have zero projects like that to be honest and it's more on collaboration with a common goal I would say.
Jim: Sure. So, historically, when they refer to collaboration, collaboration was really negotiating all those requirements in advance and documenting everything before it was implemented, whereas negotiation now, versus collaboration, is more about how do we get the product manager and the customer to understand what the ultimate goal is at a high level so that we can implement key features and then go to the next set of key features and keep doing implementation, implementation, implementation, and cycling through, and again, that feedback loop comes back, right?
Marcelo: The most successful projects we have is where we finish the project with a really large backlog that was not touched, because it was unnecessary functionality, or maybe it was not that important as others. So, for me, the most successful products or projects we have is when we have a large list of items in the background suit to be worked, they might never be working, when in the past we'll probably are meant with a customer and they are like, "Okay, I paid for that functionality and you didn't deliver." And so, that's the key, I would say.
Jim: Absolutely. It's interesting, I'm having, as you're describing this, all these memories back to, again, early in my career where we would build these exhaustive requirements lists and then, by the time we actually built it, a lot of those requirements weren't even important anymore. Whereas nowadays, and when we're talking about Agile, and Lean, and we're always trying to say, what's the MBP? What's the most important thing that we can build right now? And then as you're talking about this exhaustive list of requests, okay, it's always go back to that list, what's the next most important thing and how do we build that, right?
Marcelo: Yeah, and it's a, you know, cultural change. It's not just about calling the product manager or product owner or things like that, it's really a mindset change. And even for an IT company, a consulting company for us, you know, the developers will use it to say, "Oh, the customer does not know what they want. He did not specify that in the beginning, how should I know if he would need that?" So, that's a mindset change. And developers as well, I mean, they need to embrace these kind of things because it's, for complex projects or products, it's really impossible for you to, you know, have all the detailed requirements from day one. So, you need to change the mindset of the developers, and usually, that takes some time, yeah.
Jim: Okay, good, good. So, the last one, again, there's four values here that we've talked about. The fourth one is responding to change over following a plan, and we sort of just talked a little bit about that. But, yeah, tell me a little bit more about respond...What does that mean, responding to change versus following a plan?
Marcelo: Yeah, well as you said, we mentioned this a little bit. So, again, I would say common goals, and for us as a, you know, offshore company, this needs to be discussed or, you know, presented from the customer to us. It's not present the requirements, present your goals, your strategy, how you want to go to the market. So these things are relevant as well. And then, we don't really...We have a common goal to have the product in the market and we don't really go into low-level details of the requirements. And we all know and agree that when something is no longer needed, we'll just drop it and do not implement this thing. So, I think the key is not just to have, you know, customer prioritizing the back blog, and then we just follow backlog is really to have a common sense on the goals. And then, if we need to change anything, everyone will embrace this without a lot of drama and complain.
Jim: Absolutely, absolutely. So, just to kind of recap, the four values are, again, individual's interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. So, as we just kind of wrap up here, any additional thoughts you'd like to share about the Agile Manifesto, or about success as you've seen or how you see your team here implement it well?
Marcelo: Yeah, as I said, we do that for 12, 13 years. And it is a journey. It takes time, you know. You learn with the failures, I would say. That's an imparted thing. And one of the things I saw in the previous team was like, okay, we're doing Agile now, and Scrum, and then they kind of left or put aside, you know, software engineering practices or even software architecture. So that's a big pitfall and mistake, you can do that, you know, we have an emerging architecture. But you do need to think through architecture, you do need to go and use engineering process. So, this is something I would advise, make sure that you're following proper techniques for software development. And this is not just about, you know, writing code, and deliver writing production. So, this is something we learn I guess, and again, I think I mentioned that before, every now and then, go and look at the manifesto to remember the balance, because it's dangerous that you go too much into the implementation of that with the Scrum and now they're like lads or safe or all these things that, you know, kind of forget the basics.
Jim: Absolutely. You know, it's interesting. I had to work with a client last year that tried to implement their own version of safe and, you know, they did exactly what you said not to do right there. They tried to kind of deviate from it and take things they liked and things they didn't and they struggled a little bit. So, you know, at its core, you know, it's worked really well now for a couple of decades and the more people implement it, the more success people seem to see with it.
Marcelo: And you need to look at your own company, I mean, don't use something that's ready, or that, okay, like, this is working in Spotify, or just, you know, we use the same methods. You need to understand how your organization functions and, you know, adapt to that, I think that's a key thing as well.
Jim: Okay, great. Well, thank you very much, Marcello. It's great to chat with you today. And I appreciate you hosting us here in Curitiba. Thank you very much.
Marcelo: Thank you, Jim. Hope to see you back in Curitiba soon.
Jim: Hope to come back, thanks.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.