This is a unique gem in the whole Internet. Most software developer channels are about hacking interviews, some book algorithms, "a day in a life of an ex-GOOGLER" or even about ML which they don't even understand themselves, i.e. mostly useless information. But this channel is something very different and unique, I found many similarities between what you say and what I see in the industry being a team lead of the development team. I've seen teams failing in Scrum forced by the management as a "visibility" tooling and stand-ups used to "apply the needed pressure" (some manager's words) on developers to keep them running faster. I'm trying to learn from any source I can find, and your channel is a great source for me. Please, keep up the good work and thank you!
Another huge and super common fail of applying Agile is using it as a crutch to avoid tech debt. Not valuing the architecture and the team and generally focusing on just shipping, ie: adding value for customers, is basically building a house of cards.
@@brianlaudrupchannel Agile development practices and Test-Driven-Development with refactoring can be done together, or not. Agile is used as an alternative to Waterfall to get products out the door that can change during development. TDD and refactoring help create quality code that can be changed quicker. Both should be used together.
08:21 - The problem with retrospectives is that there is a lot of talk and little action. If I have to repeat what I said in the last retrospective what is the point? I've seen this again and again. Devs, QAs mention stuff and it gets logged but no action (or very minimal action) is taken.
Yes that’s a problem with the leadership, not the process of retrospectives. But I agree this is a common problem and gives the impression it’s a completely useless practice. Which I can totally understand if no improvements are actually being made!
What other pitfalls do you see on agile software development projects that cause them to fail? Skip to points: 01:01 High Friction Tools 02:34 Designing For Conformity 04:41 Stop What Doesn't Work 06:01 Focusing On Data Over Teamwork 07:07 Focusing On Output Over Outcomes 08:14 Not Stopping To Improve 10:39 Not Continuously Delivering Builds
I can see three more pitfalls about Software development: 1. It's about continuous integration: The team doesn't embrace TDD. I think TDD is something that everyone on the team needs to do. If some don't: some leave the team, or the team leave the TDD (and this leave CI) 2. Some Chief (CTO, CEO, etc.) doesn't even know what Agile is. So, sometimes, it's very, very hard and painfull to apply it. 3. It's comming with the second point : Chief gives responsibility without authority. I think that makes Agile even more toxic than Waterfall as it's destroy the ability of a the team to be 'proud' of their work and thus hurting peoples in the long term. What do you think ? Your videos are really good. Well done ! Cheers ! PS: Sorry for my english ^^
estebanisswimming glad to help! There are many pitfalls but I hoped these ones I see more often might help someone work on getting past the common ones. Thanks for letting me know it helps!
A small pitfall that I came across recently is trying to implement a PM tool like Asana or Trello and change/innovate the process at the same time. Was excited for the new tool and possibilities but created too much processes change and lost continuity and momentum. What would have been better is to establish a new tool and let the tool shine and give benefits on the current process, then innovate the process later.
Some pitfalls I've run into and are stressing me out and reducing my productivity: - Switching between tasks after priority changes - Leave tasks half why done and focus on a new task like bugs or client requests. - How to deal in an easy way with tasks no finished from the previous sprint. put them in the next sprint or put them back in the backlog?
Hey there in my experience there’s a couple things you can do that might help there. First would be to help stakeholders and management know that once a sprint is under way, no new work should be assigned. This is the only way to have a stable flow of progress without forcing people to leave work half done or low quality - which is worse than any delay for the stakeholder to have to wait before someone gets started on their new priorities. Second I’m of the opinion that if work in the current sprint is going long, people help each other finish and the sprint is extended. This is an unpopular opinion, but when a team is forced to hit a goal (not a commitment!) it adds immense pressure to game numbers and not stop and learn why things are taking longer. It also pits people against each other which is horrible for team culture. What good is it if 4/5 a team is done but you can’t release it? And how does it make the “late” person feel that no one will help teach them how to improve?
@@HealthyDev @Ilyes This issue obviously gives rise to certain bad practices Agile or no Agile. 1. Under what circumstances is the priority changing midway into development that you are being forced to switch tasks. There will be productivity loss as also loss of morale. 2. Bugs and Client Requests should be prioritized in the Product Backlog, why is it even becoming an unplanned input into the Sprint - this practice tells me there is no proper hierarchy outside of the Scrum Team. The Product Owner needs to filter these issues at their end. 3. Incomplete tasks (User Stories) could be taken into the next sprint along with fresh new ones. However a fundamental question needs to be asked if this is a recurring issue - The User Story estimation is not being practiced appropriately. If a Task is not getting completed within a given Sprint then why was it not decomposed further in the planning stage itself. My two cents.
@@kalyanchilkamarri7298 I agree. And personally I don't think it's ever a good idea to leave work unfinished. If a feature is going to be abandoned it should be completely removed from the code. Otherwise it should be finished before priorities can be shifted. If people don't stick to this rule, they end up with features that people assume are done (but aren't) and code that isn't in a releasable state. Basically a false sense of progress from the customer perspective - regardless of what a kanban board or backlog says.
@@HealthyDev Especially being put on a other project to fix a huge list of bugs while its original developers have switched to another project. Am I sorta a janitor that cleans other peoples' messes?
@@SurenEnfiajyan that stinks. If they don't put you on a newer project within a reasonable timeframe, might be worth considering your options. Sometimes other people than me have gotten picked to start newer efforts, but if you stay stuck too long that can be career limiting. Only you know the right timing there.
Very helpful content, most of the things you mentioned are scenarios I'm experiencing every day. After watching your video I have a clear view on how to use agile without all the hustle that slows down a team instead of making it more productive. Thank you so much.
I really like what you said about holding retrospectives. I'm a lead dev at work and we hold them but I can't seem to get more than 2 people to actually contribute, we don't want to seem like we're forcing anyone, I made them know the importance; sadly, till date not a lot of the devs participate. I think it's my job to try to foster communication between devs; but is it really my job? I dunno.
Yeah that’s definitely frustrating! There are a few reasons I believe this happens. 1) People have been hurt in the past for sharing their opinion. 2) People have shared their opinion but no action was taken to improve it. 3) They genuinely can’t think of anything to improve or contribute. I try to build some trust with people who don’t feel comfortable sharing, then ask them some questions one on one to see if I can discern if #1 or #2 might be the case. Then try to figure out what if anything can be done to help them feel safe or give feedback a second chance. It’s not always possible and like you said I’d rather have team members give no feedback than force them to. They will just resent you and the process!
Any time a detailed and thoughtful conversation breaks out about how to improve the next release, my TPM tells us to take it offline so we can move on. He only cares about the ceremony of retro, not the results.
*sigh* yeah I've seen this too. TPM "Hey everyone, lets get together to talk about what to improve". "I don't mean talk about, just bring it up and talk about it yourselves". Engineers: "Why do we need a meeting with you there for that???".
The first four points come down to one thing. What is “Agile” is defined by the agile manifesto. The first clause of which is: “Individuals and interactions over processes and tools.” If the first step of your journey is about processes like Scrum or Kanban, or tools like Jira, you’re not actually looking to be agile. If you want to be agile, you need to focus on the individuals, make sure they understand what the team is trying to achieve, which gives them the ability to act towards these goals without the constraints of process. This requires leadership, vision and nurturing talent. Why is processes and tools always the first thing mentioned? Well, leadership and vision are hard. Selling processes and tools using empty promises is easy. It’s not agile though, and I’ve never seen it work.
I am a bit sceptic about these methodes. I have worked in wonderful and high productive teams which did not follow any of these trendy methodes, and in others that as they did not work properly were forced , by management layers, to follow one of them ...omg, bad experience...there is nothing worse than an unmotivated sw team following kanban or agile And thank you again to explain things the way they are!
Totally understandable. It’s sad that many companies have implemented agile methods in such a dysfunctional way, I don’t blame engineers for not wanting anything to do with it!
Generally, 80% of productivity comes from 20% of the producers. It’s the Pareto principle and it gets harder, not easier, to disprove it the larger the team or organization gets. It is no wonder these enterprises have to resort to trendy methods for managing workflow that some fucktard consultant told them would work. The real task is to reduce the team down to the 20% who are delivering value. Good luck doing that, you may cut loose a crucial contributor.
If your sprint leaves only enough time for features to finish within that time - like a two minute counter in a fastfood shop - you will only get features that finish in that time - so just the fatty burger and not any fancy cuisine. Rigid sprints are the opposite to agile planning.
Jayme, that was a great presentation however I have been working as a systems analyst and project manager in the IT industry for more than 13 years and I realize that at least for me the way scrum or kanban dictates their processes never worked for me. I believe it is my misunderstanding about the technique but I don't see the value in getting a bunch of programmers together and let them organize themselves without the through understanding of the requirements as well the architecture of the system before hand. every programmer create their on thing and at the end is a complete spaghetti code with no connection on dependencies. I would like to hear your comment on that. Thanks
Great question. Software teams doing scrum or kanban are commonly put under high pressure to finish work by their estimates. When this isn't the case, the team has the time to refactor and make architecture decisions just-in-time so they can improve the design as the complexity of the product grows. Unfortunately many teams do NOT have management that understand this, and so the pressure to finish "features" forces them to complete the work regardless of how bad the patterns and quality are, or how much it deviates from one developer to the next. As I've said in other videos I'm a big proponent of letting people be different (and that includes bringing new development pattern ideas to the table in the middle of the project) - but that doesn't mean putting some forethought into a codebase so it is designed well should be completely left out. I guess my experiences has been (having starting serving my first architect role 20 years ago) that if I design everything up front I do make some good decisions, but I also fail to account for things I just can't understand until we're underway. That doesn't mean "no up front design" but I think that can be done alongside features in a scrum or kanban process. The problem is when teams work where their #1 priority is throughput with no time whatsoever to coordinate dependencies and design. That's just my current thinking, or at least a high level of it. I talk about this stuff some more in the video on creativity, evolving architecture, the interview I did with woody zuill, and others. It's a great topic I'll probably talk about more in the future - definitely a tough problem!!!
I worked in the team which had exactly the 7th mistake, tasks were done on a daily basis but releases once per 1-2 month and this indeed leads to frustration and if you tried to tell let’s do a build/release you would have had a problems with management and feel the pressure at once telling that you are not concentrated and dealing with things you shouldn’t deal with . It was incredibly toxic
Cons of Agile is lack of documentation, you can be assigned a task and you don't have enough information on it. You don't know who or what question to ask, what doc to look for, or what is needed to understand the project. It slows you down to get started. If not everyone is on the same page, someone is too busy with their own project and your project is not their priority so you might have to wait for weeks for the info to do your work. Lack of documentation before and after so you might have the wrong info or not enough info to do your work or to understand the requirement/product. If there's no leader in your team, you schedule the meeting not everyone shows up.
The common pitfall I see is lack of feedback from previous sprints, features never used, and developers working blindly, knowing nothing about the value they are creating. It is very common product owners demanding wishes and dreams, mostly nightmares, not sharing at all how customers receive those features.
to your point on focusing on output vs outcome…sometimes you find yourself working on a project that will take several sprints to deliver. It’s hard to prove outcome at the end of the sprint other than having code that’s been tested successfully even though it’s not usable i.e deploying to production behind some feature flag perhaps
What is the actual function of scrum? From my understanding is to push developers to complete their task within the given time.... I was label a lazy employer just because I alway got hard task that seems easy P.S: The sprint is every 2 days
What makes no sense to me is that the agile values and principles were invented by a group of software engineers but doesn't specifically focus on anything that actually improves software quality or makes life easier for software engineers. Instead it focuses on degrading the importance of certain documents and artefacts by saying other things are more important. This typically encourages a sloppiness in work. The evolution of this has lead to terms such as 'sprint' which also encourages quick fixes. As software engineers, I think our only focus should be on making good software. Having a boss beat you with a stick to make you go faster is one thing but inventing concepts that just cut corners ourselves just seems dumb.
Retrospectives need to be open and honest. People tend to avoid confrontation and they don’t forgive negative feedback. Huge limit to constant improvement. I tended to hear gripes in 121s and posed generic points to kick start discussions but weren’t ignored. I had to address things with other 121s which is exactly what I didn’t want to do.
Thanks Sudip, yes you can listen on most of the major podcast directories. You can find the link on Spotify at the top of the podcast portal for this show here: healthysoftwaredeveloper.libsyn.com/
Agile has always sounded suspiciously similar to a cult. If a project goes right, all hail Agile. If a project goes wrong, its because you didnt apply it right, or enough or you chose the wrong variant. Somehow, Agile itself is never at fault.
I feel like the concept of not calling something a bug is one thing that annoys me that we don't do. This is a very semantic decision but ties into the whole process of having a list of items to work on prioritized by the PO. When you start calling things a bug they tend to get looked at differently and seemingly changes the order of needing to be done without PO input.
Some great stuff. But the #1 problem with Agile is it seen as a panacea and actual software project management skills and experience take a back seat to a cheap paint by numbers methodology.
I can definitely relate to this. I think you actually can tell if a team is agile during the interview but it takes some courage. That might be a good subject for another video. Thanks for your feedback.
a 2345193 I agree completely. I’m working on a course to help people figure out whether agile methods even make sense at their companies based on some things I’ve learned that seem to help. I’ll be talking about these methods in some future videos. Appreciate your feedback. It’s good to know you’re seeing this too. 👍
@@HealthyDev Being someone that's worked in a couple shops that do Scrum very well, it's incredibly enjoyable and is something I strongly look for when scouting jobs. I think many companies understand the appeal and try to do "Agile" without understanding that at its heart it is about empowering developers to allow them to be more productive. Because they don't understand that without empowering the developers that nothing actually changes they ultimately always fail but never understand it. But just as it's their job to interview you to make sure that you're a good fit, it is our job to also interview them to ensure that they are a good fit.
Had the stand up is a waste of time argument many times with a manager. The team were just going through the motions, because they already knew what they were doing today, did yesterday, etc. Sadly that team was eventually destroyed by management obsessed with the idea that agile/scrum must result in an improvement and constantly badgering the members of a team that was already very efficient and had worked together for over a decade. Don't force people to do things that don't interest them. Definitely, but it is another common obsession these days. Force everyone to work in all areas. Sometimes retrospectives are held too often. Continuous delivery isn't always possible. Just as it isn't always possible to break things down into pieces that can be finished in 2-3 weeks. So there the problem becomes obsessing over delivering value at short intervals. The team ends up spending hours in meetings trying to break things down smaller. Then even if they do figure out some smaller piece of work customers won't allow their system to be updated.
Hi, very useful. Do you have anything related the problem of use Scrum for all the IT projects , like migrations, implementations, etc, not just for Development ones
There’s a playlist on my channel with all my videos about agile development and scrum. There’s also one with all my videos on lean product management. The insights I try to offer there are in the context of software, but can be applied to any problem. The key thing to get about agility is you’re letting go of predictability and control to accelerate learning what you don’t know so what you ultimately do is successful. I hope that helps some.
One of the problems I've encountered is that people don't use the process the way it's intended. I worked on a SCRUM team where we had sprints that lasted 2 months. The software eventually got shelved and most of the team members were laid off.
The thing here is that u cannot go ahead and use a methodology that it’s coming from another methodology basis that you don’t even know. In this case talking about agile methodologies, the basis is coming from lean manufacturing. And the second one is that you cannot go ahead and use only one methodology for most of your processes and projects, you must adjust to the status quo and adjust the methods.
I wish your channel was still active because this is a really important topic. It is so true that a lot of people when you ask them to do the documentation just refuse to do it or they will say they don't know why it has to be detailed and management eventually caves in and gives up on making people document what they are completing and how. We had a meeting and i asked if people don't document what they are working on how am I supposed to know who is doing what? and management said you're just going to have to learn what everyone else is doing and become an expert on what everyone else is working on. And I'm thinking that's a hell of a lot of extra work when those people could just follow the documentation guidelilnes. Then I don't have to guess because guesswork is not only hard to do but also leads to false guesses and then there's friction because of the extra work!! very frustrating that management caves in because other people are too lazy.
Good feedback, yeah it's a tough problem. I think it's okay if some developers don't do as well documenting, as long as other people are willing to cover for them and have their capacity reduced. For management to expect a lead to know everything is ridiculous in general. Part of leadership is explicitly choosing to move into facilitating and supporting people, which requires trusting your people (sounds like you know that). I talked about that more in the video "Lead Software Developers Better by Letting Go!": ruclips.net/video/Fp5oQyNV_ws/видео.html
@@HealthyDev Thank you I've found your videos really cover a lot of great management tips and wasn't sure if you're still creating new content but thank you for the reply here!
Hmm I have a little sidenote about not doing things that don't add value. Obviously in itself it's a good idea to remove as much waste as possible (hence I think scrum and lean should kind of go hand-in-hand).. But i don't feel good about saying "if the standup is not adding value, get rid of it".. because i have seen one or two teams that, even though they sit together in the same area, they *never* communicate (outside the standup) about what's blocking them, or the goal of the sprint and whether they're going to finish everything that was planned. They never communicate about actions to take to get back on track and still deliver everything that was planned.. They never communicate about how to replan and what they can focus on that they still CAN finish by the end of the sprint.. What you need to consider is that those rules in the scrum guide are not a defined process. They are not rules that are meant to be followed to the letter, but they are generative rules that are meant to elicit or let the team evolve a certain behaviour that handles risk (in this case the risk of not being able to deliver everything that was planned by the end of the sprint). In other words the standup is meant to elicit a few very important aspects of teamwork: getting stuff done together and minimize work in progress. What I have against saying "if it doesn't add value, then get rid of it", is that when the design goal of these rules are not clear to the team members and scrum/agile are getting treated as a goal within themselves, it becomes very tempting to do a standup like "this is what I've done and this is what I'm doing today, no impediments that I cannot handle" and let that become the way the standup happens every day for every team member. I mean, yeah, they are kind of following the rules from the scrum guide, but when you have a team that never does any pair programming, that never delivers by the end of the sprint and where you almost always see that a story is handled by only one person, even though they do a standup every day.. Go and have a look at how they are doing it and then ask them if the standup is adding value for them.. I think there is a good chance they will say no, so does that mean you would get rid of it? While in fact i think there might be one or two big elephants in the room that prevent them from getting the benefit out of their standup.
It sounds to me like you’re describing a team that gets value out of the daily standup, but they don’t understand why. These are the times you get to shine as a coach! You can teach other people a lot about how much they need each other (and learn yourself) by running an experiment. Give each of the team members an anonymous survey where they rate from 1-10 the benefit of the daily standup you posit (also let them write up their own ideas). If the scores are low (which you expect), offer to go without the standup for 3 sprints (or at least a couple release cycles, whatever you’re calling them). As this proceeds, collect incidents where not having the standup may have avoided an issue. Ask them to do the same. Chances are they won’t be as diligent as you (which is fine, developers are busy) but at the end you’ll have some good data to talk about. You may find when comparing the impact of the time spent doing standups to the project it’s either a) not worth keeping, b) a couple team members need to be coached on communicating better independently or c) the standup is really needed. This is just an idea, but people tend to respond better to a collaborative experiment than a game of who has the loudest voice or most convincing argument when making a decision like whether to keep the standup. YMMV
One pit fall that I see in my project now is scope creep. Practically management does not want anything released until feature x and y and ... are also released and that results in us not releasing features for very long times.
Unfortunately, in my experience that's a sign of product management who do not have much experience with software. One of the best things about the nature of our work (often not exploited which is a serious bummer) is that the cost of building a feature that isn't of value is high. It's better not to build something at all than to build it under budget. Which is why releasing minimal features, and having data gathered in production to inform the business as to how it's impacting the desired business outcomes, is essential to agile. Otherwise you're basically constructing a product without any change introduced by customer feedback. If there's no desire to adapt the product, waterfall should really be used. Even though it's not as trendy as saying you're doing scrum or kanban, if the business isn't setup to take feedback from the customer and act on it right away, there isn't a need for a backlog or any of the agile processes. They were designed for change - vs. a gannt chart in traditional project management etc. I'm guessing you may already know this just adding some clarity. I get into this in more detail in some of the other playlists related to Lean Software Development and Agile/Scrum on the channel.
@@HealthyDev yes I think so as well. The company has been doing waterfall for around 20 years and there are developers working there for 15 years. They started scaling up and hiring new people and of course chose to go with scrum. Our team is around one year old and already one PO left and one SM burned out ( I am the second SM) the only thing i can do at this point is to try to coach them and let things take their natural path and hope they would realize where the problem is coming from.
@@aminhjz sounds like you're on the right track. No project is perfect. Sometimes people have to learn hard lessons to try something truly different - and better!
Just like fire guns, Agile, and particularly, Scrum, should be banned. Its very easy for people to misuse it and make mistakes and it ends up doing more harm than good... Btw, congrats and thanks a lot Jayme, for all the amazing content of this channel. Keep up the good work!
Me and many other colleagues have noticed the tendency to accumulate lot's of tech. debt. This is, I think, because of Agile tendency to analyse and plan the solution the developers will provide. I mean, actual planning (design patterns, interfaces, protocols, etc) not "Agile" planning
I think he’s helping a lot of people and agree with some of his opinions on software development. But there are definitely things I disagree with him about too. I’m guessing he’d think the same about me, not that he has any clue who I am ;)
@@HealthyDev a book which has problems faced by software developer the problems could be non technical or technical But the main intent would be that after reading reader should not find himself alone but relatable. For example: book having scenarios of how work pressure is created and how negative feelings perpetuate within. I have seen various IT firm having same lines used by managers to create pressure or shall i say same technique used. If there is any book that talks about such things that would be very helpful i believe.
Hello Waqar this industry has many aspects to it. I’m not able to coach people independently at this time. But if you can share some of the top challenges you’re facing here, I can try to advise you or point you to other resources that might help.
@@HealthyDev I'm in third year i still dont know how to be a programmer , how to create algorithms and logics . I read books and listen lecture but I'm a bit lazy in my aim
+Waqar Ahmed you might try following some tutorials to build some basic applications. Algorithms and logic can get really mind numbing and aren’t necessarily representative of the real work we do. When I was in college I would build websites for fake companies, or just download interesting technologies and play around with them. This somehow helped me balance the monotony of the other studies. YMMV
Definitely an issue! Good call. I try my best to educate people about having an agile mindset but the more “successful” they’ve been in traditional situations makes it much harder. Hang in there!
@@HealthyDev it's really hard to convince the guys from old school, specially managers of departments like HR, Accounting..etc. we play agile internally while our job title still Project Manager.
ahmed hamza I hear ya. I’ve found I have to leave time in my schedule to assume I need to have one-in-one meetings with many people in these roles to understand their level of experience with agile methods and educate them once I understand their reservations and unique situation. In a group nobody wants to admit they don’t understand something. It’s hard work, for sure!
Output is also important. How can we not agree that it is? How else do you know if people are even trying? Or are they sitting on their phone 3 hours a day. "Oh they are just recharging etc." No stop that. Being dopamine distracted on your phone, actively stops you from doing hard tasks, due to how your stores will be depleted and the hard things no longer seem worth it. We need room for breaks but doing too much everyday... I keep thinking while watching agile videos, "yes yes, but output is still important", if the outcome is great, but if they consistently spend 6 months to create it. Where as a different team spend 2 months creating the same thing. Then we need to take a hard introspective look at what is happening. But few people really go over how we can do those tough conversations. Or maybe the 2 month team is burning themselves out, they might need to slow down. If there is low output, we need to figure out what is happening, can we train? Is the process wrong? Intermingle skills, reorganize. Specialize tasks. Or as a final straw letting them go. You can't run a business like a charity. Mine has tried and it is really getting on my nerves sometimes. You need "accountability", I want all these videos to recognize that they are all hard work but ultimately a "happy path". I know my process has a lot of improvements to go through, but this total shift in how devs vs managers think are putting real pressure on my belief in getting ROI. Not necessecarily monetary return, but goodwill and a strong happy customerbase that wants to stay. Meanwhile when do we have time to do the planning for the upcoming architecture? Someone has to think ahead, and someone has to estimate the coming costs of where we are heading, or we will fail because we did Agile correctly. If everyhing is building up to us ending up having to host 1000s of kubernetes pods, or some other conterrized system, then someone has to think, can we afford that? Do we need to stop this tracejtory and go in a different direction. If we just look at the sprint and data we end up in a spiral that isn't optimizing to go forward. Development is, or should in my book, be a happy medium path between waterfall and agility. You need to make initial choices far ahead to account for feasability, but know that those can pivot. A great plan is often not the first one you thought of.
Nobody is talking about running a business like a charity. That's taking an extreme objection to focusing on outcomes over output. Your post does a good job showing why measuring output in software is so nefarious. You can't compare two teams. They are producing different deliverables. You can't even compare two people. They design things a different way. What you can measure is profit, customer satisfaction, retention, etc. This is why what agile development is really about is getting small increments of work in front of customers on a regular basis and measuring the impact on business objectives. Too often companies won't do this because they unbelievably can't even quantify the work they're doing in business terms. So they default to efficiency as a proxy for business success.
The biggest pitfall I’ve run into is every employee is just a number. Not valuing people, their input, their needs, their experience, etc. Too many companies have decided that agile is a project management tool to get the most out of development teams, to wring the last drop of productivity out of a system without caring that they will lose their best people, lose productivity and annoy customers. The fact that it is right there in the very first value of agile makes no difference. The manifesto is dead to companies, long live the process of wringing the last drop of productivity out of those lazy developers. Oh, I just might be a little bit angry about it too because it’s just cropped up again at work.
Hang in there. I’ve had to struggle through some bad cultures when I just couldn’t get out yet due to personal circumstances. There’s no shame in sucking it up and paying the bills sometimes! With that being said, if I stay too long I start to struggle with resentment. And it’s pretty hard to undo that once it’s gotten bad enough without the clean slate of some new relationships. Hopefully things get better or some new opportunities come your way soon!
@@HealthyDev Thanks man, I've only just started looking again. I left it way too long looking back, but there are a lot of good colleagues where I am as well. I just wonder what the solution is to humanising work over where we seem to be headed. Maybe we'll have something like the "Manifesto for employee wellbeing" at some point. If employers sign it and live up to it they will find it easier to hire people...
I found your channel recently and am loving your videos. Even when I don't agree entirely, your thoughts help me clarify my own thinking and opinions. But you totally lost me on #2, and I'm wondering if your thinking has changed since this video. I think teams require testing, documentation, and code reviews because they have realized that those things are important to ensuring code is high quality and maintainable over the long term. They make rules because they realize that while pretty much nobody "likes" to do those things, they still need to be done, and that not doing those things consistently means the team is collectively digging the hole they will eventually be buried in, leading to burnout and turnover in a vicious cycle. Saying that those are the activities that *prevent* you from doing the fun stuff is short term thinking. They actually *enable* a team to do more of the "fun" stuff by ensuring that the support and maintenance burden remains lower over time. Even assuming there is one saint on the team that *loves* those things and is happy to do it for everyone else so they can all focus on the "fun stuff", it is far less efficient to farm that work off than to have it done by the person most familiar with the code while it is still fresh in their mind. And honestly allowing early career engineers to neglect things they don't like is not doing them any favors in the career development department either. Learning to recognize the value of the software engineering activities that are not "fun", and developing the discipline to not only do them but do them well is the mark of a professional and is a large part of what will show that you're ready for the next level. So I'd reframe this from "making people do things they don't like because we want everyone to conform" to "making people do things they don't (yet) fully understand the value of because it will provide a better long term work experience and help them grow their career". And then in my mind having these types of rules becomes a positive thing.
Hey there, thanks for the feedback. I guess I can see how you'd come away with this conclusion based on this video alone. If you watch the rest of my stuff, I'm a big advocate of every developer becoming well-rounded over their career. My point is that on most teams, you have people at varying levels of that in their career. We like to think if we just mentor and force people, everyone on the team will be able to do the same stuff at the same level of quality. But in my experience, especially with the rate of turnover, that's just not realistic. We're going to have people who hate documentation, hate testing, suck at database design etc. So how can we work together in this compromised state? Should we be trying to level people up? Sure. But we might need to make some compromises, and have some people on the team who are the "go to" person for essential practices in the meantime. I'm just advocating for a pragmatic approach that takes stress of people, accepts reality, and makes improvement where it's actually achievable. Hope that helps a bit.
the "new Kool-Aid" framework/philosophy that consultants can sell to a companies upper management. it basically boils down to -you'll get more output from your workers under this process. Oooh, and we (consultants) have to train and certify your workers under this method and we'll kindly sell you this software that will help you keep track (project manage) their tasks.
Agile is supposed to simply be a character trait of how people work together that makes it easier to change direction. Originally the software industry started pursuing agile methods when they saw it's too expensive to budget and plan software projects up front. But management culture cherry-picked practices and focused on the ones that offer more opportunities for micromanagement and focusing on metrics theater instead of successful business outcomes. There are big problems in the industry with agile methods - but they actually are a good thing. Unfortunately some developers have only known "fake" agile. I talk about this in several videos, here's a couple more if you're interested. "Spot a Fake Agile Team in Under 7 Minutes!": ruclips.net/video/H6GdK-dChtY/видео.html "The Secret of Scrum Nobody Talks About": ruclips.net/video/B_ERfMMSAwY/видео.html
05:47 - WHAT??!! I say again: WHAT??!! Are you saying we can think for ourselves??? This is blasphemy!!! In barely any company have I found this, the vast majority just want to follow something and not think much about it, even if it's making the devs life miserable!
Scantanious Combustion - Yes. That is what a user needs to do. When doing so, it distracts from the message, and pausing a video isn’t always an option.
This is a unique gem in the whole Internet. Most software developer channels are about hacking interviews, some book algorithms, "a day in a life of an ex-GOOGLER" or even about ML which they don't even understand themselves, i.e. mostly useless information. But this channel is something very different and unique, I found many similarities between what you say and what I see in the industry being a team lead of the development team. I've seen teams failing in Scrum forced by the management as a "visibility" tooling and stand-ups used to "apply the needed pressure" (some manager's words) on developers to keep them running faster. I'm trying to learn from any source I can find, and your channel is a great source for me. Please, keep up the good work and thank you!
Another huge and super common fail of applying Agile is using it as a crutch to avoid tech debt.
Not valuing the architecture and the team and generally focusing on just shipping, ie: adding value for customers, is basically building a house of cards.
I agree. There’s this thought that refactoring to keep the code stable as new requirements emerge happens with no cost! 🤦🏻♂️
Yeah which is why agile fails because you can no longer change anything because the code is fucked.
i guess I'm kinda off topic but do anybody know of a good place to watch newly released movies online ?
@@jayceedward4598 Ask that in your next Sprint. Lol
@@brianlaudrupchannel Agile development practices and Test-Driven-Development with refactoring can be done together, or not. Agile is used as an alternative to Waterfall to get products out the door that can change during development. TDD and refactoring help create quality code that can be changed quicker. Both should be used together.
08:21 - The problem with retrospectives is that there is a lot of talk and little action. If I have to repeat what I said in the last retrospective what is the point? I've seen this again and again. Devs, QAs mention stuff and it gets logged but no action (or very minimal action) is taken.
Yes that’s a problem with the leadership, not the process of retrospectives. But I agree this is a common problem and gives the impression it’s a completely useless practice. Which I can totally understand if no improvements are actually being made!
What other pitfalls do you see on agile software development projects that cause them to fail?
Skip to points:
01:01 High Friction Tools
02:34 Designing For Conformity
04:41 Stop What Doesn't Work
06:01 Focusing On Data Over Teamwork
07:07 Focusing On Output Over Outcomes
08:14 Not Stopping To Improve
10:39 Not Continuously Delivering Builds
I can see three more pitfalls about Software development:
1. It's about continuous integration: The team doesn't embrace TDD. I think TDD is something that everyone on the team needs to do. If some don't: some leave the team, or the team leave the TDD (and this leave CI)
2. Some Chief (CTO, CEO, etc.) doesn't even know what Agile is. So, sometimes, it's very, very hard and painfull to apply it.
3. It's comming with the second point : Chief gives responsibility without authority. I think that makes Agile even more toxic than Waterfall as it's destroy the ability of a the team to be 'proud' of their work and thus hurting peoples in the long term.
What do you think ?
Your videos are really good. Well done !
Cheers !
PS: Sorry for my english ^^
I’ve definitely seen these as well, thanks for sharing. Appreciate the feedback!
That was surprisingly very helpful! I have watched the video twice. Thanks for sharing
estebanisswimming glad to help! There are many pitfalls but I hoped these ones I see more often might help someone work on getting past the common ones.
Thanks for letting me know it helps!
A small pitfall that I came across recently is trying to implement a PM tool like Asana or Trello and change/innovate the process at the same time. Was excited for the new tool and possibilities but created too much processes change and lost continuity and momentum. What would have been better is to establish a new tool and let the tool shine and give benefits on the current process, then innovate the process later.
Some pitfalls I've run into and are stressing me out and reducing my productivity:
- Switching between tasks after priority changes
- Leave tasks half why done and focus on a new task like bugs or client requests.
- How to deal in an easy way with tasks no finished from the previous sprint. put them in the next sprint or put them back in the backlog?
Hey there in my experience there’s a couple things you can do that might help there.
First would be to help stakeholders and management know that once a sprint is under way, no new work should be assigned.
This is the only way to have a stable flow of progress without forcing people to leave work half done or low quality - which is worse than any delay for the stakeholder to have to wait before someone gets started on their new priorities.
Second I’m of the opinion that if work in the current sprint is going long, people help each other finish and the sprint is extended.
This is an unpopular opinion, but when a team is forced to hit a goal (not a commitment!) it adds immense pressure to game numbers and not stop and learn why things are taking longer.
It also pits people against each other which is horrible for team culture. What good is it if 4/5 a team is done but you can’t release it? And how does it make the “late” person feel that no one will help teach them how to improve?
@@HealthyDev @Ilyes This issue obviously gives rise to certain bad practices Agile or no Agile. 1. Under what circumstances is the priority changing midway into development that you are being forced to switch tasks. There will be productivity loss as also loss of morale. 2. Bugs and Client Requests should be prioritized in the Product Backlog, why is it even becoming an unplanned input into the Sprint - this practice tells me there is no proper hierarchy outside of the Scrum Team. The Product Owner needs to filter these issues at their end. 3. Incomplete tasks (User Stories) could be taken into the next sprint along with fresh new ones. However a fundamental question needs to be asked if this is a recurring issue - The User Story estimation is not being practiced appropriately. If a Task is not getting completed within a given Sprint then why was it not decomposed further in the planning stage itself.
My two cents.
@@kalyanchilkamarri7298 I agree. And personally I don't think it's ever a good idea to leave work unfinished. If a feature is going to be abandoned it should be completely removed from the code. Otherwise it should be finished before priorities can be shifted. If people don't stick to this rule, they end up with features that people assume are done (but aren't) and code that isn't in a releasable state. Basically a false sense of progress from the customer perspective - regardless of what a kanban board or backlog says.
@@HealthyDev Especially being put on a other project to fix a huge list of bugs while its original developers have switched to another project. Am I sorta a janitor that cleans other peoples' messes?
@@SurenEnfiajyan that stinks. If they don't put you on a newer project within a reasonable timeframe, might be worth considering your options. Sometimes other people than me have gotten picked to start newer efforts, but if you stay stuck too long that can be career limiting. Only you know the right timing there.
Very helpful content, most of the things you mentioned are scenarios I'm experiencing every day. After watching your video I have a clear view on how to use agile without all the hustle that slows down a team instead of making it more productive. Thank you so much.
I really like what you said about holding retrospectives. I'm a lead dev at work and we hold them but I can't seem to get more than 2 people to actually contribute, we don't want to seem like we're forcing anyone, I made them know the importance; sadly, till date not a lot of the devs participate. I think it's my job to try to foster communication between devs; but is it really my job? I dunno.
Yeah that’s definitely frustrating! There are a few reasons I believe this happens. 1) People have been hurt in the past for sharing their opinion. 2) People have shared their opinion but no action was taken to improve it. 3) They genuinely can’t think of anything to improve or contribute. I try to build some trust with people who don’t feel comfortable sharing, then ask them some questions one on one to see if I can discern if #1 or #2 might be the case. Then try to figure out what if anything can be done to help them feel safe or give feedback a second chance. It’s not always possible and like you said I’d rather have team members give no feedback than force them to. They will just resent you and the process!
Any time a detailed and thoughtful conversation breaks out about how to improve the next release, my TPM tells us to take it offline so we can move on. He only cares about the ceremony of retro, not the results.
*sigh* yeah I've seen this too. TPM "Hey everyone, lets get together to talk about what to improve". "I don't mean talk about, just bring it up and talk about it yourselves". Engineers: "Why do we need a meeting with you there for that???".
I really like your critical approach to SD and SCRUM adoptions.
Another problem, team members working in other projects (shared resource).
This. No clear responsibilities, treating people like interchangeable resources. A great recipe for burnout.
The first four points come down to one thing.
What is “Agile” is defined by the agile manifesto. The first clause of which is:
“Individuals and interactions over processes and tools.”
If the first step of your journey is about processes like Scrum or Kanban, or tools like Jira, you’re not actually looking to be agile.
If you want to be agile, you need to focus on the individuals, make sure they understand what the team is trying to achieve, which gives them the ability to act towards these goals without the constraints of process. This requires leadership, vision and nurturing talent.
Why is processes and tools always the first thing mentioned? Well, leadership and vision are hard. Selling processes and tools using empty promises is easy. It’s not agile though, and I’ve never seen it work.
I am a bit sceptic about these methodes. I have worked in wonderful and high productive teams which did not follow any of these trendy methodes, and in others that as they did not work properly were forced , by management layers, to follow one of them ...omg, bad experience...there is nothing worse than an unmotivated sw team following kanban or agile
And thank you again to explain things the way they are!
Totally understandable. It’s sad that many companies have implemented agile methods in such a dysfunctional way, I don’t blame engineers for not wanting anything to do with it!
Generally, 80% of productivity comes from 20% of the producers. It’s the Pareto principle and it gets harder, not easier, to disprove it the larger the team or organization gets. It is no wonder these enterprises have to resort to trendy methods for managing workflow that some fucktard consultant told them would work. The real task is to reduce the team down to the 20% who are delivering value. Good luck doing that, you may cut loose a crucial contributor.
If your sprint leaves only enough time for features to finish within that time - like a two minute counter in a fastfood shop - you will only get features that finish in that time - so just the fatty burger and not any fancy cuisine. Rigid sprints are the opposite to agile planning.
Jayme, that was a great presentation however I have been working as a systems analyst and project manager in the IT industry for more than 13 years and I realize that at least for me the way scrum or kanban dictates their processes never worked for me. I believe it is my misunderstanding about the technique but I don't see the value in getting a bunch of programmers together and let them organize themselves without the through understanding of the requirements as well the architecture of the system before hand. every programmer create their on thing and at the end is a complete spaghetti code with no connection on dependencies. I would like to hear your comment on that. Thanks
Great question. Software teams doing scrum or kanban are commonly put under high pressure to finish work by their estimates. When this isn't the case, the team has the time to refactor and make architecture decisions just-in-time so they can improve the design as the complexity of the product grows.
Unfortunately many teams do NOT have management that understand this, and so the pressure to finish "features" forces them to complete the work regardless of how bad the patterns and quality are, or how much it deviates from one developer to the next. As I've said in other videos I'm a big proponent of letting people be different (and that includes bringing new development pattern ideas to the table in the middle of the project) - but that doesn't mean putting some forethought into a codebase so it is designed well should be completely left out.
I guess my experiences has been (having starting serving my first architect role 20 years ago) that if I design everything up front I do make some good decisions, but I also fail to account for things I just can't understand until we're underway. That doesn't mean "no up front design" but I think that can be done alongside features in a scrum or kanban process. The problem is when teams work where their #1 priority is throughput with no time whatsoever to coordinate dependencies and design.
That's just my current thinking, or at least a high level of it. I talk about this stuff some more in the video on creativity, evolving architecture, the interview I did with woody zuill, and others. It's a great topic I'll probably talk about more in the future - definitely a tough problem!!!
I worked in the team which had exactly the 7th mistake, tasks were done on a daily basis but releases once per 1-2 month and this indeed leads to frustration and if you tried to tell let’s do a build/release you would have had a problems with management and feel the pressure at once telling that you are not concentrated and dealing with things you shouldn’t deal with . It was incredibly toxic
Thanks! You are a very clear speaker. Fabulous content for Business English students.
Cons of Agile is lack of documentation, you can be assigned a task and you don't have enough information on it. You don't know who or what question to ask, what doc to look for, or what is needed to understand the project. It slows you down to get started. If not everyone is on the same page, someone is too busy with their own project and your project is not their priority so you might have to wait for weeks for the info to do your work. Lack of documentation before and after so you might have the wrong info or not enough info to do your work or to understand the requirement/product. If there's no leader in your team, you schedule the meeting not everyone shows up.
I agree this is definitely a common dysfunction with immature agile teams. Bad requirements kills a sprint before it even gets off the ground.
The common pitfall I see is lack of feedback from previous sprints, features never used, and developers working blindly, knowing nothing about the value they are creating.
It is very common product owners demanding wishes and dreams, mostly nightmares, not sharing at all how customers receive those features.
Agree 100%. Something tells me you’ll relate to the videos on the Lean Software Development playlist in the channel...
to your point on focusing on output vs outcome…sometimes you find yourself working on a project that will take several sprints to deliver. It’s hard to prove outcome at the end of the sprint other than having code that’s been tested successfully even though it’s not usable i.e deploying to production behind some feature flag perhaps
What is the actual function of scrum? From my understanding is to push developers to complete their task within the given time.... I was label a lazy employer just because I alway got hard task that seems easy
P.S: The sprint is every 2 days
What makes no sense to me is that the agile values and principles were invented by a group of software engineers but doesn't specifically focus on anything that actually improves software quality or makes life easier for software engineers. Instead it focuses on degrading the importance of certain documents and artefacts by saying other things are more important. This typically encourages a sloppiness in work. The evolution of this has lead to terms such as 'sprint' which also encourages quick fixes. As software engineers, I think our only focus should be on making good software. Having a boss beat you with a stick to make you go faster is one thing but inventing concepts that just cut corners ourselves just seems dumb.
Retrospectives need to be open and honest. People tend to avoid confrontation and they don’t forgive negative feedback. Huge limit to constant improvement. I tended to hear gripes in 121s and posed generic points to kick start discussions but weren’t ignored. I had to address things with other 121s which is exactly what I didn’t want to do.
Do you have these on spotify? Pretty cool content :)
Thanks Sudip, yes you can listen on most of the major podcast directories.
You can find the link on Spotify at the top of the podcast portal for this show here:
healthysoftwaredeveloper.libsyn.com/
Agile has always sounded suspiciously similar to a cult.
If a project goes right, all hail Agile. If a project goes wrong, its because you didnt apply it right, or enough or you chose the wrong variant.
Somehow, Agile itself is never at fault.
I feel like the concept of not calling something a bug is one thing that annoys me that we don't do. This is a very semantic decision but ties into the whole process of having a list of items to work on prioritized by the PO. When you start calling things a bug they tend to get looked at differently and seemingly changes the order of needing to be done without PO input.
That's an interesting comment. The semantics do matter quite a bit, even though we sometimes feel like they shouldn't
Some great stuff. But the #1 problem with Agile is it seen as a panacea and actual software project management skills and experience take a back seat to a cheap paint by numbers methodology.
Just do not take anyone seriously when they claim to be an Agile shop.
I can definitely relate to this. I think you actually can tell if a team is agile during the interview but it takes some courage. That might be a good subject for another video.
Thanks for your feedback.
a 2345193 I agree completely. I’m working on a course to help people figure out whether agile methods even make sense at their companies based on some things I’ve learned that seem to help. I’ll be talking about these methods in some future videos.
Appreciate your feedback. It’s good to know you’re seeing this too. 👍
@@HealthyDev Being someone that's worked in a couple shops that do Scrum very well, it's incredibly enjoyable and is something I strongly look for when scouting jobs. I think many companies understand the appeal and try to do "Agile" without understanding that at its heart it is about empowering developers to allow them to be more productive. Because they don't understand that without empowering the developers that nothing actually changes they ultimately always fail but never understand it. But just as it's their job to interview you to make sure that you're a good fit, it is our job to also interview them to ensure that they are a good fit.
Summary : “Simpler is almost always better” (3:50)
Well stated.
My scrum master does not participate in retrospective she does not like to hear criticism
Had the stand up is a waste of time argument many times with a manager. The team were just going through the motions, because they already knew what they were doing today, did yesterday, etc. Sadly that team was eventually destroyed by management obsessed with the idea that agile/scrum must result in an improvement and constantly badgering the members of a team that was already very efficient and had worked together for over a decade.
Don't force people to do things that don't interest them. Definitely, but it is another common obsession these days. Force everyone to work in all areas.
Sometimes retrospectives are held too often.
Continuous delivery isn't always possible. Just as it isn't always possible to break things down into pieces that can be finished in 2-3 weeks. So there the problem becomes obsessing over delivering value at short intervals. The team ends up spending hours in meetings trying to break things down smaller. Then even if they do figure out some smaller piece of work customers won't allow their system to be updated.
Hi, very useful. Do you have anything related the problem of use Scrum for all the IT projects , like migrations, implementations, etc, not just for Development ones
There’s a playlist on my channel with all my videos about agile development and scrum. There’s also one with all my videos on lean product management. The insights I try to offer there are in the context of software, but can be applied to any problem. The key thing to get about agility is you’re letting go of predictability and control to accelerate learning what you don’t know so what you ultimately do is successful. I hope that helps some.
One of the problems I've encountered is that people don't use the process the way it's intended. I worked on a SCRUM team where we had sprints that lasted 2 months. The software eventually got shelved and most of the team members were laid off.
The thing here is that u cannot go ahead and use a methodology that it’s coming from another methodology basis that you don’t even know. In this case talking about agile methodologies, the basis is coming from lean manufacturing.
And the second one is that you cannot go ahead and use only one methodology for most of your processes and projects, you must adjust to the status quo and adjust the methods.
I wish your channel was still active because this is a really important topic. It is so true that a lot of people when you ask them to do the documentation just refuse to do it or they will say they don't know why it has to be detailed and management eventually caves in and gives up on making people document what they are completing and how. We had a meeting and i asked if people don't document what they are working on how am I supposed to know who is doing what? and management said you're just going to have to learn what everyone else is doing and become an expert on what everyone else is working on. And I'm thinking that's a hell of a lot of extra work when those people could just follow the documentation guidelilnes. Then I don't have to guess because guesswork is not only hard to do but also leads to false guesses and then there's friction because of the extra work!! very frustrating that management caves in because other people are too lazy.
Good feedback, yeah it's a tough problem. I think it's okay if some developers don't do as well documenting, as long as other people are willing to cover for them and have their capacity reduced. For management to expect a lead to know everything is ridiculous in general. Part of leadership is explicitly choosing to move into facilitating and supporting people, which requires trusting your people (sounds like you know that). I talked about that more in the video "Lead Software Developers Better by Letting Go!": ruclips.net/video/Fp5oQyNV_ws/видео.html
@@HealthyDev Thank you I've found your videos really cover a lot of great management tips and wasn't sure if you're still creating new content but thank you for the reply here!
Hmm I have a little sidenote about not doing things that don't add value. Obviously in itself it's a good idea to remove as much waste as possible (hence I think scrum and lean should kind of go hand-in-hand).. But i don't feel good about saying "if the standup is not adding value, get rid of it".. because i have seen one or two teams that, even though they sit together in the same area, they *never* communicate (outside the standup) about what's blocking them, or the goal of the sprint and whether they're going to finish everything that was planned. They never communicate about actions to take to get back on track and still deliver everything that was planned.. They never communicate about how to replan and what they can focus on that they still CAN finish by the end of the sprint.. What you need to consider is that those rules in the scrum guide are not a defined process. They are not rules that are meant to be followed to the letter, but they are generative rules that are meant to elicit or let the team evolve a certain behaviour that handles risk (in this case the risk of not being able to deliver everything that was planned by the end of the sprint). In other words the standup is meant to elicit a few very important aspects of teamwork: getting stuff done together and minimize work in progress. What I have against saying "if it doesn't add value, then get rid of it", is that when the design goal of these rules are not clear to the team members and scrum/agile are getting treated as a goal within themselves, it becomes very tempting to do a standup like "this is what I've done and this is what I'm doing today, no impediments that I cannot handle" and let that become the way the standup happens every day for every team member. I mean, yeah, they are kind of following the rules from the scrum guide, but when you have a team that never does any pair programming, that never delivers by the end of the sprint and where you almost always see that a story is handled by only one person, even though they do a standup every day.. Go and have a look at how they are doing it and then ask them if the standup is adding value for them.. I think there is a good chance they will say no, so does that mean you would get rid of it? While in fact i think there might be one or two big elephants in the room that prevent them from getting the benefit out of their standup.
It sounds to me like you’re describing a team that gets value out of the daily standup, but they don’t understand why. These are the times you get to shine as a coach! You can teach other people a lot about how much they need each other (and learn yourself) by running an experiment. Give each of the team members an anonymous survey where they rate from 1-10 the benefit of the daily standup you posit (also let them write up their own ideas). If the scores are low (which you expect), offer to go without the standup for 3 sprints (or at least a couple release cycles, whatever you’re calling them). As this proceeds, collect incidents where not having the standup may have avoided an issue. Ask them to do the same. Chances are they won’t be as diligent as you (which is fine, developers are busy) but at the end you’ll have some good data to talk about. You may find when comparing the impact of the time spent doing standups to the project it’s either a) not worth keeping, b) a couple team members need to be coached on communicating better independently or c) the standup is really needed. This is just an idea, but people tend to respond better to a collaborative experiment than a game of who has the loudest voice or most convincing argument when making a decision like whether to keep the standup. YMMV
One pit fall that I see in my project now is scope creep. Practically management does not want anything released until feature x and y and ... are also released and that results in us not releasing features for very long times.
Unfortunately, in my experience that's a sign of product management who do not have much experience with software. One of the best things about the nature of our work (often not exploited which is a serious bummer) is that the cost of building a feature that isn't of value is high. It's better not to build something at all than to build it under budget. Which is why releasing minimal features, and having data gathered in production to inform the business as to how it's impacting the desired business outcomes, is essential to agile. Otherwise you're basically constructing a product without any change introduced by customer feedback.
If there's no desire to adapt the product, waterfall should really be used. Even though it's not as trendy as saying you're doing scrum or kanban, if the business isn't setup to take feedback from the customer and act on it right away, there isn't a need for a backlog or any of the agile processes. They were designed for change - vs. a gannt chart in traditional project management etc. I'm guessing you may already know this just adding some clarity. I get into this in more detail in some of the other playlists related to Lean Software Development and Agile/Scrum on the channel.
@@HealthyDev yes I think so as well. The company has been doing waterfall for around 20 years and there are developers working there for 15 years. They started scaling up and hiring new people and of course chose to go with scrum. Our team is around one year old and already one PO left and one SM burned out ( I am the second SM) the only thing i can do at this point is to try to coach them and let things take their natural path and hope they would realize where the problem is coming from.
@@aminhjz sounds like you're on the right track. No project is perfect. Sometimes people have to learn hard lessons to try something truly different - and better!
Just like fire guns, Agile, and particularly, Scrum, should be banned. Its very easy for people to misuse it and make mistakes and it ends up doing more harm than good... Btw, congrats and thanks a lot Jayme, for all the amazing content of this channel. Keep up the good work!
Thanks Pedro! 👍
Me and many other colleagues have noticed the tendency to accumulate lot's of tech. debt. This is, I think, because of Agile tendency to analyse and plan the solution the developers will provide. I mean, actual planning (design patterns, interfaces, protocols, etc) not "Agile" planning
Nice tips, thank you. What do you think about uncle Bob?
I think he’s helping a lot of people and agree with some of his opinions on software development. But there are definitely things I disagree with him about too. I’m guessing he’d think the same about me, not that he has any clue who I am ;)
Could you recommend some good books in software engineering which are easily understandable.
Hi Mayank. I’m not sure what to suggest, our field has so many different aspects. Anything in particular related to software engineering?
@@HealthyDev a book which has problems faced by software developer the problems could be non technical or technical
But the main intent would be that after reading reader should not find himself alone but relatable.
For example: book having scenarios of how work pressure is created and how negative feelings perpetuate within.
I have seen various IT firm having same lines used by managers to create pressure or shall i say same technique used.
If there is any book that talks about such things that would be very helpful i believe.
Sir I'm Waqar From Pakistan and I'm studying Computer science third year . Sir I want to be good developer kindly help me
Hello Waqar this industry has many aspects to it. I’m not able to coach people independently at this time. But if you can share some of the top challenges you’re facing here, I can try to advise you or point you to other resources that might help.
@@HealthyDev I'm in third year i still dont know how to be a programmer , how to create algorithms and logics . I read books and listen lecture but I'm a bit lazy in my aim
+Waqar Ahmed you might try following some tutorials to build some basic applications. Algorithms and logic can get really mind numbing and aren’t necessarily representative of the real work we do.
When I was in college I would build websites for fake companies, or just download interesting technologies and play around with them. This somehow helped me balance the monotony of the other studies.
YMMV
@@HealthyDev i will act on your sayings
working agile in traditional organization whose know just the tradition way of developing.
Definitely an issue! Good call. I try my best to educate people about having an agile mindset but the more “successful” they’ve been in traditional situations makes it much harder. Hang in there!
@@HealthyDev it's really hard to convince the guys from old school, specially managers of departments like HR, Accounting..etc. we play agile internally while our job title still Project Manager.
ahmed hamza I hear ya. I’ve found I have to leave time in my schedule to assume I need to have one-in-one meetings with many people in these roles to understand their level of experience with agile methods and educate them once I understand their reservations and unique situation. In a group nobody wants to admit they don’t understand something. It’s hard work, for sure!
What if no one on the team wants to do documentations? 🥴
Holy f*ck! Have you worked in my projects or why can I agree to almost every point?
Output is also important. How can we not agree that it is? How else do you know if people are even trying? Or are they sitting on their phone 3 hours a day. "Oh they are just recharging etc." No stop that. Being dopamine distracted on your phone, actively stops you from doing hard tasks, due to how your stores will be depleted and the hard things no longer seem worth it.
We need room for breaks but doing too much everyday...
I keep thinking while watching agile videos, "yes yes, but output is still important", if the outcome is great, but if they consistently spend 6 months to create it. Where as a different team spend 2 months creating the same thing. Then we need to take a hard introspective look at what is happening. But few people really go over how we can do those tough conversations.
Or maybe the 2 month team is burning themselves out, they might need to slow down.
If there is low output, we need to figure out what is happening, can we train? Is the process wrong? Intermingle skills, reorganize. Specialize tasks. Or as a final straw letting them go.
You can't run a business like a charity. Mine has tried and it is really getting on my nerves sometimes. You need "accountability", I want all these videos to recognize that they are all hard work but ultimately a "happy path".
I know my process has a lot of improvements to go through, but this total shift in how devs vs managers think are putting real pressure on my belief in getting ROI. Not necessecarily monetary return, but goodwill and a strong happy customerbase that wants to stay.
Meanwhile when do we have time to do the planning for the upcoming architecture? Someone has to think ahead, and someone has to estimate the coming costs of where we are heading, or we will fail because we did Agile correctly. If everyhing is building up to us ending up having to host 1000s of kubernetes pods, or some other conterrized system, then someone has to think, can we afford that? Do we need to stop this tracejtory and go in a different direction. If we just look at the sprint and data we end up in a spiral that isn't optimizing to go forward.
Development is, or should in my book, be a happy medium path between waterfall and agility. You need to make initial choices far ahead to account for feasability, but know that those can pivot. A great plan is often not the first one you thought of.
Nobody is talking about running a business like a charity. That's taking an extreme objection to focusing on outcomes over output. Your post does a good job showing why measuring output in software is so nefarious. You can't compare two teams. They are producing different deliverables. You can't even compare two people. They design things a different way. What you can measure is profit, customer satisfaction, retention, etc. This is why what agile development is really about is getting small increments of work in front of customers on a regular basis and measuring the impact on business objectives. Too often companies won't do this because they unbelievably can't even quantify the work they're doing in business terms. So they default to efficiency as a proxy for business success.
The biggest pitfall I’ve run into is every employee is just a number. Not valuing people, their input, their needs, their experience, etc. Too many companies have decided that agile is a project management tool to get the most out of development teams, to wring the last drop of productivity out of a system without caring that they will lose their best people, lose productivity and annoy customers. The fact that it is right there in the very first value of agile makes no difference. The manifesto is dead to companies, long live the process of wringing the last drop of productivity out of those lazy developers.
Oh, I just might be a little bit angry about it too because it’s just cropped up again at work.
Hang in there. I’ve had to struggle through some bad cultures when I just couldn’t get out yet due to personal circumstances. There’s no shame in sucking it up and paying the bills sometimes!
With that being said, if I stay too long I start to struggle with resentment. And it’s pretty hard to undo that once it’s gotten bad enough without the clean slate of some new relationships. Hopefully things get better or some new opportunities come your way soon!
@@HealthyDev Thanks man, I've only just started looking again. I left it way too long looking back, but there are a lot of good colleagues where I am as well. I just wonder what the solution is to humanising work over where we seem to be headed. Maybe we'll have something like the "Manifesto for employee wellbeing" at some point. If employers sign it and live up to it they will find it easier to hire people...
Our industry probably needs to unionize at some point. That will introduce other issues, but it will protect many people from burnout.
I found your channel recently and am loving your videos. Even when I don't agree entirely, your thoughts help me clarify my own thinking and opinions. But you totally lost me on #2, and I'm wondering if your thinking has changed since this video.
I think teams require testing, documentation, and code reviews because they have realized that those things are important to ensuring code is high quality and maintainable over the long term. They make rules because they realize that while pretty much nobody "likes" to do those things, they still need to be done, and that not doing those things consistently means the team is collectively digging the hole they will eventually be buried in, leading to burnout and turnover in a vicious cycle. Saying that those are the activities that *prevent* you from doing the fun stuff is short term thinking. They actually *enable* a team to do more of the "fun" stuff by ensuring that the support and maintenance burden remains lower over time.
Even assuming there is one saint on the team that *loves* those things and is happy to do it for everyone else so they can all focus on the "fun stuff", it is far less efficient to farm that work off than to have it done by the person most familiar with the code while it is still fresh in their mind. And honestly allowing early career engineers to neglect things they don't like is not doing them any favors in the career development department either. Learning to recognize the value of the software engineering activities that are not "fun", and developing the discipline to not only do them but do them well is the mark of a professional and is a large part of what will show that you're ready for the next level.
So I'd reframe this from "making people do things they don't like because we want everyone to conform" to "making people do things they don't (yet) fully understand the value of because it will provide a better long term work experience and help them grow their career". And then in my mind having these types of rules becomes a positive thing.
Hey there, thanks for the feedback. I guess I can see how you'd come away with this conclusion based on this video alone. If you watch the rest of my stuff, I'm a big advocate of every developer becoming well-rounded over their career.
My point is that on most teams, you have people at varying levels of that in their career. We like to think if we just mentor and force people, everyone on the team will be able to do the same stuff at the same level of quality.
But in my experience, especially with the rate of turnover, that's just not realistic. We're going to have people who hate documentation, hate testing, suck at database design etc. So how can we work together in this compromised state?
Should we be trying to level people up? Sure. But we might need to make some compromises, and have some people on the team who are the "go to" person for essential practices in the meantime. I'm just advocating for a pragmatic approach that takes stress of people, accepts reality, and makes improvement where it's actually achievable.
Hope that helps a bit.
what is agile?
the "new Kool-Aid" framework/philosophy that consultants can sell to a companies upper management. it basically boils down to -you'll get more output from your workers under this process. Oooh, and we (consultants) have to train and certify your workers under this method and we'll kindly sell you this software that will help you keep track (project manage) their tasks.
Agile is supposed to simply be a character trait of how people work together that makes it easier to change direction.
Originally the software industry started pursuing agile methods when they saw it's too expensive to budget and plan software projects up front.
But management culture cherry-picked practices and focused on the ones that offer more opportunities for micromanagement and focusing on metrics theater instead of successful business outcomes.
There are big problems in the industry with agile methods - but they actually are a good thing.
Unfortunately some developers have only known "fake" agile. I talk about this in several videos, here's a couple more if you're interested.
"Spot a Fake Agile Team in Under 7 Minutes!": ruclips.net/video/H6GdK-dChtY/видео.html
"The Secret of Scrum Nobody Talks About": ruclips.net/video/B_ERfMMSAwY/видео.html
dude your videos are like going to therapy for me haha
They’re like therapy for me too haha. Sometimes just sharing this stuff helps me feel a little better. 🙏
05:47 - WHAT??!! I say again: WHAT??!! Are you saying we can think for ourselves??? This is blasphemy!!! In barely any company have I found this, the vast majority just want to follow something and not think much about it, even if it's making the devs life miserable!
Exactly and my scrum master she does not understand technical impediments. But without a shame loudly announces her solution.foolishness at it's best.
Here’s a tip: Pause your video/audio when text appears, so that we don’t have to read one thing and listen to another simultaneously.
Why don't you just pause the video?
Scantanious Combustion - Yes. That is what a user needs to do. When doing so, it distracts from the message, and pausing a video isn’t always an option.
1) using agile