Detailed Notes
Agile has become a cornerstone of modern development, yet the essence of its value often gets overshadowed by procedural or tool-based interpretations. In the recent Building Better Developers podcast, Rob Broadhead and Michael Meloche delve into the foundational principles of Agile and its relevance to building better developer habits, emphasizing adaptability and continuous improvement. Here’s a summary of their key insights and practical takeaways for cultivating an Agile mindset.
*Read More*... https://develpreneur.com/agile-developer-habits-simple-practices-for-big-development-wins/
*Episode Challenge:* Weekly Planning, Daily Adapting
1. Set Weekly Goals
At the start of the week, identify a few larger goals or tasks that you aim to complete within seven days. These should be substantial enough that they cannot be completed in a single day, requiring consistent progress.
2. Plan Daily Tasks
Each day, determine smaller tasks or steps that contribute to those larger goals. These tasks should be adaptable, meaning they can evolve based on progress or changing priorities.
3. Monitor Your Process
Pay attention to whether sticking to a fixed schedule (working on the same task at the same time daily) or adapting your workflow dynamically works better for you. Evaluate if adjustments improve productivity and align with the Agile principle of responding to change over following a rigid plan.
The goal of this challenge was to instill habits of flexibility and iterative progress, mimicking Agile’s core values while fostering personal and professional growth.
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
*Additional Resources*
* Agile Principles Summary – Our Next Steps (https://develpreneur.com/agile-principles-summary-our-next-steps/) * Patterns For Agile – Templates for Success (https://develpreneur.com/patterns-for-agile-templates-for-success/) * Scrum Ceremonies – Running An Effective Sprint (https://develpreneur.com/scrum-ceremonies-running-an-effective-sprint/) * VIDEO: Coaching Tips to Stop Teams Equating Points to Hours (https://develpreneur.com/video-coaching-tips-to-stop-teams-equating-points-to-hours/)
*Follow-us on:*
* https://develpreneur.com/ * https://www.youtube.com/channel/UCZOuFN_LhczvGyT2KSItH_g/featured * https://facebook.com/Develpreneur * https://twitter.com/develpreneur * http://linkedin.com/develpreneur
Transcript Text
[Music] all right we have hit record and as always we got to figure what the hell we're going to talk about so um I was oh this will be near and dear to our heart um I want to talk about the habit of getting better at agile and this specifically but um I think sdlc but I think agile in particular I think there's some good habits we can do there and um it's a little bit on the lines of learning but I think we can talk a little bit about some things that you can do some habits that you can take that you can have that will help you be better at agile even if you don't have a full team or even if you're not doing it but it's things like hitting on those rituals and and honestly just looking at the agile Manifesto and thinking about keeping some of those uh those core pieces in mind while you're doing your development because I think that is I think would help a lot of people even if you don't do like scrum or anything like that but I think going through the you know the main keeping some of those things in mind were are I think H highly useful and I think there's some ways that we can do that almost like when you did your for a while where you had your alarm that would go off it's like you know are you being busy or productive kind of thing is that kind of a some of those regular sanity checks yeah I like that and that kind of flows with some of the conversations we've had this week uh about agile and ceremonies and uh I also threw two out there which we could probably discuss next but I had like utilizing Ai and then using virtual environments uh let's see what are you thinking on utilizing AI we not talked about it yet I guess we haven't have we no so what are you thinking uh kind of like we we had the conversation one or two back about goo like how to Google Google like maybe go just go through some habits of like what are some daily things that you could start practicing with AI to see if they're you know to help streamline or automate your processes oh I like that okay so we'll do that for the second one tonight today um yeah because we're going to get close we got yeah after this we can after we're done you can figure out when our when we're going to have to start our Christmas specials because I think those are coming up that maybe week I think next week we'll do our Christmas specials so cool so AI to end the year is actually probably not a bad one for the most part or probably end the year so I like that um and I'm just going to wing it on the good and the bad because I always do because that's just that takes too much thought all right let me throw a little more light on the subject if I can reach make sure your notifications are off make sure notifications are on so they beep all the time that way people know I am around thank you the nice thing too is I only have Focus for so long so it's like all right once it comes back on we got to wrap this sucker up three two well hello and welcome back we are continuing our season of building better habits because we are building better developers you on the other end are developers that we are building better ones of you we are helping you help yourself become better whether you're actually a developer not because there are a lot of developer related things that we found are very useful even if you're not by title or trade a developer technology is everywhere and there's a lot of these tools and things we discussed that are going to help you do a better job essentially of making technology your friend and finding a way to use it this episode we're actually going to talk about one of those things little spoiler alert is we're going to get into the world of agile a little bit or agile depending on which side of the ocean you live on and that is coming up soon but first I need to introduce myself I am Rob Brad I'm one of the founders of developing or also a founder of RB Consulting where we help you just sort of like this is instead of just building better developers it's more like building better businesses we help you leverage technology take what you've got and take what's out there and find a good mix of that so that you become more efficient at what you're doing through integration automation simplification we find ways to to take that sprawl of technology and turn it into something that is a a nice pretty little thing that helps you drive your machine faster cleaner better than a regular tuneup on the world in this world of challenges that we have put together I I'm going to I'm going to throw because I keep coming back to it I love the Pomodoro thing doing just a little bit um one thing that's like Michael has talked about is the struggle of keeping them small and actually like you know doing 25 minutes stop and move on and one of the things I've played around with a little bit is having like a long and a short pomodoros I've had some where I'll just say you know what I'm essentially going to do effectively like two back to back because in a 25 minutes it actually works really well goes back to Old School school blocks of where you had basically 50 minutes and then 10 minutes before you went to your next class and I've tried that a little bit I want to say that has worked out actually really well um it is sometimes a little bit of a stretch to get that 50 minutes before before somebody interrupts me but when I do it's actually been very productive uh another one of the things is gone back to uh the building a brand I have gone back to that several times uh working on the brand working uh in my business instead of on my business and have found a lot of little tweaks uh it's actually sort of a downside because a lot of it is generating a to-do list for myself because I'm like oh I got to do this got to do that got to do this got to do that but it is getting me at least back into it and getting me to refresh myself on some of the things that are that are out there um another one that's on the to-do list it's been really interesting one as I said as I I really struggle because I have daily to-do list but I have sort of expanded that out a little bit because I'm trying to think of that you know those two or three things I want to do every day I'm also instead of doing my daily list is causing me to go back and look at other items that I've got on like my general back blog of stuff to do and things like that or just revisit in some cases I'll look at things and go you know what I haven't thought about this in a while for example I had not really looked at my Amazon server allotment of stuff and a little bit of something that got me in there reminded me that I hadn't really reviewed stuff in a while I started looking in there and I'm probably going to save myself I don't know not a lot not a ton but at least 10 or 20 bucks a month maybe more than that on servers uh plus I actually will have more servers for less money so there's like some bonuses there because I was looking at looking at licensing and making sure like I do for other businesses making sure that I'm making the best use of the licenses and the technology that I have so it's a little bit of of drinking from your your own cup kind of thing or you know practicing What You Preach good things bad things good thing was I took a whole weekend off basically I got to I got to hang out do went to a different city did a whole lot of different stuff were just fun time fun times fun times the bad side of that is I was exhausted by the time I got to the end of the weekend I was actually looking forward to going back to work this week because I needed a break from having too much fun last weekend now I did not have that with Michael so he's going to share his story around all of this go ahead and introduce yourself hey everyone my name is Michael malash I'm one of the co-founders of developer Nur also I am the founder of Envision QA where we help businesses build software customize and tailor to their needs if you're struggling with your current software stack or you don't have a software stack you don't know where to begin give us a call we'll help you figure out what it is you need and build a solution that works for you good and bad uh let's see good uh we're getting closer to Christmas I'm getting back into that holiday mood starting to watch the field good Christmas homework movies um kind of putting me back in that good kind of mindset for the holiday uh bad which will go into uh kind of our challenges I was doing really good with the Pomodoro Technique and kind of staying on track small little iterations and following a plan of things to do until I worked on building this little server idea I had for a project I'm working on and what was probably a really decent estimate of about a day's work to build any type of server from scratch when you're definitely building Hardware machines not cloud-based machines there's always that little intri intricacies you run into and this one kind of went from okay it's almost there to next thing I know I'm 24 hours in just spent 16 hours straight plowing my way through to hit a brick wall that basic we had to Pivot um we hit something that just the solution was not going to work at all for what we wanted so we uh had to Pivot downside was the fact that I spent 16 hours straight literally glued to my machine because it's like every time I turn out I almost got we'll get the clock us four hours later all I think I'll get nope so bad habit good habit go back to that list go back to taking the Pomodoro and say take when you do get to your braks also take a moment maybe if you're on multiple pomodoros of the same issue set a goal or a check kind of a sanity check after four of these should I continue or do I need to Pivot so uh that's kind of where I'm at for uh our challenges beyond that everything else is going good you know typically I'm following the Pomodoro really well uh I've actually been really cranking it with automating things so I'm keeping track of what I'm doing because I'm building servers and we typically have to replicate so everything I have I'm taking and I'm just converting it to a script so I can run on the next machine or now that I'm back in the cloudbased world we'll just take snapshots as we go and be able to spin things up quickly so keeping that in mind you know that'll save my sanity hopefully going forward and it will save yours if you keep track of what you and see if you can automate it now this actually leads us into the word using that word pivot leads us into the world of agile which is one of the things that is a a strength of of the agile approach now they interesting thing about this and why I I felt like this was a good building better developers building better habits kind of thing is one I think a lot of people don't know what agile really means is that they they have all of these like they say it's pair programming or it's Sprints or something like that and agile is actually meta to that or or predates that to some extent I guess he doesn't even predate it it was it is it got they got merged somewhere and they they are a little bit different however this does touch on things like the which is part of the challenge we're going to touch on things that are really more in the scrum world and some of the the the ceremonies and things like that that go on because we're going to talk about building better habits now I want to I want to start with reiterating there's four main things more four main values that are what the agile Manifesto puts together and if you ever want to look at it agil manifesto. org it's out there it's been there forever it's very easy to read and it's very actually insightful as a developer it's one of those things like we've talked about the 4-Hour Work week and some other things out there that we revisit on a regular basis and I think the agile Manifesto is one as a developer you should because it's going to help you I think often be a check of like am I doing this one of those kind of thing am I doing this am I doing it right now the four values are they said that you know they've sort of the Preamble is hey we're a bunch of developers we've built a lot of systems and this is what we've learned and these are the four individuals and interactions over processes and tools as far as these are the things that we have come to Value so individuals and inter actions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation and responding to change over following a plan now that last one is a perfect example of what Michael just ran into is that there's sometimes particularly when we get into the software development world if you're in the waterfall World sometimes you're sort of stuck it's like you've got to plow through you've got to get this thing done because there are down ex issues that you have to worry about because you built in the requirements it's there everybody's counting on it all of that kind of stuff in this agile World there are some things that yes there are requirements that are sort of they're Loosely required you know tied to this thing so he can look at it and he can say you know what this is taking more time than we needed to it's more complicated we needed to it's not what we need or whatever it is and he can change and that's exactly what agile is about is it's not necessarily about hey we've got this plan we've got to execute we've got to do all this stuff we can change on a regular basis we are you know it's I used it several times when we talked when we were going through some of the the lectures about it it's a difference between laying out a yard stick versus having like let's say little 6inch rulers and using that to get to your point because the yard stick once you lay it down you're going from point A to point B that's it your your path is covered but if you've got these little 6 in you know 6inch rulers that you're doing along the way you're like hey I'm going to go here for a while oh maybe I'm going to go here or I'm going to go here you may go off in a completely different direction than you originally planned on it because the world is Ever Changing as they say and there's always things that come up you're your customers may change your focus the the the budget for a project may disappear the goal the scope of a project could change dramatically and I've seen that on numerous projects and that's why you do Sprints is you you sort of go in you you plan somewhat I mean you're planning like a a Sprint or two or three or four ahead maybe but generally speaking you you know you're you're still saying staying loose and flexible in how you approach things and I want to put that in and I think that actually fits with sort of the daily for example the daily to-do list that we talk about is that yes we've talked about having uh like your your career road map which is obviously going to spend many many many years it's going to spend decades versus we talk about uh annual goals and and quarterly goals and monthly goals and things like that but when you get down to that daily that does allow you on a given day to to Pivot it is in a sense it's an agile way to look at things and we'll talk about that a little bit more as we get into the Habit side of this and the challenge side of it but now I want to sort of throw this over to Michael and get some of your feedback and your thoughts along this and and where you want to go in the this agile discussion because we're agile like that yeah it's funny like your yard stick versus rulers it's a really good analogy and when you were saying that what popped into my head initially was not necessarily software but the bridge collaps in Baltimore so you had a direct path from A to B well something fails and it collapses what do you do you know you can't really pivot because you have this one path but if you have multiple paths to get to somewhere if one's blocked you can go somewhere else to get there so that was just a funny analogy cuz we watched so much of that collapse when that happened um and that sticks with me a lot especially with the agile process because even though like I ran into that situation where I was stuck for hours it was one of those though where at the end of the day it wasn't a critical failure we could pivot we could move on we could do something else to still keep the ball moving you know as we work with ceremonies try to work to our daily routines especially with teams everyone kind of has a different process or different ceremonies as to how they work with agile and you and I have talked about this many different times because we kind of um have different approaches to this and it's kind of funny because at the end of the day we're still trying to do the same thing but you're fighting like especially corporate you're fighting that too many meeting mindset sometimes where it's like do we really need a meeting to talk about in the agile sense yes because the ceremonies are designed in such a way that we keep that ball moving we keep the process moving if anyone's got any blockers we work through those issues and we can pivot we can move forward and then you get away from that kind of waterfall approach that Rob mentioned where you have to plan everything out first and then you know this is our path we can't deviate we have to get there but life changes you know it's like I don't know if anyone's still on Windows 10 you're probably getting popups constantly telling you that hey windows isn't Windows 10 isn't going to be supported anymore you need to upgrade well oh your machine isn't supported now you need to go buy a new machine these are things that can help be planned for and avoided with like agile you just plan things out but you plan them out in a way that puts working over over you know kind of like you said like planning out all the documentation first you kind of get a idea of what it is and you start writing it start building it out although there's times I'll push back on that like if we're starting a project sometimes you do have to do a little bit of waterfall to get enough information from a customer sometimes to figure out what they want now granted sometimes their ideas change and you'll pivot a lot on that um that's where agile comes in but sometimes certain things do require a little more planning up front so it's a little more waterfall is in the requirements phace but once you get to the development and the start putting things together that's where agile comes in that's where you start really using that uh ruler versus the yard stake approach to get things from point A to point B faster and I guess what I was kind of curious because you mentioned the um customers versus contract um kind of the third value that you mentioned there what are some examples of that because I have not really touched upon that too much with the agile experiences that I've worked with so that is one that I think is it tends to be more of I guess in a as a development manager or or things like that but really the customer collaboration over contract negotiation is uh for lack of better terms it's it's it's nickel and diming on either side of it so what happens is is that we can get into situations and it's really if you've been in a larger organization or if you are in a larger organization where there are things like change requests and things like that that go on and even if you're in a small organization or if you're if you've got a side hustle or something like that there is in any given contract there is going to be potential for change requests somewhere along the way there's a scope change or something along those lines now the thing is and this actually gets into the whole idea of like fixed bid projects versus hourly and some things like that that are a whole different soap box that I can get on and and lecture about and and wax poetic about but it really comes down to working with your customer to give them a to get to a win-win situation it is working with them to give them something that is valuable to them as opposed to getting into a fight over a dollar or you know or a dollar amount even because it's it's the kind of stuff where it's like yes you know you want this thing that's going to cost $110,000 and instead of getting in you know them saying well we could probably afford $9,000 and and you're like no you know well how about 95 you know instead of getting into the contract negotiation and spending all of that time trying to agree on what you're building you could spend that time building the thing a good example is I I dealt with somebody that was not there was like a slow pay go situation going on and they're like well I'm just not going to you I'm not going to work for the customer because they're not paying so I'm not going to do the work and it's like well all you're doing is just pushing kicking stuff down the road you're actually hurting yourself as well as them because now you're not doing the work and so now you're going to have to come back you're going to have to ramp back up and now the customer is not going to be happy cuz they're not getting what was promised and so you know instead of addressing the problem in that case they ended up saying well I'm just going to pull back and it's it's a negotiation strategy but it's I mean maybe not a good one you might agree or disagree with that but instead of going to the customer and saying look you know you're not paying on time I'm delivering on time we need to work on that and then figuring that out and instead of you know beating him over the head like a good example A lot of times in that case is like if don't pay me by this day then we're we're going to stop work completely or we're going to shut down all the servers or whatever it happens to be and instead of getting into these like you know us versus them mentality the customer collaboration is when you're like look we're all working to get this thing done and if you're not if you come into a project and you're doing it for the money you're just doing because like I see dollar signs and I just want to get paid then don't do it you're not ever you will never be a better developer if you do that guarantee you because you're not doing it to be a developer you're doing it to the you know to earn some money if you want to do that that's fine but you know listen to us keep listen to us because maybe you'll sometime see the light but don't think that that is ever going to make you a better developer it's going to make you maybe a better negotiator or salesman or something like that but it's not about development at that point the contract negotiation is all sales and and that kind of stuff customer collaboration is where you're sitting there with them and saying hey you have a problem we want to solve it and there's always a budget there's always a reality there there's like there's a certain level of how well you can solve that problem and so it's working with them to figure out okay maybe we can't we can't solve it 100% but maybe we can get you 80% there or maybe we can't give you the poror solution that you think you want but you're going to find out that the Kia no offense to either of these cars or manufacturers or anything like it but maybe like you just need the Kia solution because you don't need the all that other crap and there's a lot of that this goes back to again something I can preach on for days because people will end up buying software and spending money on stuff they really don't need they don't they never use it and so they have all these features and all these things that they're not using why spend extra money to get there why get stuck into contract negotiations and wasting time over things that you really aren't going to use anyways and this goes to this is on both sides of it it is as a developer working with the customer and as a customer hopefully working with the developers to realize that you guys are on the same page and or you guys have the same goals you have the same desires we should all want if you're being a better if you're here you're building better developers you do you want to build software that people use and so it's not as much about the Bucks that are involved and I think most of us would take a successful project at 10% less of what we could have earned as opposed to a failure of a project where we earn an extra 20% bonus somewhere along the way that's those and I'm very happy you asked that because I do think that's one that as developers we don't think about it in those terms as often because we'll get in and argue with our boss or the other teammates or things like that about well this has to be this color that has to we have to use this standard or we have to use this you know this data value or whatever it is we have all these little knit picky things so while this is talking about at a a customer level I think we often get lost in the details as well and it's like everybody's argument is fine you're better off just picking one and moving forward than you are spending time arguing so one did that answer your questions and then thoughts on that yeah that answered my question but it gave me a follow-up question for you so not to detract Too Much from the agile conversation but within that contract negotiation or kind of working with the customer kind of like arbitration things like that to keep things moving forward because we always do want to provide better services to make things better at the end of the day we want to provide them something that is better than what they have even if it's just cleaner code but within the contract negotiations not necessarily as you're going on about pay but at the beginning so as you're in that research phase that deep dive into the requirements and flushing out what they need how do you avoid getting into the Trap of what they have versus what they need to kind of get that happy medium to within the conversations you know kind of for a odd comparison is where oh I want this button up here and I want it to be purple it doesn't matter you just need a button that works how what is your suggestion to our listeners and viewers to kind of avoid that early on not necessarily later but at the beginning so that you kind of can still provide the benefit but maybe not at a higher cost that you would initially want this really does come down to it really it's it I think you win and lose this actually at the beginning of a project at the initial phases because what you what you want to do with now if it's a cust you've worked with it's different but somewhere along the way there is an initial the start to the relationship and if while you're building up that in that initial phase of of building that relationship and figuring out how you're going to interact with the customer if you build trust and help them understand that there are things that they need to bring to the table and there are things that you bring to the table and for them to trust you where you're in your lane and you trust them when they're in their Lane then I think it does help those things so for example let's say you're going along and they're saying there's there's a couple ways to approach that where you you show them something let's say you're you've got some mockups for this U solution that you're going to build for them and they're you're in the negotiation phase essentially they're trying to figure out what do they want what don't they want and this is a good example because at this point what they want and what they don't want should not come down to a purple button it's there's certain functionality they need there's a problem they need solve so this goes back to our favorite what is the why why are they actually doing this and so if they bring up something like that say hey this needs to have a purple button there now you could say you fool you are not paying attention to what you need to be paying attention to that will probably not win you a contract or Nice Guy of the Year award or gal of the Year award or anything else like that but what you can do is which a lot of times you can start with the Positive approach where you just say okay what is the a lot of times this is a great one what is the business reason for that what is the business logic behind that why does that need to be purple why does it need to be there because there could be a legitimate reason there could be something where they're like we've got a person that is colorblind and can only see purple or something like that or or if you know it could be something weird like the sun shines at that spot at a certain time of the day and if it's not purple then we can't I just random stuff but if you don't know their business and you don't like they do then they may be able to bring you something but I think it's it's often frame that as a what is the what is the business reasoning behind that because if it's just they say and sometimes they'll say well there is no reason I just like the color purple and I want a button there then you can go to well what is the benefit to you of that being purple and being there versus it being pink and over on the other side of the screen or something like that and if they ask you know if they just say well I'm the customer and I want to do it then you say well I understand that but I'm trying to be a good uh consultant or I'm trying to be a good vendor for this solution and when you maybe that you say that that actually adds a cost potentially it adds a cost or it's something else we have to check or it's something that's going to be makes this more complicated than it needs to be and so we just want to ensure that you really are stepping into this knowing that you are adding a complexity to this solution and we don't I don't you know I don't have to see why I just want to make sure that you understand that you've done it so whatever your reasoning is if you don't want to explain it that's fine but if you do explain it to me then maybe I can help you with alternate Solutions or help design this better in other areas because I'll find out for example that you love purple buttons okay cool I'm going to make buttons purple wherever I want you to click on them and I'm going to make them green because you hate green wherever I don't want you to click on buttons or something like that I mean there's there are things that we can do based on even the most for lack of a better term irrational likes and dislikes of a customer is we can use that we can leverage that and make a custom solution for them and so this goes back to this is a customer collaboration instead of you don't need that or something that is very much like now you've got a brick wall and you guys are having to argue you're you're on the opposite side of the customer you're coming alongside them and you put your arm around you're like that's a pretty cool button what is the value of having it there or something along those lines and so now you're working on the collaboration side and you're you're working to build their trust and help understand that you want them to you want them to be happy you want them to be satisfied with what comes out but you also are guarding their core idea of there's a problem to be solved and they're spending money and so we want to make sure that you are spending money wisely as much as we can does that make sense does that answer your question as well yeah you actually answered it in a very agile way I love that because it was a great solution in I really like how you turn it around to how is the you know what is the value of this to you yes I don't need to fully understand it but you just need to understand the cost that was huge or to me that's one of the big takeaways from that along with the collaboration because we do want to be there to provide a solution that the customer wants but in a reasonable and cost- effective way now if they want to pay for it and that's absolutely what they want you put it in there you just do have to make sure that you communicate the cost and complexity to the customer because they don't understand software or in most cases your customer is not a developer so when we do talk to them it can't be in Tech it has to be in common language that they can understand and that also isn't talking down to them so that when you are communicating it makes sense to both parties and and you can for like a better sense collaborate on the solution versus hammer and nail and that is really where agile comes in is that you you know part of that too is we don't have to make the decision on that button right now if we're in the beginning of a project we don't have to make that decision we can like you can basically just say we're going to leave fine cool we'll leave it there no problems and then you can always come back later down the road and then fight that battle if it even needs to be fought and maybe that screen never exists it maybe that button never exists it may be that customer gets fired and somebody else gets hired I mean there's all kinds of different things that could go on that will change it and so that's where the agile side is is like we don't have to nail we don't have to die on a hill at the beginning of a project we can say sure and we can go with the flow until we need until we're further far enough along and then we've got something that is much more concrete to fight over as opposed to some sort of just like you know vague ideas that we have of how this thing will look now the challenge side of this because I think you're you know a lot of you are like wow this is about you know big things and stuff like that the challenge I have for you is does go back to the um the daily tasks kind of thing is I want you to to at the beginning of a week take a look at you know build a few tasks up so essentially like tomorrow what are you going to do in the next seven days what are you going to accomplish in the next seven days and I want you each day to and you can pick you know one big goal or two or three big goals or something like that but then each day you're going to make a progress toward make progress towards these things so not something you can get done in one day let's think of something a little bit bigger that you want to do it maybe one of the other challenges we are and then put that on a list and actually what I'd like you to do is start with I'm going to do this at you know a certain certain time certain window block every day and see how many days you can do that is it more difficult to figure out that time and schedule that thing out and do it at the same time every day or is it easier for you to adjust when you do it and now this is hopefully going to get you into that mindset of things that I think for developers we often are like this is what I feel this is what I thought this is how I have to go instead this is going to help us break that habit or that mindset and realize that hey it doesn't have to actually flow the way we originally did it it can go in a different direction it can evolve it can change because that's where you're going to become a better developer and have some really good habits about you know getting used to being agile changing being more light on your feet in a a professional sense that being said you are not allowed to be agile at all you need to go directly to your email and send us something at info@ develop Andor let us know how things are going what do you like what don't you like let us know how your challenges are going that is actually very interesting to us and especially if there's any insights or habits or anything like that that you are that you building that you finding that this is something that particularly if it's something that we've helped you build this habit because of the challenge when maybe you were you know challenged by it before for example uh the Pomodoro thing and some of the things that uh we've learned as we've gone through these challenges as well you can also leave us comments wherever you're seeing this whether it's out on YouTube on the developer n Channel you can go wherever you're at a you get your podcast there's a way to leave uh feedback and all that kind of good stuff we really you know rank us however you want to but give us a five or one or whatever the review is but it's really more about the content we want to hear from you and also we've got a form out on developer.com so you can get us there at develop andur on X if you want to send something out that way or if you just want to follow us that being said we have we got to follow ourselves on to the next episode so go out there and have yourself a great day a great week and we will talk to you next time bonus material there's a lot of bonus already in there I don't know we've like overdone it a little bit I just wanted to throw because I know we kind of talked about you know uh individual um over you know individual uh processes versus uh tools and things like that but there are still some good agile tool out there like Trello and jira uh that kind of give you that um swim Lane type approach to being agile to keeping track of things um so if you aren't really familiar with agile and just need kind of a visual way to get started look at things like that because sometimes especially for me seeing the swim lanes and seeing where things are and how things are broken down really helps me keep track of things whereas you know if you're not and you're more just a process driven person then you know go for it you it just if you're really just don't understand agile sometimes that's a good way to just get started that's actually a great area for uh bonus material both processes and tools because processes is one that I I this is near and dear to my heart I'm I'm working through that with a team right now and building out processes and trying to figure out like how to change some and and mindsets and things like that and there's a lot of stuff that we want to implement but it doesn't always make sense for example the world famous like change control and stuff like that where you have a you have to have a ticket and then it has to run through all these processes it has to be QA reviewed QA blah blah blah blah blah so that by definition a lot of times that means if there's a hot fix it takes at least 24 to 48 hours to even get that into you know done and into production and stuff like that but then sometime and it so that process is there for a reason but like everything else there are going to be times where you're like you know what we need to skip some of this the tools are the same way a lot of these tools will lead you towards or tell you that you need to do a BC and you always have to do this you have to do that thing or you have to you the tool will make you sometimes because they need to in order to provide you some of the reporting they'll make you do certain things and those don't have to be you don't have to do that you can get around it like now granted depends on where you're at at your at your company it may be that you have to do all of this crap so that this certain report gets built at the end correctly at the end of the day but if that's not the case then it may be that you can like you can skip one every so often and you can just like push a task through without it being like this full awesome ticket or you can you can shortcut a couple of things because you're like you don't have to do all of this flowery stuff around it you really just need to say this is what we need to do this is what we need to fix now the tools have gotten pretty good about working with that a lot of the agile tools because they have ways to do you know simpler versus more complex stories and tasks and stuff like that but just always you know it's one of those I think as a keep your head up and and as you're going through things are you a slave it's sort of like being productive versus being busy are you a slave to the process or the tool are you going through this stuff because that's what you were taught or that's what you think it's supposed to be or is it actually providing value to the customer the world famous like not world I get maybe it is now to me one of the most famous things that is similar to this pick just about any pick any object we in language is that when you build a class the first thing you do is you write getter and Setter methods for everything for all the properties so you write all your properties you write all these Getters and Setters great awesome there's tools that can do that but the thing is it's like you may not need all of those so you just did all of that work even if it's mindless work and you may think like I wrote 400 lines of code bully for you that may not actually be codee that ever gets used so keep an eye out on these kinds of things also uh last thing manifest agile manifesto. org I highly recommend you check it out we even talk about the 12 principles that they get into because it really does get into some things that I think you're probably going to be convicted as they say it's like the it's like the Ten Commandments everybody's broken one if not all of them the the 12 principles of agile software you can easily find probably where you have screwed up on every one of them and where you can make some improvements and thus become a better developer that being said it's time for us to motor on continue to uh we're going to be very agile and we're going to like Sprint pivot and all that other kind of all those words all those Buzz words but we'll be right back before you know it for our next episode and we'll see what we're GNA we'll come up with whatever we're going to come up with at that point have a good one [Music]
Transcript Segments
[Music]
all right we have hit record and as
always we got to figure what the hell
we're going to talk about
so
um I was oh this will be near and dear
to our heart um I want to talk about the
habit of getting better at agile and
this specifically but um I think sdlc
but I think agile in particular I think
there's some good habits we can do there
and um it's a little bit on the lines of
learning but I think we can talk a
little bit about some things that you
can do some habits that you can take
that you can have that will help you be
better at agile even if you don't have a
full team or even if you're not doing it
but it's things like hitting on those
rituals and and honestly just looking at
the agile Manifesto and thinking about
keeping some of those uh those core
pieces in mind while you're doing your
development because I think that is I
think would help a lot of people even if
you don't do like scrum or anything like
that but I
think going through the you know the
main keeping some of those things in
mind were are I think H highly useful
and I think there's some ways that we
can do that almost like when you did
your for a while where you had your
alarm that would go off it's like you
know are you being busy or productive
kind of thing is that kind of a some of
those regular sanity
checks yeah I like that and that kind of
flows with some of the conversations
we've had this week uh about agile and
ceremonies
and uh I also threw two out there which
we could probably discuss next but I had
like utilizing Ai and then using virtual
environments uh let's see what are you
thinking on utilizing
AI we not talked about it yet I guess we
haven't have we
no so what are you
thinking uh kind of like we we had the
conversation one or two back about goo
like how to Google Google like maybe go
just go through some habits of like what
are some daily things that you could
start practicing with AI to see if
they're you know to help streamline or
automate your processes oh I like that
okay so we'll do that for the second one
tonight
today um yeah because we're going to get
close we got yeah after this we can
after we're done you can figure out when
our when we're going to have to start
our Christmas specials because I think
those are coming up that maybe week I
think next week we'll do our Christmas
specials so cool so AI to end the year
is actually probably not a bad one for
the most part or probably end the year
so I like
that um and I'm just going to wing it on
the good and the bad because I always do
because that's just that takes too much
thought all right let me throw a little
more light on the subject if I can reach
make sure your notifications are off
make sure notifications are on so they
beep all the time that way people know I
am around thank you
the nice thing too is I only have Focus
for so long so it's like all
right once it comes back on we got to
wrap this sucker
up three
two well hello and welcome back we are
continuing our season of building better
habits because we are building better
developers you on the other end are
developers that we are building better
ones of you we are helping you help
yourself become better whether you're
actually a developer not because there
are a lot of developer related things
that we found are very useful even if
you're not by title or trade a developer
technology is everywhere and there's a
lot of these tools and things we
discussed that are going to help you do
a better job essentially of making
technology your friend and finding a way
to use it this episode we're actually
going to talk about one of those things
little spoiler alert is we're going to
get into the world of agile a little bit
or agile depending on which side of the
ocean you live on and that is coming up
soon but first I need to introduce
myself I am Rob Brad I'm one of the
founders of developing or also a founder
of RB Consulting where we help you just
sort of like this is instead of just
building better developers it's more
like building better businesses we help
you leverage technology take what you've
got and take what's out there and find a
good mix of that so that you become more
efficient at what you're doing through
integration automation simplification we
find ways to to take that sprawl of
technology and turn it into something
that is a a nice pretty little thing
that helps you drive your machine faster
cleaner better than a regular
tuneup on the world in this world of
challenges that we have put
together I I'm going to I'm going to
throw because I keep coming back to it I
love the Pomodoro thing doing just a
little bit um one thing that's like
Michael has talked about is the struggle
of keeping them small and actually like
you know doing 25 minutes stop and move
on and one of the things I've played
around with a little bit is having like
a long and a short pomodoros I've had
some where I'll just say you know what
I'm essentially going to do effectively
like two back to back because in a 25
minutes it actually works really well
goes back to Old School school blocks of
where you had basically 50 minutes and
then 10 minutes before you went to your
next class and I've tried that a little
bit I want to say that has worked out
actually really well um it is sometimes
a little bit of a stretch to get that 50
minutes before before somebody
interrupts me but when I do it's
actually been very productive uh another
one of the things is gone back to uh the
building a brand I have gone back to
that several times uh working on the
brand working uh in my business instead
of on my business and have found a lot
of little tweaks uh it's actually sort
of a downside because a lot of it is
generating a to-do list for myself
because I'm like oh I got to do this got
to do that got to do this got to do that
but it is getting me at least back into
it and getting me to refresh myself on
some of the things that are that are out
there um another one that's on the to-do
list it's been really interesting one as
I said as I I really struggle because I
have daily to-do list but I have sort of
expanded that out a little bit because
I'm trying to think of that you know
those two or three things I want to do
every day I'm also instead of doing my
daily list is causing me to go back and
look at other items that I've got on
like my general back blog of stuff to do
and things like that or just revisit in
some cases I'll look at things and go
you know what I haven't thought about
this in a while for example I had not
really looked at my Amazon server
allotment of stuff and a little bit of
something that got me in there reminded
me that I hadn't really reviewed stuff
in a while I started looking in there
and I'm probably going to save myself I
don't know not a lot not a ton but at
least 10 or 20 bucks a month maybe more
than that on servers uh plus I actually
will have more servers for less money so
there's like some bonuses there because
I was looking at looking at licensing
and making sure like I do for other
businesses making sure that I'm making
the best use of the licenses and the
technology that I have so it's a little
bit of of drinking from your your own
cup kind of thing or you know practicing
What You Preach good things bad things
good thing was I took a whole weekend
off basically I got to I got to hang
out do went to a different city did a
whole lot of different stuff were just
fun time fun times fun times the bad
side of that is I was exhausted by the
time I got to the end of the weekend I
was actually looking forward to going
back to work this week because I needed
a break from having too much fun last
weekend now I did not have that with
Michael so he's going to share his story
around all of this go ahead and
introduce
yourself hey everyone my name is Michael
malash I'm one of the co-founders of
developer Nur also I am the founder of
Envision QA where we help businesses
build software customize and tailor to
their needs if you're struggling with
your current software stack or you don't
have a software stack you don't know
where to begin give us a call we'll help
you figure out what it is you need and
build a solution that works for
you good and bad uh let's see good uh
we're getting closer to Christmas I'm
getting back into that holiday mood
starting to watch the field good
Christmas homework movies um kind of
putting me back in that good kind of
mindset for the holiday uh bad which
will go into uh kind of our
challenges I was doing really good with
the Pomodoro Technique and kind of
staying on track small little iterations
and following a plan of things to do
until I worked on building this little
server idea I had for a project I'm
working on and what was probably a
really decent estimate of about a day's
work to build any type of server from
scratch when you're definitely building
Hardware machines not cloud-based
machines there's always that little
intri intricacies you run into and this
one kind of went from okay it's almost
there to next thing I know I'm 24 hours
in just spent 16 hours straight plowing
my way through to hit a brick wall that
basic we had to Pivot um we hit
something that
just the solution was not going to work
at all for what we
wanted so we uh had to Pivot downside
was the fact that I spent 16 hours
straight literally glued to my machine
because it's like every time I turn out
I almost got we'll get the clock us four
hours later all I think I'll get nope
so bad habit good habit go back to that
list go back to taking the Pomodoro and
say take when you do get to your braks
also take a moment maybe if you're on
multiple pomodoros of the same
issue set a goal or a check kind of a
sanity check after four of these should
I continue or do I need to Pivot so uh
that's kind of where I'm at for uh our
challenges beyond that everything else
is going good you know typically I'm
following the Pomodoro really well
uh I've actually been really cranking it
with automating things so I'm keeping
track of what I'm doing because I'm
building servers and we typically have
to replicate so everything I have I'm
taking and I'm just converting it to a
script so I can run on the next machine
or now that I'm back in the cloudbased
world we'll just take snapshots as we go
and be able to spin things up quickly so
keeping that in mind you know that'll
save my sanity hopefully going forward
and it will save yours if you keep track
of what you and see if you can automate
it now this actually leads us into the
word using that word pivot leads us into
the world of agile which is one of the
things that is a a strength of of the
agile approach now they interesting
thing about this and why I I felt like
this was a good building better
developers building better habits kind
of thing is one I think a lot of people
don't know what agile really means is
that they they have all of these like
they say it's pair programming or it's
Sprints or something like that and agile
is actually meta to that or or predates
that to some extent I guess he doesn't
even predate it it was it is it got they
got merged somewhere and they they are a
little bit different
however this does touch on things like
the which is part of the challenge we're
going to touch on things that are really
more in the scrum world and some of the
the the ceremonies and things like that
that go on because we're going to talk
about building better habits now I want
to I want to start with reiterating
there's four main things more four main
values that are what the agile Manifesto
puts together and if you ever want to
look at it agil manifesto. org it's out
there it's been there forever it's very
easy to read and it's very actually
insightful as a developer it's one of
those things like we've talked about the
4-Hour Work week and some other things
out there that we revisit on a regular
basis
and I think the agile Manifesto is one
as a developer you should because it's
going to help you I think often be a
check of like am I doing this one of
those kind of thing am I doing this am I
doing it right now the four values are
they said that you know they've sort of
the Preamble is hey we're a bunch of
developers we've built a lot of systems
and this is what we've learned and these
are the four individuals and
interactions over processes and tools as
far as these are the things that we have
come to Value so individuals and inter
actions over processes and tools working
software over comprehensive
documentation customer collaboration
over contract negotiation and responding
to change over following a plan now that
last one is a perfect example of what
Michael just ran into is that there's
sometimes particularly when we get into
the software development world if you're
in the waterfall World sometimes you're
sort of stuck it's like you've got to
plow through you've got to get this
thing done because there are down ex
issues that you have to worry about
because you built in the requirements
it's there everybody's counting on it
all of that kind of stuff in this agile
World there are some things that yes
there are requirements that are sort of
they're Loosely required you know tied
to this thing so he can look at it and
he can say you know what this is taking
more time than we needed to it's more
complicated we needed to it's not what
we need or whatever it is and he can
change and that's exactly what agile is
about is it's not necessarily about hey
we've got this plan we've got to execute
we've got to do all this stuff we can
change on a regular basis we are you
know it's I used it several times when
we talked when we were going through
some of the the lectures about it it's a
difference between laying out a yard
stick versus having like let's say
little 6inch rulers and using that to
get to your point because the yard stick
once you lay it down you're going from
point A to point B that's it your your
path is covered but if you've got these
little 6 in you know 6inch rulers that
you're doing along the way you're like
hey I'm going to go here for a while oh
maybe I'm going to go here or I'm going
to go here you may go off in a
completely different direction than you
originally planned on it because the
world is Ever Changing as they say and
there's always things that come up
you're your customers may change your
focus the the the budget for a project
may disappear the goal the scope of a
project could change dramatically and
I've seen that on numerous projects and
that's why you do Sprints is you you
sort of go in you you plan somewhat I
mean you're planning like a a Sprint or
two or three or four ahead maybe but
generally speaking you you know you're
you're still saying staying loose and
flexible in how you approach things and
I want to put that in and I think that
actually fits with sort of the daily for
example the daily to-do list that we
talk about is that yes we've talked
about having uh like your your career
road map which is obviously going to
spend many many many years it's going to
spend decades versus we talk about uh
annual goals and and quarterly goals and
monthly goals and things like that but
when you get down to that daily that
does allow you on a given day to to
Pivot it is in a sense it's an agile way
to look at things and we'll talk about
that a little bit more as we get into
the Habit side of this and the challenge
side of it but now I want to sort of
throw this over to Michael and get some
of your feedback and your thoughts along
this and and where you want to go in the
this agile discussion because we're
agile like that
yeah it's funny like your yard stick
versus rulers it's a really good analogy
and when you were saying that what
popped into my head initially was not
necessarily software but the bridge
collaps in Baltimore
so you had a direct path from A to B
well something fails and it collapses
what do you do you know you can't really
pivot because you have this one path but
if you have multiple paths to get to
somewhere if one's blocked you can go
somewhere else to get there so that was
just a funny analogy cuz we watched so
much of that collapse when that happened
um and that sticks with me a lot
especially with the agile process
because even though like I ran into that
situation where I was stuck for hours it
was one of those though where at the end
of the day it wasn't a critical failure
we could pivot we could move on we could
do something else to still keep the ball
moving you know as we work with
ceremonies try to work to our daily
routines especially with
teams everyone kind of has a
different process or different
ceremonies as to how they work with
agile and you and I have talked about
this many different times because we
kind of um have different approaches to
this and it's kind of funny because at
the end of the day we're still trying to
do the same thing but you're fighting
like especially corporate you're
fighting that too many meeting mindset
sometimes where it's like do we really
need a meeting to talk about in the
agile sense yes
because the ceremonies are designed in
such a way that we keep that ball moving
we keep the process moving if anyone's
got any blockers we work through those
issues and we can pivot we can move
forward and then you get away from that
kind of waterfall approach that Rob
mentioned where you have to plan
everything out first and then you know
this is our path we can't deviate we
have to get there but life changes you
know it's like I don't know if anyone's
still on Windows 10 you're probably
getting popups constantly telling you
that hey windows isn't Windows 10 isn't
going to be supported anymore you need
to upgrade well oh your machine isn't
supported now you need to go buy a new
machine these are things that can help
be planned for and avoided with like
agile you just plan things out but you
plan them out in a way that puts working
over over you know kind of like you said
like planning out all the documentation
first you kind of get a idea of what it
is and you start writing it start
building it
out although there's times I'll push
back on that like if we're starting a
project sometimes you do have to do a
little bit of waterfall to get enough
information from a customer sometimes to
figure out what they want now granted
sometimes their ideas change and you'll
pivot a lot on that um that's where
agile comes in but sometimes certain
things do require a little more planning
up front so it's a little more waterfall
is in the requirements phace but once
you get to the development and the start
putting things together that's where
agile comes in that's where you start
really using that uh ruler versus the
yard stake approach to get things from
point A to point B
faster and I guess what I was kind of
curious because you mentioned the um
customers versus contract um kind of the
third value that you mentioned there
what are some examples of that because I
have not really touched upon that too
much with the agile experiences that
I've worked with so that is one that I
think is it tends to be more of I guess
in a as a development manager or or
things like that but really the customer
collaboration over contract negotiation
is uh for lack of better terms it's it's
it's nickel and diming on either side of
it so what happens is is that we can get
into situations and it's really if
you've been in a larger organization or
if you are in a larger organization
where there are things like change
requests and things like that that go on
and even if you're in a small
organization or if you're if you've got
a side hustle or something like that
there is in any given contract there is
going to be potential for change
requests somewhere along the way there's
a scope change or something along those
lines now
the thing is and this actually gets into
the whole idea of like fixed bid
projects versus hourly and some things
like that that are a whole different
soap box that I can get on and and
lecture about and and wax poetic about
but it really comes down
to working with your customer to give
them a to get to a win-win situation it
is working with them to give them
something that is valuable to them as
opposed to getting into a fight over a
dollar or you know or a dollar amount
even because it's it's the kind of stuff
where it's like yes you know you want
this thing that's going to cost
$110,000 and instead of getting in you
know them saying well we could probably
afford $9,000 and and you're like no you
know well how about 95 you know instead
of getting into the contract negotiation
and spending all of that time trying to
agree on what you're building you could
spend that time building the thing a
good example is I I dealt with somebody
that was not there was like a slow pay
go situation going on and they're like
well I'm just not going to you I'm not
going to work for the customer because
they're not paying so I'm not going to
do the work and it's like well all
you're doing is just pushing kicking
stuff down the road you're actually
hurting yourself as well as them because
now you're not doing the work and so now
you're going to have to come back you're
going to have to ramp back up and now
the customer is not going to be happy
cuz they're not getting what was
promised and so you know instead of
addressing the problem in that case they
ended up saying well I'm just going to
pull back and it's it's a negotiation
strategy but it's I mean maybe not a
good one you might agree or disagree
with that but instead of going to the
customer and saying look you know you're
not paying on time I'm delivering on
time we need to work on that and then
figuring that out and instead of you
know beating him over the head like a
good example A lot of times in that case
is like if don't pay me by this day then
we're we're going to stop work
completely or we're going to shut down
all the servers or whatever it happens
to be and instead of getting into these
like you know us versus them mentality
the customer collaboration is when
you're like look we're all working to
get this thing done and if you're not if
you come into a project and you're doing
it for the money you're just doing
because like I see dollar signs and I
just want to get paid then don't do it
you're not ever you will never be a
better developer if you do that
guarantee you because you're not doing
it to be a developer you're doing it to
the you know to earn some money if you
want to do that that's fine but you know
listen to us keep listen to us because
maybe you'll sometime see the light but
don't think that that is ever going to
make you a better developer it's going
to make you maybe a better negotiator or
salesman or something like that but it's
not about development at that point the
contract negotiation is all sales and
and that kind of stuff customer
collaboration is where you're sitting
there with them and saying hey you have
a problem we want to solve it and
there's always a budget there's always a
reality there there's like there's a
certain level of how well you can solve
that problem and so it's working with
them to figure out okay maybe we can't
we can't solve it 100% but maybe we can
get you 80% there or maybe we can't give
you the poror solution that you think
you want but you're going to find out
that the Kia no offense to either of
these cars or manufacturers or anything
like it but maybe like you just need the
Kia solution because you don't need the
all that other crap and there's a lot of
that this goes back to again something I
can preach on for days because people
will end up buying software and spending
money on stuff they really don't need
they don't they never use it and so they
have all these features and all these
things that they're not using why spend
extra money to get there why get stuck
into contract negotiations and wasting
time over things that you really aren't
going to use anyways and this goes to
this is on both sides of it it is as a
developer working with the customer and
as a customer hopefully working with the
developers to realize that you guys are
on the same page and or you guys have
the same goals you have the same desires
we should all want if you're being a
better if you're here you're building
better developers you do you want to
build software that people use and so
it's not as much about the Bucks that
are involved and I think most of us
would take a successful project at 10%
less of what we could have earned as
opposed to a failure of a project where
we earn an extra 20% bonus somewhere
along the way that's those and I'm very
happy you asked that because I do think
that's one that as developers we don't
think about it in those terms as often
because we'll get in and argue with our
boss or the other teammates or things
like that about well this has to be this
color that has to we have to use this
standard or we have to use this you know
this data value or whatever it is we
have all these little knit picky things
so while this is talking about at a a
customer level I think we often get lost
in the details as well and it's
like everybody's argument is fine you're
better off just picking one and moving
forward than you are spending time
arguing so one did that answer your
questions and then thoughts on that yeah
that answered my question but it gave me
a follow-up question for you so not to
detract Too Much from the agile
conversation but within that contract
negotiation or kind of working with the
customer kind of like arbitration things
like that to keep things moving forward
because we always do want to provide
better services to make things better at
the end of the day we want to provide
them something that is better than what
they have even if it's just cleaner
code but within the contract
negotiations not necessarily as you're
going on about pay but at the beginning
so as you're in that research phase that
deep dive into the requirements and
flushing out what they
need how do you avoid getting into the
Trap of what they have versus what they
need to kind of get that happy medium to
within the conversations you know kind
of for a odd comparison is where oh I
want this button up here and I want it
to be purple it doesn't matter you just
need a button that
works how what is your suggestion to our
listeners and viewers to kind of avoid
that early on not necessarily later but
at the beginning so that you kind of can
still provide the benefit but maybe not
at a higher cost that you would
initially want this really does come
down to it really it's it I think you
win and lose this actually at the
beginning of a project at the initial
phases because what you what you want to
do with now if it's a cust you've worked
with it's different but somewhere along
the way there is an initial the start to
the relationship and if while you're
building up that in that initial phase
of of building that relationship and
figuring out how you're going to
interact with the customer if you build
trust and help them understand that
there are things that they need to bring
to the table and there are things that
you bring to the table and for them to
trust you where you're in your lane and
you trust them when they're in their
Lane then I think it does help those
things so for example let's say you're
going along and they're saying there's
there's a couple ways to approach that
where you you show them something let's
say you're you've got some mockups for
this U solution that you're going to
build for them and they're you're in the
negotiation phase essentially they're
trying to figure out what do they want
what don't they want and this is a good
example because at this point what they
want and what they don't want should not
come down to a purple button it's
there's certain functionality they need
there's a problem they need solve so
this goes back to our favorite what is
the why why are they actually doing this
and so if they bring up something like
that say hey this needs to have a purple
button there now you could say you fool
you are not paying attention to what you
need to be paying attention to that will
probably not win you a contract or Nice
Guy of the Year award or gal of the Year
award or anything else like that but
what you can do is which a lot of times
you can start with the Positive approach
where you just say okay what is the a
lot of times this is a great one what is
the business reason for that what is the
business logic behind that why does that
need to be purple why does it need to be
there because there could be a
legitimate reason there could be
something where they're like we've got a
person that is colorblind and can only
see purple or something like that or or
if you know it could be something weird
like the sun shines at that spot at a
certain time of the day and if it's not
purple then we can't I just random stuff
but if you don't know their business and
you don't like they do then they may be
able to bring you something but I think
it's it's often frame that as a what is
the what is the business reasoning
behind that because if it's just they
say and sometimes they'll say well there
is no reason I just like the color
purple and I want a button there then
you can go to well what is the benefit
to you of that being purple and being
there versus it being pink and over on
the other side of the screen or
something like
that and if they ask you know if they
just say well I'm the customer and I
want to do it then you say well I
understand that but I'm trying to be a
good
uh consultant or I'm trying to be a good
vendor for this solution and when you
maybe that you say that that actually
adds a cost potentially it adds a cost
or it's something else we have to check
or it's something that's going to be
makes this more complicated than it
needs to be and so we just want to
ensure that you really are stepping into
this knowing that you are adding a
complexity to this
solution and we don't I don't you know I
don't have to see why I just want to
make sure that you understand that
you've done it so whatever your
reasoning is if you don't want to
explain it that's fine but if you do
explain it to me then maybe I can help
you with alternate Solutions or help
design this better in other areas
because I'll find out for example that
you love purple buttons okay cool I'm
going to make buttons purple wherever I
want you to click on them and I'm going
to make them green because you hate
green wherever I don't want you to click
on buttons or something like that I mean
there's there are things that we can do
based on even the most for lack of a
better term irrational likes and
dislikes of a customer is we can use
that we can leverage that and make a
custom solution for them and so this
goes back to this is a customer
collaboration instead
of you don't need that or something that
is very much like now you've got a brick
wall and you guys are having to argue
you're you're on the opposite side of
the customer you're coming alongside
them and you put your arm around you're
like that's a pretty cool button what is
the value of having it there or
something along those lines and so now
you're working on the collaboration side
and you're you're working to build their
trust and help understand that you want
them to you want them to be happy you
want them to be satisfied with what
comes out but you also are guarding
their core idea of there's a problem to
be solved and they're spending money and
so we want to make sure that you are
spending money wisely as much as we can
does that make sense does that answer
your question as well yeah you actually
answered it in a very agile way I love
that
because it was a great solution
in I really like
how you turn it around to how is the you
know what is the value of this to you
yes I don't need to fully understand it
but you just need to understand the cost
that was huge or to me that's one of the
big takeaways from that along with the
collaboration because we do want to be
there to provide a solution that the
customer wants but in a reasonable and
cost- effective way now if they want to
pay for it and that's absolutely what
they want you put it in there you just
do have to make sure that you
communicate the cost and complexity to
the customer because they don't
understand software or in most cases
your customer is not a developer so when
we do talk to them it can't be in Tech
it has to be in common language that
they can understand and that also isn't
talking down to them so that when you
are communicating it makes sense to both
parties and and you can for like a
better sense collaborate on the solution
versus hammer and
nail and that is really where agile
comes in is that you you know part of
that too is we don't have to make the
decision on that button right now if
we're in the beginning of a project we
don't have to make that decision we can
like you can basically just say we're
going to leave fine cool we'll leave it
there no problems and then you can
always come back later down the road and
then fight that battle if it even needs
to be fought and maybe that screen never
exists it maybe that button never exists
it may be that customer gets fired and
somebody else gets hired I mean there's
all kinds of different things that could
go on that will change it and so that's
where the agile side is is like we don't
have to nail we don't have to die on a
hill at the beginning of a project we
can say sure and we can go with the flow
until we need until we're further far
enough along and then we've got
something that is much more concrete to
fight over as opposed to some sort of
just like you know vague ideas that we
have of how this thing will
look
now the challenge side of this because I
think you're you know a lot of you are
like wow this is about you know big
things and stuff like that the challenge
I have for you is does go back to the um
the daily tasks kind of thing is I want
you to to at the beginning of a week
take a look at you know build a few
tasks up so essentially like tomorrow
what are you going to do in the next
seven days what are you going to
accomplish in the next seven days and I
want you each day to and you can pick
you know one big goal or two or three
big goals or something like that but
then each day you're going to make a
progress toward make progress towards
these things so not something you can
get done in one day let's think of
something a little bit bigger that you
want to do it maybe one of the other
challenges we are and then put that on a
list and actually what I'd like you to
do is start with I'm going to do this at
you know a certain certain time certain
window block every day
and see how many days you can do that is
it more difficult to figure out that
time and schedule that thing out and do
it at the same time every day or is it
easier for you to adjust when you do it
and now this is hopefully going to get
you into that mindset of things that I
think for developers we often are like
this is what I feel this is what I
thought this is how I have to go instead
this is going to help us break that
habit or that mindset and realize that
hey it doesn't have to actually flow the
way we originally did it it can go in a
different direction it can evolve it can
change because that's where you're going
to become a better developer and have
some really good habits about you know
getting used to being agile changing
being more light on your feet in a a
professional
sense that being said you are not
allowed to be agile at all you need to
go directly to your email and send us
something at info@ develop Andor let us
know how things are going what do you
like what don't you like let us know how
your challenges are going that is
actually very interesting to us and
especially if there's any insights or
habits or anything like that that you
are that you building that you finding
that this is something that particularly
if it's something that we've helped you
build this habit because of the
challenge when maybe you were you know
challenged by it before for example uh
the Pomodoro thing and some of the
things that uh we've learned as we've
gone through these challenges as well
you can also leave us comments wherever
you're seeing this whether it's out on
YouTube on the developer n Channel you
can go wherever you're at a you get your
podcast there's a way to leave uh
feedback and all that kind of good stuff
we really you know rank us however you
want to but give us a five or one or
whatever the review is but it's really
more about the content we want to hear
from you and also we've got a form out
on developer.com so you can get us there
at develop andur on X if you want to
send something out that way or if you
just want to follow us that being said
we have we got to follow ourselves on to
the next episode so go out there and
have yourself a great day a great week
and we will talk to you next
time bonus
material there's a lot of bonus already
in there I don't know we've like
overdone it a little bit I just wanted
to throw because I know we kind of
talked about you know uh
individual um over you know individual
uh processes versus uh tools and things
like that but there are still some good
agile tool out there like Trello and
jira uh that kind of give you that
um swim Lane type approach to being
agile to keeping track of things um so
if you aren't really familiar with agile
and just need kind of a visual way to
get started look at things like that
because sometimes especially for me
seeing the swim lanes and seeing where
things are and how things are broken
down really helps me keep track of
things whereas you know if you're not
and you're more just a process driven
person then you know go for it you it
just if you're really just don't
understand agile sometimes that's a good
way to just get started that's actually
a great area for uh bonus material both
processes and tools
because processes is one that I I this
is near and dear to my heart I'm I'm
working through that with a team right
now and building out processes and
trying to figure out like how to change
some and and mindsets and things like
that and there's a lot of stuff that we
want to implement
but it doesn't always make sense for
example the world famous like change
control and stuff like that where you
have a you have to have a ticket and
then it has to run through all these
processes it has to be QA reviewed QA
blah blah blah blah blah so that by
definition a lot of times that means if
there's a hot fix it takes at least 24
to 48 hours to even get that into you
know done and into production and stuff
like that but then sometime and it so
that process is there for a reason but
like everything else there are going to
be times where you're like you know what
we need to skip some of this the tools
are the same way a lot of these tools
will lead you towards or tell you that
you need to do a BC and you always have
to do this you have to do that thing or
you have to you the tool will make you
sometimes because they need to in order
to provide you some of the reporting
they'll make you do certain things and
those don't have to be you don't have to
do that you can get around it like now
granted depends on where you're at at
your at your company it may be that you
have to do all of this crap so that this
certain report gets built at the end
correctly at the end of the day but if
that's not the case then it may be that
you can like you can skip one every so
often and you can just like push a task
through without it being like this full
awesome ticket or you can you can
shortcut a couple of things because
you're like you don't have to do all of
this flowery stuff around it you really
just need to say this is what we need to
do this is what we need to fix now the
tools have gotten pretty good about
working with that a lot of the agile
tools because they have ways to do you
know simpler versus more complex stories
and tasks and stuff like that but just
always you know it's one of those I
think as a keep your head up and and as
you're going through things are you a
slave it's sort of like being productive
versus being busy are you a slave to the
process or the tool are you going
through this stuff because that's what
you were taught or that's what you think
it's supposed to be or is it actually
providing value to the customer the
world famous like not world I get maybe
it is now to me one of the most famous
things that is similar to this pick just
about any pick any object we in language
is that when you build a class the first
thing you do is you write getter and
Setter methods for everything for all
the properties so you write all your
properties you write all these Getters
and Setters great awesome there's tools
that can do that but the thing is it's
like you may not need all of those so
you just did all of that work even if
it's mindless work and you may think
like I wrote 400 lines of code bully for
you that may not actually be codee that
ever gets used so keep an eye out on
these kinds of things also uh last thing
manifest agile manifesto. org I highly
recommend you check it out we even talk
about the 12 principles that they get
into because it really does get into
some things that I think you're probably
going to be convicted as they say it's
like the it's like the Ten Commandments
everybody's broken one if not all of
them the the 12 principles of agile
software you can easily find
probably where you have screwed up on
every one of them and where you can make
some improvements and thus become a
better developer that being said it's
time for us to motor on continue to uh
we're going to be very agile and we're
going to like Sprint pivot and all that
other kind of all those words all those
Buzz words but we'll be right back
before you know it for our next episode
and we'll see what we're GNA we'll come
up with whatever we're going to come up
with at that point have a good one
[Music]