Offering Agile in to Clients with Prajin Shee

The Full Stack Agency series looks to empower agency owners and freelancers to offer world class digital portfolios such as websites, web apps or digital products.

Offering Agile in to Clients with Prajin Shee

in this discussion, I consult with Prajin Shee about Gray Media’s Agile processes. We touch on difficulties in changing scope while working with startups, built-in quality when developing MVP, and how to become more tightly coupled with Agile.

Download my FREE Agile lingo book: https://thefullstackagency.xyz/books/lingo-agile-book

Join the Discord: https://discord.gg/WWfVjMhSjx

Episode Transcript

00:00
Samuel
Today I spoke with Prajin Shee, who is the CTO of Gray Line Media. Now gray line media do a bit of everything. They do a bit of video and media and podcasting actually, but they also build websites for financial advisors, PR Jean, and I spoke all about their website process, including their agile processes, actually. In this discussion, we touch on kind of managing the kind of difficulties of working with startups. We also talk about building quality when it comes to MVP as well. We also talk about how to become more aligned with the agile process, if you are following on why I download my agile lingo book. If there’s any terms or anything’s mentioned in this episode, you can quickly look it up in plain English without any fluff at all. You can download for free at lean pub.com/agile hyphen lingo. You also get access to my Discord community, which you can join now for free. 


00:54

Samuel
If you download the book, as you get access to a kind of private channel where you can discuss all things agile, and if thing kind of related to the book, I’ll leave links to everything in the description below. This was a really interesting chat. If you are working with startups, were trying to implement agile and are struggling to do so then listen on in. 


01:21

Prajin
A context of where I’m at. Like about a year or so ago, me and my business partner, who’s based in the us started a media agency. We have a couple of components to that company. Well, it’s podcasting video editing and our real strong suit is development specifically WordPress, but we also are working in Shopify and web flow. So we have about 14 team members. That includes our video editors sound engineers, and about six or seven developers, which are HTML developers, PHP, developers, and then the graphics designers. It’s separated in terms of each component of development. We’ve been running about a year now, initially our niche was targeted towards financial advisors in the us. 


02:15

Samuel
That’s cool. And then what’s your role then? Within the company? 


02:18

Prajin
Yeah, so I am the CTO and I also project manage and operations. Right now my main focus is on working on the processes. We have talented developers, we create good products, but we don’t necessarily have a consistent process. That’s where we see like a discrepancy in our final product. We know we have the talent and, but Hey, sometimes X takes a little longer than other, oh, we’re missing out a couple of quality assurance checks over here. That’s where I, I am finding the largest problem. I want to address that before we scale even further. 


02:59

Samuel
Set the foundations there, get that solid and then build from that. Yeah. And where does your gut tell you? You’ve identified, there’s a process issue, but have you done any internalization on where you feel that specifically might light lay? 


03:19

Prajin
I think there are a couple of areas. One is what we’ve done recently is so we use a project management tool Soho, and there’s so many automations that we can do. We’ve also recently started using Saper and that’s helped us a lot just to streamline all of our things, to have a report generated at the end of the week. We have all the checks and balances. That’s helped a lot, but a, a couple of things is the actual development life cycle at what, when we’re actually delivering a product to a customer. Agile is a popular thing and it’s Hey, get your MVP out there, show it to the client and keep iterating. How does that work in a real world scenario? When, when a client doesn’t understand tech, they’re like, Hey, this doesn’t work, but that’s an MVP. They don’t understand it like that. They want a perfect product. 


04:11

Prajin
What’s that balance of how do you keep improving getting that quality to the level that a client wants and beyond on a, a, in a tech aspect, communicating tech to people who aren’t tech savvy, that’s, I think that’s a magical place that a lot, very few people have reached, but that’s where I’m trying to get. Yeah. 


04:34

Samuel
Yeah, for sure. I mean, just a few things. I mean, you, I didn’t know, Zoho had a project management tool. What is that? That like a CanBan board is that, and that’s working fine for you. You are, you’re able to do the work. 


04:50

Prajin
Essentially. Yeah, yeah. The real thing is, are we using cuz at the end of the day, a tool is just a tool and it’s how you use it. Are we using it correctly? Are we, are our bugs being pushed out correctly? Are we prioritizing work correctly? I, I guess that’s a more complicated issue, but something we are slowly addressing and trying to have a consistent view of how, okay, a bug comes in, is it a 24 hour release? Or is it, how are we gonna target each of these subtasks? Yeah, that’s kind of where we are at right now. Yeah. 


05:31

Samuel
What I’m hearing is actually that you are quite, you are fairly confident in the technology that’s facilitating your workflow process is fairly good. It, I mean, but it’s more about the kind of soft process around that and you’re happy you’d be happy to pivot and use a different piece of software if, if it neat, you need to, you there’s tools or tools at the end of the day, they’re only supposed to facilitate that. It’s just whether you are running the right processes for the tools to then to facilitate that process, is that right? 


06:07

Prajin
Absolutely. I mean, I guess the eventual goal is like, how do we run? How do the processes run themselves on autopilot? 


06:16

Samuel
Mm. 


06:17

Prajin
You know what I mean? Like you said, we need to build a foundation now. That in your two year three year five, we’re not nitpicking. Oh, this is not done on time. This is not done first. So yeah. Yeah, absolutely. 


06:34

Samuel
Okay. I’m just gonna make some notes. I mean, obviously topical or because I just released the agile book. I think, I think there might be some, just a lot, not alignments. I think I, I don’t doubt that you understand agile and what it’s trying to do. I think there might be some communication refinements that can happen with the client because MVP and I say this in the book and I, that sounds like such a plug, but it’s not. I do I say this in the book, MVP is this such a misunderstood term? A lot of people, a lot of businesses are trying to, they think MVP is getting just something up, whether it’s rickety or whether it’s broken or whatever. That’s not. I mean, MVP is a reduced, almost a reduced scope version of your website or your product now agile. It, it never dictates there’s this thing. 


07:38

Samuel
There’s a term called built in quality when it comes to agile and there should be systems and checks in place through automated testing. There’s regression testing, unit testing, quality assurance built in quality that every single task that makes it into that piece of software, even if that software is a contact form on a splash page, right, that the quality is there. And it, you never sacrifice that quality. The, when you say the client wants to, expects quality and all the rest of it should be there. They should never doubt that re MVP will ever sacrifice that quality. And this is how I do it. As an example, I, I explain MVP and people, we use M M P minimum marketable product MLP, minimum lovable product. All these different terms are trying to steer people away from this misnomer, which is MVP is a rough and ready version of your product, which isn’t the case. 


08:47

Samuel
The way I phrase it is that I want to get you earning money sooner so that you are not waiting around for this website to be done. We can get you to a point where you are earning money and you’re not waiting around. And, and we’re not, things aren’t getting pushed back. We are trying to bite off more that we can chew. Let’s get you to a point where you are earning money, that we can revisit. There’s, and there’s two benefits to that. Again, I, I’m probably not teaching you to suck eggs, but the two benefits of that are one, you are earning the money. Two, you are getting something out there where you are able to then learn from that. So, yes, you’ve got this big kind of lofty goal of, this product or this website that wants to do X, Y, Z, but let’s keep that. 


09:41

Samuel
Let’s keep dreaming of that, but be open to change. And that’s what agile is all about. By getting something up sooner, you can start to get that feedback and you can actually make a pivot and, and weirdly from a psychological standpoint, you get something out and you’re just like, oh, all that stress is now. We’ve got something out there, all that stress. You’re able to kind of think more clearly. The business is able to think a, more clearly. You say, a, a client doesn’t want, they want a Polish thing in, they should be absolutely reassured along the way that through the agile methodologies, whatever one you choose to do that you are not, not willing to sacrifice what gets released. It will be the best it can be, but let’s just reduce our scope and leverage those things, leverage that earning leverage that, mental break that you get from just releasing something. 


10:43

Samuel
And, and that’s the case. And that often works. Like we worked with a client last year and they wanted lows and lows of staff. It was like, look, let’s again, the same speech. Let’s get this to a point where it’s gonna earn you money. Let’s see where we are after that. Lo and behold, we get to that point, they’re really happy with their MVP solution. They’ve, they, they said 300 times return ROI on the website. It’s like, well, I think it’s just a way of phrasing this agile process rather than, and up some of those misnomers, like I say, like MVP should not sacrifice qualities. Well, agile doesn’t allow you to sacrifice quality. There’s this other thing called a hardening sprint, which is, and we’ve done it a couple of times. It’s, it, no’s perfect, but it’s this a hardening sprint is a sprint where it’s like, right, made a few sacrifices along the way. 


11:40

Samuel
We’ve got a bit of technical debt. This needs tidying up. There’s a document that needs to be right. Let’s just spend the week just kind of doing those things. Unfortunately, it’s not a good thing because your quality should be built in every, you’ve got this thing called an acceptance criteria, which is like, right, what do we need to hit? What are these checkpoints we need to hit on the, every single task that means it’s done. And that’s the definition of done. Does it need to pass or unit test, do unit tests need to be written and passed? Do, does it need to run past this particular person? Does design need to see it? All these kind of checks are in place and only then can we consider it done? If it’s not passing those things, then you’re not building in that quality. It’s just, it’s a case of hardening sprint should never kind of happen. 


12:30

Samuel
I, I, where does that sit with you and how, how does that feel in terms of that perspective on the approach with clients? 


12:40

Prajin
No, absolutely. I mean, I see two huge pros, especially working with several clients halfway through a project, or like once we’ve built a large portion of the project, they do there, there is a scope creep, not necessarily in terms of what they want, but also their vision for the business. By having that MVP polished MVP, it also gives them the opportunity to kind of say like, Hey, we’re in the right direction, or Hey, or we want to skew it a bit in a different direction. So that’s a really interesting point. It gives them also the opportunity to tell us, Hey, pause, maybe we can try this approach before we’ve already created a huge membership site with seven, third party APIs. You know, so yeah, that’s really interesting. Another thing that you said, which really interested me was the checks like the checks on every single aspect of the technical process. 


13:40

Prajin
That something that you have built in your processes in terms of, let’s say it’s a signup form, something like a simple signup form. Do you actually have a checklist that these are the criteria that need to checked before we can say that this particular component is done? Is there an actual physical checklist? 


14:00

Samuel
Yeah. Yeah. It’s in it’s. It is in the Trello card or it’s in the Zoho, the, the task that’s represented a lot of these systems. They allow you to, when you create a card, it kind of builds out JIRA does it, and various things like that, but absolutely, it’s a physical checklist that you go, you tick off and just make sure all these things are done. There’s no, there’s no lingo. There’s no jargon there. It’s literally a checklist, so establishing that and that should be a team decision. Then that should be like, right. What, what do we think that needs to happen for this task to get done. Because every team is different and that’s, I think what was it, one of the points in the agile manifesto, it’s like this idea that it’s tools and pro people and communications over tools and processes. It’s this idea that because every team is different and they’re gonna work differently in every, project’s gonna be different. 


15:01

Samuel
Let’s agree together on certain things that we think are important. Maybe, maybe the client doesn’t appreciate design. I that’s a silly example, but maybe they don’t appreciate design. Maybe design is not that, part of your definition of done or anything like that, but it definitely helps for everyone to feel like they’re their perspective is being listened to on projects. Agreeing that with a team, I mean, again, you want to productize as much as you can. Obviously, you are probably gonna have in your mind defaults in place those standardized ideas, and then going from there. Again, every project’s different, every budget is different. You’re not gonna be able to this. This is all time at the end of the day that it’s being spent on. And that’s potentially one criticism of scrum. It is a little lot of ceremonies, a lot of like things you need to do and all this kind of stuff. 


15:56

Samuel
It, sometimes KanBan is just a, just, let’s just get it done. If these things help build in that quality and create that reassurance, then there’s no harm in at least having a starting point that you believe is a definition of the done thing. 


16:12

Prajin
Absolutely. That’s really interesting. Yeah. 


16:16

Samuel
The other thing is as well, you mentioned businesses being able to kind of pivot and change and stuff like that. I think that’s screaming the importance of having a solid kind of, I mean, what, when you kind of kick off a project, what is your process there? Like, do you have a strategic kind of workshop? Do you have any kind of onboarding? 


16:38

Prajin
Absolutely. I mean, I guess there are a couple of steps. One is kind of getting the scope from the client, which I think is a standard approach, but then how do we communicate that scope to the different departments since we’re multidisciplinary in the sense it’s not just one team that’s gonna work on a project. There’s that initial meeting with the creative lead, a tech lead and the PM who’s the person who’s gonna actually communicate with the clients. So like the account managers. We have all the key stakeholders without getting technical. We get we kind of build up the narrative of what the project is and in the progression of the project. Very loosely, we kind of sit together and work down the timelines and then it kind of auto-populates. Whether, if it’s a podcast, we know that, okay, we need the podcast on all filed this day 48 hours from then we’ll have to have the thumbnail executive summary, something published on Lipsin. 


17:43

Prajin
So, so those processes are already inbuilt, but to kind of figure out the narrative and the timeline, that’s more of a, a call, a discussion, a brainstorming session, playing on, playing around with the project management tool and then agreeing upon it and getting a final sign up from the client here. This is our projected timeline, and this is what we’re looking at. This is how it’s gonna be broken together. Here are the deliverables. It’s very collaborative and flexible because what we’ve noticed is things change. We need to be ready to adapt to those changes. It’s not just on our side, but like where we understand that the client’s position may change cuz businesses evolve, nothing is static. That’s kind of how we work as well within obviously we’re not gonna work an extra a hundred hours, within reason we’re quite accommodating and expect that accommodation back when teaming up. 


18:49

Prajin
We don’t even, and like to say, we work for a client, we work with a client, what I mean? That’s kind of like the overarching process. 


18:57

Samuel
Yeah, yeah, no, I completely agree. I use, I use, I think that’s terminology is so important to use. Like it shouldn’t be a full, it should be a, it depends what you’re doing at the end of the day. If, if you are happy with that, like vendor relationship, but I prefer this, the companionship that you make with a client, but the, the reason why I ask and you’ve touched on some good points there as well is just because businesses do change. I wonder. There’s something we work into our kind of strategic processes. It’s trying to understand the actual business, two aspects, the business goal, like what are the business trying to achieve right now? What is that for me? It’s the vision statement that really highlights this because you can have a vision, but how the business achieves that vision can manifest in so many different ways in, and by understanding the vision for me, it feels like you, they can pivot around it if they wanna, if they want to, for instance, I don’t know, feed a hundred thousand homeless people, that’s their vision. 


20:07

Samuel
It doesn’t matter whether it’s a website, doesn’t matter, it’s a podcast. It doesn’t matter whether it’s a, a, whatever, but understanding that vision allows ’em to be very flexible in how they, how they go about doing that. The reason why we try and understand that is because it, again, it allows us to work together in that they know that we are on the same lines and that the decisions we make or the suggestions that we make are kind of aligned to that vision. Working and you tell me, like, let me know if that’s something you’re doing, but understand the vision of the business itself. And also what is the goal? What is the vision of the project? They’re all, they’re the sort, I imagine it like, a, a pendulum, I guess, you’ve got this point, you’ve got this anchor point and then, and there are things kind of swinging around. 


21:06

Samuel
That’s where that’s what I like to think of these vision statements. That’s why we try and get those out of the client. Is that something that you work with them on or try and facilitate out of them? 


21:18

Prajin
So, yes, we do. I, I, I think that does help us figure out their goals. Often clients don’t even have a well-defined vision, but let’s say they do. And they communicate that with us. The real issue is for that vision to translate into a product. We might understand, Hey, this is where they wanna be. That to PM, to the developer, to tester often. I, and I do think it’s a challenge is to get that, to go down into every role. They build something it’s not, Hey, I’m building to make something work, but I’m building to satisfy a requirement to build something that aligns with a vision. You know? I, I think there’s often a disconnect in, in that when you can’t really necessarily communicate the vision of another company to your, our team and that to reflect the product. That’s, and that’s a part of quality is not just, Hey, does everything work? 


22:38

Prajin
Does it look good, but does it make sense if a product works? It doesn’t mean that it’s a good product and it’s satisfying the requirements and going above and beyond. 


22:50

Samuel
How, how are you communicating that at the moment then? What’s your, 


22:53

Prajin
What’s your, to be honest, it’s frankly, not done very well. I mean, we have the initial in the sense that we have room to improve. It’s, it’s just that general team meetings. We do scrum meetings, we do daily scrum meetings, and that’s when I get the chance to kind of communicate things very quickly to people I can like, Hey, we’re kind of moving away from the whole concept. That’s where we try to make sure everyone’s aligned in the same direction. But, but yeah, there’s definitely a place where I feel like sometimes we go away from why we’re building a product, 


23:38

Samuel
Does, do you feel that why changes than throughout a project? 


23:42

Prajin
Absolutely. I mean, I mean, unless you are focused on the goal, you’re like a blind man and you’re just keeping ongoing. You might, you might end up in the right place, but you would’ve taken a long route or something like that. And that’s, that’s the thing. How am I getting from eight to be is a big, big component? Yeah. So I’d love to know. How would you communicate, let’s say a client’s vision and actually get that vision represented in the product? Do you know what I mean? 


24:24

Samuel
Yeah. it’s tricky cuz I dunno which end to start. One thing, one thing that is unfortunate, potentially people, some people who are implementing, whether it’s design development or whatever, sometimes they’re, then they don’t care as much as you want them to be a, being someone who owns their business and all the rest of it. Your heart and soul is in almost every single project hopefully. The realization is that that does not trickle down to people who just want a paycheck at the end of the day. Doesn’t mean to say they don’t exist. I would, I was an employee at one point and I would really try and every meeting I would go in and, come out the end of the day with a headache, just because I’ve been thinking so passionately about these things, these people do exist obviously, but it’s that recognition that sometimes is not always gonna be the case. 


25:25

Samuel
Right. Just with that as a kind of foundational thing, working from the other end, when we do our onboarding or the scoping workshops, we involve the kind of leads of each department, because one, they can input into the strategic process anyway. That’s a lead developer, that’s a, a designer UX or something like that. You’ve got these, what we call consultants, right? There, they’re the ones who do a lot of the thinking. Sometimes they even hand that work off to people. They’re doing a lot of the strategic thinking, the kind of problem-solving aspect and also under, and they get to hear the horse’s mouth, the vision. So there’s an incentive there. Well, not an incentive, but there’s a, a point there, which the people who are defining the solution hearing and listening to that vision and they, aren’t just, it’s not just, oh, you’re a designer. 


26:27

Samuel
I’m gonna put you into the meeting. They’re for me, they’re people who show interest in whenever I interview them, for a job or whatever, I, I’m always interested to know like what gets their gears going like, and are they PA and what, what is their methodology for scoping out a project and all the rest of it. And, and if they mention along the lines of what are the business goals, what’s the, what is it trying to achieve? Those kinds of those kinds. If they’re asking those kinds of questions, then I know they’re the personality. They’re just, have the skill set to be involved in those initial meetings. And they’re the ones defining the solution. From that point onwards, it’s, there’s not, I mean, I have an onboarding meeting with the team. Absolutely. Like we discussed what was learned from the discovery, the strategic scoping session, what was learned there. 


27:26

Samuel
We communicate that vision than to the team at that point, from there, I’m happy, not happy to let it go, of course, but I’m almost expecting that they are just, some of those individuals are just there to implement the work. I know the strategic consultants who are there in the workshop, they’re building that vision and that methodology into the project, because that’s their skill set. There are two types of workers. I find those who cannot function without the requirements and those who cannot function without the vision. That’s the separation between like people who just gimme a bunch of stuff to do, I’ll do it. They don’t, they don’t care to think. They don’t want to think about whatever. And, and they’re good. They’re like foot soldiers at the end of the day, they just kinda get the work done and you need them. The others who can’t function without the vision. 


28:21

Samuel
They’re the ones who I expect to carry out that and to constantly remind themselves of why are we doing this? What is, what is the purpose of it? Challenge when things change, challenge that and say, well, this is the goal of the project. What, how is this falling in line with that? You know? And, and that tends to work with me. It’s initially it’s in the interview process really where that understanding starts, but you can’t force people to you can’t, you can’t just shake them until they say until they just take that visual mind. It’s, it’s a bit of prep work in the beginning just to kind of understand where there, where their moral compass lies thing. The only sticking point there, which you mentioned as well for me, is if the vision changes and whatever, and I’m not sure I have a, a, a fantastic answer for that because for me a vision shouldn’t change. 


29:20

Samuel
I don’t, I’m not sure whether this is more of a financial issue for you, whether they change something and you’re having to shift or pivot or whatever, whether that’s the issue here, or whether it’s the product itself suffering and the quality of the product itself suffering, because that change in vision, like what views, the the issue with a vision changing during the life cycle of a project. 


29:46

Prajin
I mean, it’s severalfold. I guess, the main issue, which I often find is a vision and a goal are two separate things. I feel like often, what businesses do they have short term goals, or they have a particular, it’s not necessarily clear set their vision. What happens is once we start building out a product and your vision might skew a bit, and it might change, you wanna address a larger community or a smaller community. Naturally, the product will change the functionalities with change. As an effect, it’s time, it’s money. It’s aligning the team again to the change in the client’s business. Cuz we need to cut to like get inside the client’s head cuz off, especially working with SES of not even SES, let’s say startups, they’re keeping on changing. You know, they get funding. They, they think they have a great idea, but they’re still okay, this is our market. 


30:59

Prajin
That is our market. Our vision is X this year. To be at the same pace as them, Isn’t easy. And, and I haven’t found a solution for that apart from like chasing after them, it’s like a race, they know what, where they’re going because it’s there in their head. The rest of us is kind of just like, oh, he, he means this. Or she means that. We’re like meandering through this product build because we wanna build a, a great product. But it’s yeah. The thing is, it’s not a well-defined vision. When we have our initial chats, we try to get that out from a client. We try to build that. Okay. You mean this and this is exactly what you want. We, we try to provide the solution as much as possible, but unless that’s internal, unless that’s coming from the individual, it’s bound to skew at times. 


32:02

Prajin
And that’s what I’ve seen. Yeah. 


32:04

Samuel
Yeah. Like going back to the start thing, like that’s just always gonna be the case. I don’t think you think the startup is changing? No, no, no. The founder is changing and everyone else is trying to keep up with the. 


32:20

Prajin
Founder. Yeah. 


32:22

Samuel
It, it happens all the time and I’m sure they’re just as kind of frustrated, with the founder of the vision as much as you are. You are playing catch up to those people playing catch up, probably, but that’s an assumption, but I’ve seen that a lot. It, it would be interesting to see or understand how deep into the scrum methodology you guys are, are doing because scrum is good for that. I think you should have those systems and checks in a place where you, yes, you’re protecting two weeks’ worth of work. Once you’ve got those two weeks’ worth of work, the client and everyone should be aware that is it. Like things could change. They, they could be a bomb could go off or something, but then, the sprint is protected until you get to that end. That’s why you do the presentation, you say where they are and you create that alignment on any kind of business updates. 


33:24

Samuel
Maybe there’s a business update process in place in that review, that sprint review portion or ceremony of the sprint. I wonder whether there’s some, just some using the scrum framework a bit more rigidly. And, and to bear that in mind that if you are working with a startup, things could change and that you have that point every single two weeks or however long your sprint is to get that feedback and understand, right. Where are we? What, what are the latest updates and your product owner well, should be the one who is constantly in touch with the business as well. It comes to sprint planning, they’re only allowing cards or they’re prior they’re, they’re working behind the scenes to prioritize the backlog, to be in line with the kind of the newsprint goal, the business requirements or something like. I, I feel like scrum is a good framework and maybe it’s worth looking a bit more deeply into that. 


34:27

Samuel
The other aspect of this is a mindset thing. I completely sympathize with things constantly changing. It’s just, sometimes it is very, very frustrating. Again, going back to the kind of agile method manifesto is around this idea that we should welcome change, and it should be something that we are not necessarily like mentally affected by, sorry, 


34:58

Speaker 4
I’m not sure what you want me to change, 


35:00

Samuel
Sir. Just thinks I’m talking into Siri. I’m not sure what I said there to prompt him, but it’s being open and welcome to change. I is part of agile. And, and maybe again, maybe it’s a case of Remo, like reminding that the team or the client, even that you are happy to adjust and pivot, but you, there needs to be some rigour and reassurance that you are not just being pulled around on an every other day basis that once that sprint is set in place, that’s it. And you go for it. Do you know what I mean? There could be something there could be a bit of communication around agile and what, what we’re here to do and how we respond to change. Or it could be more of a, looking more in-depth at your process when you work, when you are working with startups and that you do have that kind of check-in place to say, right. 


36:05

Samuel
Are we still going along the same lines? We’ve got this, we’ve got this product. I mean, I can’t imagine. I mean, you tell me, I can’t imagine it changes too dramatically whenever, whenever changes do happen. 


36:18

Prajin
No, not necessarily, but as decoupled as software can be a change, a minor change effects, plausibly may affect feature number two and three, and this is more of a technical thing, but like, let, Whether it’s a compatibility issue or a conflict between a couple of codes. It’s not ne like in the outset, a change may seem small, but it affects, oh yeah. Absolutely X, Y, and Z communicating that and having that delivered. So like we wanna deliver products quickly. Yes, sure. But we wanna have bug free products. That involves, that Iration that testing. When we keep getting changes from left-right. Center, Hey, we need this a member. That’s a member of a community said they want this feature. Yes. Let’s prioritize this. We, we move every couple of low priority stuff to the backlog. We add this to the next sprint. You get that from like three or four different places from the same client and you, and managing the sprint is just like, you just can’t control it. 


37:41

Prajin
You’re just getting stuck from everywhere and there are different components things break. Yeah, 


37:49

Samuel
Sure. Yeah. Again, I wonder if scrum more tight connection to scrum might help here, but again, you’ve got this idea of a different definition of ready, which is okay, we’ve got this requirement, it’s this new feature that we need to build in that cannot just enter the current sprint cuz the sprint is protected and then we need to, again, this is the same as the definition of done. It’s an agreed-upon, acceptance criteria basically, but for it can be accepted and it feels like, yes, it might have a knock-on effect, but what a business analyst would do or potentially a product owner or someone assigned to that task, they might collect requirements from different people to understand the overall impact of this thing. It’s a risk assessment. In some cases, in this case, it sounds like specifically, it would be a risk assessment. It’s like right before we do this, we need to just understand the effect it’s having. 


38:50

Samuel
That could be, yes, the work is still going on, but you pull a developer over it and say, Hey, we got this requirement. What are your thoughts on it? Do you think it’s gonna affect anything, blah, blah? And, and though that kind of, that the kind of not acceptance criteria, but the information though, the requirements gathering of that particular card is understood that could potentially be fed back a business to say, right, we’ve done a kind of risk assessment on this ticket. This is where this is what we feel like. It’s, you know what it’s gonna break? You could potentially get a bit more of fear all well, if it’s gonna break X, Y, Z, if the effect of this, me changing the size of this logo is gonna affect, system a and system B either, maybe it’s worth, maybe it’s not worth bringing in or something like that rather than kind of blindly accepting it and checking it into the, into the sprint. 


39:44

Samuel
Maybe a bit more rigour around the the risk assessment of bringing in something and not being afraid just to pull a developer aside for half an hour to chat about something there’s this thing called three AME, which is again, just three people, business analysts, quality assurance, and a developer pull into a room just to kind of talk about a particular ticket. Potentially there could be smaller subtasks off of that, that start to prepare for something like that. Maybe, maybe an API needs to be rewritten or something like that. Well, we could rewrite that API to accept both things, and then that’s something that can be done without affecting too much. Yeah, again, a bit more rigour around, not just accepting things at face value and chucking it into this sprint. It’s again, when you, I feel like when you’re aligned to that business vision, you’re able to sympathize with the business and, and if something smells a bit funny that you’re able to be like, right, okay, we’re gonna take a look at this. 


40:48

Samuel
I’m not sure if this aligns or I’m not sure if this is the best thing for the project, but let me do a bit of fishing around, come back. And then, and there’s your risk assessment? I mean, it used to be project management used to be a big old risk assessment piece. And, and luckily with agile, it’s a bit more kind of quick-fire and you’re able to get some answers or general idea, but try, try and protect, trying to protect that sprint is kind of key to that thing. Because again, it’s just gonna fresh straight everyone just like, Hey Wednesday, I know we’ve just started the sprint on a Monday. Let’s all we’ve gotta change to this now, which means rewriting all of our APIs or something like that. So it’s it. It’s, it’s gonna p**s, everyone, off and they’re not gonna carry, you mention about them not carrying that vision. 


41:35

Samuel
It’s, it is hard to when you’re constantly being thrown around and it’s like, oh, it’s changed and whatever. It’s meeting in the middle, I guess. 


41:44

Prajin
That’s actually really interesting. I mean, and I think maybe that’s something that we may need to like our team needs to reconsider is to be more strict on our sprints right now we’re very loosely following that methodology. Like maybe get into it more seriously and actually all those. As you mentioned, those physical checklists and stuff, we have it for some things, but maybe for really document all our processes, what is done and what affects a, B and C that’s, that’s a something which I can see would have a great effect on our final quality. So, yeah. 


42:25

Samuel
Yeah, I think so, cuz I mean, you’ve got agile, which is this mindset, this overall vision. You’ve got scrum, which is this methodology implementation of that mindset with a bit more framework around it. And it’s still a very light framework. You can pick up, you can pick up a lot of the kind of default, the ceremonies themselves very quickly a few of those ideas. It’s, it’s not a heavy read if you were to sit down with the scrum Alliance and have a look at the, have a look at some of the things in place. Oh, I, on the one hand, I’m thinking you don’t necessarily need to understand a lot of them just follow it. I think that’s an okay place to kind of start. What you get is a lot of people who just blindly follow something and do not really understand why they’re doing something. 


43:19

Samuel
It’s definitely worth that extra process of kind of understanding what the real thing is here. Startups, I think scrum is, is very, is a very good place to be. It’s, it’s a, a good method. It’s, it’s the most widely used agile methodology to be fair. It’s for a good reason, even scaled agile, which is for big organizations where you’ve got layer upon layer or levels, they call them, they use scrum at the core, you’ve got these individual scrum teams, you still have scrum underneath it, but yeah. I think that could, that could help you. Cool. 


44:01

Prajin
Yeah. Should. 


44:02

Samuel
Wrap it up there then. 


44:03

Prajin
Yeah, absolutely. I mean, that was super valuable. Cool. I really enjoyed that chat. 


44:08

Samuel
Nice. Is there anything, what was your kind of key takeaways from that? Is there anything that you are kind of eager to implement or change or do anything with that? Now, 


44:18

Prajin
Now a couple of things, one really is to actually get my scrum foundations, I mean, I have a very loose idea of it and we’ve just been running our business without really pushing and being strict on that or any framework. I think really getting down to, like you said, maybe pick up a book and actually get theory and practically implement that. Be more strict about how we run our sprints and start from. Yeah. I mean, that’s the starting point where like the first action point for me is to be more strict on our sprints and go from there. 


45:05

Samuel
Yeah. Just like I say, it’s like a page or two, the scrum framework’s very light. It’s something that, but I think there’s a lot of these things are that they’re intentionally there to put, to solve some of the issues that you are having specifically. It just felt quite right there to recommend that. So, and the only thing is it’s just, it does make it work for you. It can feel like there’s just lots of ceremonies and it’s like, oh, we’ve got spring planning now. Oh God, can’t we ask and all this kind of stuff, but these things are there. Try it. If it works for you, keep going with it. If you start to see a pro, if you start to see progress with that, if not just maybe tailor it or make something that works at the end of the day, it’s just a framework for you to customize and whatever. 


45:57

Samuel
I’d be interested to know if you do start to use that and whether you do see an improvement, it would be good to catch up and yeah, 


46:04

Prajin
Definitely. 


46:05

Samuel
See what happens there, but cool. 


46:07

Prajin
Awesome. 


46:09

Samuel
Nice one Regine. Yeah, 


46:10

Prajin
That was really good. Yeah, it was. I really appreciate your time. Means a lot to me. 


46:15

Samuel
No worries. Worries. All right. Well, enjoy the course of your day then. And we’ll catch up soon, 


46:21

Prajin
Right, Samuel. Thanks for that. Take. 


46:22

Samuel
Care. 


46:22

Prajin
Bye. Bye. 


46:24

Samuel
I just wanna say a big thank you to, again, that was a really cool conversation. Like I said, if you’re learning agile and you want no fluff answers to some of the jargon that’s in agile, then head on, it’s a lean pub.com/agile hyphen lingo, where you can download my book for free. Lastly, if this is a content you’re interested in, then let me know, because this was kind of a new thing for me. Do let me know, like the video, if you wanna see more of it and I’ll see you down in the comments. 

 

Leave a Reply

Your email address will not be published.