Ines Garcia joins to talk about Agile Software Development.
Ines is a London-based Salesforce MVP, Agile Coach, Scrum Professional.
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Main Points
- Agile has the concept of continuous improvement and Kaizen, why is this so similar to DevOps?
- Is agile here to replace the waterfall model?
- What is agile, how to define it?
- Introduction about the agile card game developed by Ines
- Explanation about the four principles from Agile Manifestos
- Typical frameworks used in Agile
Links
Video Teaser On Agile Software Development
Outro Music
Dream of the Shore Bordering Another World – Chrono Cross
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLehame. Here's reason number two that admins and users love this app: easy automation. Pluton Text uses platform events and invocable Apex actions, so admins can create automated texting that is customized for the needs of their work and users. Starting with the app's open source automation library, admins can set up text notifications, appointment reminders, text lead, and text case audience polling, customer surveys, and all of it built with processes and flows. It's not magic, just good design. Check out the Proton Text open source automation library at protontext.com.
[01:11] Hey everybody! This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I have a wonderful guest with me, Ines Garcia. Hello. Hello, everyone. Good to have you on the show. Thank you. Thank you so much for having me. Yeah. Would you mind to introduce yourself a bit? Yeah, of course. Um. Well, I'm Ines Garcia. I am an Agile coach and a Salesforce MVP. So together, I help companies to become more Agile whilst delivering Salesforce technology. Hmm. So you are definitely wearing two hats: the Agile professionals and the Salesforce MVPs, and many more. Yeah, I think in the kind of work that we do nowadays, you tend to um be quite T-shaped across skills. Uh huh. So I was really a beginner for Agile before talking to you. And even though I join a lot of Agile projects, I do a lot of Scrum meetings and the sprints, but I don't have this systematic learning about Agile. Then I real realize the interesting point is that it's so similar to, on the technology side, the DevOps. The DevOps is also talking about what is continuous improvement and the Kaizen, from the Japanese word. So, why is it so similar? Is it really rooting from the same thing originally? Um. So maybe. So they all three different
[02:42] concepts. So yes, kaizen is a Japanese business philosophy about continuous improvement, um, of working practices and personal effectiveness. Um. So, and that is certainly a concept that is used in the agile context very, very often. Um. Why I think is because maybe Agile is kind of like a grandson of Lean manufacturing, which comes from Japanese background Toyota manufacturing systems, hence other Japanese
[03:19] concepts within the Agile world as well. Yeah. So that that will be one. Now you talk about DevOps, but let's not confuse DevOps and Agile are different things, although they can work together very nicely. Essentially, what they have in common is this continuous improvement and reduce the time to market. That's good to me. DevOps is to the machines, to the you know the things are non-human assets, and the idea is really about the team, about the collaboration, and the people inside. Yeah, you could say that. I guess DevOps comes from development and operations, right? And over time, yeah. In other ways, that you may be looking at delivering project development and operations, they somehow in a in a very different situation. They want to get the stuff done quickly, while operations doesn't want disturbance on the business as usual. So it generates this. Not conflict, but these polar ways to look at to look at it, and and end up generating a lot of handoffs between. Something ready to go to actually hit value in the market. So DevOps is really that philosophy to bring the two things
[04:49] together. Okay. So it's about working better together, broke down silos and share responsibility. So it has a human connotation. What I'm trying to get to. Okay. But there is a lot about about automating. How can you automate your infrastructure, your workflows, the testing of your code, and the continuous measuring of how your application DevOps is today very strongly attached to software development. Okay. But yeah, essentially you you generating a lot of automation around everything. Um. And and for that you're gonna need tools to help you so it doesn't drain your team right so tools to help you to test your code like stuff like Jenkins or for your source control Git and and for deployment and for performance. Although deployment is a funny one with Salesforce, right? Because you have users using it, so continuous deployment sometimes is something that you you want to be the fastest as possible. But you're still gonna need to train your users. Depends of the things that you're changing. Yeah, definitely. Thanks for correcting me. I was a bit naive on that. I'm I'm throwing my thoughts. That's what Salimindi right. So let's start a little bit with what I understand is that the Agile is here to really to replace the older
[06:19] model, which is called the waterfall model, right? So a lot of people understand. Okay, waterfall is the old and it doesn't adapt to the current modern society. So what is the the really like the knowledge and the and the wisdoms behind? Why is the AI already here to replace the waterfall? So if you think.
[06:44] About delivering something last century, so a century ago, we were really focusing execution rather than innovation. You had very clear steps, very defined modules, defined plans to deliver very defined products. Life was certainly more predictable than now. Now things change more quickly, so you need to constantly inspect and adapt, so that you can continue being competitive to the market, right? And like. Survive, although what you really want to get to is about thriving in an ever-changing world. So I think that's the big difference. The so it's certainly an alternative of doing something. Although waterfall is like a methodology, like a very descriptive way of doing something, whilst in my mind, agile is a mindset, and it's a mindset, a set of attitudes that you approach things with. Okay, I kind of grabbed the idea because in the decades ago, the society, the environment is more predictable, but now the the pace is so much faster. What was the saying? Is like the only thing that not changes the the world is changing all the time. So right. So we do
[08:14] need to have the agile methodology to really adapt to the changing environment. Yeah, and the thing where I find the biggest flaw with waterfall is that you basically at the beginning of the project is when you are deciding a lot of things, and in that point of time is when you know the least that you ever going to know about that project. So you are just building up in. You know a lot of assumptions and best intentions. Um, but I'm sorry if I break this to you, we can't predict the future. Okay. The the only certain thing about estimates is that estimates are always wrong. So how can you continuously inspect and adapt? Hmm. I see. I see. So Agile really, I think, focusing to it does have planning, but adaptive planning because the ever changing environment, the technology, the people change. So you need to be adaptive about it. Development, of course, we're gonna develop something, but it's evolutionary development. So it's not the old way of doing something. You really need to look at things in a different way, okay. If you want to be competitive, if you want to, you know, alleviate certain systematic things you might have, it's all about. Early delivery, and continuous improvement, and what they really encourage is that rapid and flexible response to change. Okay,
[09:44] so is it possible to really define what is agile? People are talking about it, but it's just a fluffy term nowadays. I I don't really get it. Are you able to define that? Yeah, Agile is a mindset that it does does it promotes the adaptation into your planning in in the way that you develop into that delivering earlier. So you are looking at smaller things. Ultimately, all those things I kind of just said what helps you, what allows you to do is go to the market earlier, so you can deploy earlier. Doing that, obviously, the things that you're deploying will be smaller, so you can get feedback earlier. And you can focus into what really wanted, right? Because think about it, like in a company, you will have tons of ideas. It will be all the ideas will be to be in my mind for four things. So you either generate more revenue, or protect the revenue, or reduce the costs, or protects the costs. So all these different ideas from lots of different departments is gonna cover one of those things or more than one. Now. Having tons of ideas is a good stuff, but you can't deliver them all. So the trick in my mind here is: what is the bare minimum you can throw to see if it's doing what you actually wanted to do? And if your bet or your idea is not behaving as
[11:15] you expected in the market, that's okay. Let's reduce waste. Let's not put more effort and months to something that is not doing what you expect. Go and try something else. And if something else is doing what you expect or even better, there is the focus. So it's all about bringing maximizing that value. And sometimes it's about maximizing the art of the job not done. Which you know, it's about reducing waste. Okay, it sounds like what I'm doing now. My spare time is limited, so I have a lot of things I want to do, but every day I need to, you know, take something out of that list because I don't have time to do it. I have to prioritize all the time. And then just get the bare minimum stuff done, and which is the most important, and then quickly get the feedback. Right, I can deploy it to the environment, let the users to try, and give me feedback. Then I know how to improve. Exactly. Like for example, I tell you a story that happens to me last year. I had.
[12:20] Just over a year ago, I was going back home from my client, from one of my clients, and suddenly I had this idea. I had an idea for a game. I really like games, like board games, card games. You know, I like to spend my time on that. Um, and I had an idea of a game and. Agile together. So one of the things that you do in one of the principles of Agile is reflect regularly, so you can tune and adjust. So it's not only about the product, but it's about the process. And you can imagine with grown-ups, this kind of meeting sometimes comes very draining and boring. But it doesn't have to be boring. So I normally try to invent things to make it a bit more energizing, rather. So I had this idea for like kind of retrospective for teams. And it's a big thing. Like with everything else, have to develop a product in the market, like to sell it, to produce it, to design it, to everything. So I basically had this big thing in my mind for months and did nothing about it. And then one day I said I should be preaching by example. So, what is the bare minimum that I can do? To test if this thing is gonna go, and then broke out different things I could do, and every week I will do one thing, one thing, one thing, one thing, and five months later I was already sending everything to production.
[13:55] Hey! Thanks for listening to the show, Salesforce Way Podcast. It's all the time looking for both guests. And topics. If you have guest recommendation or any topics you'd like to listen to, don't hesitate to let me know. My Twitter, LinkedIn, and email information is at the end of the show notes of each episode. You can also find it on the SalesforceWay.com website. I really, really, really need help from you on this matter because only you, my lovely listeners, know what yourself want. So, please help me invite great guests to talk on great topics, so that we spread great knowledge. Now let's get back to the show. Ah, what was the game you were in the Dreamforce nineteen, right? Yeah, actually, I was really happy. I think I have a copy here. I was really happy to to be allowed to sell to sell it in Dreamstore. But there you go. So the game is called. Bards, nerds, and tards. Okay. And essentially, as a team, you know, you'll have some. It has four different ways to play. That's you can see I'm a gamer, right? Right, right. And then you will have. Different statements,
[15:26] like for example that this one, you know, you can't foresee this future, so you con constantly tune both your product and your process. And so, as a team, for example, one of the games is that you will have one nerd in your hand, one bird, and one dead. So, imagine it's your turn. You throw the statement, you read it out loud, and then quickly everybody chooses either an er, the better at it. What do they think? So, if everybody is throwing a test to the table, okay, guys, we have too many terts. What can we do about it to make it better? So, this is this is really cool. I understand you have a website for your game, right? Yes. Okay, I will put that the website link to our share notes. You can also tell us what's the link. The link is bertnerdsanddads.
[16:22] Okay, it's even hard for me to remember. You can find it as well as ah the agile retrospective game dot com. Okay. I'll name it as well, but I will get the link to our share notes because when you show this to me, it's really interesting. It's gamification, you know. It's it's much easier to learn the the knowledge like this. Okay. Yeah. Thanks to let me talk about it, but essentially what I'm trying to say is that you can apply Agile to anything, right? And it's all about testing. What is the bare minimum tested? See, you know, I did so many like. Early drafts and things that I could play with people and see how is the interactions, which thing I should change in the game, and you know. Okay, I get it. So it's it's easy for me to grab this idea because I was coming from the DevOps and DevOps has a lot of similar ideas. I still don't exactly tell what's the boundary between the Agile and the DevOps. That's something I will do it offline later. But I also get the core principles from the Agile Manifesto dot org that website. There were four sentences about the item manifestos. So it's hard to tell here in the podcast. It's a like four sentence. The pattern is like we value A over B. Four sentences. We value individuals and interactions over process and tools. For example, one of the the
[17:52] sentences. So, are we able to briefly touch these these four sentences? Yeah, absolutely. So, um, so yeah, if you go to agilemanifesto.org, you basically encounter a few things there. Um, that was put together more than twenty years ago by a bunch of people. Um. They were like representative of Scrum, Extreme Programming, Crystal, Feature Driven Development. You know, pragmatic programming. Lots of different people that they were doing things differently, and they went to a ski resort in Utah. Left all the discrepancies away, and they were like, "Okay, we we are doing things differently. What do they have in common?" And so they come up with the manifesto. Now, the manifesto has four values, what you just covered, and then it has some principles. So, the values. I really like how they written because normally when you talk about new philosophy, new way to look at something, you have words, right? Like courage and openness. But I really like the fact that they are giving you a weighting. So there is, it's not that there is no, yeah, and it's not that there is no value in the items on the right, but they value more the items on the left, right? So as you said. It's about valuing individuals and interactions over processes and tools.
[19:22] So, what tend to happen sometimes is that we get really focused about are we going to be using this particular tool? Like, are we using Jira over People Talk Tracker over Agile Accelerator? Or when companies wants to become more agile, sometimes they dictate down. To the granular level of tools, and tools and processes are there to help you. Not to be forced upon you, and where the value is about those conversations. So, for example, you may have heard about story, story point, or point poker point, or something like this about the pieces of work. And sometimes you you find really strong opinions, you know, about the points should be the same across teams. No, the points are there really to enable a conversation. So we may be discussing a piece of work that needs to happen. The question is how heavy, how big the thing is. You think it's a three? I think it's an eight. Clearly, we're thinking about it in different ways. Maybe change of scales. Maybe there is some part of the application that we can reduce. That you know about it, I don't. Maybe there is some complexity that I'm aware that you don't. So the values in about the conversation, that the points enable rather, is not about the points.
[20:53] Yeah. So the tools and the points is to helping us to earlier discover some disputes or arguments between the teammates or between teams, right? And it's after all, it's still up to the people to to solve the the problem to agree upon something. Yes. Yeah. It's it's those interactions where the value lies. Over if we use this tool, or the process is that, or. You know, the things are there to support you. It's not that we don't have tools, so we don't have processes. Of course, that's good. That's a good point. How about the other three sentences? Are you able to remember them? Of course. And so, is working software or working product over comprehensive documentation? And again, that's another one. It's not that you are agile; you are not doing documentation. That will be a very naive way of why you get things done quicker. Of course, there is documentation, but the way that you look at documentation, it may be a bit more lightweight, easier to digest.
[21:59] And you have tools actually like API things that can generate documentation for you anyway. So, so what matters the most is about that working product. That's where the value lies. And you have another one that kind of support the first one in my mind quite strongly, which is the customer collaboration over contract renegotiation. So it's about those interactions, those individuals, rather than you know it's not in these four corners of this contract, then we don't do it. Because as things change so quickly, we rather work together to deliver value than you know specific requirements, documentation, or something like that, or contract. That's the third third sentence in the manifesto, right? The customer collaboration over the contract negotiation. Yeah, and then over time, the way that you craft contracts will evolve. You start with what you have, but yeah, certainly the collaboration about bringing value to the customer—that's what matters the most.
[23:05] So invest your time on that value rather than rewriting exceptions of your contract, for example. Okay, and then the last. The fourth one is about responding to change over following a plan. So, so again as. Fairly, as we were talking before, it's about you know changing a rapid, flexible response to change that, where the value lies, and it's not that we won't have plans. There will be plans. We know they'll be wrong, so we're constantly going to be looking at them, and yeah, reflecting and reacting to it. Yeah, yeah. I think we talked. Repeatedly about this responding to the changes. I think that's really something we have already beating our brains in Agile. Yeah. So there are also some practices, right? I mentioned when I join an Agile team, there are the scrums, there are like a Kanban flow tools. So, so what are the Good tools that you think people should learn when they they are doing Agile project. So, so there are two very commonly used frameworks. You just mentioned them. So one is Kanban and another one is Scrum. I am a Scrum practitioner. They have few levels and stuff. So I earlier
[24:35] this year I managed to get to the last one, which is good. So I'll concentrate in Scrum more. So. In this ever-changing environment, what you're trying to do is get the most out of uncertainty. And how Scrum tackles that is with time boxes and feedback loops. So you have your big time box, which is a sprint. Within the sprint, you will have other little time boxes, which are you'll have a sprint planning for a certain amount of time. You will have a daily stand up where the team aligns. This is forum by the team to align their plan for the next 24 hours and highlight anything that may stop them achieving that plan and self organise to tackle the obstacles. Then you have the time box about the review, so where you show the product because a lot of the work that we do is very conceptual. Is very different when you show it. is is a very good way to digest. Like this was the idea. This is how it looks, and the review is a place where new ideas will emerge, and that's natural. When you look at it, you are like, oh, this is great. Actually, how about this? Is this, um. Responding to change, customer collaboration, and then the last time box is about reflection of the process. So think that we focus a lot
[26:05] about the product throughout every day through that time box, but it's good to pause. Reflect into how you can be better in your own process, right? And that's one of the principles. Agile have twelve principles, so the last one is about reflect regularly, tune and adjust, so you can become more effective. And so that retrospect is very very important and is unfortunately one of the things that gets dropped the most. Yeah, and it's because it's hard. It is hard to open up and look inside. Yeah, I remember one of my customer projects we did. Is the end of each sprint we spent half an hour. We write down the things we did good, the things we did bad, the things can be improved. Several of these categories, and each team member team team member were just sitting in front of the whiteboard and write down the points and stick to the whiteboard and then discuss. I think that's a kind of retrospective. Improvement thing. I I didn't know it was part of Agile. I just ah this is really cool. We really need it. Um, how did you find the not only surfacing the ideas of what can be better, but the implementation of those ideas or those experiments? How did you do that? Yeah, it it really improved
[27:36] because we sometimes we just didn't have the time or the chance or or the bravery to bring it up because we are consultants, right? They are our customers. We do what they say. They pay us the money. So you know it's a little bit over that, and then of course when we really build the trust in between, we help each other. We can easily bring up those points. We can improve together, and it really made the difference. I'm really happy to hear. All right. So we talked a lot. You really helped me to understand the Agile thing and the principles. And I really also enjoyed the Agile Manifesto. Those four sentences was really eye opening for me. So thank you, Ines. I don't know. Before we close the session, do you still have something else you want to add? So yeah, there is just so much, but we have the time that we have. So what I will say is, don't don't overwhelm yourself with lot of different things. Start where you have. Start with what you have to die. Right. It's all about an evolution. It shouldn't be a revolution. So, what is the bare minimum you can do as a team? So you can reflect more often. You can adapt the way that you look at things. How quickly you can get things to the market, and how can you do it safer?
[29:06] How can you learn? You know. So yeah, I will definitely say don't overwhelm because there is so much out there, and it's all about evolving. Over specific tools or processes. So, yeah, great. Thanks, Ines. It was really great chatting with you. Thank you so much for having me. Yeah. See you next time. Oh, oh, oh, oh,
[29:42] oh, oh, oh, oh, oh
[29:50] Oh, oh, oh, oh, oh, oh, oh, oh, oh
[30:07] Oh, oh, oh, oh, oh, oh, oh, oh, oh
