I worked for a major securities brokerage house on Wall Street, and we were a COBOL shop. We had well over 500 programmers on staff, each dedicated to the silo of business they were working on. Why? Because the software required an intimate understanding of the business, the user requirements, and a reliable working relationship with the user community. Every team had its subject matter experts, and that knowledge was passed on to newer members of the team, which required a year or two before a programmer can speak intelligently with the users. You can imagine the panic and chaos that ensued, a new set of geniuses in the IT department decided it would be a good idea, to retire the SMEs, and institute Agile as the next thing. It took the better part of a decade to recover from that turd of an idea, and the integrity of the systems and the confidence of the user community has never been the same.
Lol. Software devs that like agile are masochists. Imagine being a house builder and thinking it was a good idea to let customer change things every two weeks whilst micro managing your progress through daily scrums. Most of the time agile seems to be an excuse not to do planning under the guise of adaptability. I’ve never seen SMEs increase after going to agile. Most agile team meetings you leave thinking the team must be new, but you look them up and they have been working for a couple years. Hilarious. I love it
The worst part of your story? You had _everything_ required to work agile and quickly respons to customer needs. In fact you had the perfect, cross functional, agile setup. It just wasn't called that. This is what is so hard for some agile proponents to understand: In many cases life is more complex than creating another web page with a database backbone. Sometimes you actually can tell exactly what is needed beforehand. If you are writing software for a car you will have engine, break pedal, steering wheel, an automatic gearbox, indicators and switches for various functions. You can create a list with most of these at the start of the project, and you can create you software in such a way that it can accommodate changes like exactly the kind of switch, gear box etc will be in place when the cars rolls off the assembly line a year from now. But it is possible to create an overall plan, if, but only if, you know the subject matter at hand. You said it takes one or two years for a developer to gain enough knowledge to even ask the right questions, this is not something that "agile" is very good at. Agile works best when demands change drastically over time, when not much knowledge is needed to create the next visible feature and there is very little interdependence in the subject domain.
Yeah, typical. Some new manager comes in and needs to do something "cool" and fashionable, such as Agile/scrum, so they make a lot of changes that do nothing but create disruption and chaos. It's the arrogance of thinking that experience has no value, and that you, with your "cool" methodology, know better
@@rogermouton2273 Let's acknowledge the reality that the giant legacy COBOL application and its business processes was in a slow death spiral. Any sort of of remedy is going to be somewhat painful. This reality exists despite who is newly hired in management. It's not that experience has no value, it's that experience that is completely locked into a legacy paradigm has less value over time than an agile solution. Sometimes management has the hope that overlaying agile on top of a legacy monolith is going to give them the best of both rather than the worst of both.
I worked for a company that said they are agile. But had no budget to accommodate changes at all. Turns out, what they meant by agile is just the team being crunched to work overtime and weekends to meet stupid unrealistic expectations
Can you spot a fake agile team? Are your teams benefiting from feedback? Share your thoughts with the community below. Skip to points in the video: 0:00 Introduction 0:17 How This Video Will Help You 0:49 Why Care About Agile? 1:19 Why Continuously Deliver Software? 2:17 Why Infrequent Releases Frustrate Customers 2:36 Misunderstanding the Minimum Viable Product 3:12 The Futility of Agile Theater 3:33 How To Know A Team Is Using Fake Agile 3:45 Question #1: How Does The Team Gather Feedback? 4:30 Question #2: How Much Is Budgeted For Change? 5:35 Why People Resist Agility
The most simple, clear and full of content video about agile fails that I have ever seen in my life. Man, I want to see all of your videos! I’m tired about being frustrated on every project that I work, I know what’s wrong I know where to fix, but I don’t have a high level role yet to start making decisions instead of the manager/architect/team leader. What do you recommend me to to in this case? I’m basically just a developer, but I use to work as a consultant as well sometimes. I’m close to do a presentation in my current company about Agile/Scrum as I know it could potentially increase our projects experience. But I’m still not sure If they will start using that correctly or not.
Henrique Palomo hey sorry I missed this one. Unfortunately I struggle with this too. The only things that seem to have an impact is either getting a high enough position to enact changes through authority, or to demonstrate an improved practice yourself and use that as leverage to get the support for having more influence. When done by authority it’s quicker but people will be resentful if they aren’t educated enough about the changes to see what’s in it for them. When I do something myself there’s obviously less resistance but I’ve got to be way more patient. It’s tough either way - old management habits are hard to change! YMMV
Thanks for this! I'm 3 weeks into a new job and just realised they're not interested in Agile for agility - they follow scrum because it's what other companies do 😬
I benefited alot from those daily meetings when I was new to dev. Right now those daily meetings help me help the "newer" devs stay productive. Just my 2cents.
@@SerBallister 15 minute meetings to make snap decisions about design which affect developers for example do NOT substitute for a well thought out design ahead of time. In some companies, they use stand up meetings to discuss architecture workarounds. Anyway a different subject. I wonder how SpaceX manages their SW development. Someone there needs to write a book.
Sadly you’re right this is almost becoming the de facto methodology. If you haven’t seen it already there’s another video on here that talks about exactly that, “The Secret of Scrum Nobody Talks About”: ruclips.net/video/B_ERfMMSAwY/видео.html
I am really passionate devloper. I am done with devlopement..These bunch of non tech jokers dont understand progarammingf is an art. You are not supposed to disturb a singer singing on stage. A good reusabel peice of code is an art. And to write good block of code a lot of time has been spend to master the craft. But everyone wants things now. Agile is a good way to fuck a dev
@@HealthyDev I think part of what has been happening is the certifications are quite easy to get, easy to recruit for. Then you embed this person with no hands on dev experience in the daily team life. This non technical PM is now hearing chatter that in the old world they would never hear and the opportunity for ill-informed micromanagement appears. The restraint for this is supposed to be diligence to the agile principles and the ability to coach the team in those regards, but in my experience, agile practitioners are in reality not accountable to anyone for how well they handle those aspects. Mostly, project managers (of all types) in many orgs are typically accountable for project success. This is the "one neck to choke" concept that upper management in Western business has latched on to since at least the 1950's.
One sign of fake agile in view is all the business agile disciplines, but none of the developer agile disciplines - no tests, no pairing opportunities etc.
@Jeffrey Haines I'll give you pairing, but repeatable preferably automated tests are a requirement to quickly change code and respond to requirements changing and evolving.
Really you need to spot an agile organization - if the dev team is agile and making an internal product, for example, but the client group is not participating in the continuous feedback loop, the dev team's agility is moot. Clear metrics to measure value are also useful. You could end up getting a ton of feedback but need to know what feedback is actionable and should be prioritized.
I agree this is preferred. Unfortunately it seems most truly agile teams are pockets within an enterprise operating as a bit of a skunkworks, or a top down “transformation” was done that checks all the boxes but misses the point. I agree completely with the data you gather needing to be actionable - otherwise the effort of gathering it is waste. 👍
NuncNuncNuncNunc this is sort of the situation i’m in. I don’t have enough time to handle every single end of full stack development all the time. I take feedback as it comes in, but i find it difficult to seek out or research and develop a way to have it come in more naturally. The feedback I do get I try to work with within the limitations of my abilities, what I can outsource, and the limitations of the dated project dependencies.
I think this was a good point to bring up, I am only a second year student, and probably may make a fool of myself here, but I do know developing. And there is a psychology inherit in most programmers, that is there is a socialization that takes place inside any group of people. Hierarchies are formed, bias' are formed, and without you even realizing it, a pecking order is established. Even among the developers, that is between the developers themselves outside tech leads, and team leads, and higher order management. This pecking order can be due to insecurities of the developers, or even lack of insecurities, impostor syndrome, etc... When this happens, the bias' of the alpha become the inevitable bias' of the team, it is a cascading effect, and as we know inheritance from waterfall is bad! I think being agile, is being open to the input of the entire team. I guess my point is, (sticking up for the new developer joining a team), being new does not necessitate inexperience. Some developers may be new to the team, but not new to development. And no one has all the answers! Agile is just as much about being flexible and open to change with respect to the project, as it should be being flexible to the input of the team; the WHOLE team, not just the dog that barks the loudest!
Agree completely. You might be interested in my video on democratic software architecture, it’s on point with your conclusions: ruclips.net/video/1CDUHW_HXbQ/видео.html
It's the new hiding place for bad programmers and worse managers. Everything in "agile" that says *how* to do agile is covering up a shortcoming of programmers or especially managers of programmers.
One thing I don't like about agile development is that its easy to fall in the trap of focusing on the next deliverable that the long view can get lost (high level architecture, etc).
So true. Some aspects of software don't lend well to delivering a vertical chunk of new stuff or vertical stack of changes. Usually such changes impact horizontally.
Imagine what a house builders house would look like agile... every room would have different flooring and trim, the foundation would be the wrong size, wires would end up under the bath tub.. lmao
One thing i dont like about agile is the short sprints. We have two week sprints, which means potentially, every two weeks there is a release that never goes as smoothly as the theory suggests. This frequent after hours job is not just a massive disruption in my private life, but also in my work life: You get two weeks worth of work to complete, but then half a week is spend prepping for the release and another half for testing, not to mention support that comes in the way. I've suggested we do 3 or 4 weeks sprints instead. That way, we spend less time prepping and doing admin, and proportionally doing more time coding. The powers that be didn't bite.
I believe the solution to smoother sprints, if you’re going with scrum, is way less scope per sprint and way more automation. Manual testing and deployment, and putting developers on new work the second new stuff is in production doesn’t seem to work. My understanding of the psychology behind doing releases more frequently is the pain of inefficiencies in your release process is so bad it forces you to change. If you only release once a month, people don’t seem to have the motivation to improve since it’s “only occasional overtime”. My two cents at least.
@@andishawjfac Well, I did get it to 3 weeks now, and its amazing how much that improved our quality of live. We actually did have some longer sprints as well, but those are the exception.
Hi, I am just a truck driver here. I think employers are part of the reasons why there are a lot of people faking to be a professional in that field. Because every employer wants you to have 5 years of experience when you are 22 and just graduated college. There are no opportunities for entry-level practices so therefore people fake their resumes and become who or what they are not.
Seems to me that just about everything I read and see online about Agile, assumes that it's being used in an environment where there's regular releases of some piece of software to a very large community of users. Most of the projects I've been on are not like that. Eg, doing the data migration for a large government system, dealing with requests for enhancements and fixes to systems that are internal to an organisation. Many or most of the teams that I've been on claim to be 'Agile' or scrum, and they run two-week sprints, etc. It's all complete BS because, for one thing, you generally can't produce anything meaningful within two weeks - so you artificially create a bunch of stories, or tasks, or whatever to fit within two weeks, and create a huge and meaningless admin overhead of sprints, and moving stuff between sprints, etc. In short, most organisations are stupid, and think 'let's do Agile, because it makes everything better', then mindlessly go through the 'Agile motions' of sprints, sprint planning, stand-ups, user stories, etc, etc, regardless of whether it actually makes sense in their context. Most so-called Agile teams would do far better by doing away with all the BS, and just having a prioritised 'to do' list, managed via some issue tracking system, such as Jira.
Breaking down things into smaller peieces is key to Agile, if you aren't doing that, you aren't being Agile. It's an organisational transformation, not a new dev process. So many companies want to implement Agile, but don't want to be Agile.
@@andishawjfac Sometimes things don't break down into smaller pieces. "Figure out what the new database schema should support" or "figure out what the new database schema should be" probably aren't going to break down into a 2-week sprint that you can deliver value on. From everything I've seen, "agile" is a way for bad management and bad programmers to disregard their lack of ability.
@@darrennew8211 If you don't think you can break those things down, you aren't good enough at your job, the problem being you aren't giving acheivable goals. "Figure out what the new DB schema should be" First off all, not every single task you will do in every sprint will deliver value immediately, things like infrastructure/engineering and devops have tasks where there is no customer value, however it does deliver value to the team, which then allows better delivery of value to the customer. So sprint 1 you setup a test DB with some basic tables and schema and test how well that works with a basic version of whatever is creating the data, you then review that and decide what you are doing the next sprint to move fowards. I find those who say they cannot break things down are often those who don't fully understand what they are trying to acheive, if I can break your example down in 2 minutes, I don't see how you can argue.
@@rogermouton2273 I never said break things down just for the sake of it, don't put words in my mouth and then get angry at them, that's very childish.
According to what you are saying, it’s impossible for a big project to be agile. Hell, Netflix doesn’t even respect your criterias of reviewing an increment of a sprint with its customers. There is no way a project with 18 agile squads can review their increments directly with the customer.
Hey there! Thanks for the feedback, you are correct! Multi-team big products like that are not agile, regardless of what they say - unless each team is able to introduce their changes and measure the impact independently of the others. Netflix has one of the most advanced deployment and change management strategies out there, so it wouldn’t surprise me if they are able to do it by testing changes on subsets of their customers. You may have heard of this - it’s called “canary” or “ring” releasing. It sounds like you may work there? Perhaps you can tell us? One of my favorite videos about the danger of trying to scale agile when that kind of setup isn’t available is from Jez Humble (author of Continuous Delivery and somebody I owe much of my career to) here: ruclips.net/video/2zYxWEZ0gYg/видео.html Maybe this can help someone who’s considering the claims I make in this video, and what to takeaway vs ignore.
@@HealthyDev I'd say one of the better responses for large teams is scaled agile framework. It's not agile, it's agile at scale. :) www.scaledagileframework.com/
@@AaronBockelie respectfully, I don't believe agile development is possible at scale (I mean to BE agile, not follow some agile practices) so I'm not a proponent of SAFe. If at a company that wants to call all their teams agile, use many of the practices, but not actually have any agility - it's a popular framework. Jez Humble has an excellent set of videos about this if you'd like a little background on why I feel this way. We both came to many of the same conclusions, but he does a fantastic job here explaining the scaling problems with agility in case you'd like an alternate view: ruclips.net/video/2zYxWEZ0gYg/видео.html ruclips.net/video/cH6bnQzJojo/видео.html I hope this doesn't mean to sound like I'm slamming SAFe or your opinion. Many people like it a lot - and for what it does it's popular. I just don't believe it helps teams be agile personally.
@@HealthyDev I think this touches on a continuous question I have when examining team agility: if a team unit can be agile, is it actually necessary for the company to be agile? One purpose of a company (if abstracted, a bunch of people financially invested in success) is to ultimately be responsible for a product that is brought to market as fast as possible to remain competitive. I agree that it is incorrect to call a company agile - by the very nature you can't. What I wrestle with and I'm not so sure of is this: where on the continuum of team agility onto...something that it is not does the "company" get placed on? Scaled agile seems to fit that spectrum model a bit, but it's just one of many different approaches to large organizations. Professionally, I speak with a lot of organizations that are "water-scrum-ban" ;) at the larger scope. Trying to classify or chart a path towards lean is the direction I want to see them go when I start making tooling recommendations. I certainly am not offended by safe, because I think it is more about how to market a package to large companies. Anyway I'm not sure where I'm headed with this other than thanks for the response and links to the youtube videos and generally agree with your sentiments on this topic. A
Good questions! Agile software development is all about inspecting and adapting on every level, meandering towards a product, trying to create value all along the way (which is not always possible). And that's it, basically... all the jazz about scrum, kanban whatever is just fluff and methods, that may or may not fit your team or environment. I, as an "agile coach", absolutely don't care about following the strict framework of scrum or going with a slushy flow in kanban. I rather help a team finding a sweet spot of non-obtrusive methodology, productive happy times for the team and a healthy rate of delivering value to the stakeholders.
@@HealthyDev Thanks. Working in a great company that has agile methods deeply engrained helps a lot. And we are a very close team of agile coaches, supporting various teams and ourselves. That also helps a lot. In this regard, I'm a happy dude. But I had my fair share of looking into the mounds of hell when management viewed "agile" as a method of exercising control over software devs and not as a means of creating value and transparency with a glimpse of happiness and well-being for the devs.
Absolutely! I’d be curious if you have any feedback on my video about agile budgeting. Fixed budgeting seems to be the norm with agile projects these days, leading to all sorts of dysfunction... ruclips.net/video/pG4wNLopMZA/видео.html
Those are great questions. I have asked the first one before and never received a good answer, e.g. "If it works we don't receive any bugs.", but I think for my next new team I will dig a little deeper. Wow budget for change, that one is going to be a challenging conversation in an environment that wants fixed requirements and design up front with no scope creep, i.e. change, but I feel the team and the management are ready to hear it.
It is negative for customers when the software is continually updated. When software is capable of being updated after delivery, it is vulnerable to hacking. If the company developing software can not define the required features of the software, they are incompetent at developing business opportunities from software.
When you continuously deliver software you have automated procedures, and manual processes, for the same things you'd do for any release. If you need to do threat detection, hire a firm to check every release, or have internal staff. It can be done. It's cheaper than building a product for 2 years come to find it's not competitive anymore and it fails (complete wasted budget) or 40% of the features you built never get used.
@@HealthyDev Of course it can be a business threatening challenge to know what to develop before you develop it. But delivering an incomplete product with plans to update it later is terrible for the customer. I suspect that many times the customers are unaware that they are being enlisted in such a scheme.
@@engineeringoyster6243 that's why you never release the product to your entire customer base. You do what's called canary releasing in continuous delivery. Release to a small audience you've already identified as wanting to be involved in early development. They vet upcoming work, you then release to a larger ring of people afterwards. The ring gets larger over time.
I didn't read all the comments and the video is 2 years old, but while I agree with the first question, I'm don't think the second question is all that valid, but it's somewhat subjective. Not having a budget means you can't develop; that's a financial issue and not process. Two questions that I didn't see are 1) is your release process automated i.e. CI type flow. If you can't release on a whim, being agile is a stretch, 2) is your code agile? If your developers don't follow SOLID principals (for example), it won't matter what process you're using. My 2 cents...
Hey thanks for the feedback, solid definitely helps. I linked in the comments (and in a card during the video) to another video that explains much more about agile budgeting: ruclips.net/video/pG4wNLopMZA/видео.html thanks for watching. 👍
If there is a PO who is responsible for deciding what the team's doing next, then the PO should prioritize changes based on user feedback just as any other improvement, and I fail to see why a separate budget would be necessary. Agree with everything except the second and last question.
When using agile techniques, you should guide them all the time with help of a LSS Black Belt 🥋. The thing here is that SCRUM and all these agile tools, comes from Lean Manufacturing stuff, but If you don’t know nothing about it, you’ll be using them in the wrong way. The most important thing to achieve success in a Lean environment, is leadership.
Absolutely! You may enjoy this other video "Leadership Skills for Lean Software Development" from earlier in the channel if you haven't already seen it: ruclips.net/video/tb5yrBZSVh4/видео.html
Great video, thank you for sharing! You as a dev are going to waste if you cannot spot fake scrum and fake agile. Your life will Just become a pain down the road at such a company. Listening to Jamie's advice you can save yourself from that early. Thanks again and please keep up the Great videos.
budgets are set by an executive team months before a project begins, how would our lT leader sell a padded budget for a undefined deliverable like "business feedback"? I'm serious, that sounds like a hard sell. While I agree with the premise, the reality sounds like it would never remain in the budget.
I talk about this in the earlier videos on the channel about Agile Budgeting, Minimum Viable Products, and Agile Project Management. Here's a couple snippets from my instagram related to that topic: instagram.com/p/BW7t8g_hkWF/ instagram.com/p/BWyTsewB5rQ/ hope that gets you started. Thanks, great question!
It’s like any management methodology, great in principle but once the management consultancies get hold of it they turn it into simple “admin for cash”. Look at any project than runs into millions and in all likelihood 90% of the cost is admin. The more clearly defined the process of decision making the further removed the decision makers are from the consequences of their failings. Check out the “agile is dead” lectures (by one of the guys who helped write the manifesto. Pure comedy :)
Actually, the main reason the agile system is better is that the software development process works FAR FAR better if it is built in a spiraling manner chunk by chunk. There are several reasons for this. Most important, the developers are able to build and test the entire time which makes the overall efficiency of building the software far far more efficient. The other aspect is the part you noted which is the ability to discover the actual requirements in a natural progression. As for MVP, the nuance here is that it can mean the level of functionality that is acceptable for a company to release, i.e. one that will not tarnish the product long term but rather give everyone, including users, a nice start from which to build.
Problem here is if you just listen to customers then your software product will become an actual mess. A lot of customers don't really know what they want, and think they need certain features when they don't. Especially when you have a multi-tenanted product, you can't listen to all customer feedback and think it's going to benefit your product.
That's a great point, not sure if you saw my video on "The Secret of Scrum Nobody Talks About" but I brought that up there: ruclips.net/video/B_ERfMMSAwY/видео.html The companies you work with should be grateful you understand this!
Do all teams need to be agile? We where purchased and the old owners had no agility what so ever, we where out working with our customers a lot so we got feedback indirectly. But with the new owner we sorta try to have standups and stuff but we don't really gather all that much feedback. Think we where much more effective before.
How do you feel about "agile" software teams that build software with long-lead hardware dependencies? It takes time to build a car or fighter jet out in the market and get feedback from real customers. I see a lot of orgs create this ghost "developer role/user" to simulate the impact of customer feedback to ensure continuous value is delivered.
Great question. Since software doesn’t have to be manufactured and once designed it can be rolled out to customers without additional physical product being manufactured, it has some unique attributes that make continuous delivery easier to achieve. With that being said, there are ways to be agile with hardware dependencies. It requires some interesting creativity but Jez Humble gives a cool example of one way this can work in a video from my playlist of favorite software development videos here: ruclips.net/video/2zYxWEZ0gYg/видео.html
What if the company _only_ allocates time for customer feedback? I guess it depends on the kind of software; for example, if you've built a landing page for a business, I don't see a problem incorporating the feedback directly. But if you're selling a software that's shared between multiple clients, letting a few wealthy, vocal clients dictate how your product is designed is a horrible idea. Clients are selfish and don't care if their favourite features negatively impact your company and your other clients.
Hey there. That right there is the essence of product management. Getting feedback from customers doesn't automatically mean you should do what they say. As you said, you can't let one big client drive all your features (and boy have I seen that go bad). But if you don't budget for feedback, or have a process that accommodates it, there's no ability to in the first place. Hope that helps a bit!
Hey Shawn thanks for the question! Not sure if you had a chance to watch the video on agile budgeting I mentioned in this one (it’s also in the episode description) but it will help with this. The short of it is you’re choosing how much to spend to pursue outcomes and not actually tracking how long things take because software development is a highly variable low repeatability activity so it’s a complete waste of time. Rather than try to guess or estimate effort on features, refactoring, or any other activity - you focus on delivering extremely small changes with a measurable way to know what impact you’re having before investing more.
I can spot a fake / dishonest agile team effort with 99% accuracy and one question: "Do you use pair programming?" ... Agile XP with pair programming is ultimately highly effective, producing much higher quality code - and faster with less burnout / turnover.... If done correctly, and management is willing to pay-off the initial technical debt necessary to get it airborne. But this is rare.
I'm a bit confused. I'm currently doing my DSDM. The PRL is what the project is planned by. If the Business Sponsor or the Business Visionary has not specifically stated that they want to plan for time to make changes to a solution after taking feedback from users, then it's safe to assume that this information will be picked up during post project and the Sponsor will either release more funds for the team to make changes or go into Pre Project and take things from there. The whole idea of Feasibility and Foundation is to get things set out so the solution team can get on with developing. If the Visionary or Sponsor want to make a change, then the PM will warn them of the consequences (extended time and resources). If the change is still green lit then fine, it gets added to the PRL. So why pre plan for changes from feedback? That being said, it sounds like that would be a good question for me to ask when setting up a project.
Now the automotive software teams want to become agile. The buget reserved for a costumer feedback it's a fuzzy, it's a woozy, it's fairy dust. The only concentrate on major quality issues that are holier expected to be solved with an update of the tuning.
Measurable signals for each released change that indicate whether the investment in that idea/feature should continue, is good enough, or should be removed altogether. How those signals are arrived at and the correct measurements are unique to each business goal in the product so they may be quantitative or qualitative (like the example in the video of reaching out to customers for feedback). Hope that helps a little.
What if the new customers come in and give different feedback that involves getting rid of certain features? Or is it gonna be a continuous process of getting feedback and then improving the software?
Yep, continuous process of feedback and improving. A team wouldn't remove a feature just based on one user's feedback. They'd have to see that the feature didn't contribute to the business goals of building it in the first place, or it's underused. I plan to talk about A/B testing more in the future which is a way to determine this.
I wonder what software these agile manifesto guys developed. I wonder if It's like some cooks made a revolutionary kitchen management method but these cooks have only worked on Taco joints.
Bankrupt Gamer the authors of the agile manifesto were really on to something. I blame inexperienced managers and consultants for it being applied incorrectly.
Agile" isn't new or novel...in the 70's manufacturing had a series of management ideologies "lean manufacturing" and "sigma 6" that had the same "management loves it but the people working under it hate it" reaction.
@@ghostbond1074 exactly. I think a lot of people throw it out completely, thinking it's a system specifically designed to micromanage developers - not looking into the Toyota Production System or any of the history that led the founders of scrum and the agile manifesto to try applying those concepts to software. I don't blame them, management being in control tended to focus on the practices that helped them feel in control, while the benefits of agility went out the window...
Yes that’s the budget I’m referring to. The cost of the effort involved to deliver things that weren’t identified until the customers offered them as desires when using a version of a product. Hope that makes sense!
To be honest, those two questions are not the truth. Is a "change" ok, or is it a problem for a team. I dont think two questions questions this all. But yeah, i got ur point.
Healthy Software Developer yes, sure. You claim there a two questions you have to ask to figure out if a team is agile or not. I do not agree, i guess there more indications of beeing agile. However i would say that agile is not an absolute state. But to point it out, i guess what youre saying is nice and makes sense. The team i am with (i am a product owner) is on the way of beeing agile. 👍
I hear you. There are definitely other indicators, I agree. I tried to boil it down to the essentials, but it’s still my opinion. With all the effort people spend on scrum, kanban, DevOps and the like - I’ve just been on many projects where people don’t understand agile means “able to respond to change”. And in my experience people who don’t budget for more than their original ideas, or accommodate feedback, are in a bad position to change. Once something needs to change they need to rebudget, and there’s psychological resistance to feedback if the team doesn’t start the project assuming some of their ideas are bad. So you can still start a project with the intention to be agile and not do the two things I mentioned sure. But when changes happen they encounter serious resistance (money and mindset). It’s hard to move with “quick and easy grace” in this state. Just my opinion from working on over 30 projects. I’m not a researcher so I base my opinions off what I see in the real world. I definitely don’t have all the answers - just trying to share some things to help people hopefully think “big picture”. Sorry if this one didn’t resonate with you. Appreciate you taking the time to give me some honest criticism!
Agile is good if implemented in the right way in project s..but it's a way to keep a check on developers especially in India..I like the channel name and I think young pple in IT will learn a lot from your experience.
Thanks Abhishek. Yes this is becoming more common in the US. I talked about it in my video “The Secret of Scrum Nobody Talks About”. Many companies are abusing agile methods as a micromanagement technique and completely missing the point!
Relieved that you did not advocate any “evangelical” recipes, especially scrum. I’m still not satisfied with your answer to the “fake agile” question. The most important principles of agility are self managing teams (see ya later, scrum!) and incremental releases (constant value, which you brushed against briefly). There are many signs you are not being “agile”. Are you following a process for the sake of a process? That becomes evident when the subject of process and its plethora of ceremonies overtake the topic of *how to technically deliver customer value*. Process as a religion also creates a great deal of acrimony within a team, and the “definition of done” can easily be used as a means to slow the team and squash creativity. Saw it with the team nextdoor and damn glad it was not my team! I actually knew of people going into a conference room to build a proof of concept to present at a future sprint planning. Why not? They were idle while waiting for code reviews and couldn't pull a "story" until then! Are you planning the Taj Mahal when a shotgun shack will do the trick? “Sprints” can become building blocks for a massive project, and deliverables become overwhelming, and then the scope changes underneath. That’s not agile - that’s a recipe for failing slowly. A series of small waterfalls adds up to one big waterfall. Don't do waterfall. It takes engineering and creativity to produce value incrementally! How much scope creep do you tolerate with tasks? Do you design something for one day, and it goes on for many more, and nobody calls it out? Do you divide the task, cancel it, or just shrug your shoulders? If you are truly being “agile”, then responding to customer feedback is a given. You don’t need a “process”, per se. You need maturity (focus on customer value, not your resumé), prioritization (well-groomed yet flexible backlog), and the discipline to stay focused on short term deliverables that actually have value. If you have self-managed, frequently-releasing teams, you don't have to "go to the board" to deliver quickly for customers. Agile, right?
I like that you recognize the risk of cherry picking practices! I talked about that in one of my other videos “Why Do Some Programmers Never Agree?”: ruclips.net/video/cqNBVrym3_U/видео.html I also agree we shouldn’t do things just for the sake of it, they must be in service of agility itself. I talked about that in my video about common agile fails. ruclips.net/video/-WgQdHOx_hA/видео.html However I stand by my points in the video. The reason why so many of the things you advocate are unpopular and management seem to sometimes even actively oppose them is because the project is funded and measured in a way that fights agility, and/or the leadership have no humility to expect the need to change (hence no feedback process). The video I link to in the description gets into budgeting and it’s impact on the ability to be agile as well. YMMV
To me, scrum (or possibly its most common interpretation of it) is a tried and tested way to burn out your programmers: everything is a sprint; there is no time for reflection, distance, taking a few steps back and considering. No, once one sprint is over, we go straight into the next one. Even the vocabulary of the thing is stress-inducing: backlog, sprint, velocity... brrr
@gwaptiva I hear you. That wasn't the original intention of scrum, it's just how it's being abused. So I don't blame you for seeing it this way - I have many times too! Another video on the channel that talks about this (if you haven't seen it yet you may or may not get something out of it), is "The Secret of Scrum Nobody Talks About": ruclips.net/video/B_ERfMMSAwY/видео.html
I think we can flip the problem around. Something like... "If the business AND customer knew exactly what they need and want...we could reduce the dependence on agile". This would then shift the focus away from agile and rather to finding a better way of coming up with a solution that skips having to get the software out in small pieces and take constant feedback to improve it.
So, i essentially, work as a one man team for my companies web interactions. I have a very small beta group, 1-3 people tops, and they often give very little feedback. What are some good recommendations for expanding the beta availability and gathering additional feedback from regular users. I’ve always assumed I was following AGILE development, even though i was never taught it or had anyone else to tell me i was doing otherwise. Even though I primarily work with e-commerce and content management, we do continuously work on new features and functionalities for our customers to gain value from visiting the site - in theory, leading to more traffic and more conversions.
Motivate people by offering them something for their time, then have an open ended interview (I would keep it to under 30 minutes) asking what their biggest problems that your product solves are. If they are existing customers, ask them what problems they have with your product. If you want to serve more customers, you want to be able to describe their problems better than they can in sales and marketing copy. Features and benefits are great - but if the work we do isn’t helping them solve problems that cause pain, there’s low motivation to pay. This is different for a luxury product where the problem is a desire for status and prestige, but that’s another topic. I’m not sure what market you’re in so it’s hard to offer anything concrete - these are just some general things you might consider to help you steer investment in development towards the most valuable and profitable outcomes from your product.
Healthy Software Developer thanks for the response. I’ve tried surveys and other methods to gather the data over the years. I work for an HVAC distribution company, so we are completely B2B and most of our customers are busy, only interested in talking to you during their busy work hours, and are generally non tech-savvy, people (which is weird when you think about what they work with all day) so the customer adoption rate for digital interaction and sales has been slow growing. I also have a lot of anxiety about dealing with customers face to face, lol. I’m not in sales, I left sales & marketing for the tech end of marketing by using code to run campaigns & other online initiatives for my company. Ive done sales, ive got a degree in marketing - so I understand market research - but sales & customers, no thanks, those are different hurdles all together.
@@RyanValizan understandable. We can only be who we can be. If you have a hard time talking to the customers, maybe you can encourage somebody else you have a good relationship with to do more of that for you and still get the input you'd like. Yes - motivating customers to discuss your product is a complex thing...
Healthy Software Developer thanks for the input. It’s not so much a product, however, but more/less another avenue to purchase. My primary focus is on the ecommerce end of things. I’ve set things in place to track user movement and search history, but it’s hard to know what they feel about it or would like to see or have access to with their account - these customers with accounts all have internal accounts, some with credit even, in our older ERP system as well. This is merging in the next year.
@@RyanValizan I see the dilemma, yes that's tough when you've got a product with a lot of existing features. I talked about in some of my earlier videos how when teams release several features at once, even if they have clear success criteria for whether a change they made achieved the business outcome they wanted, they don't know which change to attribute it to. That's even harder (pretty much impossible) when you've got an existing product with features built over a long period of time. Perhaps you can isolate changes to a single flow you want to test the impact of and reach out directly to some of those internal accounts - asking them to do some things that will take them through the path where you can get the data you need to know if what you're testing is reaching its goals?
The term Agile itself is counter-productive. It's like a brand with an imposed good reputation, with nothing special behind it. Continuous early feedback, and iterative releases that add immediate value; I feel like I've been striving to do exactly that for the last 25 years, and now this has a brand name? How about a patent on the obvious.
Hmm... While I agree that customer feedback often should be done better.... I also think a lot of the talk about processes is so general that it misses some actual challenges for teams which are not doing the kind of work the speaker subconsciously has in mind. As a backend engineer. The "customer" is often our selves. It rare that there is not some sore spots to improve in your infrastructure. So there's always something to do to automate processes, do better monitoring, testing, deployments, data safety, security, performance. We always know one crucial thing which we're pretty sure customers don't like: "Downtime". So being able to handle infrastructure changes without downtime or risk of "bad" downtime ... is always on the table. Sure - that is often of little value to the product department. It brings no new features to the customer.... and that unfortunately often breeds a culture where stuff has to break and break hard to get that sort of work prioritized. - regardless of the amount of red flag raised by developers in advance.
I would say monitoring, testing, deployments, data safety etc. ARE of high importance to the product team. The only problem is we don't always do a great job as engineers of tying the benefits to money. For example "Companies that had a security leak lost an average of 12m in lost revenue due to a loss in brand respect last year. If we don't care about data safety that's your call, but I'd hate to see all the features you designed this year not result in any rewards for you if we end up paying more recovering from a security disaster" etc.
@@HealthyDev Yes... but for many product-managers the metric is whether it put something visible to the user in production. Will the user discover when it's rolled out? Unless you have serious stability issues the answer is to that wrt. all those things are most often no. ... so ... many companies develop a de-facto regime where stuff has to break (and break hard) for important technical changes to get prioritized.
@@pm71241 I sympathize with your frustration, believe me. I personally feel these days though that it's up to us as software developers to teach product managers what is important to measure in addition to features and why. Much like we as developers aren't taught things like soft skills and dealing with politics at companies as part of our education, product managers often can't be taught enough about the unique nuances of managing a software product versus some other type of product. Yes in theory it's their job and they should know, but I guess I've adopted the stance that I'd rather take it as a challenge to teach them then just throw my hands up in the air. It's a difficult situation to be sure!
I’d agree if your only experience with agile has been fake agile projects (also sometimes called scrummerfall or waterscrum). When you’re on a really agile project, you’ll know it. At least that’s been my experience. Most projects claiming to be agile are more about pushing developers to produce code faster than they are about being able to respond to change. YMMV
I'm working different trade owner refuses to let me speak to customers at all. I said screw it I did what harden shit worker would do not give flip. So my observation if you can't talk directly to customers it's because your boss is lieing to them.
You do not have to guess anything. Client makes specification containing what they need and if something missing its their problem. All you have to deal with are dead lines. Features are problem of client. Doing MVP is good idea but it has to be properly set up to make it extendable and scalable. When you make product for masses then ofcourse its different story. But you do not have to deal with clients and dead lines.
“Minimum Viable” means that it provides enough value such that someone will PAY for it. Everyone is always willing to offer their opinion (for free) on how to change something….but that has nothing to do with an “MVP”.
Exactly. And the first release to customers often doesn't drive enough sales. That's why the MVP comes AFTER adaptation to multiple feedback cycles and releases.
In some constelltations, however, fake agile is the only type of agile that you want, because the full agile experience just doesn't work or would be highly inefficient. Think "do scrum with 2 people"
Full agile to me is a team fully able to adapt. Which usually means less process! Another video here that gets into what you’re describing (which may or may not be helpful) is “Scrum is the Motor of your Project, but who’s Steering?”: ruclips.net/video/9b0HgIdTDPE/видео.html
Unfortunately, with the popularity of CI/CD, you're saying "(continuously deliver) value" but I believe the original intent of the manifesto was "continuously (deliver value)".
Unfortunately, that's not enough. It's "red-green-refactoring" not just "red-green". And all the real work is done on refactoring stage. The purpose of "red-green" stage is to check if your tests (even if they are manual) works correctly. Time-wise it's like 10% on red-green stage and 90% on refactoring stage. However! A LOT of companies tend to deliver the product right after the green stage. It 10 times cheaper and most investors and even customers won't notice any difference! But, if you go like that, each sprint you increase complexity exponentially. And by increasing complexity, you increase cost of every new feature. Exponentially. And after a year or 2 you will be in a situation, when you cant move at all. You will have to stop and rewrite everything from scratch. And while you will be doing that for the next year, your competitors will go further. So.. if you are not doing refactoring since very beginning - competition is already lost. True agile team have ZERO legacy code at any moment. If there is some legacy code - it's not true agile team. Even if it's just a tiny bit.
It is easy: Ask my team. We will tell you: no. The company only want to have agile development teams, but not want to transform into an agile company. So it makes no sense to use agile when anything outside the development teams are not agile.
I hate Agile when there is a regular every day status meeting. You feel like a slave begging not to get fired (although I never been fired). Once (or rarely more than once) a week meeting is enough for me.
You are complaining about Scrum, which is said to be an agile methodology. The agile manifesto does value communication, that's an important thing. But it doesn't say how.
This highlights some of the issues with agile if it's seen as an engineering approach only. There are a set of guidelines for designing a product that the proposed approach breaks. 1. Find out what the user needs, not what they want. Feature requests are too little too late. Reaching out to beta testers is too little too later. Instead, you should know if the product will work BEFORE building it. 2. Feedback is the worst kind of user insight. Usability testing, contextual enquiry and a bunch of other user and customer research tools exist that tell you what the user needs are before the design is done before a single line of code is created. Don't build to find out if what you built is right! 3. Customers often don't equal users, especially in the enterprise space. In short - this is why agile fails. It's not user-centric enough. BUT the idea of continual releasing is good but ensure you know what the user NEEDS BEFORE you build anything.
Nice! They have been sitting in the corner of my bedroom not getting much love lately. I need to fix an issue with the floor tom so my wife can start practicing again (I was teaching her so we could play together). I haven’t played out for decades. Do you play in a group or anything like that?
Sorry, I think you put too much false statements in you talk. Like for example about “before agile” era. For example, many teams in large and not so large companies don’t work in agile as written in agile manifest, more over some of them have CD and some don’t. And both of this approaches work for that companies. And some of them were doing this way before that manifesto. So, agile is just a tool, in some businesses it really shines and in some it doesn’t. It is way to bad to say that before agile was introduced teams and companies were delivering not what customers wanted because of too long development time.
I think I’m understanding what you’re saying here. I didn’t mean to imply that every company in business before the manifesto had this problem. I was referring to the industry overall, which is most companies in my experience. Hope that helps.
@@HealthyDev funny how this stuff (minimum viable system first, emphasis on architecture, early testing, adaption to user feedback and suggestions, incremental and iterative improvement and continuous integration, ability to back out changes that don't workout, document everything) was all known back at least since the 1968 NATO Software Engineering Conference, and was discussed at length in the proceedings, yet somehow what most organisations seemed to get out of that conference was waterfall. Excuse me what?
![Digital Circus Episode 4 [TRAILER]](http://i.ytimg.com/vi/abZtsmMUbJo/mqdefault.jpg)
If your team use "being agile" as an excuse for a chaotic environment without any kind of feedback... yeah, it is totally fake
I worked for a major securities brokerage house on Wall Street, and we were a COBOL shop. We had well over 500 programmers on staff, each dedicated to the silo of business they were working on. Why? Because the software required an intimate understanding of the business, the user requirements, and a reliable working relationship with the user community. Every team had its subject matter experts, and that knowledge was passed on to newer members of the team, which required a year or two before a programmer can speak intelligently with the users.
You can imagine the panic and chaos that ensued, a new set of geniuses in the IT department decided it would be a good idea, to retire the SMEs, and institute Agile as the next thing. It took the better part of a decade to recover from that turd of an idea, and the integrity of the systems and the confidence of the user community has never been the same.
Lol. Software devs that like agile are masochists. Imagine being a house builder and thinking it was a good idea to let customer change things every two weeks whilst micro managing your progress through daily scrums. Most of the time agile seems to be an excuse not to do planning under the guise of adaptability. I’ve never seen SMEs increase after going to agile. Most agile team meetings you leave thinking the team must be new, but you look them up and they have been working for a couple years. Hilarious. I love it
The worst part of your story?
You had _everything_ required to work agile and quickly respons to customer needs.
In fact you had the perfect, cross functional, agile setup. It just wasn't called that.
This is what is so hard for some agile proponents to understand:
In many cases life is more complex than creating another web page with a database backbone.
Sometimes you actually can tell exactly what is needed beforehand. If you are writing software for a car you will have engine, break pedal, steering wheel, an automatic gearbox, indicators and switches for various functions. You can create a list with most of these at the start of the project, and you can create you software in such a way that it can accommodate changes like exactly the kind of switch, gear box etc will be in place when the cars rolls off the assembly line a year from now.
But it is possible to create an overall plan, if, but only if, you know the subject matter at hand.
You said it takes one or two years for a developer to gain enough knowledge to even ask the right questions, this is not something that "agile" is very good at. Agile works best when demands change drastically over time, when not much knowledge is needed to create the next visible feature and there is very little interdependence in the subject domain.
Yeah, typical. Some new manager comes in and needs to do something "cool" and fashionable, such as Agile/scrum, so they make a lot of changes that do nothing but create disruption and chaos. It's the arrogance of thinking that experience has no value, and that you, with your "cool" methodology, know better
@@patjohn775 9
@@rogermouton2273 Let's acknowledge the reality that the giant legacy COBOL application and its business processes was in a slow death spiral. Any sort of of remedy is going to be somewhat painful. This reality exists despite who is newly hired in management. It's not that experience has no value, it's that experience that is completely locked into a legacy paradigm has less value over time than an agile solution. Sometimes management has the hope that overlaying agile on top of a legacy monolith is going to give them the best of both rather than the worst of both.
I worked for a company that said they are agile. But had no budget to accommodate changes at all. Turns out, what they meant by agile is just the team being crunched to work overtime and weekends to meet stupid unrealistic expectations
Can you spot a fake agile team? Are your teams benefiting from feedback? Share your thoughts with the community below.
Skip to points in the video:
0:00 Introduction
0:17 How This Video Will Help You
0:49 Why Care About Agile?
1:19 Why Continuously Deliver Software?
2:17 Why Infrequent Releases Frustrate Customers
2:36 Misunderstanding the Minimum Viable Product
3:12 The Futility of Agile Theater
3:33 How To Know A Team Is Using Fake Agile
3:45 Question #1: How Does The Team Gather Feedback?
4:30 Question #2: How Much Is Budgeted For Change?
5:35 Why People Resist Agility
Hey folks someone on Facebook mentioned the agile manifesto isn’t quite 20 years old, I got it mixed up with scrum which is older. Sorry about that!
The most simple, clear and full of content video about agile fails that I have ever seen in my life.
Man, I want to see all of your videos! I’m tired about being frustrated on every project that I work, I know what’s wrong I know where to fix, but I don’t have a high level role yet to start making decisions instead of the manager/architect/team leader.
What do you recommend me to to in this case?
I’m basically just a developer, but I use to work as a consultant as well sometimes.
I’m close to do a presentation in my current company about Agile/Scrum as I know it could potentially increase our projects experience. But I’m still not sure If they will start using that correctly or not.
Henrique Palomo hey sorry I missed this one. Unfortunately I struggle with this too. The only things that seem to have an impact is either getting a high enough position to enact changes through authority, or to demonstrate an improved practice yourself and use that as leverage to get the support for having more influence.
When done by authority it’s quicker but people will be resentful if they aren’t educated enough about the changes to see what’s in it for them.
When I do something myself there’s obviously less resistance but I’ve got to be way more patient.
It’s tough either way - old management habits are hard to change!
YMMV
Thanks for this! I'm 3 weeks into a new job and just realised they're not interested in Agile for agility - they follow scrum because it's what other companies do 😬
Agile. Interruptions are one of the biggest detractors to a software developers' productivity. Daily meetings is right up there.
If a 15 min meeting fucks up your whole day, then maybe the fault isn't on the meeting
I benefited alot from those daily meetings when I was new to dev. Right now those daily meetings help me help the "newer" devs stay productive. Just my 2cents.
@@tuliof it's a perfect place to micromanage the development of a project. They never last 15 minutes. Who are you kidding...
@@jflow5601 Yeah, often priorities shift because of these meetings
@@SerBallister 15 minute meetings to make snap decisions about design which affect developers for example do NOT substitute for a well thought out design ahead of time. In some companies, they use stand up meetings to discuss architecture workarounds. Anyway a different subject. I wonder how SpaceX manages their SW development. Someone there needs to write a book.
In my last 7 years of software dev. I have experienced agile is atool set used by companies as a tool of brutal micromangement
Sadly you’re right this is almost becoming the de facto methodology. If you haven’t seen it already there’s another video on here that talks about exactly that, “The Secret of Scrum Nobody Talks About”: ruclips.net/video/B_ERfMMSAwY/видео.html
I am really passionate devloper. I am done with devlopement..These bunch of non tech jokers dont understand progarammingf is an art. You are not supposed to disturb a singer singing on stage.
A good reusabel peice of code is an art. And to write good block of code a lot of time has been spend to master the craft.
But everyone wants things now.
Agile is a good way to fuck a dev
@@HealthyDev I think part of what has been happening is the certifications are quite easy to get, easy to recruit for. Then you embed this person with no hands on dev experience in the daily team life. This non technical PM is now hearing chatter that in the old world they would never hear and the opportunity for ill-informed micromanagement appears. The restraint for this is supposed to be diligence to the agile principles and the ability to coach the team in those regards, but in my experience, agile practitioners are in reality not accountable to anyone for how well they handle those aspects. Mostly, project managers (of all types) in many orgs are typically accountable for project success. This is the "one neck to choke" concept that upper management in Western business has latched on to since at least the 1950's.
One sign of fake agile in view is all the business agile disciplines, but none of the developer agile disciplines - no tests, no pairing opportunities etc.
@Jeffrey Hainesyou are right. That's why I said opportunities. I genuinely enjoy pairing with great developers
@Jeffrey Haines I'll give you pairing, but repeatable preferably automated tests are a requirement to quickly change code and respond to requirements changing and evolving.
@Jeffrey Haines That's exactly what I mean by automated tests. :)
Really you need to spot an agile organization - if the dev team is agile and making an internal product, for example, but the client group is not participating in the continuous feedback loop, the dev team's agility is moot.
Clear metrics to measure value are also useful. You could end up getting a ton of feedback but need to know what feedback is actionable and should be prioritized.
I agree this is preferred. Unfortunately it seems most truly agile teams are pockets within an enterprise operating as a bit of a skunkworks, or a top down “transformation” was done that checks all the boxes but misses the point. I agree completely with the data you gather needing to be actionable - otherwise the effort of gathering it is waste. 👍
NuncNuncNuncNunc this is sort of the situation i’m in. I don’t have enough time to handle every single end of full stack development all the time. I take feedback as it comes in, but i find it difficult to seek out or research and develop a way to have it come in more naturally. The feedback I do get I try to work with within the limitations of my abilities, what I can outsource, and the limitations of the dated project dependencies.
That moment when you realize your software team is a fake agile team.
Continuously deliver value! Also my favorite part of the manifesto, well done.
When the team still racks up tech debt and goes through crunchy deathmarches 🤣
I think this was a good point to bring up, I am only a second year student, and probably may make a fool of myself here, but I do know developing. And there is a psychology inherit in most programmers, that is there is a socialization that takes place inside any group of people. Hierarchies are formed, bias' are formed, and without you even realizing it, a pecking order is established. Even among the developers, that is between the developers themselves outside tech leads, and team leads, and higher order management. This pecking order can be due to insecurities of the developers, or even lack of insecurities, impostor syndrome, etc... When this happens, the bias' of the alpha become the inevitable bias' of the team, it is a cascading effect, and as we know inheritance from waterfall is bad! I think being agile, is being open to the input of the entire team. I guess my point is, (sticking up for the new developer joining a team), being new does not necessitate inexperience. Some developers may be new to the team, but not new to development. And no one has all the answers! Agile is just as much about being flexible and open to change with respect to the project, as it should be being flexible to the input of the team; the WHOLE team, not just the dog that barks the loudest!
Agree completely. You might be interested in my video on democratic software architecture, it’s on point with your conclusions: ruclips.net/video/1CDUHW_HXbQ/видео.html
I have heard about agile whenever i come across job applications as a requirement. Your videos are really informative, thank you.
Happy to help!
'Agile' is simply the new name for micromanaging.
It's the new hiding place for bad programmers and worse managers. Everything in "agile" that says *how* to do agile is covering up a shortcoming of programmers or especially managers of programmers.
So true
Micromanagers just use fancy words to make their poor management skills look less bad.
Agile is still Agile
When I hear agile, I instantly get PTSD.
Love your honest video with real life examples. Keep it up.
Thanks Prasad. 👍
I think you hit the nail on the head with this one.
One thing I don't like about agile development is that its easy to fall in the trap of focusing on the next deliverable that the long view can get lost (high level architecture, etc).
So true. Some aspects of software don't lend well to delivering a vertical chunk of new stuff or vertical stack of changes. Usually such changes impact horizontally.
Imagine what a house builders house would look like agile... every room would have different flooring and trim, the foundation would be the wrong size, wires would end up under the bath tub.. lmao
@@patjohn775 that’s why the best developers spend a lot of time revisiting and refactoring things they’ve written before
But that should have already been dealt with by the Business Visionary, Business Analyst and Project Manager. At least in DSDM it is.
One thing i dont like about agile is the short sprints. We have two week sprints, which means potentially, every two weeks there is a release that never goes as smoothly as the theory suggests. This frequent after hours job is not just a massive disruption in my private life, but also in my work life: You get two weeks worth of work to complete, but then half a week is spend prepping for the release and another half for testing, not to mention support that comes in the way. I've suggested we do 3 or 4 weeks sprints instead. That way, we spend less time prepping and doing admin, and proportionally doing more time coding. The powers that be didn't bite.
I believe the solution to smoother sprints, if you’re going with scrum, is way less scope per sprint and way more automation. Manual testing and deployment, and putting developers on new work the second new stuff is in production doesn’t seem to work. My understanding of the psychology behind doing releases more frequently is the pain of inefficiencies in your release process is so bad it forces you to change. If you only release once a month, people don’t seem to have the motivation to improve since it’s “only occasional overtime”. My two cents at least.
If you can't change the length of a sprint, you cannot adapt, adapting is the foundation of being Agile. Inspect, Adapt it's why Scrum is bullshit.
@@andishawjfac Well, I did get it to 3 weeks now, and its amazing how much that improved our quality of live. We actually did have some longer sprints as well, but those are the exception.
Hi, I am just a truck driver here. I think employers are part of the reasons why there are a lot of people faking to be a professional in that field. Because every employer wants you to have 5 years of experience when you are 22 and just graduated college. There are no opportunities for entry-level practices so therefore people fake their resumes and become who or what they are not.
Seems to me that just about everything I read and see online about Agile, assumes that it's being used in an environment where there's regular releases of some piece of software to a very large community of users. Most of the projects I've been on are not like that. Eg, doing the data migration for a large government system, dealing with requests for enhancements and fixes to systems that are internal to an organisation. Many or most of the teams that I've been on claim to be 'Agile' or scrum, and they run two-week sprints, etc. It's all complete BS because, for one thing, you generally can't produce anything meaningful within two weeks - so you artificially create a bunch of stories, or tasks, or whatever to fit within two weeks, and create a huge and meaningless admin overhead of sprints, and moving stuff between sprints, etc. In short, most organisations are stupid, and think 'let's do Agile, because it makes everything better', then mindlessly go through the 'Agile motions' of sprints, sprint planning, stand-ups, user stories, etc, etc, regardless of whether it actually makes sense in their context. Most so-called Agile teams would do far better by doing away with all the BS, and just having a prioritised 'to do' list, managed via some issue tracking system, such as Jira.
Breaking down things into smaller peieces is key to Agile, if you aren't doing that, you aren't being Agile. It's an organisational transformation, not a new dev process. So many companies want to implement Agile, but don't want to be Agile.
@@andishawjfac tasks should be broken down into pieces that make logical sense, not into smaller pieces for the sake of it
@@andishawjfac Sometimes things don't break down into smaller pieces. "Figure out what the new database schema should support" or "figure out what the new database schema should be" probably aren't going to break down into a 2-week sprint that you can deliver value on.
From everything I've seen, "agile" is a way for bad management and bad programmers to disregard their lack of ability.
@@darrennew8211 If you don't think you can break those things down, you aren't good enough at your job, the problem being you aren't giving acheivable goals.
"Figure out what the new DB schema should be"
First off all, not every single task you will do in every sprint will deliver value immediately, things like infrastructure/engineering and devops have tasks where there is no customer value, however it does deliver value to the team, which then allows better delivery of value to the customer.
So sprint 1 you setup a test DB with some basic tables and schema and test how well that works with a basic version of whatever is creating the data, you then review that and decide what you are doing the next sprint to move fowards.
I find those who say they cannot break things down are often those who don't fully understand what they are trying to acheive, if I can break your example down in 2 minutes, I don't see how you can argue.
@@rogermouton2273 I never said break things down just for the sake of it, don't put words in my mouth and then get angry at them, that's very childish.
Dude, your channel is awesome. Thanks for the content.
Glad it’s helping you! No problem Lucas, thanks. 🙏
According to what you are saying, it’s impossible for a big project to be agile.
Hell, Netflix doesn’t even respect your criterias of reviewing an increment of a sprint with its customers.
There is no way a project with 18 agile squads can review their increments directly with the customer.
Hey there! Thanks for the feedback, you are correct!
Multi-team big products like that are not agile, regardless of what they say - unless each team is able to introduce their changes and measure the impact independently of the others.
Netflix has one of the most advanced deployment and change management strategies out there, so it wouldn’t surprise me if they are able to do it by testing changes on subsets of their customers. You may have heard of this - it’s called “canary” or “ring” releasing. It sounds like you may work there? Perhaps you can tell us?
One of my favorite videos about the danger of trying to scale agile when that kind of setup isn’t available is from Jez Humble (author of Continuous Delivery and somebody I owe much of my career to) here: ruclips.net/video/2zYxWEZ0gYg/видео.html
Maybe this can help someone who’s considering the claims I make in this video, and what to takeaway vs ignore.
@@HealthyDev I'd say one of the better responses for large teams is scaled agile framework. It's not agile, it's agile at scale. :)
www.scaledagileframework.com/
@@AaronBockelie respectfully, I don't believe agile development is possible at scale (I mean to BE agile, not follow some agile practices) so I'm not a proponent of SAFe.
If at a company that wants to call all their teams agile, use many of the practices, but not actually have any agility - it's a popular framework.
Jez Humble has an excellent set of videos about this if you'd like a little background on why I feel this way.
We both came to many of the same conclusions, but he does a fantastic job here explaining the scaling problems with agility in case you'd like an alternate view:
ruclips.net/video/2zYxWEZ0gYg/видео.html
ruclips.net/video/cH6bnQzJojo/видео.html
I hope this doesn't mean to sound like I'm slamming SAFe or your opinion. Many people like it a lot - and for what it does it's popular. I just don't believe it helps teams be agile personally.
@@HealthyDev I think this touches on a continuous question I have when examining team agility: if a team unit can be agile, is it actually necessary for the company to be agile? One purpose of a company (if abstracted, a bunch of people financially invested in success) is to ultimately be responsible for a product that is brought to market as fast as possible to remain competitive. I agree that it is incorrect to call a company agile - by the very nature you can't.
What I wrestle with and I'm not so sure of is this: where on the continuum of team agility onto...something that it is not does the "company" get placed on? Scaled agile seems to fit that spectrum model a bit, but it's just one of many different approaches to large organizations.
Professionally, I speak with a lot of organizations that are "water-scrum-ban" ;) at the larger scope. Trying to classify or chart a path towards lean is the direction I want to see them go when I start making tooling recommendations. I certainly am not offended by safe, because I think it is more about how to market a package to large companies.
Anyway I'm not sure where I'm headed with this other than thanks for the response and links to the youtube videos and generally agree with your sentiments on this topic.
A
I just realized maybe there's another tl;dr acronym I just invented. SINA: SAFe Is Not Agile (but it stands upon agile process)
Good questions! Agile software development is all about inspecting and adapting on every level, meandering towards a product, trying to create value all along the way (which is not always possible). And that's it, basically... all the jazz about scrum, kanban whatever is just fluff and methods, that may or may not fit your team or environment. I, as an "agile coach", absolutely don't care about following the strict framework of scrum or going with a slushy flow in kanban. I rather help a team finding a sweet spot of non-obtrusive methodology, productive happy times for the team and a healthy rate of delivering value to the stakeholders.
You sound like a real agile coach. I’m happy for the teams that get to work with you! Great perspective.
@@HealthyDev Thanks. Working in a great company that has agile methods deeply engrained helps a lot. And we are a very close team of agile coaches, supporting various teams and ourselves. That also helps a lot. In this regard, I'm a happy dude. But I had my fair share of looking into the mounds of hell when management viewed "agile" as a method of exercising control over software devs and not as a means of creating value and transparency with a glimpse of happiness and well-being for the devs.
your videos are really good. Clear and to the point
Thanks! Glad to have you here. 🤠👍
i'm not sure what you mean with budget. but, i don't think a fixed budget works for agile. from my experience, it also requires an "agile" budget
Absolutely! I’d be curious if you have any feedback on my video about agile budgeting. Fixed budgeting seems to be the norm with agile projects these days, leading to all sorts of dysfunction... ruclips.net/video/pG4wNLopMZA/видео.html
Those are great questions. I have asked the first one before and never received a good answer, e.g. "If it works we don't receive any bugs.", but I think for my next new team I will dig a little deeper. Wow budget for change, that one is going to be a challenging conversation in an environment that wants fixed requirements and design up front with no scope creep, i.e. change, but I feel the team and the management are ready to hear it.
It is negative for customers when the software is continually updated. When software is capable of being updated after delivery, it is vulnerable to hacking.
If the company developing software can not define the required features of the software, they are incompetent at developing business opportunities from software.
When you continuously deliver software you have automated procedures, and manual processes, for the same things you'd do for any release. If you need to do threat detection, hire a firm to check every release, or have internal staff. It can be done. It's cheaper than building a product for 2 years come to find it's not competitive anymore and it fails (complete wasted budget) or 40% of the features you built never get used.
@@HealthyDev Of course it can be a business threatening challenge to know what to develop before you develop it. But delivering an incomplete product with plans to update it later is terrible for the customer. I suspect that many times the customers are unaware that they are being enlisted in such a scheme.
@@engineeringoyster6243 that's why you never release the product to your entire customer base. You do what's called canary releasing in continuous delivery. Release to a small audience you've already identified as wanting to be involved in early development. They vet upcoming work, you then release to a larger ring of people afterwards. The ring gets larger over time.
@@HealthyDev Do those customers get a significant discount for being your Beta Testers?
@@engineeringoyster6243 if they're beta testing, it should be free.
I didn't read all the comments and the video is 2 years old, but while I agree with the first question, I'm don't think the second question is all that valid, but it's somewhat subjective. Not having a budget means you can't develop; that's a financial issue and not process. Two questions that I didn't see are 1) is your release process automated i.e. CI type flow. If you can't release on a whim, being agile is a stretch, 2) is your code agile? If your developers don't follow SOLID principals (for example), it won't matter what process you're using. My 2 cents...
Hey thanks for the feedback, solid definitely helps. I linked in the comments (and in a card during the video) to another video that explains much more about agile budgeting: ruclips.net/video/pG4wNLopMZA/видео.html thanks for watching. 👍
If there is a PO who is responsible for deciding what the team's doing next, then the PO should prioritize changes based on user feedback just as any other improvement, and I fail to see why a separate budget would be necessary. Agree with everything except the second and last question.
Keep up the good work and I like the arm motions, you would be all the way across the pool by now.
🤣
Can confirm that I work on a fake agile project! (But I knew before...)
When using agile techniques, you should guide them all the time with help of a LSS Black Belt 🥋. The thing here is that SCRUM and all these agile tools, comes from Lean Manufacturing stuff, but If you don’t know nothing about it, you’ll be using them in the wrong way.
The most important thing to achieve success in a Lean environment, is leadership.
Absolutely! You may enjoy this other video "Leadership Skills for Lean Software Development" from earlier in the channel if you haven't already seen it: ruclips.net/video/tb5yrBZSVh4/видео.html
Great video, thank you for sharing! You as a dev are going to waste if you cannot spot fake scrum and fake agile. Your life will Just become a pain down the road at such a company. Listening to Jamie's advice you can save yourself from that early. Thanks again and please keep up the Great videos.
Thanks Balint!
budgets are set by an executive team months before a project begins, how would our lT leader sell a padded budget for a undefined deliverable like "business feedback"? I'm serious, that sounds like a hard sell. While I agree with the premise, the reality sounds like it would never remain in the budget.
I talk about this in the earlier videos on the channel about Agile Budgeting, Minimum Viable Products, and Agile Project Management. Here's a couple snippets from my instagram related to that topic: instagram.com/p/BW7t8g_hkWF/ instagram.com/p/BWyTsewB5rQ/ hope that gets you started. Thanks, great question!
It’s like any management methodology, great in principle but once the management consultancies get hold of it they turn it into simple “admin for cash”. Look at any project than runs into millions and in all likelihood 90% of the cost is admin. The more clearly defined the process of decision making the further removed the decision makers are from the consequences of their failings. Check out the “agile is dead” lectures (by one of the guys who helped write the manifesto. Pure comedy :)
Actually, the main reason the agile system is better is that the software development process works FAR FAR better if it is built in a spiraling manner chunk by chunk. There are several reasons for this. Most important, the developers are able to build and test the entire time which makes the overall efficiency of building the software far far more efficient. The other aspect is the part you noted which is the ability to discover the actual requirements in a natural progression. As for MVP, the nuance here is that it can mean the level of functionality that is acceptable for a company to release, i.e. one that will not tarnish the product long term but rather give everyone, including users, a nice start from which to build.
You give good advice. Just starting out in this world. Thank you.
Problem here is if you just listen to customers then your software product will become an actual mess. A lot of customers don't really know what they want, and think they need certain features when they don't. Especially when you have a multi-tenanted product, you can't listen to all customer feedback and think it's going to benefit your product.
That's a great point, not sure if you saw my video on "The Secret of Scrum Nobody Talks About" but I brought that up there: ruclips.net/video/B_ERfMMSAwY/видео.html The companies you work with should be grateful you understand this!
Do all teams need to be agile?
We where purchased and the old owners had no agility what so ever, we where out working with our customers a lot so we got feedback indirectly.
But with the new owner we sorta try to have standups and stuff but we don't really gather all that much feedback.
Think we where much more effective before.
This is really good... Thx for sharing!
My pleasure!
How do you feel about "agile" software teams that build software with long-lead hardware dependencies? It takes time to build a car or fighter jet out in the market and get feedback from real customers. I see a lot of orgs create this ghost "developer role/user" to simulate the impact of customer feedback to ensure continuous value is delivered.
Great question. Since software doesn’t have to be manufactured and once designed it can be rolled out to customers without additional physical product being manufactured, it has some unique attributes that make continuous delivery easier to achieve.
With that being said, there are ways to be agile with hardware dependencies. It requires some interesting creativity but Jez Humble gives a cool example of one way this can work in a video from my playlist of favorite software development videos here:
ruclips.net/video/2zYxWEZ0gYg/видео.html
Please keep making these videos! I love your content!
Thanks Dixon, appreciate the encouragement! I plan to soon :)
What if the company _only_ allocates time for customer feedback? I guess it depends on the kind of software; for example, if you've built a landing page for a business, I don't see a problem incorporating the feedback directly. But if you're selling a software that's shared between multiple clients, letting a few wealthy, vocal clients dictate how your product is designed is a horrible idea. Clients are selfish and don't care if their favourite features negatively impact your company and your other clients.
Hey there. That right there is the essence of product management. Getting feedback from customers doesn't automatically mean you should do what they say. As you said, you can't let one big client drive all your features (and boy have I seen that go bad). But if you don't budget for feedback, or have a process that accommodates it, there's no ability to in the first place. Hope that helps a bit!
How about if a team doesn't budget / allocate time for refactoring?
Hey Shawn thanks for the question! Not sure if you had a chance to watch the video on agile budgeting I mentioned in this one (it’s also in the episode description) but it will help with this.
The short of it is you’re choosing how much to spend to pursue outcomes and not actually tracking how long things take because software development is a highly variable low repeatability activity so it’s a complete waste of time.
Rather than try to guess or estimate effort on features, refactoring, or any other activity - you focus on delivering extremely small changes with a measurable way to know what impact you’re having before investing more.
I can spot a fake / dishonest agile team effort with 99% accuracy and one question: "Do you use pair programming?" ... Agile XP with pair programming is ultimately highly effective, producing much higher quality code - and faster with less burnout / turnover.... If done correctly, and management is willing to pay-off the initial technical debt necessary to get it airborne. But this is rare.
I'm a bit confused. I'm currently doing my DSDM. The PRL is what the project is planned by. If the Business Sponsor or the Business Visionary has not specifically stated that they want to plan for time to make changes to a solution after taking feedback from users, then it's safe to assume that this information will be picked up during post project and the Sponsor will either release more funds for the team to make changes or go into Pre Project and take things from there.
The whole idea of Feasibility and Foundation is to get things set out so the solution team can get on with developing. If the Visionary or Sponsor want to make a change, then the PM will warn them of the consequences (extended time and resources). If the change is still green lit then fine, it gets added to the PRL. So why pre plan for changes from feedback?
That being said, it sounds like that would be a good question for me to ask when setting up a project.
Now the automotive software teams want to become agile. The buget reserved for a costumer feedback it's a fuzzy, it's a woozy, it's fairy dust. The only concentrate on major quality issues that are holier expected to be solved with an update of the tuning.
straight to the real point
Great video! Lots of it in Japan. 99%
Sorry to hear! Hang in there, I hope the industry turns things around if we’re persistent to care enough to educate them! 👍
The art the background...Austin from above?
SUBSCRIBED! Btw, what's the correct answer to question # 2?
Measurable signals for each released change that indicate whether the investment in that idea/feature should continue, is good enough, or should be removed altogether. How those signals are arrived at and the correct measurements are unique to each business goal in the product so they may be quantitative or qualitative (like the example in the video of reaching out to customers for feedback). Hope that helps a little.
What if the new customers come in and give different feedback that involves getting rid of certain features? Or is it gonna be a continuous process of getting feedback and then improving the software?
Yep, continuous process of feedback and improving. A team wouldn't remove a feature just based on one user's feedback. They'd have to see that the feature didn't contribute to the business goals of building it in the first place, or it's underused. I plan to talk about A/B testing more in the future which is a way to determine this.
These are really good questions
I wonder what software these agile manifesto guys developed.
I wonder if It's like some cooks made a revolutionary kitchen management method but these cooks have only worked on Taco joints.
Bankrupt Gamer the authors of the agile manifesto were really on to something. I blame inexperienced managers and consultants for it being applied incorrectly.
Agile" isn't new or novel...in the 70's manufacturing had a series of management ideologies "lean manufacturing" and "sigma 6" that had the same "management loves it but the people working under it hate it" reaction.
@@ghostbond1074 exactly. I think a lot of people throw it out completely, thinking it's a system specifically designed to micromanage developers - not looking into the Toyota Production System or any of the history that led the founders of scrum and the agile manifesto to try applying those concepts to software. I don't blame them, management being in control tended to focus on the practices that helped them feel in control, while the benefits of agility went out the window...
I would add to that, you have "architects" playing police because everything can break since they never budget for refactoring and test development
subscribed! thanks for the video
Great points! Thank you!
Is budget includes time spent by the team, in addition to money?
Yes that’s the budget I’m referring to. The cost of the effort involved to deliver things that weren’t identified until the customers offered them as desires when using a version of a product. Hope that makes sense!
It's easy to fake having the benefits of Agile; it's hard to fake bearing the costs of Agile.
To be honest, those two questions are not the truth. Is a "change" ok, or is it a problem for a team. I dont think two questions questions this all. But yeah, i got ur point.
Hey Baris thanks for the feedback. I don’t fully understand your comment. Could you clarify what you mean when you’re able? Thanks!
Healthy Software Developer yes, sure. You claim there a two questions you have to ask to figure out if a team is agile or not.
I do not agree, i guess there more indications of beeing agile. However i would say that agile is not an absolute state. But to point it out, i guess what youre saying is nice and makes sense.
The team i am with (i am a product owner) is on the way of beeing agile. 👍
I hear you. There are definitely other indicators, I agree. I tried to boil it down to the essentials, but it’s still my opinion.
With all the effort people spend on scrum, kanban, DevOps and the like - I’ve just been on many projects where people don’t understand agile means “able to respond to change”.
And in my experience people who don’t budget for more than their original ideas, or accommodate feedback, are in a bad position to change.
Once something needs to change they need to rebudget, and there’s psychological resistance to feedback if the team doesn’t start the project assuming some of their ideas are bad.
So you can still start a project with the intention to be agile and not do the two things I mentioned sure. But when changes happen they encounter serious resistance (money and mindset). It’s hard to move with “quick and easy grace” in this state.
Just my opinion from working on over 30 projects. I’m not a researcher so I base my opinions off what I see in the real world. I definitely don’t have all the answers - just trying to share some things to help people hopefully think “big picture”.
Sorry if this one didn’t resonate with you. Appreciate you taking the time to give me some honest criticism!
Agile is good if implemented in the right way in project s..but it's a way to keep a check on developers especially in India..I like the channel name and I think young pple in IT will learn a lot from your experience.
Thanks Abhishek. Yes this is becoming more common in the US. I talked about it in my video “The Secret of Scrum Nobody Talks About”. Many companies are abusing agile methods as a micromanagement technique and completely missing the point!
No thought is given to design
No such thing as a real or fake agile team...agile isn't even a process.
Hey, your videos are awesome. Where'd you get that artwork in the background?
Thanks for the support! I don’t quite remember, but it was a print I found online. It’s a map of downtown Austin drawn in a whacky style.
@@HealthyDev oh man, no wonder it stood out to me, I live in ATX. Definitely gonna try to find that piece
@@HealthyDev lol reverse image searched a cropped screenshot and got it
Nice! :)
Relieved that you did not advocate any “evangelical” recipes, especially scrum. I’m still not satisfied with your answer to the “fake agile” question. The most important principles of agility are self managing teams (see ya later, scrum!) and incremental releases (constant value, which you brushed against briefly).
There are many signs you are not being “agile”. Are you following a process for the sake of a process? That becomes evident when the subject of process and its plethora of ceremonies overtake the topic of *how to technically deliver customer value*. Process as a religion also creates a great deal of acrimony within a team, and the “definition of done” can easily be used as a means to slow the team and squash creativity. Saw it with the team nextdoor and damn glad it was not my team! I actually knew of people going into a conference room to build a proof of concept to present at a future sprint planning. Why not? They were idle while waiting for code reviews and couldn't pull a "story" until then!
Are you planning the Taj Mahal when a shotgun shack will do the trick? “Sprints” can become building blocks for a massive project, and deliverables become overwhelming, and then the scope changes underneath. That’s not agile - that’s a recipe for failing slowly. A series of small waterfalls adds up to one big waterfall. Don't do waterfall. It takes engineering and creativity to produce value incrementally!
How much scope creep do you tolerate with tasks? Do you design something for one day, and it goes on for many more, and nobody calls it out? Do you divide the task, cancel it, or just shrug your shoulders?
If you are truly being “agile”, then responding to customer feedback is a given. You don’t need a “process”, per se. You need maturity (focus on customer value, not your resumé), prioritization (well-groomed yet flexible backlog), and the discipline to stay focused on short term deliverables that actually have value. If you have self-managed, frequently-releasing teams, you don't have to "go to the board" to deliver quickly for customers. Agile, right?
I like that you recognize the risk of cherry picking practices!
I talked about that in one of my other videos “Why Do Some Programmers Never Agree?”: ruclips.net/video/cqNBVrym3_U/видео.html
I also agree we shouldn’t do things just for the sake of it, they must be in service of agility itself.
I talked about that in my video about common agile fails.
ruclips.net/video/-WgQdHOx_hA/видео.html
However I stand by my points in the video. The reason why so many of the things you advocate are unpopular and management seem to sometimes even actively oppose them is because the project is funded and measured in a way that fights agility, and/or the leadership have no humility to expect the need to change (hence no feedback process).
The video I link to in the description gets into budgeting and it’s impact on the ability to be agile as well.
YMMV
To me, scrum (or possibly its most common interpretation of it) is a tried and tested way to burn out your programmers: everything is a sprint; there is no time for reflection, distance, taking a few steps back and considering. No, once one sprint is over, we go straight into the next one. Even the vocabulary of the thing is stress-inducing: backlog, sprint, velocity... brrr
@gwaptiva I hear you. That wasn't the original intention of scrum, it's just how it's being abused. So I don't blame you for seeing it this way - I have many times too!
Another video on the channel that talks about this (if you haven't seen it yet you may or may not get something out of it), is "The Secret of Scrum Nobody Talks About":
ruclips.net/video/B_ERfMMSAwY/видео.html
@@gwaptiva They should have burnout charts instead of burndown charts!
@@gwaptiva is that not what retrospectiv is for reflection on how it went ? What can we do bette do we need free play code days ect's?
I think we can flip the problem around.
Something like... "If the business AND customer knew exactly what they need and want...we could reduce the dependence on agile".
This would then shift the focus away from agile and rather to finding a better way of coming up with a solution that skips having to get the software out in small pieces and take constant feedback to improve it.
So, i essentially, work as a one man team for my companies web interactions. I have a very small beta group, 1-3 people tops, and they often give very little feedback. What are some good recommendations for expanding the beta availability and gathering additional feedback from regular users. I’ve always assumed I was following AGILE development, even though i was never taught it or had anyone else to tell me i was doing otherwise. Even though I primarily work with e-commerce and content management, we do continuously work on new features and functionalities for our customers to gain value from visiting the site - in theory, leading to more traffic and more conversions.
Motivate people by offering them something for their time, then have an open ended interview (I would keep it to under 30 minutes) asking what their biggest problems that your product solves are. If they are existing customers, ask them what problems they have with your product. If you want to serve more customers, you want to be able to describe their problems better than they can in sales and marketing copy. Features and benefits are great - but if the work we do isn’t helping them solve problems that cause pain, there’s low motivation to pay. This is different for a luxury product where the problem is a desire for status and prestige, but that’s another topic. I’m not sure what market you’re in so it’s hard to offer anything concrete - these are just some general things you might consider to help you steer investment in development towards the most valuable and profitable outcomes from your product.
Healthy Software Developer thanks for the response. I’ve tried surveys and other methods to gather the data over the years. I work for an HVAC distribution company, so we are completely B2B and most of our customers are busy, only interested in talking to you during their busy work hours, and are generally non tech-savvy, people (which is weird when you think about what they work with all day) so the customer adoption rate for digital interaction and sales has been slow growing.
I also have a lot of anxiety about dealing with customers face to face, lol. I’m not in sales, I left sales & marketing for the tech end of marketing by using code to run campaigns & other online initiatives for my company. Ive done sales, ive got a degree in marketing - so I understand market research - but sales & customers, no thanks, those are different hurdles all together.
@@RyanValizan understandable. We can only be who we can be. If you have a hard time talking to the customers, maybe you can encourage somebody else you have a good relationship with to do more of that for you and still get the input you'd like. Yes - motivating customers to discuss your product is a complex thing...
Healthy Software Developer thanks for the input. It’s not so much a product, however, but more/less another avenue to purchase. My primary focus is on the ecommerce end of things. I’ve set things in place to track user movement and search history, but it’s hard to know what they feel about it or would like to see or have access to with their account - these customers with accounts all have internal accounts, some with credit even, in our older ERP system as well. This is merging in the next year.
@@RyanValizan I see the dilemma, yes that's tough when you've got a product with a lot of existing features. I talked about in some of my earlier videos how when teams release several features at once, even if they have clear success criteria for whether a change they made achieved the business outcome they wanted, they don't know which change to attribute it to. That's even harder (pretty much impossible) when you've got an existing product with features built over a long period of time. Perhaps you can isolate changes to a single flow you want to test the impact of and reach out directly to some of those internal accounts - asking them to do some things that will take them through the path where you can get the data you need to know if what you're testing is reaching its goals?
The term Agile itself is counter-productive. It's like a brand with an imposed good reputation, with nothing special behind it.
Continuous early feedback, and iterative releases that add immediate value; I feel like I've been striving to do exactly that for the last 25 years, and now this has a brand name? How about a patent on the obvious.
when the features and patches that come out of your sprints are steaming piles of dog shit that noone is allowed to refactor .... that's fake agile
Does the entire team often got sick or high turnover?
Then that's true agile
Hmm... While I agree that customer feedback often should be done better.... I also think a lot of the talk about processes is so general that it misses some actual challenges for teams which are not doing the kind of work the speaker subconsciously has in mind.
As a backend engineer. The "customer" is often our selves. It rare that there is not some sore spots to improve in your infrastructure. So there's always something to do to automate processes, do better monitoring, testing, deployments, data safety, security, performance.
We always know one crucial thing which we're pretty sure customers don't like: "Downtime".
So being able to handle infrastructure changes without downtime or risk of "bad" downtime ... is always on the table.
Sure - that is often of little value to the product department. It brings no new features to the customer.... and that unfortunately often breeds a culture where stuff has to break and break hard to get that sort of work prioritized. - regardless of the amount of red flag raised by developers in advance.
I would say monitoring, testing, deployments, data safety etc. ARE of high importance to the product team.
The only problem is we don't always do a great job as engineers of tying the benefits to money. For example "Companies that had a security leak lost an average of 12m in lost revenue due to a loss in brand respect last year. If we don't care about data safety that's your call, but I'd hate to see all the features you designed this year not result in any rewards for you if we end up paying more recovering from a security disaster" etc.
@@HealthyDev Yes... but for many product-managers the metric is whether it put something visible to the user in production.
Will the user discover when it's rolled out?
Unless you have serious stability issues the answer is to that wrt. all those things are most often no.
... so ... many companies develop a de-facto regime where stuff has to break (and break hard) for important technical changes to get prioritized.
@@pm71241 I sympathize with your frustration, believe me. I personally feel these days though that it's up to us as software developers to teach product managers what is important to measure in addition to features and why. Much like we as developers aren't taught things like soft skills and dealing with politics at companies as part of our education, product managers often can't be taught enough about the unique nuances of managing a software product versus some other type of product. Yes in theory it's their job and they should know, but I guess I've adopted the stance that I'd rather take it as a challenge to teach them then just throw my hands up in the air. It's a difficult situation to be sure!
What difference does it make? seriously....... waterfall vs agile vs whatever doesn't mean sh*t
I’d agree if your only experience with agile has been fake agile projects (also sometimes called scrummerfall or waterscrum). When you’re on a really agile project, you’ll know it. At least that’s been my experience. Most projects claiming to be agile are more about pushing developers to produce code faster than they are about being able to respond to change. YMMV
Who set up that drum set?
I'm not sure what you're asking. It's my 1971 square badge gretsch kit.
I'm working different trade owner refuses to let me speak to customers at all. I said screw it I did what harden shit worker would do not give flip. So my observation if you can't talk directly to customers it's because your boss is lieing to them.
my company broke our agile team up into individual contributors and cancelled all the meetings. I feel duped. 🤭
I think I'd be more interested in establishing whether a team is doing real agile... In order that I can avoid them!
Ha! I hear you. Your comment says a lot about how badly our industry has f!$@ed up adoption of what agility really means…
You do not have to guess anything. Client makes specification containing what they need and if something missing its their problem. All you have to deal with are dead lines. Features are problem of client. Doing MVP is good idea but it has to be properly set up to make it extendable and scalable.
When you make product for masses then ofcourse its different story. But you do not have to deal with clients and dead lines.
ABSTRACT ART AND LOAD FEAR INDUCING DRUMS - HMMM SHOULD WE BE WORRIED?
they include "agile" in the description
“Minimum Viable” means that it provides enough value such that someone will PAY for it. Everyone is always willing to offer their opinion (for free) on how to change something….but that has nothing to do with an “MVP”.
Exactly. And the first release to customers often doesn't drive enough sales. That's why the MVP comes AFTER adaptation to multiple feedback cycles and releases.
In some constelltations, however, fake agile is the only type of agile that you want, because the full agile experience just doesn't work or would be highly inefficient. Think "do scrum with 2 people"
Full agile to me is a team fully able to adapt. Which usually means less process! Another video here that gets into what you’re describing (which may or may not be helpful) is “Scrum is the Motor of your Project, but who’s Steering?”: ruclips.net/video/9b0HgIdTDPE/видео.html
Unfortunately, with the popularity of CI/CD, you're saying "(continuously deliver) value" but I believe the original intent of the manifesto was "continuously (deliver value)".
I'm really dense this afternoon. Expand on this, what are you saying with the different emphasis? Thanks.
Unfortunately, that's not enough. It's "red-green-refactoring" not just "red-green". And all the real work is done on refactoring stage. The purpose of "red-green" stage is to check if your tests (even if they are manual) works correctly. Time-wise it's like 10% on red-green stage and 90% on refactoring stage. However! A LOT of companies tend to deliver the product right after the green stage. It 10 times cheaper and most investors and even customers won't notice any difference! But, if you go like that, each sprint you increase complexity exponentially. And by increasing complexity, you increase cost of every new feature. Exponentially. And after a year or 2 you will be in a situation, when you cant move at all. You will have to stop and rewrite everything from scratch. And while you will be doing that for the next year, your competitors will go further.
So.. if you are not doing refactoring since very beginning - competition is already lost.
True agile team have ZERO legacy code at any moment. If there is some legacy code - it's not true agile team. Even if it's just a tiny bit.
It is easy: Ask my team. We will tell you: no.
The company only want to have agile development teams, but not want to transform into an agile company.
So it makes no sense to use agile when anything outside the development teams are not agile.
I've been on agile teams over a decade and none were truly agile
Kind of shows you how badly it’s been adopted eh? 🥲
I hate Agile when there is a regular every day status meeting. You feel like a slave begging not to get fired (although I never been fired).
Once (or rarely more than once) a week meeting is enough for me.
You are complaining about Scrum, which is said to be an agile methodology. The agile manifesto does value communication, that's an important thing. But it doesn't say how.
This highlights some of the issues with agile if it's seen as an engineering approach only. There are a set of guidelines for designing a product that the proposed approach breaks.
1. Find out what the user needs, not what they want. Feature requests are too little too late. Reaching out to beta testers is too little too later. Instead, you should know if the product will work BEFORE building it.
2. Feedback is the worst kind of user insight. Usability testing, contextual enquiry and a bunch of other user and customer research tools exist that tell you what the user needs are before the design is done before a single line of code is created. Don't build to find out if what you built is right!
3. Customers often don't equal users, especially in the enterprise space.
In short - this is why agile fails. It's not user-centric enough.
BUT the idea of continual releasing is good but ensure you know what the user NEEDS BEFORE you build anything.
A gazelle is agile.
Thank you!
Awesome😎
This one unfortunately takes a bit more than 7 minutes, but a team that allows technical debt to sit around for years is a fake agile team.
Coconut Headphones
I play drums too!
Nice! They have been sitting in the corner of my bedroom not getting much love lately. I need to fix an issue with the floor tom so my wife can start practicing again (I was teaching her so we could play together). I haven’t played out for decades. Do you play in a group or anything like that?
@@HealthyDev no its hard to find the right people who want to play the same style. if anything i would do youtube covers
@@enersha I feel the same way. I just play solo and write little riffs and stuff, maybe jam with my kids or wife here and there. It's still fun! :)
@@HealthyDev I'm also a programmer but the job market is not so good
Sorry, I think you put too much false statements in you talk. Like for example about “before agile” era. For example, many teams in large and not so large companies don’t work in agile as written in agile manifest, more over some of them have CD and some don’t. And both of this approaches work for that companies. And some of them were doing this way before that manifesto. So, agile is just a tool, in some businesses it really shines and in some it doesn’t. It is way to bad to say that before agile was introduced teams and companies were delivering not what customers wanted because of too long development time.
I think I’m understanding what you’re saying here. I didn’t mean to imply that every company in business before the manifesto had this problem. I was referring to the industry overall, which is most companies in my experience. Hope that helps.
Nothing like a bunch of stale sporting metaphors to motivate a nerd like me 🙄
This one’s more for management - I believe many developers know these concepts nowadays.
@@HealthyDev funny how this stuff (minimum viable system first, emphasis on architecture, early testing, adaption to user feedback and suggestions, incremental and iterative improvement and continuous integration, ability to back out changes that don't workout, document everything) was all known back at least since the 1968 NATO Software Engineering Conference, and was discussed at length in the proceedings, yet somehow what most organisations seemed to get out of that conference was waterfall. Excuse me what?
It was 2001
Agile ruined my life.
Every single person involved in drafting "The Agile Manifesto" says it's all fake.
Agile is nonsense
For those in a hurry, he starts talking about the subject at 1:34, for those who need coaxing and spoon feeding just keep watching.
Definitely, 7 minutes is way too long. Thanks for encouraging them to skip that long intro 🤷♂️🙃