Agile Uncertified | Philosophy Over Rituals

[@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.

[@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.

[@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?

[@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

[@mikeryan2388]

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

[@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.

[@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

[@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.

[@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!

[@agremis]

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

[@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.

[@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.

[@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

[@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.

[@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.

[@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.

[@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.

[@IterativeTheoryRocks]

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

[@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!

[@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.

[@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.

[@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

[@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

[@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.

[@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.

[@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.

[@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.

[@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 🙂

[@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

[@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.

[@nomex9829]

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

[@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.

[@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!

[@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.

[@siyaram2855]

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

[@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.

[@krccmsitp2884]

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

[@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.

[@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)

[@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.

[@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.

[@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.

[@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.

[@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

[@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.

[@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.

[@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.

[@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.

[@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.

[@CarlosEduardoLeao]

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

[@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.

[@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"

[@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.

[@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.

[@mauro.orlando]

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

[@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.

[@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.

[@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.

[@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.

[@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?

[@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

[@rogerpetruki4759]

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

[@ContinuousDelivery]

My pleasure! Thanks.

[@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

[@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.

[@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.

[@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 👍

[@robertholtz]

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

[@abShar0705]

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

[@BboyKeny]

I'm worked with Agile as a software engineer many times. My problem has always been that we build al sorts of untested features and assumptions. Till we have a release batch. I prefer the Lean Startup framework. Since you don't just build a ton of assumptions, not knowing how any feature will be useful of detrimental for the user. Lean Startup let's you make as fast as possible a Minimal Viable Product and then test it with real costumer. Agile sprints together with Lean Startup, Lean Analytics and UX (User Experience). Then you have the philosophical and practical tools to make successful software company.

[@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.

[@DanielLiljeberg]

I was recently asked, along with a colleague, to hold an "agile fundamentals" type lecture. We explained traditional style projects and what agile was a response to. After that we told them about a lot of names, frameworks etc that they would probably meet out in their work life (scrum in particular did we show the main structure off), but stressed that those were not agile. Sure, they are used to facilitate agile practices, but it is the practices, the way of viewing and handling things that is actually the agile part. It is about how you as an individual think about and handle learning, discovery, transparency, why and value etc. Agile is more a way of being than a toolset. With that said, I like Scrum for instance. Why? It is very helpful when everyone speaks the same language and it helps facilitate the core fundamentals of the agile mindset. Everyone being "agile" and running around doing their own thing would probably negate a lot of the actual benefits we strive to reap the benefits of when we say we want to be agile. Besides the empirical aspects of agile I also think it brings with it psychological benefits for many individuals and teams. Something that I don't think we should underestimate. The growth I have seen in people when they feel they have more control over their situation and the added ownership that comes from developing your solutions to problems instead of just being told what to do is massive.

[@ContinuousDelivery]

Yes, I am happy with Scrum too. It doesn't say enough about engineering or software, it is a PM discipline not a SW dev discipline, so I prefer Extreme Programming, I think it has more profound things to say about the engineering of systems. For me Continuous Delivery is a second-generation XP process.

[@DanielLiljeberg]

@@ContinuousDelivery Indeed, probably why Scrum actually works in many non development scenarios :) But Scrum can be used as the overarching guiding "process", then you can use XP, TDD, Mob programing etc, during the actual development work. I think the important aspect with any process is to understand not only how we do it, but why we do it.

[@ContinuousDelivery]

@@DanielLiljeberg Yes, agreed! My real reservation with Scrum, is that it is too east to cheat, not that it is wrong. XP is more difficult to cheat, because it is a bit more proscriptive in terms of working practices. No CI == No XP!

[@defeqel6537]

@@ContinuousDelivery my biggest problem with Scrum is exactly that people who do not understand Agile abuse it, e.g. having the management fix both a timeline and goals, but then still push more work on the team in the name of being Agile. Basically forcing upon the team the worst parts of Waterfall and Agile, while limiting the benefits. I haven't actually tried Kanban, but I feel like it better reflects management needs while forcing them to prioritize requirements.

[@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

[@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.

[@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…

[@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.

[@chpsilva]

I agree 100% with this core concept of treat software development from a scientific point of view. However, customers would be less than amused with the impredictable timelines and higher costs that are typical of the scientific research area.

[@ContinuousDelivery]

This approach isn't slower, the data says that it is faster. I don't recommend "full on scientific rigour" but a more lightweight application of scientific style thinking.

[@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!

[@geiramk]

Thing with the alphabet is that it only works if everyone communicating speaks the same language. Pictographic writing is more work up front in establishing a common base of understanding, but then lets everyone understand it regardless of where they come from. Defining as much as possible as early as possible in a project gives a group of people from the business/functional side and from the development side a much better common understanding of the scope and complexity of what they're about to embark on. Less friction and more understanding as problems and (usually fewer) unforeseen changes inevitably turn up.

[@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.

[@jkuang]

Here is my experience with Agile Process: a) Daily scrum meeting (15 minutes only) works. It gives everyone the chance to make an issue visible and official. In many organization, an issue is ignored if it was just discussed in private b) Adopt 3 weeks or 4 weeks Spring cycle. Do not do 2 weeks Spring cycle. It is too short. c) Although we say that QA team will do the testing. The reality is that developers still need to get involved in answering questions from QA and fixing issues. It is not possible to "stack" the team. So instead, use 2 weeks for development and use one week for QA testing. This gives developers some times to "breath" and help out on the QA testing and fixing. So don't stack up! d) This is important: get rid of the time entry system you have. Instead, use the Sprint Points as your only trueth of work load. In many organizations, entering work hours is separated from entering Sprint points. Instead, only do Sprint points upfront. Each story is assigned a Sprint point (5.8 hours each). And be very serious and accurate about a Sprint point assignment. Do not inflate or shrink Sprints points to "fit" into your expectation and agenda. Once the Sprint Points are assign to the stories, use that as the authoritative mechanism for assignment. NO MORE SEPARATE WORK HOURS. SPRINT POINTS ARE YOUR WORK HOURS! e) For any task that you have outside of grooming session (be practical, it happens), create a SPIKE ticket and assign Sprint Points to it. Every activity is tracked as Sprint Points. Don't just do work without a ticket. This means, you should have only one or two Spike tickets for each Sprint. f) For a task that lasted longer than one sprint, the rule is that to break it down but link them together. But reality is that, most likely people will just change the fix version to move it to next Sprint. That is because it is quite difficult and confusing to have multiple tickets for the same issue. Don't freak out about it. This is reality. :)

[@ContinuousDelivery]

I have seen many orgs that look like this, I consider this to be the failure of agile thinking, because what you describe has nothing at all to do with agile principles, which are very simple, and are described here: agilemanifesto.org What you are describing is a kind of condensed waterfall process, not agile at all.

[@karsh001]

Really great video. If I'd present this to a leader. He (or she) would shoot me down with a 'I don't pay you to play around'. It is more reasonable, in my view, to point out to that agile is cheaper because you skip unnecessary controls and detailed plans that will just change.

[@ContinuousDelivery]

Well, I hope that it depends on the leader, but if they say that they are mistaken. The most succsessful companies in the world don't work by creating detailed plans, they work by inspecting & adapting.

[@LeslieMRichardson]

It is cheaper in the short run only. First, the number of failed projects has skyrocketed since 'Agile' was adopted. It is estimated that more than 95% of projects with over 50 people now fail. Second - the quality of what is delivered is far inferior to the results of older approaches ... this results in what is termed 'lost opportunities'. Harder to quantify, which is what the Agile gurus love - that way they can continue the capex/opex/budget obfuscation. The biggest success of 'Agile' is selling the Kool-Aid to management; that 'lack of planning' is the best plan.

[@ContinuousDelivery]

@@LeslieMRichardson Can you give me a source for those statements please?

[@LPFan33]

@@LeslieMRichardson This comment is full of shit. How would you even begin to quantify how many of those projects that claim to adapt Agile are actually properly adapting Agile? Read a few comments here and you'll see that a lot of bussinesses are improperly adapting agile because it sounds great to managers but in reality they have no clue, so they just hire some certified scrum masters and assume everything will be magically great. Spoiler alert: It's not in the scrum masters best interest for a team to be truly agile, because it would render their position obsolete.

[@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.

[@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?

[@MisterKorihor]

The issue that I have with Agile is the set of practices that are usually associated with Agile. I don't have a problem with developing software in an iterative fashion. In fact, I believe iterative software development is usually the correct approach. However, I don't like many of the Agile practices. Practices like: pair programming, collective code ownership, daily standups, unit testing, estimation poker, etc. Many of these practices only work well in a narrow range of conditions.

[@ZlothZloth]

{shrug} You've got to take your own situation into account. Daily standup meetings were a joke when our group consisted of me and my PM, who sat right next to me. When we added a team member in another time zone, they got a lot more interesting.

[@reav3rtm]

@@ZlothZloth I always considered daily scrum as very useful in... stopping devs from procrastination and that's it. When you need to tell everyone what you did and what you plan to do, it focuses your mind a bit and makes it harder to hide you are doing nothing.

[@sexygeek8996]

Daily meeting: too early and I'm still half asleep, so I won't remember half of it Pair programming: I can't stand having someone so close to me all day Unit testing: a necessary step that often gets skipped Management view: they can change requirements on a whim without delaying development

[@MisterKorihor]

@@sexygeek8996 The value of unit testing depends on the type of code that you're writing. For example, how well does unit testing work if you're writing a bunch of stored procedures and wrappers around those stored procedures? Or another example: How well does unit testing work if you're writing tons of UI code to do basic CRUD operations for lots of tables? On the flip side, if I'm writing tricky business logic that manipulates a POCO model, then yes, unit testing is useful here.

[@sexygeek8996]

@@MisterKorihor I mostly write code that does critical calculations, interfaces to other systems, gets called in multiple places or gets reused in other applications. Unit testing is very important in these cases. I leave UI code to the newbies.

[@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.

[@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' 😁😎

[@npkonstan1681]

Agile is iterative,good but waterfall can be iterative also.One of the problem with agile is that they think that will have the business people to collaborate daily! The other problem I see is the notion of Minimum Viable Product ,I will tear my hairs off,in what universe? In avionics? In banking? I medicine? Do you think everyone is creating dashboards or web-sites ? Forgot to mention I worked as a Mainframe developer,so take my words with a grain of salt.

[@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.

[@_iyalei]

I love that, especially the conclusion!

[@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.

[@chickenduckhappy]

Before alphabeths, there was Kuneiform, an abugida derived from prior pictograms. Kuneiform was around for around as long alphabeths have existed, with a long overlap. Kuneiform is an abugida because the Sumerian language has significant vowels. Accadian, a semitic language, following it, kept using the same Kuneiform abugida nonetheless, in a somewhat different way. In a parallel process, Egyptian (also a semitic language), also slowly shifted from mostly symbolic to mostly phonetic, giving way to the second alphabet. The first one existed in the levante for a short time. And it probably wasn't really the first but I agree that ours, originating from the Hieroglyphs, was the first to be vastly successful :)

[@ContinuousDelivery]

Cool, thanks for the information. 😎

[@pila1280]

For agile to work, it needs a highly cohesive and experienced team. The problem with most projects these days, are that there are too many inexperienced members from the high attrition and fast hiring culture.

[@ravenmadd1343]

In the multinational i work in we went " agile" overnight which amounted to heave reuse and rebranding of Waterfall. Over the year it's become more in line with Agile but at work we call it WAgile ( waterfall agile) because the company processed it to death.

[@ContinuousDelivery]

Also known as “Scrumerfall” 😖

[@michaelkirk4173]

"more complex things through agile" Meanwhile auto companies are assembling literally tens of thousands of parts built by thousands of companies.

[@Goohuman]

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

[@willd1mindmind639]

Agile originally just meant flexible. Back in the 90s and prior large projects required coordination among multiple teams and often involved complex systems including hardware and software. Waterfall was popular because you needed to have designs and APIs in place so that the different teams could build to those APIs. And then the system itself was the result of these multiple components working together over a network, without the web interfaces of java, http and so forth doing the middle ware. However, if the project you were working on was a smaller project such as something built on data entry (which was popular in the 90s) using DBase or Form Flow you likely did not need a huge waterfall project plan to implement. Also, waterfall was based on emulating the practices in traditional engineering and manufacturing where you first produced a design and blueprint before proceeding with manufacturing. Also, businesses liked waterfall because they care about schedule and budget. And waterfall often promised (and failed) to give an up front estimate of the time and effort required to build something. That has budget implications as you then need to hire staff and provide facilities for those folks to do the work over that time frame. This was/is especially true if you were a contractor building something for a third party based on a contract where they gave you a set of requirements and you had to scope out the effort and deliver a cost proposal. However, since the advent of web development, agile has taken on a new meaning as many apps and web sites can be built from scratch by a small team without a huge amount of effort. For those kinds of applications you don't need huge waterfall project plans. However, that does not mean you don't need requirements and you don't need design. Requirements and design are always the achilles heel of any project no matter what methodology you use to implement it, along with testing. That hasn't changed in software since there has been software. Also companies still care about schedule and budget and aren't just going to let folks just iterate to infinity without delivering a completed product. This is why most agile shops are micro managed because corporations want to see progress from day to day activities and deliverable items being produced. So they use the agile tracking software to generate reports and metrics they can use for management to keep track and report status. That said, most of the time, the agile teams are not really building whole new applications and platforms as opposed to maintaining existing applications and adding new functionality in smaller chunks. Also keep in mind that in the 90s software was delivered using CDs or floppies and you couldn't assume that there was some server somewhere running the application that could be updated remotely. Or if there was such a server, the process of installing and updating it was nowhere near as streamlined as it is now and involved a lot more work in the middle of the night, taking down the system and then doing the upgrade. The modern era of everything on the web with virtual servers and cloud hosting frameworks makes everything a lot easier.

[@cowhidemusic8904]

The real problem is that only 5-10% of the workforce is smart, creative and talented enough to work under Agile. Most people simply want a well defined task. Agile, at least from what I have seen, assumes that people will figure the task out. The leadership also does not budget for money or time for writing detailed tasks (user stories). I see it falling on its face!

[@plan.b2]

"Most people simply want a well defined task." On the other hand: Most customers simply want a well determined delivery time and cost estimation etc.

[@glennmorrow2755]

Um, surely not. Agile, surely, does not mean chaos - which is what letting 100% of your workforce do whatever they want would be. That would be crazy. Agile would be your designers, scopers, planners are sitting out in front and maybe a few key coders. They would be the ones on your cutting edge (this 5-10% of your workforce you speak of probably). Once they have worked out what works and what you want, then your main workforce is given simple and well defined tasks to implement that while the frontline tackles the next new thing. That's how you build stuff. Like ants are very agile, always checking out new things and opportunities but it is not the whole ant colony doing that, or certainly not all the time anyway, once a new area of development is found (by the scouts) the body of the colony comes in being very not-agile now and gets to work do very predescribed tasks, while the scouts are out looking for the next thing. But then if the body of works hits a problem the colony may go agile again while some of them determine what the issue is and decide on small or large changes and organise the colony to then work on that. Agile is co-ordinated agile surely, not just everyone being non-stop innovative. Mother nature has done agile for millions of years.

[@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