Agile Uncertified | Philosophy Over Rituals

[@driven01]

Sadly, I've been in so many agile projects that go south. Very few Agile projects actually implement agile correctly. People focus on scrum, user-points, grooming meetings. In short, there is so much focus on the process that everyone forgets that they are trying to build an actual product. I've been on a few where Agile was utilized correctly, but they are almost like a unicorn. In so many projects, Agile literally gets in the way as opposed to helping. And don't get me started on "fail early, and pivot" because most companies want to do this without building in the time for the course correction. They assume all of these design changes (even when they throw their "wish list" in there) come for free in both time and resources. It's borderline insanity.

[@jonjonr6]

My employer is implementing Agile, and wants everyone to learn and adopt Agile, even groups that don't develop or produce software. As I've been doing training, some of the things you pointed out have been standing out to me as ironically obvious issues. The whole thing preaches "individuals and interactions over processes and tools". Yet, it has a structure and process. It may be loose, but it's still there. And then it goes on to suggest that by throwing software out the door continually, you would be able to create and maintain a steady pace, as if designing, building, debugging, and completing all features takes exactly the same amount of time. I'm no developer, but I understand that some things take longer than others. I also understand pushing out software iterations just to push something out the door is bad practice. The thing that makes me most skeptical... Agile isn't new, but companies hear about it, or hire someone where it was being done, and it suddenly becomes this new magical solution. I'm not saying it's complete snake oil, but there's plenty snake oil in the commercial market. Someone hears this "new" great thing and suddenly, it's going to solve all the problems. And it couldn't possibly bring in it's own set of new problems. The emperor's new clothes. Even worse about Agile is it has a cult-like component, "being Agile". Co-opt some positive ideas that have little to do with process, and make it part of the gimmick.

[@steevmsteevm]

@@jonjonr6 "It suddenly becomes this new magical solution" is - in my experience - the real problem. As the video says, these are tools, not solutions. Tools are meant to make it easier to reach your goal, they are not the goal itself.

[@ian1352]

I hear this excuse for agile quite often, yet waterfall is regularly attacked by using examples of poorly implemented waterfall.

[@ian1352]

@@jonjonr6 Unfortunately agile may be intended to be loose, but things like scrum are very rigid. Just try suggesting that your team doesn't need one of the mandated meetings. Companies also assume that team performance must improve due to the magical powers of agile. When a team that was already efficient and delivering a quality product doesn't get any better management assumes it is because they're not doing agile right and starts interfering. At that point team performance plummets. There is also a whole lot of other nonsense that goes along with things like scrum. Like assuming that a team of people who keep their personal life outside of work can't possibly be working as a cohesive unit. The result is once again management interference to make them do group therapy style getting to know each other. And performance plummets.

[@driven01]

@@ian1352 I've been on far less waterfall projects that go south than Agile projects. Yes, you can f- anything up with enough talent. Waterfall succeeds (usually) because it based on phase line reviews to move forward ... and without a focus on ceremony.

[@gillianbc]

Sadly, in my experience of agile dev, the focus is on getting that task to ‘done’ as quickly as possible, even if that means building up a technical debt that is never addressed. Huge amounts of man hours in ceremonies, less time for productive work.

[@a0flj0]

That's a matter of culture, not process. Agile or no agile, if there's no culture that promotes quality and no understanding of technical debt, the results will be the same. One more thing: technical debt isn't what most people think it is. Technical debt doesn't mean shitty code. That's just bad quality. Technical debt is knowingly, intentionally making compromises in architecture or code structure for short term advantages - like a simpler implementation that performs worse for the sake of shipping a feature earlier, or some code duplication for the same reason - there's almost never a reason for introducing technical debt other than shipping faster. Making such a compromise doesn't mean accepting shitty implementations. Shitty code in a properly designed part of the application is not technical debt, it's just shitty code.

[@gillianbc]

@@a0flj0 Completely agree - you articulated what I meant so much better than I did

[@Reinfallt]

This is exactly my experience as well. The whole idea seems to be to close as many jira issues as possible in a sprint for the graph to look good at the end.

[@a0flj0]

@@Reinfallt That happens when the scrum master runs scrum, instead of the team running scrum, and the scrum master just assisting.

[@mlitkey301]

Technical debt is unavoidable. Today’s cutting edge code is tomorrow’s technical debt. A truly mature organization recognizes that managing technical debt is an ongoing part in tandem with new feature prioritization.

[@thsstphok7937]

Thank You. I think this is one of the most important life lessons. Make simple plans and adapt. Experiment, fail and learn. Eliminate hypothesis.

[@JohnSmith-ox3gy]

ImproviseAdaptOvercome.png

[@michaelnurse9089]

Test hypothesis or eliminate hypothesis?

[@revealingfacts4all]

Agree, but I was doing this before it was labeled as agile

[@UncategorizedContent]

In agency type work where you must send the client a bill for your time and you must bill enough time to justify your role, "experimenting, failing, and (possibly) learning" will be the summary reason given for your firing.

[@mehdi5738]

GG

[@nickmonks9563]

As an accidental Product Manager in a very small organization, this was an enormously helpful breakdown of a) what Agile truly means, and b) the kind of thinking that keeps you agile; avoiding the trap of waterfall thinking when agile processes will work much better to get to solutions. Thank you!

[@CookiesDarkMatter]

I’m a Scaled agile coach and this makes me want to question a lot of things I learnt. Thank you.

[@ContinuousDelivery]

Thank you

[@thehandofjibreel8756]

That's humble of you. Well done :-)

[@monkyspnk777]

Specifically what points were brought up that made you think that? Please name four or five?

[@CookiesDarkMatter]

@@monkyspnk777 one that left a mark was the whole “value stream mapping “, not treating software like an assembly line thing.

[@BittermanAndy]

Shouldn't you be questioning what you've learnt... always?

[@markpullan3202]

Putting aside specific methodologies, agile for me is about two important tenets (a) Fast feedback loops at all levels, allowing you to identify problems early and self-correct. (b) Assuming that the initial plan is wrong and the initial direction will change, and providing tools and techniques to help manage and communicate this. The main flaw with waterfall wasn't the up-front planning or design, it was the assumption that those were correct and largely immutable that caused problems.

[@georgebeierberkeley]

Been programming for 30 years or so. It took me 20 years to not fall in love with my code, to review these periodically without bias, to not get offended when judged, etc. The hardest lesson for me on the path agile programming was my own ego.

[@CallousCoder]

In the 90s, we just started to code based on meager requirements and we refined them on our way. And sure, some code needed to be scrapped and rewritten for a change in vision. But we always managed to deliver. Our software house was seen by the big sluggish competitors in the medical business as "cowboys". We were AGILE before it was a thing. Because our board members were all vets and doctors and when they can't design requirements to the fullest extend, as the intended customers, than who can? Our customers loved our user group days. Because they got to see where we are, we had concrete questions for them and they for us, as well as good constructive feedback. Unlike our big snooty English competitor, who just coded and released -- much to the dismay of their clients. They were 10 times as big as we were and went under. If they spend more time in listening to their customers and worked incrementively they'd probably heard that their product was heading in the wrong direction with each annual update.

[@johnshaw6702]

Fellow cowboy here. I laughed the first time I read about Agile programming, since I had never worked any other way. That's was the advantage of being the programming department for a small company. They did not care, or know, how you got the job done. As long as it worked and they could not figure out a way to break it, they were happy.😁

[@CallousCoder]

@@johnshaw6702 That’s cool to hear John! Yeah I guess small companies, just innately worked that way. We were also a tiny softwarehouse compared to the others. Another advantage of starting to work for a small company, is that you literally have to do everything to an extend. So you also managed the network, and talked to customers and heck even fixed things. I think that juniors should start at small companies, they’ll learn more than at FANG.

[@CallousCoder]

@@spleenware for sure Scott! Agile has become synonymous with “crap code and ready to scrap code”. CI/CD is the cause of this. Because delivering patches and functionality is easy. In the 90s when I made an update to the Animal Group Health analyses suite, it cost us 5K in floppies not counting the man hours producing the copies. So you’d Damn well made sure the code worked and was stable and you didn’t want to scrap it in a Next release because it took (far) longer to write.

[@spleenware]

@@CallousCoder Agree. I'm astounded at how much lazy coding is done. Rummaging around in stackoverflow for something that 'looks right', bunging it in, add any and all lib dependencies in, and hope for the best. The result is bloatware. Actually, I consider the entire Web ecology as bloatware.

[@CallousCoder]

@@spleenware I recently said: “if car manufacturers would make cars like software engineers make code, you’d end up with a new car every 12 months. And initially it would do 200km/h but after a year it hardly manage to do 80. And the windshield wipers would stop during a rain storm. Because it has a bug. And you’d be at the gas station inflating your tires every week, but it’s okay it’s an MVP! “You have rubber tires!”. It’s terrible where we’ve gone to.

[@ericweeks8386]

My company (very large) is proving to me every day that it doesn't matter what methodology you use if you have management who is clueless, it still goes wrong. Agile just makes it take longer, since we spend so much time in meetings. We're more worried about burn down charts, and not meeting that line on the graph, than doing good work. Thanks Agile/Scrum! Did you know every single software development problem can be solved inside of 2 weeks? I didn't. I guess my 30+ years of experience taught me nothing! And now, I have at least 4 bosses right over me, and all of their bosses as well...all wanting to meet to talk about the progress made/not made on their pet project, which is taking longer than it should (according to them), because the person who wrote the LBC has no idea how things work, and what other things will be affected by the new widget request. Design? No way! That's waterfall crap! We'll ITERATE until we get it right! Except, of course, when you're dealing with financial systems that move real money, not webpages that show pictures and comments, that doesn't work so well.

[@tuzaguilar4201]

Same here. Meetings everywhere. What I hate too are the Scrum Masters and Project Managers who has near zero technical capabilities and insists on interjecting their theories where the developers are discussing the solution. Total waste of time. The stand up is a little annoying at first but it does bring some value in getting everyone aware of what's happening. The Sprint planning with everyone including the newbie proposing a number to complex project? Biggest joke to me.

[@Meritumas]

Exactly! I feel your pain!

[@feasterfamine836]

Modern SDLC: 1) “Analysis” 2) Implementation 3) Denial 4) Anger 5) Depression 6) Bargaining 7) User acceptance - if failed go to 2

[@ContinuousDelivery]

🤣

[@kwkw5711]

You forgot blame for those at the sharp end and praise for higher management who contributed virtually nothing to project success. Oh and legal proceedings against third parties

[@piotr780]

no analysis all the time, so real responsibility for analysis goes to the leader of implementation, that means that leaders are so important

[@edwardcullen1739]

Ah... The old "Cascading hydric acid" approach we all know so well!

[@kwkw5711]

@Super Mario development in prod too I am afraid ie no separate development environment

[@amad-os8rp]

You make me want to learn more and be better every day. Thank you.

[@ContinuousDelivery]

Thank you, what a nice thing to say 🙂

[@agremis]

As a Chemical Engineer who became a Software Developer, I found this video particularly interesting and appealing

[@ian1352]

Proper waterfall never worked like. Waterfall itself was incremental. Timelines were dynamic, designs were updated, and software tested as pieces became available.

[@BryonLape]

Waterfall never existed in the manner the agile priests tout.

[@robertholtz]

I’ve been a developer and software architect for 30 years. I don’t believe anyone anywhere has given a better talk about the real need of a better approach and methodology for making great software.

[@TheBigBlueMarble]

Agile has the potential of being transformative, but it takes more than implementing a few rituals. The first "agile" dev shop I worked for interpreted agile to mean they had to do standups every day and did not need to document any requirements. That was it. That was what agile meant to them.

[@defeqel6537]

Sounds, sadly, quite familiar. Also, claims of doing Agile, but still micro-managing the teams WHILE pushing responsibilities to the team that are not the team's.

[@_Mentat]

I work there now! Agile has been disastrous for us. Being agile is good - but the endless rituals and ceremonies of Agile(tm) is corporate death; all creativity is killed. Innovation? Forget it. Only the Product Owner could "legally" do it, and he's got all the creativity you would expect of a middle manager.

[@driven01]

This!! Happens WAY too often. I can't even tell you how many times I've heard "we don't document because we use Agile."

[@Koyasi78]

Coming out of college when agile was hitting the scene i liked the idea. It sounded much like the work i had done in class...iterating through to a solution learning more of the whole as i go. Then i got to see it up close and all i saw was what you described. An excuse to have no structure at all and add more meetings in the calendar. For a long time i was against agile because of the corrupted definition and usage.

[@christian.mar.garcia]

@@_Mentat Agile is not a methodology, it is a set of values and principles for developing software. If you are following some project management workflow, then you are not using agile.

[@stricken5tein]

I've been combing the internet for weeks and this is the best summary of Agile I have come across (maybe even better than the Agile Manifesto). Someone can memorize the Agile Manifesto and still not really understand the most important core idea of agile, which is embracing inevitable unpredictability and change.

[@ContinuousDelivery]

Thanks 😀

[@scooble]

Pretty much the same with ISO9001, if you implement it badly, it's worse than not doing it all

[@deusEXmachinaV42]

The most ironic part of agile development- taking an agile development process and rigidly applying it.

[@imqqmi]

Agreed, agile isn't a pattern, it's the fluidity that allows you to change methods as the situation calls for. When agile fails, the team is stuck in a pattern and fails to adapt. People have a natural resistance against change as it takes energy and effort, and there's some fear involved of the unknown. It takes discipline to constantly detect if you're stuck and have to be awake and alert to see the best path open up in front of you. It takes some courage to step onto that path too.

[@koskarvounis]

Excellent video, full of wisdom! You know that something is wrong when you've been to organisations where the daily standups are made of 15 people... including the company's accountant

[@a0flj0]

I did work in a - still functional - team of 17, at some point. Then we split it up. But we never called in the accountant :-)

[@Krushard]

Yeah... in agile you'd split a team of 15 into 5 teams, cut stand-up time to 10 min, then have 5 plannings, 5 retros, 5 second plannings, 5 refinements and hire a few agile coaches as a cherry on the top, lol.

[@a0flj0]

@@Krushard 3 people per team is too little. Optimal is 5 people in a team. Some people researched this. Below 5 people are are too thinly spread. Above 5 the communication overhead becomes increasingly costly. Refinement is improperly called refinement - a more adequate term is grooming. That involves more than just making stories look better. IME, however, far too few people and teams recognize the criticality of backlog grooming. I've seen entire projects fail because backlog grooming was not done properly. If done badly, it can even impact overall system architecture, and when that gets messed up, everything gets messed up. The more focused a team, the less time is spent in refinement, retro and other scrum ceremonies. An agile coach should never be a long term participant to the scrum processes. If he isn't able to bring the team up to speed within a few months, he should be fired - he's worthless, scrum has to be done by pigs, not chicken, and an agile coach is a chicken to the extreme. The elephant in the room, with agile methods, IME, isn't scrum or agile ceremony itself. It's usually management that's external to the team. In order for agile processes to work, you need buy-in from management. If your product owner is just a proxy to the actual people with knowledge of the domain, or even an worse, an indirect one (for example he either communicates by email or in meetings directed by managers who are completely disconnected from the domain with the business stakeholders), if your scrum master is invested with the authority of a project manager by management, if architecture is prescribed by architects not part of the agile teams, if management insists on ceremony without having a clue about how to verify the substance, if organizational boundaries make proper continuous integration impossible, if similar organizational boundaries prevent teams from communicating directly and efficiently, agile methods are bound to fail regardless of what agile coaches you bring in, or how much money you invest in training your technical people for agile processes.

[@Krushard]

@@a0flj0 Ah, I see you're a bit out of the loop. You're walking on the edge bro, "grooming" was deprecated in favor of "refinement" because of american obsession with pedophiles.

[@a0flj0]

@@Krushard The pigs and chicken parable was also removed from scrum, and I still use it.

[@artsolano6762]

The best methodology that has worked for me has been a hybrid approach of Agile and Waterfall. We include project planning and architecture stories early in what we call a super sprint planning session. This step may involve detailed requirement gathering however areas that are less understood take a more agile approach at this point. They are set aside for a later super sprint. We then follow natural sprints that will eventually build towards the goals/epics defined in the super sprint effort. An inherent flaw in Agile is its inability to look above the trees. A major flaw with waterfall is its inability remain on the blue print that was so costly to develop at the onset. Departure from the blue print most often creates a better solution. The more experiences and repetitive the problem is however leads to a more waterfall influenced process in agile. You are going to do less steering and change when its something you have done before. One of the largest misconceptions in agile is that it speeds up software development. So many managers assume this. It actually slows things down quite a bit. It does however tend to give a solution that the product owners/market desire more. And in that sense, it does save time in producing a product that is optimized. Hacking a solution is always faster but risks rewrites and several versions before getting the solution optimized.

[@_winston_smith_]

Thanks for speaking the truth! Agile aficionados love to use the straw man of waterfall. That obviously never worked. Software development has always been iterative. That does not mean you shouldn’t attempt detailed architectural planning up front, even if you recognize the need to inspect and adapt. This is especially true when designing both hardware and software.

[@spleenware]

In both Agile and Waterfall, I've seen the same mistakes made. It's like an engineering company assigned to build a bridge, who plans it all out and embarks on the epic task, without making a model bridge first. I know we call this the MVP, but it's too often just an acronym.

[@CarlosEduardoLeao]

I was looking for content like this for a while. Thanks for all this knowledge! Your channel is full of very good lessons!

[@IterativeTheoryRocks]

Great video. As a 45 year practitioner of software development, I fully endorse this.

[@16randomcharacters]

There are two things that torpedo true agile in almost all companies. First, true agile means accepting some chaos, some lack of control, and that is antithema to the type of people that tend to start companies. Second, it requires a level of trust in the people on the ground to pull in the direction needed, and trust is not a popular concept in management circles. So instead of a flexible dynamic iterative process, agile becomes a rigid system for enabling micromanagement.

[@RevStickleback]

It depends. Too often it's brought in because management has heard the sales pitch of "*this* company brought in agile and saw development times drop 50%, and *this* company brought it in and saw defects fall by 60%" and they think it means if their company does it, dev times will drop by 50%, and defects will drop by 60%. When it fails to deliver those results, they assume it's because the devs aren't doing their jobs properly.

[@chrzan9608]

This is by far one of the best videos I've seen on the topic. I could not emphasize more how important it is to think agile! Inspect and adapt! All the tools around it are of lesser importance. It's the way of thinking that matters. How many times I've seen a Dev(including myself) just make an assumption that some part of their project will work how they've assumed, just to later discover that that part does not work like it was assumed. The consequences of over planning and over assuming are mid to large size rewrites, costly stuff. More experienced, agile, inspect & adapt kind-of Devs know in advance which part of the project they don't know or plainly - do not understand, you plan for that. You focus on that part first, learn & adapt so that you don't fall into a trap of finding something that doesn't fit with the rest. Over planning = assumptions = mistakes = rewrites/re-shaping = money lost

[@markemerson98]

spot on - to add: agile is often (in my experience) cherry picked - I am always still amazed at why 'conveyor belt' delivery is even used as an approach in the digital world... agile fits the 'unknown' much better

[@nomex9829]

Brilliant. I have never heard these ideas spelled out so clearly.

[@exfalsoquodlibet]

As a former chemical engineer (now software developer) I think I can relate to the process control parallelisms that you lay out. Controlling (in the sense of putting sensors and programming controllers) a transformation process that is well understood is profoundly different from controlling one that's mostly unknown. In particular, you need to generate more information and design more, easily reachable customization points that can make your system __converge__ towards a stable point. Waterfall applied to an unknown system is likely divergent: fundamental control theory says that, given a sets of inputs (i.e. scope/time/resources) and outputs (i.e. a released product), you'll have success in controlling the inputs (i.e. making a detailed long-term plan) if and only if you know perfectly the relationship between inputs and outputs (i.e. you understand the system perfectly); if you don't, you must approach the problem the other way around, by controlling the outputs (i.e. get data from a completed piece of work) and use feedback to modulate the inputs (i.e. review and adapt).

[@ContinuousDelivery]

I think that one of the interesting things about "information" and its control is that the answers are so generic. That is why I think that the stuff that I quote in this video, from the Chemical Engineers, is so interesting. This is just as applicable to information processes, like the development of software, as it is about the creation and management of chemical processes. Really interesting stuff!

[@Gravybagel]

I’ve watched a lot of your videos. This one is by far my favorite. I think delving into physics and infinity really put a lot of meat on the bones. Your finishing statement was a real cherry on top as well.

[@BrianLarney]

When I first heard of Agile, I was stoked! I thought, finally an adaptive approach that will lead to better software and quicker delivery. An SDLC that makes sense! Unfortunately, after more than a decade and through the efforts of several teams using a variety of tools, I have yet to see the Agile approach work successfully. Every time it seems to devolve into an elaborate task management system. Daily standups become little more than morning role calls reminiscent of grade school attendance. Each day, people go round the horn and developers report what they did yesterday, what they will be working on today and if there any blockers. In short order, developers begin to focus only on working toward what they can report the next day rather than creating solutions to problems. Details are minute and understanding the big picture goes out the window. Agile requires all players to participate. Sadly, I've yet to see that happen. Usually after a short time, the only ones left adhering to the process are the developers themselves. All other parties are interested only in the progress the developers make and people quickly lose interest in anything else the Agile approach has to offer. Meetings are canceled left and right, deliverables are king and tasks are meant to be completed daily regardless of their importance. Business folks stop participating too. It adds too much overhead to their day and just like in the the waterfall approach, requirements are slow to come. The difference is now we agree to move forward without actually knowing what is needed. Every time I read a paper about Agile or watch a video like this, I get reinvigorated by the idea. It sounds like an awesome solution to a variety of SDLC issues. Sadly, I've yet to experience an implementation of this approach that holds up to the promise it offers.

[@SteinGauslaaStrindhaug]

For me the standup nonsense has always been a minor waste of time (or major in the case those "standups" that goes on and on so I have to sit down in order for my hypermobile knees not to fail), where I say what I did yesterday (which is almost always something else than what I said I was going to do) and then think of something I might do next; which quite often is "continue working on whatever I was working on yesterday". Fortunately I've always been one of the productive developers, so my limited respect for The Rituals has always been tolerated, since I do actually make things work.

[@defeqel6537]

@@SteinGauslaaStrindhaug Where the daily standups help in my experience is getting engagement from the less experienced or proficient members, and especially for reporting issues or blockers. I don't mind spending 5-15 minutes a day for just those benefits. It's also prime time (after everyone's had their turn) to bring up sudden requirements changes or similar. The "what people have done, and are going to do" part isn't that helpful, except in those cases where there is something sudden or unusual about a task (e.g. the build server is broken, who is going to work on getting it working again, so that not everyone will waste their time).

[@SteinGauslaaStrindhaug]

@@defeqel6537 yes it would probably be useful if the standup was the only time we could communicate, but we're on Slack all the time anyway, and in the before times we were in the same room as well so communication is not exactly complicated. And usually if there is something important we've already said it in the chat or we wait until the standup ritual is over to do the actual talking in Slack afterwards, as it's awkward to do any real discussion with everyone listening and waiting for the ritual to be done.

[@defeqel6537]

@@SteinGauslaaStrindhaug Yeah, I guess it depends on the culture. Personally, I don't really put things in Slack / Teams, nor read it very often, and just make backlog items with the relevant information and inform the team the next day about it. I don't like to interrupt or be interrupted while focusing. I guess, the example of build server being broken would be an exception to that, as that should be fixed as soon as someone notices, so should be communicated ASAP, but other things can usually wait until the next morning (e.g. new alignment meetings with other teams, requirement changes, reporting a new bug, etc.)

[@WeWereEatingRotisserieChicken]

Truer words have never been spoken.

[@AllanKobelansky]

All great in theory. The perils are when your management want COB deliverables, all the while you being agile. *You* change. *You* adapt. But don’t change the slide deck you presented to management. Because that would hint at a runaway train. Then you JIRA the hell out of your discoveries. And don’t miss a sprint deadline. Because that would point towards a runaway train. And have everyone stand around explaining what they didn’t accomplish yesterday, that they hope to accomplish today. A group shaming process. A process that helps the manager determine if they will meet their next PID review. And to determine if she should command a “swarm” operation, because we all know 9 women can have a baby in one month. If all principles of Agile are applied, then you have a chance. If you apply three or four principles of Agile, I’ll call agile, but continue with waterfall, that’s a recipe for being part of another failed development group. Excluding the manager, of course.

[@Terrados1337]

So many people need to watch and understand this video! At the moment, I am fortunate enough to word independently. Being "agile" helps immensely by structuring workload and flow but also at a psychological level. Reaching small goals every day makes work way more fulfilling. I also witnessed how "agile" many companies are. A former coworker was so frustrated he told the bossman to just shut up and wait a week. He rebuild the entire project (3 months of work, 7 people) on another framework, documented everything, and quit. He said working on that team was as "agile" as Han Solo in Jabba's Palace :D

[@pugix]

Agile development came bottom-up from the ranks. It was a hard sell back in 2003, when I started to work on an Agile team. We just kept learning. I gave talks about the benefits of sprint reviews, automated testing, etc.. One important principle that you didn't explicitly mention in comparing waterfall to agile: batch size. Small units of work are key to agile. With waterfall you had a gigantic batch of analysis, another for design, another for 'implementation', and yet another for testing. Agile works at chipping away the batch size, so that all phases complete in a short time period and the product grows incrementally with each delivered feature having been through all the phases. Alistair Cockburn quoted Peter Naur as saying that programming is theory building. That is to say, what programmers do is to learn and create a theory of a system. I'm retired now and don't have to worry about whatever 'post-agile' might mean. Seems to me that agile is at bottom a set of principles that don't need to change much, but always need application to specific environments and problems in a continuous kaizen.

[@piotrd.4850]

There's nothing inherently agile in 'reviews, automated testing' and other practices.

[@tallawahh]

That alphabet thing was also a good example of making reusable components to be used across different projects

[@ContinuousDelivery]

Yes, I loved that example when I first saw it.

[@tallawahh]

@@ContinuousDelivery indeed, it’s kinda difficult for me personally to keep future projects in mind while I’m developing but reusable components definitely reduce development time

[@ContinuousDelivery]

@@tallawahh I think that one of the 'tricks' is to work so that your designs are nicely structured, so that they kind of "leave doors open to allow change" without overthinking all the ways that you code may be used in future. Funnily enough I am writing about exactly this right now for my next book. Fundamentally I think that this is about thinking in terms of managing complexity. We use modularity, cohesion, separation-of-concerns and abstraction to decouple our systems. We can 'encourage' all of those properties in our designs by the 'Testability' of our code, because it is hard to write tests for code that isn't modular, cohesive etc etc. I hope that my next book will give some useful advice on this topic (my hope is that it will be useful, it will definitely include the advice) :)

[@tallawahh]

@@ContinuousDelivery it sounds like a good read, looking forward to it. And keep up the good work 👌🏽 small but really impactful channel; so easy to stay engaged with ur content

[@errrzarrr]

@@tallawahh reusable components is not merit of Agile, this concept exists much before computing existed in other engineering. In software is the software Architecture that brings this concept to the field, certainly much before Agile/Scrum even existed

[@low_k0]

Thank you, you are describing the essence and the important differences of agile software development. Unfortunately, the misuse you described is something I've seen much too often in my career. One fundamental issue with agile concepts in established companies is that managers (e.g. project managers) are mostly only eager to have the inspect part without the adapt because the way they have been trained (economic, not scientific) adaption and change always produce loss. I think for agile to really take off in corporate scenarios some managers need to have a change of mind and need to be able to let go of the controlling and focus on providing good boundaries for developers to work in.

[@TheNoodlyAppendage]

Unfortunately many companies mistakenly think that agile means no planning. I hate having to explain to managers that a project still requires a design document and that they cannot just throw new features in without articulating them on paper or pdf in a change request.

[@siyaram2855]

Please make more video. I have never felt so much at ease watching a video related to Software Industry.

[@andydataguy]

I've been binging your videos for the last week. Newbie developer here. So thankful to have stumbled across your channel!! So much value and knowledge. So excited to purchase your courses (waiting until I grasp the basics so that I can use your course to better develop my first large project)

[@silentgameplays]

Nice video! The main issues are that,unless its a fairly new bootstrapped startup,basically it comes down to a bunch of Agile tools/practices slapped on/integrated with the Waterfall processes and crunches. You just replace PM with a PO to report to stakeholders,hire a nice Scrum Master to do standups every now and then,preferably daily,set deadlines for sprints and that's it. As a cherry on top don't forget to use some Atlassian tools like Jira/Confluence/Trello,as long as the product is being delivered on time,no one in the stakeholder or VP section of the company actually cares about Agile philosophy,the product needs to be delivered in the set deadlines.Currently there is no empiric approach that is like the goal of Agile,more of "let's use Agile because it is trending" with Waterfall model under the hood approach.

[@Greedygoblingames]

Some excellent points made here. "Agile" is definitely a term that is misused and abused in many businesses claiming to be agile without really understanding what that means.

[@ContinuousDelivery]

Thanks

[@perfectionbox]

Agile fails because at the start, software is small enough to easily change, but later on becomes large and stiff, allowing only the most superficial/inconsequential features to change, or those that were designed to be changeable (e.g. themes/skins/config settings). As a project evolves, managers receive increasing pushback on change requests and feature additions.

[@drop6597]

exactly. "This car needs to be an airplane now, our customers want airplanes. Why is company B's airplane so much better than ours?! Because we are launching a ford escort off of a ramp and throwing some wings on it." At some point if the software isn't doing exactly what you need it to do, you don't need change requests, you need to take it out back and put it out of it's misery.

[@nobilismaximus]

Agile is really chasing your tail for as long as you can until they that pay realize they are getting nothing and cut the strings.

[@michaelnurse9089]

Large inflexible engineering is usually created by large inflexible organizations. On the other hand, there are those who with 10x less resources beat out all competitors - SpaceX, Cray in the above video, Google search and so on because they are agile. If you are an inflexible organization you are going to injure yourself trying to do flexible things ( see the Boeing 737 Max Fiasco) - but conversely don't cry when you become the next Kodak, Blockbuster, Yahoo or IBM because somebody else was flexible.

[@MaxHaydenChiz]

Agile works fine. What you are talking about is poor operations management and poor organizational design: Problems further up the hierarchy. You get these same problems in factories that try to do lean or in engineering teams that try to use statistical quality control or accounting departments that try to implement advanced activity based costing systems. Agile can only fix problems within the relevant scope. It can't magically make a poorly run organization well run. Plenty of large legacy code bases have talented developers and manage to do large scale refactorings and design changes. But those are well run organizations to begin with. And so Agile works for them because it is in an environment where it can. If you are in a broken inflexible organization, no development process will work. It's odd to blame agile for this.

[@perfectionbox]

@@MaxHaydenChiz To be clear, I don't have a problem with an agile philosophy or mindset, but there's just something about Agile that makes most companies screw it up and use it to brazenly justify management nuttiness.

[@krccmsitp2884]

That's the most convincing and plausible explanation of Agile I've read so far.

[@Larry00000]

As a programmer from the beginning of time, we had no development process. Proposed systems were oversold with regard to both time and cost (mostly by vendors). This put a lot of pressure on developers, but it was a lot of fun working thru the nights because it was the newest thing. Wondering how a budget is developed for agile systems?

[@Proactivity]

I've worked in too many companies where the Dev teams wanted to implement Agile methodologies, but were too afraid to push back against the established processes. So they implemented a Frankenstein hybrid model where they renamed the Project Manager to SCRUM Master, forced everyone to stand up in the daily meeting, and declare themselves agile but mostly carry on as before.

[@ContinuousDelivery]

Yes, from my personal experience, I think that this is the commonest form.

[@rickwalters8553]

Hi, Dave… I’ve watched a handful of your videos now, and don’t agree with everything you say, and even believe you’re wrong about some thing… but I mean that as the highest praise: you reliably make substantive assertions and ask questions that promote review, analysis, and discourse. I.e., scientific debate over quasi-religious dogma. I’m learning from you but also, more importantly, because of you. Very important in the internet era, and refreshing… thanks!

[@mauro.orlando]

Never heard a so clever analysis of what agile is and what could be. Thanks!

[@RodLaycock]

Spot on Dave, food for thought. The worst thing i hear daily is that people state state they are doing Agile without really understanding it. They run a meeting at the start of a 2 week sprint, have daily standups and deliver a demo at the end of it. This is not Agile. the sooner non devs accept this, we the sooner we can demonstrate more agility. Many a meeting I have attended in which a feature has been deferred until later because of an unknown. Make an educated assumption, if its wrong amend just that assumption. That should tell the educated that this is not Agile and is Waterfall with Agile-esque ceremonies.

[@MagnusAnand]

This channel uses no of the modern video editing techniques, sound effects, animations... All looking for users’ engagement. Yet it provides invaluable content.

[@JohnSmith-ox3gy]

Funny how the new standard flashy, high energy and click baity videos have started to loose their advantage due to oversaturation. There is not always a single way of doing things right, but a plurality.

[@marcn6]

That's why the 2x playback speed exists

[@DrorF]

Very true! It felt weird at the beginning. Made me question the value of it. But when I kept watching, it seemed very valuable. Now I'm subscribed and watched several videos. I don't understand why this channel doesn't have more subscribers. Maybe it's because of the toned down style. Maybe it's because it's not that old.

[@antongromek4180]

Once more, i'm deeply impressed , Mr. Farley

[@TheJacklwilliams]

I couldn't agree more. He correctly points out that dev skills and even mastery are a small piece of the pie. The actual cycle, management of it, and processes/procedures to move through the effort should be front and center.

[@antongromek4180]

@@TheJacklwilliams I really like the Memorys of the good ol' C64 Days, when programming was still nice and easy😉

[@TheJacklwilliams]

@@antongromek4180 Now that, feels like a hundred years ago. The only thing it was missing was the web. I still remember poking in basic from the magazine article, saving it to cassette and runnin it. LOL… Having access to sooo much learning, that’s always been my favorite thing about the internet, even before the entire WWW debacle began…

[@abhilashbandi3866]

Learning and discovery. Brilliant. But management always want predictability!!

[@ContinuousDelivery]

Yes, but when they do, they are being irrational. It doesn't always help to tell them that quite so directly though 🤣

[@errrzarrr]

Is the pandemics of the measurability

[@mrspecs4430]

In other words they need to learn how to work with probability as we left the realm of deterministic processes.

[@BittermanAndy]

@@ContinuousDelivery ...and not just management, customers. They want to pay no more than $X and get the product they want (even if it's not what they asked for) in Y amount of time. Irrational, sure, but they're the ones paying the bills. I suspect this is in many cases an intractable problem.

[@DudeWatIsThis]

Management are economists, and so are customers. We are engineers. They are the dumb teens who think that they know better, we are the adults who _actually_ know better. We should be smart enough to explain the problems we face when building them what they're asking for.

[@adambickford8720]

Every single company I've worked for knows what features they want by what date(plus whatever features come up in the interim). Every single one of them also claimed to be agile.

[@LPFan33]

It's very sad isn't it. I have literally witnessed that bussiness/management person asks for estimation and then just takes the estimation given and sets it in stone as a hard deadline.

[@robertholtz]

7:24 - I find a certain unexpected perfection in observing that you misspelled “imperfectly.”

[@chortkeh83]

I think the issue is to embed agile thinking at the core of the business, that is to have business executives who not only respect agile in tech, but also think agile. Without it I still have to circumvent business to practice agile. Do you have any pointers to help me on this?

[@ContinuousDelivery]

I agree, convincing people is the hardest part, but I don't think that we can lay this only at the door of the business. Don't get me wrong, they don't get a free-pass, but in my experience we, developers, often blame the biz for our assumptions of the biz. Sure, a commercial person is going to ask for more sooner, but I think that it is relatively rare for biz people to actively tell dev teams to "cut corners", or "don't test", or "don't refactor", or "create low-quality work to make the dates". The problem is that it is always a difficult conversation to say "No" to people. So we tend to say the things that we think that they want to hear. So step one is, at least, taking ownership of the stuff that we should own. It is our responsibility to do a good job. It is not up to someone who isn't working on the code to tell us how best to write the code. So no estimates that give the "option" of not testing, not refactoring, not staying on top of tech-debt and so on. Next, I think that we need to speak to non-technical people in terms that make sense to them, not in terms that we understand. I think that an important starting point for this, is that we are being honest with ourselves about why we want to do something, and if we hope to convince others to change, there needs to be a REAL reason why we think that this is an improvement, and not just because we'd like to play with the tech, or it would make my CV better. Finally, the best way to convince people is to fix a problem that they have. This is a good topic, maybe I should make a video on this?

[@defeqel6537]

@@ContinuousDelivery Yeah, and I think being both honest and assertive about the state of the project, and the requirements, helps here. That said, everyone always seems to be about limiting their own work as much as possible, even when we try to create metrics to show both our progress and technical debt, those are never followed by the business people, even if they have been the ones to request those metrics.

[@robervaldo4633]

excellent; at 6:45 - "waterfall was such a bad fit for software that it only succeeded when people circunvented the process!" - I think this fits well with the tendency I see in IT to incentivize "hero behavior"

[@williamheymann8180]

I really liked this video. I don't like waterfall at all but I have also seen agile taken to such extremes by people that it creates problems also and I agree that a bit more design can be really good. From my own experience working with scientific simulations at least taking the time up front to figure out what math you need to implement, what the assumptions are, how you will discretize and solve it at a very high level make sense to do upfront. Trying to do that stuff as you go along is a disaster. I have seen systems fail because they just started coding and later realized the equations they wanted to use where not really compatible with the kind of solution method they had chosen, and a LOT of work was wasted, and it would have only taken a few days to solve that part in advance.

[@dougr550]

It's amazing how easy it is to change all the words but still do basically the same thing as what you were doing before. The philosophy is the knowledge you need to make it work :) Also interesting that Lean and Agile as far I'm concerned are basically the same thing. Small production runs, being to quick to deliver to market, and leadership values are all identical. The 14 Lean Management principles are my reference for the philosophy we want to follow when building strategically for business agility.

[@vadym8713]

It’s interesting how agile resonates with modern ideas of management and even philosophy. I’ve recently read ‘team of teams’ book which was written by army general and ‘Antifragile’ by Nassim Taleb and they are essentially about agile principles. 20 years ago agile was viewed by majority as some weird almost insane methodology and now it’s backed up by science. I’m impressed by this and it’s great to have people like Dave who shares what agile is really about

[@johnshaw6702]

I assume you mean the majority working for big companies. I worked for and with small companies 20+ years ago and most used what I would call an agile approach, at least when they were working with me. Then again, maybe they just adapted based on how I worked when interacting with them.

[@marna_li]

Software development is a complex social process with people who depend on each other. You cannot predict the exact outcome from the start since things change along the way. That is why agile works so well in producing a good outcome.

[@limwsv]

Part of the problem is that the founding members of the Agile movement reading/inspiration list cover only the Toyota production system. So they use the ideas like Kanban and so on and apply the Toyota LEAN approach to software engineering. The truth is that already back in 2006, a book call The Toyota Product Development System describe a methodology better suited to software engineering. Software engineering is a creative activity and requires a creative engineering apporach.

[@johncasey5594]

Some of the best projects I have worked on were ones where there was just me as the developer and a subject matter expert, that's it. Other projects I have worked on have had me as the developer, a DBA, a project manager, a stakeholder, etc. Endless meetings after meetings, people trying to look busy creating documentation, specs, etc. and then having meetings to discuss them and each revision based on the last meeting. 50% or more of your time is blown in meetings. My other favorite thing is when your boss wants something done faster, so he offers a non developer for you to use and expects that will allow you to complete the project in half the time.

[@Goohuman]

Found your channel and am very pleased. Thank you for sharing your knowledge.

[@doog535]

After almost 25 years in software development, I've seen Agile fail (or enable mediocrity) multiple times. I don't believe this is because Agile is fundamentally flawed, but because it allows humans to procrastinate. Rarely have I been at a company that actually iterates back over its code. Rarely have they actively solicited and acted on input. Typically, the parts of the code that are not fun to write, like robust exception handling or parameter validation are pushed off as not part of the MVP but "something we will work on later". Later rarely comes. Another issue I've seen is developers use the excuse that they can't anticipate every issue to avoid doing any engineering at all. I've repeatedly inherited code that is not scalable, performant, self healing, supportable, etc. Engineering is about taking what we have learned in the past and not making the same mistakes again. Yet I watch Agile developers paint themselves into the same corners that we did in the 90s, because they are trying to find the simplest (not the best) solutions. Every development methodology requires oversight, but some need more than others. Agile requires a strict adherence to philosophy ... MVP is functionally limited but fully implemented, feedback is actively solicited and analyzed, code is iterated over and improved and expanded .... but in my experience that rarely happens. For all its flaws, I've seen waterfall force developers to create robust, performant code.

[@ClaymorePT]

> Rarely have I been at a company that actually iterates back over its code. I have never seen this happening except when the code fails and needs to be refactored. Management does not care about iterating back. They don't understand that. What they see in that process is that the previous iteration failed because everything that was supposed to be done, was not. If the features are implemented, management will never want to go back because that means that: a) either the implementation is not complete and the devs lied; or b) devs wasting time trying to be perfect and improving beyond what is required. In these companies, Agile fails because management wants their Scrum not Agile, and this is the problem. Management wants tasks to be done and never go back. They don't want library updates. They don't want framework updates. They want code to be written once and sold many times until no one wants to buy it.

[@robertkelleher1850]

Our organization is starting to convert to Agile and Scrum. We were told this yesterday. HELP!!!!! When to use Waterfall - Requirements are well known with little uncertainty - The work is repetitive - Working with well-known tools - The project is short When to use Agile - Uncertainty around requirements is high - Product has high end user interactions - Requirements need to be prioritized - Time to market is key

[@buddysnackit1758]

I worked on a team that was all ritual vs philosophy. Insistence of using the "poker" number unassociated with hours. I always used hours in my own head because that is how I think. My estimates were always listened to more carefully than others. I usually was a low number or a question mark. What did that mean? It meant that I either knew how to make the software or I didn't. If I didn't then making a long term guess was never a thing for me. LOL....the beginning of infinity? I know the answer. I wonder if he did. The beginning of infinity is now and here. Why because there is an infinite past and an infinite future. When you go from past to future you have changed states and defined the end. Same with forward and backward or up and down.

[@WarpFactor999]

I led one of the largest scale agile development efforts for one of the world's largest companies for several years. With a few changes after I took over, we had 12 successful deployments in a row with no failures. (We had 14 SCRUM teams spread across three countries.) This was on THEE most critical software for the company. This was a company wide record (one in a row was the previous record) and received a president's award. So, yes, agile can be done at scale for large scale critical software, but it takes a dynamic model that has 100% company buy in. When it works, it's a rocket sled ride on rails. Previously, it was nothing but a crash and burn, and is frequently the result when companies try to "go agile" but don't understand what commitments are required. Second, there are things that need waterfall development, such as back end services and support functionality which have to be delivered as complete packages. Once that is in place, agile can add functionality to that base. Trying to do both using agile is usually a big mistake.

[@JamesChurchill3]

Colin Chapman of Lotus once said 'Simplify, and add lightness'. I think this philosophy can help with software too, when you take away everything that doesn't add to the end product, you end up with a much more reliable, maintainable, and modifyable end product.

[@ContinuousDelivery]

Yes, good design is when you can't take anything else away. Elon Musk says "the best part is the one you don't need" kzbin.info/www/bejne/rGnJZ6Rqp9qpmtU

[@JaumeSabater]

Brilliant talk. Absolutely brilliant. Bravo and thank you!

[@ericpmoss]

I f'ing hate Agile (tm). Like any other religion, it starts with some guy saying "hey, there's this Golden Rule thing, check it out" and ends with a professional priest class, televangelists, and an Inquisition. The original Agile guys have abandoned it for this reason, and would themselves be outcasts in the modern control-freak managerial system.

[@samueljaworski5737]

This is exactly how I feel

[@Meritumas]

The worst is so called "Corporate Agile" BS, where the most important is a bunch of middle managers, scrum "maister", points and "Scrum Ceremonies". I am sick of it. It kills developer productivity, dialog between teams and customers and successfully demotivate engineers.

[@dmlled]

04:29 the good iconic guitars!

[@abShar0705]

This is probably better than a CSPO certification, subscribed sir. My regards to your content, articulation and experience

[@einatkatz9122]

Can you publish these lectures as podcasts?

[@NorthernRealmJackal]

I'm always happy to see software dev. experts and vloggers take a critical look at the strengths and weaknesses of agile (and faux agile). But my main issue is that no one talks about the decades of research on design-processes already done within human-centered ixD and UX in general. In their current state, it's a well known fact that most agile teams don't mix well with dedicated designers (I believe NNGroup have articles/videos on the issue). But if we could invent workflows in which they did, we could leverage the flexible value- and solution focused methods of ixD, Design Thinking etc. in software development. Essentially, interaction design seeks to do the same as agile dev., but it does so through paper, post-its, mockups, anthropology and end-user data - and thus works much more efficiently through its iterations compared to agile, which is build with an entire functioning, QA'ed and deployed product in mind. And that makes it harder to pivot. Agile should seek to maximize the amount of knowledge gained per hour coded. And since coding, deploying and collecting (lackluster) feedback, isn't always the most efficient way to gain knowledge about a domain, we should probably code less, and integrate better anthropological processes alongside the coding. I don't care if you expand your profile or bring in specialists, but good code is (by itself) useless to our clients. Software has to be matched with and shaped by end-user needs and values.

[@MrSebastianJOh]

Wondering how Agile approach helps with a project with known scope, milestones and budget.

[@keinlanz]

It doesn't. But the fallacy is going into complex software development believing you can perfectly define and understand scope and milestones before you even even start building.

[@piotrd.4850]

@@keinlanz That's why you don't go there :D Simplify above all.

[@ddanielsandberg]

I hope Dave doesn't mind me plugging one of Dan Norths presentations "Why agile doesn't scale and what you can do about it". It is primarily about how "agilists" and business talk past each other and how developers need to stop focusing on technical things and "standups, burndowns, burnups, userstories, storypoints and ..." and taking a more holistic view and understanding of the business. Organizations tend to end up in a vicious cycle where they restructure the organization and hire a new CEO/CIO/CTO every three years and start over, while all the senior developers, PMs, etc just gives up, sighs and leaves for "something better" and all the lessons learned are forgotten. Agile (and CD) affects the entire organization, from the sales people to CEO/CTO/CIO to developers, HR and training. Without this understanding, no process or methodology will make much of a difference in the end. kzbin.info/www/bejne/fGXFkICZoL2Yl5I kzbin.info/www/bejne/Z37IlY2Jqc50hsk (better audio)

[@ContinuousDelivery]

No problem, plus Dan is an old friend 👍

[@BobFrTube]

In the 1960s my approach was to knead code rather than writing it. I remember one day I was about to write a program out on paper and realized that I could just start typing in code and expanded it as I understood what I was doing. As to the alphabet -- the story is far more nuanced because pictographs never really worked well but we like rebuses and used for their sounds and cultural references.

[@rogerpetruki4759]

Another masterpiece from my fav YT channel. Thanks Dave for sharing such a brilliant content.

[@ContinuousDelivery]

My pleasure! Thanks.

[@porky1118]

So "Agile" is just the way, most/good programmers already work, but in order to let the programmers work, how they work most efficiently, in more traditional business, you need a new term to convince them. Did I get that right?

[@MichaelLehnGermany]

Totally agree. E.g. you can learn how in math a complex system has evolved that is still maintainable and expandable. And even if some might disagree, this is system is still teachable to the next generation. Also it is notable that the mathematical discipline shows how a general system can evolve and origin from a special case.

[@defeqel6537]

A very nice video, and I especially liked the last few sentences on evolving agile, although I sincerely hope we are able to combine the engineering approaches to improving agile with management requirements, as the latter tends to be the reason most of us are stuck with faux-Agile processes.

[@ContinuousDelivery]

I hope so too!

[@myronww]

The most proficient teams use a hybrid approach. They use iterative development to allow for right size scopes of work and include some elements of waterfall to inject process into the release cycle.

[@ContinuousDelivery]

I am afraid that there is no evidence to back that assertion. In my experience they definitively don't do both.

[@truthseeker3740]

Unfortunately fixed budgets stand on the way of proper agile development, especially in government projects where a certain output of functionality is expected within defined budget and without which payment is withheld.

[@piotrd.4850]

Because - surprise, surprise ! - NOT EVERY PROJECT REQUIRES Agile.

[@engineeringoyster6243]

One of the many compelling arguments against Agile is their use of juvenile names for the various processes used in Agile. Scrum is a compelling example. Anyone who is familiar with the game of rugby knows the essential elements of the scrum that starts play. A rugby scrum is a brutal and violent physical combat between the two teams. Serious injuries are common. I've worked in technical fields for almost half a century and most of that work has been on teams and in groups for most of that work. Working with these smart, capable coworkers is universally an experience in respectful cooperation. Very much the opposite of a rugby scrum. Thus, I tend to discount Agile because a fundamental component of Agile is called a scrum. Words have meaning and turns out that an Agile scrum has almost no similarity with a rugby scrum. Which begs the question about why the founders of Agile choose the noun scrum for this brief, daily coordination meeting. I conclude that they must have an immature view about life in general and work and software development specifically.

[@ContinuousDelivery]

"Scrum" is not a fundamental part of agile, it is the name of one common version. Extreme Programming uses the term "Iteration" for a short fixed time-scale piece of work (what Scrum calls a "Scrum"). I agree with you, I don't like the terminology of Scrum much either, and I sometimes joke that the only reason that Scrum is so prevalent is that it is the easiest agile discispline to cheat at.

[@_Mentat]

Agile has ceremonies, rituals, artefacts and banishes people who point out its flaws -- it's a cult.

[@engineeringoyster6243]

@@_Mentat Yes Agile certainly does. And, you have to be part of the In Crowd to know all these inane stuff.

[@BittermanAndy]

Like sprints that are immediately followed by more sprints then more sprints, as if it's possible to sprint a marathon! Terrible nomenclature. And let's not get into the pigs and chickens guff that some Agile practices espouse. So much of the religion that has built up around Agile doesn't even make sense. Agile itself does, sure. But the practices and implementations and religions and ceremonies and rituals... not so much.

[@btmillack21]

There are three limitations to agile development in my opinion. 1. Stakeholder Stakeholder want to know what they are getting at which prize and in which quality in advance. An open "inspect and adapt" will not be able to fulfil such a goal without planning. 2. Communication If you have a problem that you can solve with the typical 5-7 people team , all is fine. But this is not scalable. As the problem grows you need more teams and you are loosing out on communication. There must be no free inspect and adapt, as the neccessary coherence between the teams will fail. 3. pyramidial structure of solutions As you do not know the final result you have to start with assumptions and go from there. Inspect and adapt will help you to correct mistakes in these assumptions. But this becomes more and more difficult if you move forward. After some time (in my experience after half a year to a year) you will no longer be able to correct fundamental flaws you build in at the beginning. Instead you are beginning to compromise. This can even lead to failure. In order to prevent such a situation you need to plan in advance. Agile works best in well understood problems.

[@johnguerriere]

Well done Dave. My new favorite channel!

[@ContinuousDelivery]

Thanks for watching!

[@christian.mar.garcia]

Some people think that agile is a methodology, but it is a set of values and principles for developing software. The main value is to embrace change and to use some core principles like testing and deliver business value by focusing on the product rather than on project management.

[@JanMagnusson72]

More than 10 years ago, I started to note thatt most agile implementation projects that I saw were "cargo cults". That is, the practitioners adopted numerous rituals that mimicked successful organizations, but never really understood what made those rituals work.They implemented scrum boards, daily stand-ups, new roles and procedures. But what they did not do was ensure that they could work iteratively in ever smaller steps of "inspect and adapt". They did not understand that it was the small iterations and the ability to inspect and learn from them that was the success story, not the rituals, and since they didn't change the fundamentals, the rituals basically became new names for the same waterfall-y process that they had before. They did not understand that it was the small steps, the continuity of the agile approach that was the secret sauce. But to implement that, you need to work much harder, perhaps not with the processes and rituals, but with your product and engineering culture. Refactoring existing products so that they are possible to deliver in small increments. Refactor your team structures to support this. Implement vertically aligned products and organizations instead of horizontally layered structures. This is much, much harder to do than to re-brand your processes and so rarely happened. Agile and in particular Scrum, became brands rather than actual ways of working. To me, to be agile means that you continuously inspect and adapt your product, processes, organization, culture, ways of working, tooling, and so on. If you simply implement scrum rituals, pat yourself on the back and say you're done, you got it wrong.

[@ContinuousDelivery]

Yup! Agile, or rather Scrum, won the marketing war. These days most orgs claim to be 'agile' when they are not. I think that the agile ideas were the right ideas, but did not survive mass adoption very well. So we need to find better ways of helping people to get the benefits. I think Continuous Delivery is better than most, because we are a bit more proscriptive. If you can't create something releasable at least once per day, it is not really Continuous Delivery. Now, try and do that without being genuinely 'agile' 😁😎

[@normbograham3]

One side effect of Agile, is actually too many chiefs. The scrum master, is one more boss, that wants to expand his authority, yet, is not the client, not the architect, not the project manager, etc.

[@iokwong1871]

This is one of best video on agile around, and as mentioned many videos on this topic are simply one big misconception around the concept. Focusing too much on the top or style being one of the most common one. However, there's one part of the videos I whole heartly disagree. That's "alphabet is a big step forwar from pictographe." The reasons can go on, but let's make it simple. Alphabet is simple just an idea that grown. In comparison, pictographe, or even objectform is not common use or grow more than Alphabet. And how these high dimension form of language can grow into infinity is simple not being explore. We might just be living in a time where these are form of language don't have the best distribution means avaliable, not to say such situation can't change. Imagine 400 years ago, someone said, "Oh~ math is just good at counting, It can't be use to decribe the universe～“ Again the lack of advancement of an idea doesn't mean the idea don't have the potential. So what's this mean to Agile? Current Agile concept is only focusing on one goal. and faulty idea is only faulty because of its relationship to that goal. And this is also where Agile start to fall apart, especially when it is apply to a large co, where a huge number of Agility is happening, and there no way to linking them.

[@richardjafrate5124]

Since I was a little kid, in the 1960s, my dad always told me that if I wanted to do something that I should just start doing it and learn along the way. He said "If you wait until you know how, you'll never do anything."

[@evanharris1212]

Hi Dave, great video, thanks for posting, I really value your thoughts and perspective on software development. I've never read anything about post agile so i'll have to dig into what the current state of thinking is. I had one question about a comment you made in the video, why do you think what comes next should be more prescriptive than the current state of agile? Is it so we can avoid the ambiguity and arguments in how agile techniques are implemented, or is there a larger philisophical reason you think we need more definition? Keep up the good work.

[@ContinuousDelivery]

Thanks! The reason that I think that what follows probably needs to be more proscriptive, maybe more specific is a better word, is because while I think that the ideas of agile are correct, and that it was a huge step-forward for the industry, the problem is, as is true of all popular ideas, is that they get watered-down as they spread. The "post-agile" people say that agile was a failure, when what they really mean is that if you apply agile rituals and treat it like some kind of religion with magic words like Scrum and Sprint, then it doesn't work. One of the problems with agile, in terms of adoption, is that it leaves a lot down to individuals and teams. This is for very good reasons, high-performing teams ARE autonomous! But they are also very disciplined, autonomy alone isn't enough. So I think that what comes next could improve on agile, not by changing anything at the level of the "agile manifesto" but by being more precise about the guide-rails that steer teams towards what really works. For example, I'd put the metrics "Stability & Throughput" front and centre. "Do all the stuff that it says in the agile manifesto, but measure your progress with Stability & Throughput". "Stability" measures the quality of our work, "Throughput" measures the efficiency with which we can create work of that quality. These are almost impossible to cheat. So it is not good enough to stand up during meetings and to call two weeks worth of work a "Sprint" to declare success. You are successful when you can improve the quality of your work and work with more efficiency.

[@TheoWerewolf]

Agile is a wonderful solution to a specific set of problems - the ones it was actually crafted to solve. The problem with Agile is that it's become kind of a religion with its advocates trying to cram it into every possible situation even when it just can't work. Worse, they tend to promote a very specific, unironically rigid interpretation of Agile and so miss the basics that are right in the name of the approach: being agile.

[@petermanger9047]

You can nerd out as much as you want!

[@ContinuousDelivery]

😎 be careful what you wish for 🤣

[@jayak3768]

I am not really sure how we got the term waterfall. Software apps I have worked on are mostly iterative in nature. That is the features are developed in phases over time. The software takes different iteration before entering a phase of maturity. And then it degrades again, because business ask for changes and modifications for which the software was never designed and there are overlapping or contradictory concepts or flows implemented in the software without fundamentally fixing or rearchitecting.

[@nordicgardener]

I tried to discuss with the Agilestias in a factual manner, but failed every time. It took me a very long time to realise that their basic principles was not in accord with mine. I have always thought that also SW should be developed with basic engineering principles as guidance, as this has been proven for hundreds of years. But I came to realise that the Agilestias I worked with saw themselves as craftsmen. I tried to convince hem that that was an old ineffective paradigm to use, and no other technical discipline used it since hundreds of years. But they continued to claim it isn't possible to develop software like cars, buildings, roads etc. In desperation I said that "Agile is a total capitulation to complexity." They just called me old fashioned and continued with "what everybody else was doing" in almost an extatic religious manner. I eventually resigned and have not regretted it.

[@maverickvideos9122]

How does a truly empirical process deal with Budget, Timing and Quality?

[@Sgt__Hawk]

I absolutely agree with everything you said. On an empty playing field this probably is the best approach to new and innovative software. But how do you budget agile projects?? Even the most coarse effort estimations are bound to be wrong with this approach. So how do you put a price tag on a customer project before you started implementing it (if bidding for a tender for instance)? I guess this lack of predictability in a business context is the major reason many companies fail to embrace agile development (in the sense of this video) completely and try to make it as "waterfally" as possible while just maintaining the agile rituals to mollify the developers. I'm sincerely interested in your feedback on this.

[@Sgt__Hawk]

Well, never mind. Just found your video on it: kzbin.info/www/bejne/rGOUm5purMdkm7c

[@unfa00]

Enlightning! Thank you!

[@iampuff7]

The problem is that agile is intrinsically a participatory framework and most companies still operate with management imposing the compromise on the team when the compromise should be owned by the team

[@Monzy_]

Which companies exits that practices actual agile development? I’ve only heard about Spotify.

[@ContinuousDelivery]

Lots, nearly all of the big web companies, Facebook, Google, Amazon, Netflix. But also Tesla and SpaceX. Capitol One bank, NY stock exchange, Volvo trucks and many many many more.

[@SuperTalentedRipley]

Do some reading on Disciplined Agile, from the "makers" of PMP. I believe it attempts to take on the "what's next" for agile.

[@Tips-r-us]

i prefer to look at it as a production line for code, where the code is Agile, but the effort is the production line that we call CI or CD.

[@Fiascopia]

Yep, the sprints are the production lines that have repetative behaviours but the thing being produced changes every run.