What people mean by "The Agile era is over" is that the training market is over saturated, so now the snake oil salesmen need to come up with a new and shiny buzzword to lure Manglement into buying into their niche And the other camp is devs that are fed up fakegile and want something that actually adheres to the principles.
Software Engineering is still the most dependent Engineering practice on decisions from people who are not Engineers. That's why we get fucked over every 2 years when the new shiny "bullshit bingo captain" comes along to tell us how much better something is, without prototyping or testing assumptions first and weighing trade-offs of the new thing.
@@morgadoapi4431 There are a lot of people trying to make money on selling coaching on a slightly different way when the way you were coached on before didn't achieve the magical results that were promised. Thanks for reminding us of this challenge.
Excellent video! Quite so many golden bits incredibly condensed here. Felt compelled to rewatch and create time-stamps of favorites: @0:19 At its heart, agility is about learning @0:26 If we can improve on agile, what would post-agile really look like? @1:50 The 4 values of the Agile Manifesto @2:15 The 12 principles of the Agile Manifesto @3:14 Post-agile is really a misnomer @5:00 From Scrum: "Inspect and Adapt". @5:23 Agile closely aligned with the fundamentals of science. That's why it works @5:35 Scrum: easiest to cheat. @6:18 Einstein's quote on the definition of insanity @6:51 Build on the idea that the roots of science are also the roots of agility. @7:00 The most agile approach to agile thinking of all is to think about how we can improve upon it (
I was very early adopter of Agile methodology, way before it was mainstream, and already then we noticed the fatal flaw with the Agile manifesto in practice: the customer. Every time it broke down due to either customer not understanding why they should commit any of their staff’s time to the project, or even if they did, it was either a person who couldn’t give valuable feedback or didn’t dare to due to limited authority. Then in cases where the person would have had both, they couldn’t commit to semi-regular meetings either due to unexpected more important issues or lack of interest
Many years back, many orgs I saw felt agile, teams with few devs using burn down charts, trying things, feeling quick to learn/adapt. The last few years? Feels like many regressed to waterfall inspired workflows. Everyone says they are agile but few seem close. Insanity meeting on the branch strategies from hell. Productivity grid to a halt because the tightly coupled software placed into a gazillion different repositories without any logical connection to how the software is built. “CI/CD” is just build servers, often not close to continuous delivery. Important test phases (integration, security, robustness) in the end of the “agile” workflow, so all issues are found late needs to go back through a lot of different “agile” process. What “agile” did not solve was making people do agile, or and how to handle lack of people with the correct experience/ know how at the right phases.
Too many "agile coaches" getting paid consultancy rates to give everyone Scrum Master certificates, without actually helping them understand the agile mindset. Too much religion, making agile an ideological battle instead of trying to find the best way to work, and certainly not making any allowance for the problems it isn't suitable for - "always agile, all the time, and if it doesn't work for you, you're doing it wrong" goes the mantra. A failure to understand agile at the management level, meaning that trying to implement it at the dev team level is impossible: "we need features ABC by date X - sure, you can do two week sprints until date X if you want to, as long as we have features ABC by then". You're right, agile did not solve the problem of making people do agile - that's true. It didn't even solve the problem of making people understand when to be agile, and when not to.
@@BittermanAndy yah… at least if people were clear about what they are doing and why they are doing it. Stop focusing on what theory org adhere too and just see if the ways of working are sane, productive or just insane. Branch/repo strategies that brings productivity to zero (or if devs ignore the crazy strategy, create a mess of branches not in sync) is one of my favorite “why do you do that and do you understand the impact?”…. And people being “agile” but you still find out things doesn’t work very late. So far from the CD ideology, branch and release mess :-)
Agree. Especially with that last sentence. Agile is great, we all know this, but it seems that it fails very often when a team doesn't consist of 10x Devs/QAs/Ops/Sec/.../ and 10x /Mangers/POs/PMs/SMs/.../. The video says Scrum is popular because it allows for cheating, and I agree, but it hasn't addressed the question of why teams are cheating. I mean, if these agile methodologies are so great, why would anyone deviate from them? It's because doing things "right" (agile) is difficult and often expensive. If there is anything post-agile it has to be something that can be applied to a wider mix of people (both managers and tech people) in terms of experience, education and motivation. Good people to put over processes = Expensive Don't need "comprehensive documentation"? Hire people who can function without it = Expensive Being prepared to respond to change instead of following "the plan" = Expensive We need Agile for the _real_ world which is messy, often underfunded and understaffed.
@@neur0transmitter "The video says Scrum is popular because it allows for cheating, and I agree, but it hasn't addressed the question of why teams are cheating. I mean, if these agile methodologies are so great, why would anyone deviate from them?" - a very good question, which far too few people spend time thinking about.
I never thought much about agile. As I saw it practiced, it seemed to do the job. I have never seen a worse abomination though as when it is used not for software development but as a tool to control software developers by those that know nothing about software development, only JIRA and Agile. What a nightmare.
Back when I used to write software in the late 80’s we started out with “we do this, we do it repetitively.” Or “we need to store this info and retrieve it to do this.” I started out with the data, then built out a skeleton. Took it to the customer ran through it to see if it matched their general requirements. If it did then it was add the rest of the functionality, release it to the customer get them to run with it for a while and then revisit it and ask what they like and more importantly what they didn’t like. It was only simple stuff but the improvements to productivity was massive. We seem to not want to do that any more. Where I work now I see data stuck in systems and we have to do manual processes to get the info out. 30 years and we seem to have gone backwards.
I've worked at a place where this approach was initially taken to build what was the current platform, and you're right it works, it was a prototype initially that could be built quickly and did the job. The problem came when 20 years later when extra things needed to be added on, extra functionality, extra geographical customers who needed access to a certain part of the data through a subscription but not others, this was becoming more and more impossible to develop. You could say, well this should have been thought about after the initial prototype was built and shown and signed off, but it wasn't needed at the time and so it wasn't in anyone's thoughts. Plus it was extra work that didn't provide any extra revenue for the company and they are the ones in the end who pay the wages. The problem really is when a lot more complexity is introduced and a platform becomes so big that it needs someone with experience to look at the architecture and many legacy systems not a point where it costs more to keep hacking new bits onto a system with workarounds than it is to redesign the platform and develop it in an Agile way, releasing incrementally, switching functionality from the old platform to the new one as it gets released and eventually retiring the old one completely.
From the perspective of the industry I used to provide software for (automotive), Agile was never more than a collection of new buzz words for what was already done. Only we had different names: We had no "Sprints" (which sounds like everyone is doing over time and comes closer to a heart attack, which sounds hectic and chaotic), we had iterations. Planned. Because whenever we deliver a new version to our customer (the OEM), they have a right to know what to expect (which new features, which fixed bugs, which implemented change requests,...?). Our iterations were as such planned. Our test department also wanted to be able to evolve their test system to test the new state of the next version in parallel to it being implemented. The customer (OEM) had to manage many supplier for various devices and of course they could not write the perfect specification prior to anyone starting to work. They had the science part of what agile people keep talking about. We as suppliers hardly ever had any "science" elements in our work. We had experience and there was never anything radically new to do. So we could plan better and know which people would be best suited for which tasks. Our iterations (with new, documented drops to the customer) could be as short as 4-6 weeks. This is well in the realm of what "Agile" companies also want to do, right? And because we were but one out of maybe 20-50 supplies, it was not up to us, which features and fixes we deliver in which iteration. Because such highly distributed systems could only give insights if they all were on the same page. So, from my view it was all about new buzz words for existing practices: Dictionary: "iteration" "sprint", "Test driven" "Every working step needs a test step, from small to large" (Unit tests, integration tests, black box tests and then the integration tests at the OEM with other devices), "Adapting and learning" (mostly on OEM side) "New insights result in change requests, which update the specification of the device to a new version, which will then be implemented by the supplier in iterations, agreed upon beforehand". The last part is important... during the (roughly, typically 2 years of development), we typically had an average of a few hundred up to something like 2000 entries in our change management system. Of which, 99.5% were change requests by the OEM and the rest were actual bugs or misunderstandings. This is how "science" part looks like in automotive. So what excactly is new to Agile from that perspective? Only the words, my man - only the words. So what could be post Agile? The insight that new words do not make a new approach. And that people should stop taking those new buzz-"processes" as a religion or some insights from a higher power. A whole new breed of "overhead cost", I fancy, has emerged from all those "Agile, SCRUM, whatnot trainers and consultants", whose main job appeared to be to declare anything done before as being stupid and less enlightened and to justify their own, lucrative new vocation :)
You are completely wrong in your last, important part. The fact that you have a change management system that suggests to me that you had one big design which you had to change as you went along, 2,000 times, meant that all that work had been put into designing something in one big chunk before the project started in detail, and when it came to the time of implementation of wasn't what was wanted or needed. That to me sounds a lot like waterfall development. I completely understand that in an automotive environment you need everything designed, and signed off, before you start assembling the final product, and so this is why it has to be this way to a certain extent, but it sounds like a recipe for things taking longer than needed. In software development of course you need an outline with high level estimates, but how to actually implement them isn't done before you start releasing earlier parts of the product. You can't do this in an automotive production environment as everything needs to be signed off before you get to this stage, you don't design the engine as you've just released the chassis I would imagine.
@@mattpotter8725 A car consists of a (amazingly high) number of embedded control units, which are interconnected via various field buses. A supplier is typically responsible for 1 such control unit (rarely, 2 suppliers have to team up and get a share of the eventual production and sale of the unit). The OEM (car manufacturer provides the specifications of each device to the respective supplier (e.g. using DOORS requirements management systems) and there are 3 major milestones, where the OEM interconnects a set of co-dependent networked devices for testing. They are often called A, B and C sample. For each of those sample phases, the OEM wants to test how the devices work together and as such, the feature set, each device has to provide in those samples is pre-set/pre-negotiated between suppliers and OEM. In the aftermath, there a fixing iterations being scheduled (typically each between 1-2 weeks), where the findings of those sample tests get worked on (bugs fixed, specifications updated when the OEM specified something that is not working etc. ...). There is next to no waterfall involved. But there is no "we just write code and you get what we give you" mentality in that industry. Every iteration small or big is planned and agreed upon with OEM. The whole development cycle for such a project is between 1 and 2 years. And the OEM also needs transparency as for team strength, methodology and development process, which often is being assessed in the framework of CMM or SPICE or automotive SPICE process assessments.
This was a very nice video. Great Question " Are we able to release product to production after sprint ?" I see that Organization has put too much emphasis on processes rather than engineering practices. The elephant in the room is/are legacy applications. Organization thinks that they have to spend million of dollars to get their programmers trained on engineering practices (Continuous Integration, Refactoring and TDD/BDD). They are not willing to give extra time to their developers to figure out engineering practices on their own. Vikas
I would disagree. There are cute principles that need to be adhered to, but in every Agile team I've been in, which were Scrum and Kanban methodology, you always had retrospectives where you looked at the good and bad things in the previous sprint (in Scrum) or period of time or iteration (in Kanban) and said what went well and what doesn't, suggesting new things to try and where he things that had been suggested and tried in the last retrospective didn't work they were either dropped off adapted. Each team would do this individually and come up with good and bad things and there would be a Scrum of Scrums that learnt across the whole IT department new techniques. I think you are confusing for principles with engineering practices. I always found Agile have those at the coal face the ability to suggest new techniques and new practices whereas before this you were basically told from above how to do the work you yourself had great ideas and knew best how to do, that often didn't work. I have worked at places that left the implementation to non exists, who thought they knew what they were doing, who picked and chose what bits they liked and which bits they didn't, and in the end of became such a mess that a consultant had to be brought in to sort out the new and get everything working correctly, increasing productivity of the teams.
@@mattpotter8725 The question is "Are we able to release product to production after sprint". How retrospectives can help if team members don't have exposure to good engineering practices that enable agile developments. In my experience, retrospective meetings after couple of sprints become rituals . People run out of ideas how to improve sprint in future. Retrospective meeting can be useful if we bring additional talent (can be consultants ) to bring new insights. With Regards, Vikas
Agile Manifesto signatory here. My copy of Agile Software Development: Principles, Patterns, and Practices was signed by the author, Robert Martin, on15 June, 2003. I worked on small teams applying agile from around that time until 2016, when I retired. I experienced the "impedance mismatch" between existing business management and the teams, but the teams were able to persuade management and get them on board. How? First, to their credit, they let us try it. And when we delivered, let us keep doing it. The key is continuous group learning. Everyone has to learn, including managers, customers, developers, testers. Old roles had to be changed. People learned to wear more than one hat. We were fortunate to have bosses willing to have a go. With good reason, our first agile project was to rebuild from scratch a one million dollar system that totally failed to see production. We succeeded, kept learning and each project was better than the previous one. It worked because we were able to develop a collective learning process, with sprint reviews being key. What went right? What didn't work? How can we do better? What new thing should we try? What might we stop doing? I have a hunch that as agile gained some traction in upper management, as a buzzword, it wasn't well understood. Applying agile in a specific environment always depends on having the right group of individuals assembled. People ready to collectively learn and get collective rewards. In our individualistic culture it doesn't always work. I'm not surprised that agile has failed in name. It's always had strident detractors, too. Used to be that the older process that used large batch sizes (one year for gathering requirements, etc.) and separation of responsibilities was said to fail because it wasn't done properly! Same can be said for agile. If the work isn't organized well, the project will fail, regardless of the methodology. Agile worked well for us, and I'm sure it still does for some teams. It's not a panacea. Agile requires even more discipline than older methodologies. Group discipline. Some groups simply aren't good at it.
Great video, and I agree with everything you’re saying. I’ve worked at two large corporations as they shifted to “Agile” and the result was actually more dsyfunction and less effectiveness. This was because the companies failed to change their processes/hierarchy/communication (culture) while they made the shift. People hid their work, stovepiped their efforts, and kept working in the old manner while claiming they were agile. I would love to see a video about the intersection of Agile and Conway’s Law.
"Shifting" or "Transforming" to agile is not the same than "evolving" to it. Companies and their managers forget that. Scrum's marketing tells the opposite as well, making people belive that you can start in the devs team instead of the head of the organization.
@Dave - Absolutely amazing. This video is perfect as I've noticed similar issues from my past. I think it would be extremely beneficial if you create a video in tandem with "5 common Mistakes in user stories" is to include the (zero/one/many, INVEST, SPIDER) technique on how to break down user stories given more examples. Each one teaches me more and more! Reading the original XP book also opened my eyes to agile a bit more since I find it helps technical readers enhance their pitfalls and enabling myself and our org to grow.
What I have learned. Collect a group of competent and smart people and they can produce a working stuff whatever way of work is used. If You collect dumb, lazy and unconcern people there is no such an organizational approach to yield any positive income. I feel somewhat 6x-10x more people in software industry than normally should.
I was thinking exactly the same, all the time we talked about the wrong things about agile in the actual software development process, we talk just about the managers and PMs, etc etc. But we always left out the “bad programmer factor” the guys who put together all this great ideas on the agile manifesto were great programmers with great soft skills. Every time I read the agile manifesto I can easily see how many programmers exists out there that definitely cannot accomplish those goals
@@abrahamgarcia2171 This is one of the challenges I have. It seems like a lot of the newer developers are resume stuffing more than they. are interested in delivering a good solid solution. It could be I have just had a lot of bad luck. I don't know if it is the devs, the education system, or the practices that don't lend themselves to good solid coding. Still trying to figure it out. II didn't have this problem in the 90s with developers.
@@ShadCollins to some degree because lots of companies lack leadership and there actually isn't anything to gain besides some additional technology names for the resume
Probably my favourite video yet. I'm a big fan of the science approach and have been using it in software testing for years. Testing is all about forming hypothesises of risk and threatened value, and then finding evidence to make a counter claim against value. So I fully agree with the falsification statement, it's about time the idea that testing as verification, validation or demonstration dies forever and we take a more applied scientific or engineering approach to all software activities. 👏
"I'll see you on the dark side of the fumes..." Love the shirt. And the video. Embracing the scientific method to develop and deliver working software will strengthen the product, improve any process, and benefit the participants.
That may be true, but when your customers are demanding restrictive contracts and rigidly defined processes, "we won't do that, it would be doing agile wrong" just means you go out of business.
It has mostly become either synonym for SCRUM-BUT(T) mess or more heavy and complex than any formal, traditional method could ever hope to become. I think already 5 of authors of original manifesto realized, that they have been badly beaten by law of unintended consequences and wrote posts "wait, it's not what we meant".
I would like post agile to be a world that reintroduces more formality in requirements. I've done too much maintenance work on agile systems where nobody really knows what the system is supposed to do and the only ones that did have left the company
Yeah, the manifesto point about documentation irks me... While development , since everything is in flux, you dont do ducumentation. Afterwards? Nobodys paying you to do documentation on working software. So it never gets done and maintanance flies out the window. Self explaining code? Shure, by itself maybe, ut code does not explain decisions in complex system design, and finding out WHY it is this way, or if it is even still in use can become a realpain, and expensive.
In Agile software development, only the tests are the documentation. If the tests do not cover the essential functionality (or better even all use cases) then it's difficult.
@@mateiacd they only cover WHAT the usecase is, not WHY. And to not start on how the tests get adapted over changes in other features, and if the reason one was created is still aplicable... I know that more formal intent doesnt solve all the problems, but having in mind how to convey all those meta information while developing the tests and later while adapting them kinda expects the developer to be omnicient. With a documentation that explains what the point was you can later deduct it the tests are still applicable...or if the feature itself has become obsolete. Also: test maintanance is easier (what aspect of a test was that way because the feature should be that way, and what was because of the sorounding workflow), and decumenting all use cases and all edge cases, while good, can become a pain to maintain. So having an informal intent how the behavior should be for later manual checks can safe a lot of time. (Obviously depending on how criticsl the feature is for operation and security, those should have comprehensive automated tests, but some UI mask tests can be a pain later on when an aditional text field can break hundreds of tests because the exact order and amount and position got checked...)
Thank you for this! I haven't been able to gather any value out of the term "post agile" when I can clearly see evidence that we are not even meeting the requirements for "agile". Seeing that there are opportunities of refinement is where there is value. More of an Agile++ rather than a "this instead of agile" approach.
Yes, it's a failure. EVERYWHERE I've worked that uses 'Agile' uses it different. Almost everywhere sees the word Agile and they hear "Abracadabra". The unfortunate truth is most shops are run by people not technical, with outdated tech, or just out of touch. Either way, if you have good requirements and a good architect, you will get through regardless of the approach. How the work is organized can help in my opinion, but you aren't going to succeed without the proper people making decisions, and that is the actual blight that I see more than anything.
I think the applicability of agile techniques is very industry and situation specific. When your customer is a large bureaucracy with a 2 year evaluation and procurement process, good luck getting fast feedback. The whole agile approach falls apart without a competent customer who is ready and willing to provide good feedback. When selling to the military or large telcos you quickly discover that these organizations are filled with clueless people. Another big problem is the emphasis on face to face communication. During the pandemic many organizations proved this is unnecessary. With many teams distributed around the globe, this type of thinking is becoming an anachronism.
Sadly “good requirements” is almost a contradiction. The often thing that makes them good is that you’re able to deliver them. Studies have suggested that even when waterfall projects go well, there are significant number of wasted features. If customers can’t give you both good requirements and frequent feedback then you will end up with sub optimal results. “Agile different” is unsurprising given that it’s basically nothing more than some values and principles
yeah, this. CD even covers it in the video... adoption fails because agile requires a change in culture, and changing culture is hard. Ergo it arguably is NOT a good way to go because you'll almost never be able to win the uphill battle against culture. Which should start the creative juices flowing... is there ways to get SOME of the benefits of an agile culture, without having to completely rework the culture? Are there 1 or more agile practices that provide increased value, but are easily & consistently implementable? What about the agile manifesto makes it so hard to adopt consistently? Can it be reworded? Are some of the principles in the manifesto actually BAD ideas, and thus should be dropped/replaced? And BAM... you're doing post-agile thinking. You're informed by agile ideas & the industry experience with agile... without holding agile as a creed. you aren't assuming the authors of the manifesto were geniuses & 100% correct about everything. You are inspecting & adapting... and applying that to the idea of agile itself (which is what you should have been damn well doing in the first place).
Long timer here. You're exactly right. I've seen a lot of teams quacking Agile vocab like flocks of geese, much fewer actually being Agile. And thousands of consulting and "training" hours billed along the way (not by me). Your question, i.e. have we actually done it? ... is on the money.
Unlike most of the commenters here, I have seen the success of agile. Maybe, because I started my career in 2001 on a project with a 500 page spec. It was painful give me iterative. In terms of planning XP is seriously dated but it’s technical practices are spot on and more and more mainstream. Maybe also because I’ve worked in London where there are a lot of highly experienced (old) developers. That said, there is room for improvement. Here’s two examples. I saw part of the agile movement as a response to the trend of offshore/outsourcing at the time. These days, I don’t think that we need to be so strong. The internet has changed things and I now work with an entirely distributed team. “Working software being the primary measure” is rubbish. Success should be measured against business outcomes.
Agile is, in the end, just another aproach to sorting out the task of developing a complex system, not a magical solution. Depending on the system, customer, industrie, etc it is can be a solid aproach, and with others it can lead to a total project failure. Is it a system that is dependent on all components working and needs to be done to this timeframe, no delay accepted? Yeah, a moving target with an agile aproach is probably not the best. Is it an online service that can get iterated on (Netflix, etc)? Shure, do agile. A technical system without much user interaction? Probably more specification and less "user feedback" needed. Research or prototyping? Agile, the faster the better. Agile is one tool of many, not the the key to every project.
The main problem with agile is not necessarily the core principals. Its that the process has been coopted by management focused on sprints, deliverables, features that can be checkmarked by the sales team, and building an assembly line out of software development. At its heart, agile is actually a bottom up organizational approach that allows those closest to production and actually using the software to make decisions, respond quickly and build the software in a more efficient distributed way. Those principals still apply. But as long as we co opt the process and introduce rigidity and insert strict roadblocks in the decision making and workflow, it will not be agile, but rather another set of speed bumps that will eventually go to the wayside for the next big thing. The key is that any workflow must fit naturally with behavioral economics in order to encourage the aspects that we want to build up. And adding complication and speed bumps and removing the ability for people to make natural decisions is counter to our natural instincts.
I am a new developer and this video breaks down this concept quite nicely. I have always wondered if there are different or new approaches to building software.
I've watched development change over the 30 thirty years, failing to learn and inventing "new" stuff all the time for now real better development practices: - Thinking a new framework will fix things oh don't like LAMP - lets use .Net oh we hate that lets move to NodeJS - In the rush to move away from Waterfall we decided design wasn't needed either. - After 30 years of grand promises of reuse, we still write so much code from the ground up. Imagine if we had to construct a new paint factory, everytime we wanted a different colour. Yet we do it development again and again and again. - Poor testing - Developers telling users there business processes are wrong, rather building what the user needs. - Going hand in hand with the above, developers making poor efforts to understand what the purpose is on the software they are building. I imagine if the construction industry put up buildings the way software development is done. There'd be no plans, each building would use different sized doors, windows, pipes etc. run on different voltages each floor would have a different roof height. I often see Agile as a fix to poorly software construction practices. The same way buildings that have many design changes suck, so does some much software.
I don't know and don't mind. We must want to go proper methodologies with good practices in place. Agile was a power-grab from non-tech people to remove tech and engineers from influence. A trap we all fell on, a trap we can get out of though
Geeze Dave thanks! Suplimenting my own learning and development with your shared insights. Currently working hard at bringing in and showing benefits of automated testing at work. I've been making leaps and bounds in this regard. I've been increasing my knowledge of quality code because what became immediately apparant is that if you didn't code with testing in mind code is often very difficult to test. So refactoring is at the order of the day! This is a skill in itself I imaging. Would be awesome to have your take on refactoring! It's becoming a lot better but I struggled with things like what will the dev think who's code I refactored. I found some older code that my boss wrote that I felt needed some love. Great journey and enjoying it a lot. Thank you for the awesome content! Keep up the great work!
I find that 99% of resources on agile focus on how you work in an agile manor within an organisation. However it's very difficult to fully move to agile processes in a B2B environment if agile is not applied at all levels of an organisation this intially starts with sales and what you are selling the client. The hardest part of apply agile within an organisation is this sales process what do we sell to the client, how to we cost a project, who is taking risk in the contract at what level. A client is generally looking to fix scope and cost and reduce risk in their contracts this is antagonistic to agile processes. I would argue this is the much harder issue to solve in deploying agile within an organisation but gets so much less focus in resources on agile.
That is the problem, the whole solution is being sold up front as a waterfall, unusually by a some account exec and probably with your technical input. Typically you also have to delver the goods on time and within budget so the exec gets the reap the benefits and praise etcetera, while you are the unsung hero if it succeeds. You will bill your hours once off, and the customer will be perpetually charged the value. Personally I would like to somehow earn passive income from any efforts as an incentive to keep the product viable as well.
I agree with much of what is said but would add that adoption of an agile software development approach inside a traditional business and budgeting model where senior managers commit to fixed deliverables, costs and timelines, are unwilling to delegate and unable to be involved with the development process is the usual model I see. Business management needs to evolve to allow agile approaches to work - or in a few cases maybe agile approaches do not meet business needs.
One thing I've seen a lot, pre Agile, was the addition of new requirements from the customer late into the development cycle that would generally cause some significant rewrites of code which would cause a delay in completion. Agile seems to start at base functionality, then collaboration with the customers to get the rest of the functionality of the product worked out at each stage.
Amazing work in this channel across the board. In case you're open to suggestions: I would really like to see a full video about SAFe to hear your perspective on it
I love this as a pitch for continuous delivery! When I've gone into 'Agile isn't working' environments I always found terrible development practices. Teams could not release reliably, so they could not estimate and therefore product could not plan. The grand process all falls apart because final step fails. Once we get teams confidently executing they tend to not care about the 'big A' agile process because all of sudden work is flowing and efficiency is up. I'm not saying all teams who love Agile are excellent developers , just saying that in my experience teams who fight agile are projecting engineering problems onto process.
I think the problem lies in how quick the industry moves. You're right in saying that it's probably from bad development practices a team can't have a releasable product every 2 weeks. But by the time everything gets solidified and the team can get their bearings after having development goals to meet while also trying to learn new technology, the next thing is already out and you have to learn that. A lot of products I've worked on have been releasable every 2 weeks, but there was still a ton of tech debt because people forcefully writing pieces how they knew best. Not to mention having to work with old code bases and make them up to date without funding from starting from ground 0. So at what point during agile do you let your developers catch up? Your good ones pretty much live and breath software development so they spend a lot of time outside of work learning and researching, but that's not normal for most jobs.
agree with those words. "Once we get teams confidently executing they tend to not care about the 'big A' agile process because all of sudden work is flowing and efficiency is up." / "teams who fight agile are projecting engineering problems onto process."
As one who has met some of the original agile thinkers. I agree with you 100%. It was always about delivering software. I think the term iterative development may be a better way of describing agile. One small step at a time. Continuous delivery from the first "hello world" to the finished product. I also think solid thinking is encapsulated in the Rational Unified Process: en.m.wikipedia.org/wiki/Rational_Unified_Process
Doesn't the whole agile thing miss the fact how contracts and customers work? Manifest says: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." - well most customers have fixed schedule delivery written into the contract and aren't even interested in beeing flooded with CD.
Not really, any more than any other approach. The idea of fixing time and scope is an illusion. Sure, it would be great if you could, but you can't. Ever hired a builder or a plumber? Ever talked to a startup about when the venture will succeed? These are all guesses. Agile admits the reality of this, You can work to a fixed date, but vary the content, or you can deliver fixed content, and vary the schedule. This isn't new to agile, people have spoken about this in planning for decades before, it is just that many businesses run on superstition and magical thinking rather than reality.
There is a great quote from Matthias Fischer from Toyota, "Everyone wants to be lean until they find out what it takes." Same with Agile (they're kind of the same thing anyway).
For a realistic "post-Agile" view, I recommend listening to what Joe Justice has said about his time at Tesla. He mentioned that he now considers "individuals" to include robots and scripts, for example. Tesla supposedly has 3-hours sprints. I'm not sure about the specifics, but it does sounds like the Musk companies have had to go beyond what is currently considered Agile, although it's probably more of an extension/reinterpretation of Agile than a completely new thing.
I'm still trying to wrap my head around this from a small dev perspective whom is also a noob. Would "release working programs in smaller sprints and get feedback faster" mean say...if I were making a video game, perhaps release the game to the public after only having say a world to join and ability to move in it? even if there is nothing to do because it's not implemented?
You don't need to be agile if you know what you are going to create and have it worked out all the way up front. In a perfect world, you would only have one iteration and that would be it. Users doesn't need to be external users. But the main point of the Agile manifesto is to get started - and adjust as you go. It doesn't hurt to have a plan up front, but as long as you have a rough idea of where you are going, that's often good enough to get started.
I think you point about technical over management is an interesting one I believe that is why video game companies often have disastrous launches for games.
Agile is an adjective. The agile manifesto set goals we should aim for in order to think agile and work agile. Linguistically there is nothing past agility. There can only be the opposite. Agile means 'move quickly and easily' or be 'quick, smart and clever' (Webster). The opposite is be stupid and slow. You can be more agile when you can deliver even quicker. But essentially, I am agreeing again with your video.
Ok hear me out, I am not one of these anti agile guys however in my experience working in a big company (who funded a lot of r&d projects and mvps) many of them don't want to work agile. This starts that they don't check progress regulary and instead check progress on their internal milstones every other time. Often leading to frustration when it is not as they expected. My other experience is as a developer having customers who were often annoyed when they changed requirements and then recived a build with not much visible change and more progress under the hood. Also they often hate to write their requirements down and instead prefer long meetings where they tend to try and discuss everything.
Agile is like building a go-kart as you are rolling down the hill. Then at the end when you see another hill in front of you, you realise that you should have built a car.
@@ContinuousDelivery Have you seen any of ThunderF00t's take down of SpaceX? That's Musk hucksterism in practice. SpaceX's main goal was to build a cheaper rocket, in fact it's more expensive.
Sure, but even if nasas contracts helped them, the core tech is their domain and they directly benefit from the developed product. Its more like amazon and their tech services then the normal software house where they dont benefit from the product itself.
the problems with Agile are: 1. rapidly releasing software to the customer often times results in a customer experience that is suboptimal because it feels unfinished and this then drives the customer away to a more finished product 2. prioritising value to customer can make it difficult to improve the developer experience which can drive talented engineers away and without talented engineers it is difficult to develop and release quality software 3. the entire process makes it extremely difficult to justify exploration of new technologies and tools which leads to bored engineers who leave the business or who just do the bare minimum leading to a suboptimal customer experience. I think those things are what I would expect post-agile to address
iism.org/ has some interesting articles and takes on everything you mention. I don't know if I would consider them "post-agile", they certainly advocate for Agile, but also put forth many other principles and concepts of management, business, and organization, that are generally absent from Agile (as well as absent from the manifesto). Yes, the main thing is that Agile says too little, it doesn't tell you how to improve your business correctly, it doesn't tell you how to innovate through technologies correctly, nor does it tell you how to retain talented engineers. This is both bad and good. Bad in the sense that it doesn't provide an answer on all those questions you pose; but good in the sense that if it were to try and provide an answer, it would over extend its reach and become more brittle, become outdated faster, and basically be wrong from the get go, since it'd be almost impossible for such manifesto to come up with the correct answers to all of these (even if such answers were to exist).
@@gonzalowaszczuk638 I wouldn't want Agile to dictate solutions to the problems it creates; I would just like it to not cause those problems in the first place. By stating it's mission in the way it does it leads to the interpretation that you must always release something of value to the customer at the end of each sprint. Changing this to "you must always release something that provides value (saving development time, increasing profits, increasing NPS, etc.)." means it would then be easier to justify new tooling, process changes, bug fixes, development pipeline enhancements or things that will eventually come together several releases down the line to provide customer value (in a meaningful and user-friendly way).
@@bicarbon8 If you want to get technical, the manifesto answers your question: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." "Continuous attention to technical excellence and good design enhances agility." You should prioritize that new tooling, process changes, bug fixes, and development pipeline enhancements. Rereading your original points: - #1 is debatable, since without doing Agile your product would not exist, it would only exist 10 months from now after "finished", with Agile at least the customer gets something now. Foregoing Agile doesn't give you magical powers. - #2 should be included in the above principles from the manifesto. The developers have to be motivated, the team has to be motivated. Give them the tooling that is necessary - #3 If the team is self-organizing, the team can decide to perform these new explorations. Otherwise, this seems to perhaps be more of a R&D decision, and likely also include the whole organization outside the team too (depending on the reach of these "explorations"). However, I would advise against trying "new technologies" just for the sake of trying new technologies. If they are not accompanied by adding value to the customer or the business, then are they worth it? You are basically shuffling things around just to have developers try a new toy, that's not good engineering. You don't tear down a functioning bridge just because the civil engineer wanted to try a new type of cinder block that is becoming popular.
@@gonzalowaszczuk638 in response to your comment on #1 being debatable: you needn't wait 10 months to deliver your product, unless of course it requires 10 months of work to provide something valuable and user friendly, but providing a small piece of the end product to the customer each sprint doesn't solve their problem and risks leaving with the same feeling as not having anything would. If I want a car, giving me a skateboard doesn't solve my problem unless I only wanted a car because I didn't know skateboards existed and I'm young, fit and never need to carry much around with me. I simply think that encouraging constant releases containing customer value every 2-3 weeks results in value that might end up detracting from the overall experience because teams will seek out quick wins instead of delivering towards a unified experience and giving the customer access to something too early can negatively impact their impression of it.
There is no doubt that Dave Farley is absolutely right in all that he is saying in this video. One should be guided only by the Agile Manifesto and its values and philosophy. And that means those values and philosophy should be burnt into your brain and heart. Everything else is just ceremony.
I believe Agile has been adopted largely because it is more useful for *management*. They can identify programs going off the rails more quickly. There is often no focus on what makes *developers* more effective. Teams living in a silo and not communicating, at the right level, with other teams is the biggest problem. Small talented teams that know each other need less Agile, larger and less talented teams need it more. Management just cares about tickets being closed while developers are bad at creating new tickets as a task is revealed to be more complex than originally thought. This can lead to being seen as "non-productive", which may not be the case. Many developers just see it as a constant distraction. I see a large benefit when a team has "analysis paralysis" - just DO something, learn, and iterate. I've done successful waterfall. I believe it depends on how well understood requirements are.
My team is highly productive. We have successfully completed many projects on time and follow agile very informally. In the last year, we have been asked to convert our legacy systems to be cloud-native. This means months of development that result in backward compatible APIs that doesn't result in customer-facing features. We have been criticised for not being agile, and I understand why; however, we are still delivering consistently. I feel that our current work steam is not conducive to agile, but we are still criticised for our agileness. At this point, I think agile needs a rebrand as it doesn't work for all projects.
Well, the way that you can tell wether you are working in an agile way is to take a look at the agile manifesto. It is not very proscriptive, but I think it is pretty universally applicable. Lots of people have a naive view of what a user-focus means. It is not just about user interface features, the usability and utility of your system is about more than that. So I am perfectly comfortable doing work that is "of value to users" deep in the stack.
@@ContinuousDelivery thank you for your insight. If only the corporate drones could see that the original manifesto wasn't about theatre but about how to deliver reliable software. Sadly I'm not very good at politics so we are at the mercy of our corporate overlords.
Would you concider making a video about how to handle databases in continous delivery? And also maybe infrastructure upgrades with as little downtime as possible. Are distributed databases the way to go?
Its the classic problem. Devs are obsessed with code, DBA's are obsessed with databases, Infrastructure are obsessed with, well infrastructure. Nobody seems really interested in the system. The amalgamation of the 3 into a coherent working thing that the salesmen have sold. Agile was always a counter to RUP and its like , RUP was always a reaction to RAD and the early days of mass IT, If you have been in the business long enough its just a depressing circle.
RUP is much better than Agile to be honest. Anyway, I can live with a simple iterative/incremental process with proper requirements elicitation phase and design phase. I can't live with Agile in endless conversations pretending good stuff will 'emerge'from that like in fantasy because good design don't emerge from random talks from non -tech people
you are inspiring, though i came to think that a management can only ever pretend to be agile in that it is never the one that endorses in its mind and body the responsibility and burden of a releasable software.
As usual, I agree with your overall sentiment, the same line of thought was applied to the criticisms of OOP. But on that note, I don't think Einstein ever said that.
I think it is very convenient when a process fail to blame everything but the process. The reason a lot of teams fail to implement agile successfully is because agile itself is a flawed process that will never be the one size fits all solution some people would love it to be.
@@ContinuousDelivery For starters: "Working software over comprehensive documentation" and "Responding to change over following a plan" - both which loosely translates to "tons of billable hours / works on my machine" and "I have no idea what I'm doing / let's bleed customer dry". Really, I thought it is channel for grown-ups. Agile was created to address VERY NARROW case where one can NOT define requirements in advance, not when everyone assumes that these are not needed. This is work organisation pattern for small tiger team NOT project management methodology and certainly not absurd on SAFe.
@@piotrd.4850 Well I have seen it work for about a thousand developers working on the same codebase, so not just for small teams. Commonly for teams of hundreds, composed of many smaller teams. I don't understand your translations at all, they seem non-sequitur to me.How does "Working SW over comprehensive docs" relate to "only works on my machine" the definition of "working", at least for Continuous Delivery is being useful to users in production. "Tons of billable hours" well only if you are crap at writing code perhaps, the teams that work the way that I describe produce measurably higher quality software more quickly, not less, so actually fewer "billable hours". Read the "Accelerate" book or the "State of DevOps reports". The companies that work this way are not "small agile tiger teams" they are often some of the more successful companies in their fields, Amazon, Google, Microsoft, Tesla, SpaceX, Ericsson, Volvo, US Air force UK Government, the list goes on.
@@ContinuousDelivery Aligned on everything you said in the above comment. But curious to know more about the last line. Do organizations like Amazon and Google practice any Agile frameworks like Scrum, Kanban ? If not, what do they have to ensure their way of working is Agile ?
@@sujithsukumaran8689 "agile" development isn't defined by "agile frameworks" it's defined by the agile manifesto. Following a framework like Scrum doesn't guarantee agility, in fact most teams that claim to follow Scrum aren't agile in the sense of the agile manifesto. Scrum, and any other "agile framework" are more like training wheels for agile practice.
Not only has Agile not failed, it's ubiquitous. Build small, break small. In the real world, work processes are constantly evolving, so must the digital assets that we create to implement them. Anything that takes a year to ship will ship obsolete.
The problem with "Agile" is that it is used as a noun, like something you can sell and buy, a fixed recipe you do implement, not as an adjective, which is a trait your processes have, if you design them with being agile as a target, i.e. questioning and shaping the processes itself.
The problem with Agile is that it means something different for every person. There is no definition of what it means to be agile. The whole trend started with a vague manifesto that set down some guidelines, then others ran with it and tried to turn it into these specific things. When that is your original source for your process of course everyone is going to do it differently. This is why Agile is bad. There is no set definition. Everyone is able to make it whatever they want it to be. This is why people crave a post-agile world. They want a process that is well defined, and has a clear benefit. The Agile Manifesto says all the right things, all the things that make people feel warm and fuzzy inside. The problem is those things are not always conducive to predictability. People crave predictability. Not just managers, but developers too. Unpredictability often results in poor results and delayed results. Usually what you need to get good results is a strong well-defined process that is flexible. People over priced sounds nice, but it's wrong. Working software over documentation sounds correct, but it's wrong. You need a process that values people. You need good documentation in order to create working software.
It is still valid for building something to begin with and then using agile to maintain it. The first version of a finished product is difficult because frequently there is only an internal function that no one outside of development can see at the end of a sprint.
Yes it is. Don't listen to anyone telling you it isn't. Software development (proper software development) is plenty of methodologies: interative, iterative/incremental, evolutionary , RUP, and of course waterfall. If someone insist too much on Agile, be careful it might be an snake oil seller. To this point such word is almost a red flag.🔴
@@ShadCollins not always agile. You can maintain it with iterative incremental. Won't mention RUP because for a one-person project it is an over kill just as Agile is an overkill.
When my manager told me that Agile is the "best" software development methodology, I asked him to prove that analytically or scientifically! There's always scope for improvement and who knows what the SW industry is going to adopt after another 25 years?
I don't think it's possible to measure agile in total isolation of things like trying to measure weight. A better question is to compare agile to not agile. It's it better to value prices over people? The agile manifesto is about qualities that good software development practices have. There is also a book called Accelerate that does have data on this though.
@@folie-n3t I read Accelerate but I want a proof that Agile is the "best" like how it's proved in math and science...I do understand that it's not possible ;)
My experience is that a hybrid approach works best. It also depends on what sort of company you are. If you are a company that isn't a B2C offering or a tech-only company, then agile has a harder time getting started. I usually work for manufacturers, financial services, or retail. Their job is to sell their product, not build technology. They need technology to do it effectively but that isn't their core business. Starting off with waterfall and then maintaining with agile has worked pretty well but a lot of the younger coders think scrum is agile and that react is the only way to write websites. That is what they were taught a few years ago in school and they have plenty of ego but limited experience. A number I have run into have also never had to maintain their own code because they leave to go somewhere else for 20k more. They keep doing the same thing at different places. They aren't learning, they are repeating but at a higher salary. Other people probably have different experiences but this is been mine. I have had some wonderful developers but they have been coding since the 90s or earlier, are careful, and do their best not to repeat mistakes they have made when they had to fix their own bad ideas.
Anyone heard about six sigma? This was way back when GE was bigger than Microsoft in market cap. Then everyone started doing six sigma and everyone was six sigma certified until GE imploded and became an example of how not to do things. Six sigma started in engineering and then slowly became management speak. With tech companies being top market cap, it's only logical that agile which came from software becomes the next six sigma and everyone and their dog being an expert at agile, the cool kids move away from it. Agile was trendy when it was used in big tech but nowadays it's become a buzzword that's been muddied with $10 courses promising expertise and did I mention RUclips?
Imagine your job is to deliver mail, and suddenly management decides you have to justify, in agonizing detail, exactly where you are going to place each foot on your route. How far your are going to bend your knees during each step, your elbow during each time you reach into your bag. How long it will take to walk from each mailbox to the next. And: why, on your previous route, sometimes you ended up taking longer strides than predicted and sometimes shorter ones, and why the knee and elbow flex angles were sometime off, and how you are planning to fix all these problems. Welcome to Agile.
Isn't the way we wrote software pre-AGILE more the engineering methodology? Agile seems to lend itself to putting out a lot of broken software due to lack of discipline on the team and the urge to rush everything out with a simple unit test written by the person who wrote the software (fox guarding the henhouse).
@@thisolddown I've never seen it not be like that. After people implemented Agile, the agile coaches told them they didn't need QA departments. The executives love that so they got rid of their QA teams. I saw this at a company I was at and also at my wife's company. Quality control is now terrible. It got so bad at my wife's company they started getting complaints from customers so they had operations people start doing QA on top of their normal jobs. Not that the operations people are well qualified to do QA work.
@@thisolddown One more bit Sean, I'm not looking for validation on whether to use Agile or not. I am looking to see if II am missing something. I have been in IT for 35+ years and you have to keep up. I keep being told Agile is the end all be all and I am just not seeing it for companies that I work with (e.g. real goods, services, financial, etc.) It seems like a great idea for websites but I can't figure out how to apply it to things with specifications and deadlines.
You are right. We need proper engineering methodologies to come back. Only thing Agile did was remove documentation, proper design and let non-tech people to make engineering decisions removing engineering from influence. A power grab.
Very few did anything close to agile. Most had Scrum imposed on them and the unlucky had it as SAFe. Agile was declared dead by those who made the manifesto years ago. We are still "pre-agile".
I think one of the issues is that new developers think agilie is scrum. Scrum is its own thing on top of agile. You don't have to implement scrum to be agile.
It appears that "Agile" ignores the reason why bureaucracies even exist, and how they form: proficient people at the bottom, not the top, start to document what they are doing in order to improve the efficiency and working method of their colleagues, while the top - the bosses take those documents and shoe-horn the production to conform with these documents. This they do in order to get a slow organization that works however incompetent its workers are, because the organization grows and a bureaucracy is the easiest way to get an automatic competence improvement for newbies. Agile makes it almost impossible to hire newbies, so it becomes an isolated organism that cannot grow, and when people leave, the competence of the organism decreases.
In my experience, "Agile" has just been an excuse to throw process, design, and documentation out the window. The poorly-documented & unplanned code isn't released any faster, nor does it have fewer bugs, than any code created via a waterfall.
Well I suppose that may how some teams do it, but that is not what agile says or does. The highest quality system that I have ever seen, let alone worked on, was written using agile principles by the most disciplined team that I have ever worked with. We did some very cool stuff faster and with higher quality than I have seen before and solved some interesting and difficult problems along the way. Oh, and it was in a heavily regulated industry too. So I am afraid that I disagree with all of this.
@@rmworkemail6507 How do you know, I don't describe the science bit here? Science is an approach to discovering new knowledge, one take on modern engineering is that it is a practical application of scientific approaches to learning how to solve problems. The scientific method is: Characterisation Make a guess based on experience and observation. Hypothesis Propose an explanation. Deduction Make a prediction from the hypothesis. Experiment Test the prediction. You can apply this approach to development in a wide variety of ways. C: The user has this problem H: I think this test describes something that represents that problem. D: When I run this test, I expect it to fail with this error message, 'cos I don't have any code to make it pass yet. E: run the test and see if it matches the results. There's a lot more that we can take from science... Start by assuming that your guesses, designs, understanding is wrong, rather than right, and figure out how to falsify your ideas ratter than prove them. Control the variables, so that you can clearly see the results of you experiments. So I think it valid to talk about applying scientific style reasoning to SW and when we do, calling it "Engineering".
I think, agile failed in exactly one thing - it failed to convince developers, that it is pro-developer. No one knows that manifesto for agile software development was written by group of nerds, who wanted to have healthier working environment. People don't see connection between it and their everyday working routine. There are substantial stuff, that developers do, and there are "another innovative aproach", that managers happily demand from the workers and then show to each other in reports and presentations. And agile seemingly belongs to the second category. "How it can be about development? It does not say anything about architecture!" - that's what I heard from one of my colleagues, when we discussed this topic. Probably, it is because programmes like concrete, material stuff, they don't like philosophy (usually), and agile manifesto is anything but concrete. So, it was picked by people who haven't written a single line of code in their lives, but publish their opuses on deep meaning of "interactions" of "responding" and its implication on scheduling team meetings.
Could someone help educate me here on Agile's origins? From what I can tell it was created by a bunch of guys that all worked for tech companies. Is that why it is harder to make work inside of traditional business that works on deadlines? Or is there something else I am missing? I have been doing the deliver fast and iteratively before agile existed but a lot of other things that go with agile seem geared for technology companies or startups.
@@thisolddown I guess that is part of the problem that I see with Agile. It seems to work best when there is infinite time and budget. Before I can get a project approved in most companies, I need to be able to tell the steering committee or board how long it will take and how much it will cost. I can provide a range but that is about all the allowance I am normally given. If it is a regulatory project, the deadline is fixed and it is just a matter of the best way to do it and how much will that cost. Regulators don't care how unreasonable their timeframe is, you simply must comply. I haven't found that Agile holds up well in these normal sort of business scenarios. If someone knows how to make Agile work in these situations, I am all for being educated on how to pull it off.
@@thisolddown I appreciate your thoughtful write-up. I think one of the challenges is that developers are trying to achieve what no other department in a business gets. Many departments are told what to deliver and by when. The only variables you control are how many people it takes and how long the hours are. It does feel like a situation where developers have decided they want their cake and to eat it too even though no one else gets to do this. Infrastructure is frequently given deadlines, budget constraints, no more staff and told to make it happen. I've seen plenty of internal legal teams told to get a deal closed and they only have so many people so they outsource pieces of it but the deadline and deliverables don't change. At times there are projects that are negotiable but a lot of our lives in corporate are ruled by constraints we didn't come up with.
@@thisolddown A) I really appreciate you talking back and forth with me on this. B) I think a lot of companies don't really fit in with agile. There are some great ideas from agile like talk to your customers, frequently and often. A lot of us were doing that pre-agile. My wife works at pretty big public healthcare company that has a huge tech arm. Among her hats is what would be a scrum master. They don't call it that but it is what she does among other things. They are frequently handed dates by either the federal government or sales that committed to something without talking to anyone. So they do agile and scrums but it doesn't matter because what they do is figure out how many two week periods between now and the deadline and break up the task to get it done into sprints and people put in as many hours as it takes to get the deadline,. It is a perverse implementation of agile but it is still labeled as agile and successful even though it isn't agile at all. Her company might as well not be agile and would achieve the same results but without all the religious ceremonies every day of stand-ups. They don't use burndowns because management won't accept those for project statuses so they keep a separate excel sheet for the project status maintained by a PM. But the company thinks it is agile. There are some awesome concepts from agile but we did a lot of those pre-agile. There are some phenomenal mind-blowing sort of things from CI/CD if your company needs to do things at that velocity or is a B2C company. The hang up I get is it seems most of the devs treat agile as the bible and refuse to admit there is any other way to doing it or the young ones seem to be corrupted into thinking deadlines is not a thing. I am still trying to figure out the middle path. I don't believe in dogma or holy wars. Just in doing the right thing and moving the company forward. Whether that is with agile, scrum, agile 2.0, post agile, water/agile, whatever. I am results-oriented.
@@thisolddown It seems like this sets up a constant fight between the developers and the business that pays them. Development, much like IT, use to be about being pragmatic. Now it seems that is gone and it is a my way or the highway from the development staff. Is this what you are trying to tell me?
The best tools are great to have, but with lesser skilled people they are practically useless. Conversely, great skill can do wonders with sub-par tools. Sometimes, you have to plan certain stages out, and it takes vision to know where the end goal is. Other times, its difficult to see the ultimate goal until you run 100 miles so you can see the next horizon. There are many tools in the toolbox, and agile is one of them. Bad communication will make any project fail. Haste often still makes waste.
I think that agile is more than one of the useful tools in the box, even more so if I am correct in thinking of agile as an informal adoption of some scientific fundamentals. None of that means that I disagree with what I take to be the thrust of your comment, sure, no process allows us to take our brains out of gear. If there was a cookie-cutter recipe for writing software, we could automate it, and do ourselves out of a job in the process. Software development is a complex, difficult task. At the limits, it is one of the more difficult things that we as a species do. Sure, most SW dev isn't that hard, but some of it is, and one of the difficult things is that even when you are doing something simple, like a server less function or a web-page, you are skating on the surface of some genuinely difficult, maybe even profound, problems. Ideas like coupling and concurrency, for example are world-class difficult, and impact teams even when doing relatively simple things. So having some discipline, some organising structure around which we shape our ingenuity and creativity seems more important than just picking tools from the tool box. It helps keep the beginners away from the deep end, and it helps the experienced people to build on, and enhance their own work as their learning deepens.
I agree with you, I started coding in an "unworthy" language. Everybody said it was crap for what we needed to do but using sound design and a flexible architecture we ended up with a product that beat the competition in features, speed and robustness. We were always refactoring and making small improvements and always blowing people's minds on what we could do with such a technologically inferior language. It took 15 years and the advent of the SAAS model before that language was replaced by something webfriendly.
Your videos and software engineering are so good, I constantly want to share them with my students. Unfortunately, I have to keep inserting caveats that “this person is a complete philosophical ignoramus, so ignore every philosophical thing he says.”
Who does Agile now? Certainly NOT everyone who says they do. We've seen it before, ad nauseum. In my career it started with Structured Programming. Everyone said they were doing Structured, but not many were. Skip forward a decade or two and everyone said they were building Relational systems. Using an RDMS is not building a relational system. And then it was OO. Etc. Just look at the relative popularity of Python and Eiffel to see how important correct software is to the majority. Sigh.
Excellent presentation. Agile (and other development processes) often fail because the current popular object-oriented design approach has a multitude of serious flaws. One of the main keys to fixing software development is to address the rotten core of object-oriented design. Functional programming is teaching us how to overcome those failings.
The language paradigm used is hardly a major issue with code. The biggest issue with code usually boil down to poor organization, poor design choices, and lazy programmers. Those all exist in every paradigm.
@@evancombs5159 The ubiquity of object-oriented programming and its associated ills causes significant issues in many development processes. Object-orientation works against agile by making code more fragile than it should be, meaning that much more re-work and testing is required to accommodate new features.
@@paulcarter7445 poorly designed code is fragile no matter the paradigm you are working in. Stop being a zealot, and focus more on writing quality code.
@@evancombs5159 The issue is that object-orientation encourages poorly-designed code - it causes a proliferation of stateful objects to be spread throughout an app - a disaster waiting to happen - which frequently does. An increasing number of programmers are aware of those issues and use only the modularization part of object-oriented languages.
I think agile isn't going to be superseded quickly and wholly, because it aligns with the nature of reality and how our brains work best. A bit like reactive systems align with the workings of the computer.
@@4yt158 Analytical perhaps not, but let me explain: I believe the nature of reality is that it's chaotic or complex at best if you look at complexity theory. That means that planning doesn't work, because things are often not predictable. To me, that means that predictions should be verified using real-world feedback. This is achieved through releasing early and often. I believe that we're unable to oversee most things in advance. We don't know what we don't know. This means any estimations are probably too optimistic and that it makes no sense to design before writing any code. I believe that the human mind works best when it's engaged playfully. For me at least, releasing early and the interaction with end-users, provides that sense of play. Every iteration feels like "the next move" in a chess game to find the best solution for this particular client.
@@RoelBaardman Having studied complex adaptive systems, I understand the intuition behind what you're saying. However, I'm looking for analytical proof that agile SW development is the best methodology...
I always thought to really be in contact with my customers. But just now realise from an agency/freelance perspective my customer is not the customer of the software. I have mixed up customer and consumer. And consequently maybe more often than not, listened to the wrong feedback.
What people mean by "The Agile era is over" is that the training market is over saturated, so now the snake oil salesmen need to come up with a new and shiny buzzword to lure Manglement into buying into their niche
And the other camp is devs that are fed up fakegile and want something that actually adheres to the principles.
Yep
Software Engineering is still the most dependent Engineering practice on decisions from people who are not Engineers. That's why we get fucked over every 2 years when the new shiny "bullshit bingo captain" comes along to tell us how much better something is, without prototyping or testing assumptions first and weighing trade-offs of the new thing.
@@morgadoapi4431 There are a lot of people trying to make money on selling coaching on a slightly different way when the way you were coached on before didn't achieve the magical results that were promised. Thanks for reminding us of this challenge.
Yep that's why "DevOps" has been weaponised as "Agile 2.0"
Indeed it sounds like "we need a new buzzword".
Excellent video! Quite so many golden bits incredibly condensed here. Felt compelled to rewatch and create time-stamps of favorites:
@0:19 At its heart, agility is about learning
@0:26 If we can improve on agile, what would post-agile really look like?
@1:50 The 4 values of the Agile Manifesto
@2:15 The 12 principles of the Agile Manifesto
@3:14 Post-agile is really a misnomer
@5:00 From Scrum: "Inspect and Adapt".
@5:23 Agile closely aligned with the fundamentals of science. That's why it works
@5:35 Scrum: easiest to cheat.
@6:18 Einstein's quote on the definition of insanity
@6:51 Build on the idea that the roots of science are also the roots of agility.
@7:00 The most agile approach to agile thinking of all is to think about how we can improve upon it (
I was very early adopter of Agile methodology, way before it was mainstream, and already then we noticed the fatal flaw with the Agile manifesto in practice: the customer.
Every time it broke down due to either customer not understanding why they should commit any of their staff’s time to the project, or even if they did, it was either a person who couldn’t give valuable feedback or didn’t dare to due to limited authority. Then in cases where the person would have had both, they couldn’t commit to semi-regular meetings either due to unexpected more important issues or lack of interest
Happens all the time
Many years back, many orgs I saw felt agile, teams with few devs using burn down charts, trying things, feeling quick to learn/adapt. The last few years? Feels like many regressed to waterfall inspired workflows. Everyone says they are agile but few seem close. Insanity meeting on the branch strategies from hell. Productivity grid to a halt because the tightly coupled software placed into a gazillion different repositories without any logical connection to how the software is built. “CI/CD” is just build servers, often not close to continuous delivery. Important test phases (integration, security, robustness) in the end of the “agile” workflow, so all issues are found late needs to go back through a lot of different “agile” process. What “agile” did not solve was making people do agile, or and how to handle lack of people with the correct experience/ know how at the right phases.
Too many "agile coaches" getting paid consultancy rates to give everyone Scrum Master certificates, without actually helping them understand the agile mindset. Too much religion, making agile an ideological battle instead of trying to find the best way to work, and certainly not making any allowance for the problems it isn't suitable for - "always agile, all the time, and if it doesn't work for you, you're doing it wrong" goes the mantra. A failure to understand agile at the management level, meaning that trying to implement it at the dev team level is impossible: "we need features ABC by date X - sure, you can do two week sprints until date X if you want to, as long as we have features ABC by then".
You're right, agile did not solve the problem of making people do agile - that's true. It didn't even solve the problem of making people understand when to be agile, and when not to.
@@BittermanAndy yah… at least if people were clear about what they are doing and why they are doing it. Stop focusing on what theory org adhere too and just see if the ways of working are sane, productive or just insane. Branch/repo strategies that brings productivity to zero (or if devs ignore the crazy strategy, create a mess of branches not in sync) is one of my favorite “why do you do that and do you understand the impact?”…. And people being “agile” but you still find out things doesn’t work very late. So far from the CD ideology, branch and release mess :-)
Agree. Especially with that last sentence. Agile is great, we all know this, but it seems that it fails very often when a team doesn't consist of 10x Devs/QAs/Ops/Sec/.../ and 10x /Mangers/POs/PMs/SMs/.../. The video says Scrum is popular because it allows for cheating, and I agree, but it hasn't addressed the question of why teams are cheating. I mean, if these agile methodologies are so great, why would anyone deviate from them? It's because doing things "right" (agile) is difficult and often expensive. If there is anything post-agile it has to be something that can be applied to a wider mix of people (both managers and tech people) in terms of experience, education and motivation.
Good people to put over processes = Expensive
Don't need "comprehensive documentation"? Hire people who can function without it = Expensive
Being prepared to respond to change instead of following "the plan" = Expensive
We need Agile for the _real_ world which is messy, often underfunded and understaffed.
@@neur0transmitter "The video says Scrum is popular because it allows for cheating, and I agree, but it hasn't addressed the question of why teams are cheating. I mean, if these agile methodologies are so great, why would anyone deviate from them?" - a very good question, which far too few people spend time thinking about.
Sounds Like Marxism with Inverted totalitarianism. The Paradox.
I never thought much about agile. As I saw it practiced, it seemed to do the job. I have never seen a worse abomination though as when it is used not for software development but as a tool to control software developers by those that know nothing about software development, only JIRA and Agile. What a nightmare.
I'm reminded of Bruce Lee's maxim for Jeet Kune Do: "Absorb what is useful, reject what is useless, and add what is essentially your own."
Back when I used to write software in the late 80’s we started out with “we do this, we do it repetitively.” Or “we need to store this info and retrieve it to do this.” I started out with the data, then built out a skeleton. Took it to the customer ran through it to see if it matched their general requirements. If it did then it was add the rest of the functionality, release it to the customer get them to run with it for a while and then revisit it and ask what they like and more importantly what they didn’t like. It was only simple stuff but the improvements to productivity was massive. We seem to not want to do that any more. Where I work now I see data stuck in systems and we have to do manual processes to get the info out. 30 years and we seem to have gone backwards.
I've worked at a place where this approach was initially taken to build what was the current platform, and you're right it works, it was a prototype initially that could be built quickly and did the job. The problem came when 20 years later when extra things needed to be added on, extra functionality, extra geographical customers who needed access to a certain part of the data through a subscription but not others, this was becoming more and more impossible to develop. You could say, well this should have been thought about after the initial prototype was built and shown and signed off, but it wasn't needed at the time and so it wasn't in anyone's thoughts. Plus it was extra work that didn't provide any extra revenue for the company and they are the ones in the end who pay the wages. The problem really is when a lot more complexity is introduced and a platform becomes so big that it needs someone with experience to look at the architecture and many legacy systems not a point where it costs more to keep hacking new bits onto a system with workarounds than it is to redesign the platform and develop it in an Agile way, releasing incrementally, switching functionality from the old platform to the new one as it gets released and eventually retiring the old one completely.
From the perspective of the industry I used to provide software for (automotive), Agile was never more than a collection of new buzz words for what was already done. Only we had different names: We had no "Sprints" (which sounds like everyone is doing over time and comes closer to a heart attack, which sounds hectic and chaotic), we had iterations. Planned. Because whenever we deliver a new version to our customer (the OEM), they have a right to know what to expect (which new features, which fixed bugs, which implemented change requests,...?). Our iterations were as such planned. Our test department also wanted to be able to evolve their test system to test the new state of the next version in parallel to it being implemented. The customer (OEM) had to manage many supplier for various devices and of course they could not write the perfect specification prior to anyone starting to work. They had the science part of what agile people keep talking about. We as suppliers hardly ever had any "science" elements in our work. We had experience and there was never anything radically new to do. So we could plan better and know which people would be best suited for which tasks. Our iterations (with new, documented drops to the customer) could be as short as 4-6 weeks. This is well in the realm of what "Agile" companies also want to do, right? And because we were but one out of maybe 20-50 supplies, it was not up to us, which features and fixes we deliver in which iteration. Because such highly distributed systems could only give insights if they all were on the same page.
So, from my view it was all about new buzz words for existing practices: Dictionary: "iteration" "sprint", "Test driven" "Every working step needs a test step, from small to large" (Unit tests, integration tests, black box tests and then the integration tests at the OEM with other devices), "Adapting and learning" (mostly on OEM side) "New insights result in change requests, which update the specification of the device to a new version, which will then be implemented by the supplier in iterations, agreed upon beforehand".
The last part is important... during the (roughly, typically 2 years of development), we typically had an average of a few hundred up to something like 2000 entries in our change management system. Of which, 99.5% were change requests by the OEM and the rest were actual bugs or misunderstandings. This is how "science" part looks like in automotive.
So what excactly is new to Agile from that perspective?
Only the words, my man - only the words.
So what could be post Agile?
The insight that new words do not make a new approach. And that people should stop taking those new buzz-"processes" as a religion or some insights from a higher power. A whole new breed of "overhead cost", I fancy, has emerged from all those "Agile, SCRUM, whatnot trainers and consultants", whose main job appeared to be to declare anything done before as being stupid and less enlightened and to justify their own, lucrative new vocation :)
You are completely wrong in your last, important part. The fact that you have a change management system that suggests to me that you had one big design which you had to change as you went along, 2,000 times, meant that all that work had been put into designing something in one big chunk before the project started in detail, and when it came to the time of implementation of wasn't what was wanted or needed. That to me sounds a lot like waterfall development. I completely understand that in an automotive environment you need everything designed, and signed off, before you start assembling the final product, and so this is why it has to be this way to a certain extent, but it sounds like a recipe for things taking longer than needed. In software development of course you need an outline with high level estimates, but how to actually implement them isn't done before you start releasing earlier parts of the product. You can't do this in an automotive production environment as everything needs to be signed off before you get to this stage, you don't design the engine as you've just released the chassis I would imagine.
@@mattpotter8725 A car consists of a (amazingly high) number of embedded control units, which are interconnected via various field buses. A supplier is typically responsible for 1 such control unit (rarely, 2 suppliers have to team up and get a share of the eventual production and sale of the unit). The OEM (car manufacturer provides the specifications of each device to the respective supplier (e.g. using DOORS requirements management systems) and there are 3 major milestones, where the OEM interconnects a set of co-dependent networked devices for testing. They are often called A, B and C sample. For each of those sample phases, the OEM wants to test how the devices work together and as such, the feature set, each device has to provide in those samples is pre-set/pre-negotiated between suppliers and OEM. In the aftermath, there a fixing iterations being scheduled (typically each between 1-2 weeks), where the findings of those sample tests get worked on (bugs fixed, specifications updated when the OEM specified something that is not working etc. ...). There is next to no waterfall involved. But there is no "we just write code and you get what we give you" mentality in that industry. Every iteration small or big is planned and agreed upon with OEM. The whole development cycle for such a project is between 1 and 2 years. And the OEM also needs transparency as for team strength, methodology and development process, which often is being assessed in the framework of CMM or SPICE or automotive SPICE process assessments.
This was a very nice video.
Great Question " Are we able to release product to production after sprint ?"
I see that Organization has put too much emphasis on processes rather than engineering practices.
The elephant in the room is/are legacy applications.
Organization thinks that they have to spend million of dollars to get their programmers trained on engineering practices (Continuous Integration, Refactoring and TDD/BDD).
They are not willing to give extra time to their developers to figure out engineering practices on their own.
Vikas
I would disagree. There are cute principles that need to be adhered to, but in every Agile team I've been in, which were Scrum and Kanban methodology, you always had retrospectives where you looked at the good and bad things in the previous sprint (in Scrum) or period of time or iteration (in Kanban) and said what went well and what doesn't, suggesting new things to try and where he things that had been suggested and tried in the last retrospective didn't work they were either dropped off adapted. Each team would do this individually and come up with good and bad things and there would be a Scrum of Scrums that learnt across the whole IT department new techniques. I think you are confusing for principles with engineering practices. I always found Agile have those at the coal face the ability to suggest new techniques and new practices whereas before this you were basically told from above how to do the work you yourself had great ideas and knew best how to do, that often didn't work. I have worked at places that left the implementation to non exists, who thought they knew what they were doing, who picked and chose what bits they liked and which bits they didn't, and in the end of became such a mess that a consultant had to be brought in to sort out the new and get everything working correctly, increasing productivity of the teams.
@@mattpotter8725 The question is "Are we able to release product to production after sprint".
How retrospectives can help if team members don't have exposure to good engineering practices that enable agile developments.
In my experience, retrospective meetings after couple of sprints become rituals . People run out of ideas how to improve sprint in future.
Retrospective meeting can be useful if we bring additional talent (can be consultants ) to bring new insights.
With Regards,
Vikas
Agile Manifesto signatory here. My copy of Agile Software Development: Principles, Patterns, and Practices was signed by the author, Robert Martin, on15 June, 2003. I worked on small teams applying agile from around that time until 2016, when I retired. I experienced the "impedance mismatch" between existing business management and the teams, but the teams were able to persuade management and get them on board. How? First, to their credit, they let us try it. And when we delivered, let us keep doing it.
The key is continuous group learning. Everyone has to learn, including managers, customers, developers, testers. Old roles had to be changed. People learned to wear more than one hat. We were fortunate to have bosses willing to have a go. With good reason, our first agile project was to rebuild from scratch a one million dollar system that totally failed to see production. We succeeded, kept learning and each project was better than the previous one.
It worked because we were able to develop a collective learning process, with sprint reviews being key. What went right? What didn't work? How can we do better? What new thing should we try? What might we stop doing?
I have a hunch that as agile gained some traction in upper management, as a buzzword, it wasn't well understood. Applying agile in a specific environment always depends on having the right group of individuals assembled. People ready to collectively learn and get collective rewards. In our individualistic culture it doesn't always work. I'm not surprised that agile has failed in name. It's always had strident detractors, too.
Used to be that the older process that used large batch sizes (one year for gathering requirements, etc.) and separation of responsibilities was said to fail because it wasn't done properly! Same can be said for agile. If the work isn't organized well, the project will fail, regardless of the methodology. Agile worked well for us, and I'm sure it still does for some teams. It's not a panacea. Agile requires even more discipline than older methodologies. Group discipline. Some groups simply aren't good at it.
Thanks for sharing your experience!
Great video, and I agree with everything you’re saying. I’ve worked at two large corporations as they shifted to “Agile” and the result was actually more dsyfunction and less effectiveness. This was because the companies failed to change their processes/hierarchy/communication (culture) while they made the shift. People hid their work, stovepiped their efforts, and kept working in the old manner while claiming they were agile.
I would love to see a video about the intersection of Agile and Conway’s Law.
"Shifting" or "Transforming" to agile is not the same than "evolving" to it. Companies and their managers forget that. Scrum's marketing tells the opposite as well, making people belive that you can start in the devs team instead of the head of the organization.
@@Cerebradoa Agreed!
"Culture eats strategy for breakfast" -Peter Drucker
No change can be implemented if a change in mindset is not implemented first.
@Dave - Absolutely amazing. This video is perfect as I've noticed similar issues from my past. I think it would be extremely beneficial if you create a video in tandem with "5 common Mistakes in user stories" is to include the (zero/one/many, INVEST, SPIDER) technique on how to break down user stories given more examples. Each one teaches me more and more!
Reading the original XP book also opened my eyes to agile a bit more since I find it helps technical readers enhance their pitfalls and enabling myself and our org to grow.
What I have learned. Collect a group of competent and smart people and they can produce a working stuff whatever way of work is used. If You collect dumb, lazy and unconcern people there is no such an organizational approach to yield any positive income. I feel somewhat 6x-10x more people in software industry than normally should.
I was thinking exactly the same, all the time we talked about the wrong things about agile in the actual software development process, we talk just about the managers and PMs, etc etc. But we always left out the “bad programmer factor” the guys who put together all this great ideas on the agile manifesto were great programmers with great soft skills. Every time I read the agile manifesto I can easily see how many programmers exists out there that definitely cannot accomplish those goals
@@abrahamgarcia2171 This is one of the challenges I have. It seems like a lot of the newer developers are resume stuffing more than they. are interested in delivering a good solid solution. It could be I have just had a lot of bad luck. I don't know if it is the devs, the education system, or the practices that don't lend themselves to good solid coding. Still trying to figure it out. II didn't have this problem in the 90s with developers.
@@ShadCollins to some degree because lots of companies lack leadership and there actually isn't anything to gain besides some additional technology names for the resume
Excellent restatement of Popper. Also praise for the explicit link between science and engineering. Well stated!
Probably my favourite video yet. I'm a big fan of the science approach and have been using it in software testing for years. Testing is all about forming hypothesises of risk and threatened value, and then finding evidence to make a counter claim against value. So I fully agree with the falsification statement, it's about time the idea that testing as verification, validation or demonstration dies forever and we take a more applied scientific or engineering approach to all software activities. 👏
"I'll see you on the dark side of the fumes..."
Love the shirt. And the video. Embracing the scientific method to develop and deliver working software will strengthen the product, improve any process, and benefit the participants.
Thanks. I was trying to work out the shirt the first time around. Just re-watched the video and got grokked it all now.
well, in my opinion it's organizations that are heavy on process, tools and contractual restrictions that are using agile wrong
That may be true, but when your customers are demanding restrictive contracts and rigidly defined processes, "we won't do that, it would be doing agile wrong" just means you go out of business.
@@BittermanAndy whenever your customer manages your work, not product no amount of tools or methodology will help
It has mostly become either synonym for SCRUM-BUT(T) mess or more heavy and complex than any formal, traditional method could ever hope to become. I think already 5 of authors of original manifesto realized, that they have been badly beaten by law of unintended consequences and wrote posts "wait, it's not what we meant".
I would like post agile to be a world that reintroduces more formality in requirements. I've done too much maintenance work on agile systems where nobody really knows what the system is supposed to do and the only ones that did have left the company
Yeah, the manifesto point about documentation irks me... While development , since everything is in flux, you dont do ducumentation. Afterwards? Nobodys paying you to do documentation on working software. So it never gets done and maintanance flies out the window. Self explaining code? Shure, by itself maybe, ut code does not explain decisions in complex system design, and finding out WHY it is this way, or if it is even still in use can become a realpain, and expensive.
In Agile software development, only the tests are the documentation. If the tests do not cover the essential functionality (or better even all use cases) then it's difficult.
@@mateiacd they only cover WHAT the usecase is, not WHY. And to not start on how the tests get adapted over changes in other features, and if the reason one was created is still aplicable...
I know that more formal intent doesnt solve all the problems, but having in mind how to convey all those meta information while developing the tests and later while adapting them kinda expects the developer to be omnicient.
With a documentation that explains what the point was you can later deduct it the tests are still applicable...or if the feature itself has become obsolete.
Also: test maintanance is easier (what aspect of a test was that way because the feature should be that way, and what was because of the sorounding workflow), and decumenting all use cases and all edge cases, while good, can become a pain to maintain. So having an informal intent how the behavior should be for later manual checks can safe a lot of time. (Obviously depending on how criticsl the feature is for operation and security, those should have comprehensive automated tests, but some UI mask tests can be a pain later on when an aditional text field can break hundreds of tests because the exact order and amount and position got checked...)
Thank you for this! I haven't been able to gather any value out of the term "post agile" when I can clearly see evidence that we are not even meeting the requirements for "agile". Seeing that there are opportunities of refinement is where there is value. More of an Agile++ rather than a "this instead of agile" approach.
Yes, it's a failure. EVERYWHERE I've worked that uses 'Agile' uses it different. Almost everywhere sees the word Agile and they hear "Abracadabra". The unfortunate truth is most shops are run by people not technical, with outdated tech, or just out of touch. Either way, if you have good requirements and a good architect, you will get through regardless of the approach. How the work is organized can help in my opinion, but you aren't going to succeed without the proper people making decisions, and that is the actual blight that I see more than anything.
I think the applicability of agile techniques is very industry and situation specific. When your customer is a large bureaucracy with a 2 year evaluation and procurement process, good luck getting fast feedback. The whole agile approach falls apart without a competent customer who is ready and willing to provide good feedback. When selling to the military or large telcos you quickly discover that these organizations are filled with clueless people. Another big problem is the emphasis on face to face communication. During the pandemic many organizations proved this is unnecessary. With many teams distributed around the globe, this type of thinking is becoming an anachronism.
Sadly “good requirements” is almost a contradiction. The often thing that makes them good is that you’re able to deliver them.
Studies have suggested that even when waterfall projects go well, there are significant number of wasted features. If customers can’t give you both good requirements and frequent feedback then you will end up with sub optimal results.
“Agile different” is unsurprising given that it’s basically nothing more than some values and principles
Totally agree with you!
When I hear the word Agile, I can almost always substitute in the phrase, we have no idea how long this will take, and it fits.
yeah, this. CD even covers it in the video... adoption fails because agile requires a change in culture, and changing culture is hard. Ergo it arguably is NOT a good way to go because you'll almost never be able to win the uphill battle against culture.
Which should start the creative juices flowing... is there ways to get SOME of the benefits of an agile culture, without having to completely rework the culture? Are there 1 or more agile practices that provide increased value, but are easily & consistently implementable? What about the agile manifesto makes it so hard to adopt consistently? Can it be reworded? Are some of the principles in the manifesto actually BAD ideas, and thus should be dropped/replaced?
And BAM... you're doing post-agile thinking. You're informed by agile ideas & the industry experience with agile... without holding agile as a creed. you aren't assuming the authors of the manifesto were geniuses & 100% correct about everything. You are inspecting & adapting... and applying that to the idea of agile itself (which is what you should have been damn well doing in the first place).
Long timer here. You're exactly right. I've seen a lot of teams quacking Agile vocab like flocks of geese, much fewer actually being Agile. And thousands of consulting and "training" hours billed along the way (not by me). Your question, i.e. have we actually done it? ... is on the money.
Unlike most of the commenters here, I have seen the success of agile.
Maybe, because I started my career in 2001 on a project with a 500 page spec. It was painful give me iterative.
In terms of planning XP is seriously dated but it’s technical practices are spot on and more and more mainstream.
Maybe also because I’ve worked in London where there are a lot of highly experienced (old) developers.
That said, there is room for improvement. Here’s two examples.
I saw part of the agile movement as a response to the trend of offshore/outsourcing at the time. These days, I don’t think that we need to be so strong. The internet has changed things and I now work with an entirely distributed team.
“Working software being the primary measure” is rubbish. Success should be measured against business outcomes.
"Success should be measured against business outcomes" - YES. Your software works but you have no money? Sucks to be you!
@@BittermanAndy Well, problem is, that in most cases it means "less software" rather than more.
The best thing about programming is that the information is so vast, that people do not peak untill their 60's.
I say this with reverence and respect.
😂 no offence taken
Agile is, in the end, just another aproach to sorting out the task of developing a complex system, not a magical solution. Depending on the system, customer, industrie, etc it is can be a solid aproach, and with others it can lead to a total project failure.
Is it a system that is dependent on all components working and needs to be done to this timeframe, no delay accepted? Yeah, a moving target with an agile aproach is probably not the best. Is it an online service that can get iterated on (Netflix, etc)? Shure, do agile.
A technical system without much user interaction? Probably more specification and less "user feedback" needed. Research or prototyping? Agile, the faster the better.
Agile is one tool of many, not the the key to every project.
The main problem with agile is not necessarily the core principals. Its that the process has been coopted by management focused on sprints, deliverables, features that can be checkmarked by the sales team, and building an assembly line out of software development. At its heart, agile is actually a bottom up organizational approach that allows those closest to production and actually using the software to make decisions, respond quickly and build the software in a more efficient distributed way. Those principals still apply. But as long as we co opt the process and introduce rigidity and insert strict roadblocks in the decision making and workflow, it will not be agile, but rather another set of speed bumps that will eventually go to the wayside for the next big thing. The key is that any workflow must fit naturally with behavioral economics in order to encourage the aspects that we want to build up. And adding complication and speed bumps and removing the ability for people to make natural decisions is counter to our natural instincts.
I am a new developer and this video breaks down this concept quite nicely.
I have always wondered if there are different or new approaches to building software.
Excellent and insightful talk. Thank you!
I've watched development change over the 30 thirty years, failing to learn and inventing "new" stuff all the time for now real better development practices:
- Thinking a new framework will fix things oh don't like LAMP - lets use .Net oh we hate that lets move to NodeJS
- In the rush to move away from Waterfall we decided design wasn't needed either.
- After 30 years of grand promises of reuse, we still write so much code from the ground up. Imagine if we had to construct a new paint factory, everytime we wanted a different colour. Yet we do it development again and again and again.
- Poor testing
- Developers telling users there business processes are wrong, rather building what the user needs.
- Going hand in hand with the above, developers making poor efforts to understand what the purpose is on the software they are building.
I imagine if the construction industry put up buildings the way software development is done. There'd be no plans, each building would use different sized doors, windows, pipes etc. run on different voltages each floor would have a different roof height.
I often see Agile as a fix to poorly software construction practices. The same way buildings that have many design changes suck, so does some much software.
So who are the main forces that propose post-agile in the first place? Developers, managers, influencers... or agile coaches?
coaches, hustlers, partners, consultants....
I don't know and don't mind. We must want to go proper methodologies with good practices in place. Agile was a power-grab from non-tech people to remove tech and engineers from influence. A trap we all fell on, a trap we can get out of though
Hoh that conclusion! Really good video to help inspire Programmers to become Software Engineers and Software Engineers to do better.
Geeze Dave thanks! Suplimenting my own learning and development with your shared insights.
Currently working hard at bringing in and showing benefits of automated testing at work.
I've been making leaps and bounds in this regard. I've been increasing my knowledge of quality code because what became immediately apparant is that if you didn't code with testing in mind code is often very difficult to test. So refactoring is at the order of the day! This is a skill in itself I imaging.
Would be awesome to have your take on refactoring! It's becoming a lot better but I struggled with things like what will the dev think who's code I refactored. I found some older code that my boss wrote that I felt needed some love.
Great journey and enjoying it a lot.
Thank you for the awesome content!
Keep up the great work!
Ha! Went and searched! Looks like you have covered it! Going to have a watch! ruclips.net/video/p-oWHEfXEVs/видео.html
Checkout the stuff on Refactoring on my course site - it's free, courses.cd.refactoring
Awesome will do!
I find that 99% of resources on agile focus on how you work in an agile manor within an organisation. However it's very difficult to fully move to agile processes in a B2B environment if agile is not applied at all levels of an organisation this intially starts with sales and what you are selling the client. The hardest part of apply agile within an organisation is this sales process what do we sell to the client, how to we cost a project, who is taking risk in the contract at what level. A client is generally looking to fix scope and cost and reduce risk in their contracts this is antagonistic to agile processes. I would argue this is the much harder issue to solve in deploying agile within an organisation but gets so much less focus in resources on agile.
That is the problem, the whole solution is being sold up front as a waterfall, unusually by a some account exec and probably with your technical input. Typically you also have to delver the goods on time and within budget so the exec gets the reap the benefits and praise etcetera, while you are the unsung hero if it succeeds. You will bill your hours once off, and the customer will be perpetually charged the value. Personally I would like to somehow earn passive income from any efforts as an incentive to keep the product viable as well.
I agree with much of what is said but would add that adoption of an agile software development approach inside a traditional business and budgeting model where senior managers commit to fixed deliverables, costs and timelines, are unwilling to delegate and unable to be involved with the development process is the usual model I see. Business management needs to evolve to allow agile approaches to work - or in a few cases maybe agile approaches do not meet business needs.
One thing I've seen a lot, pre Agile, was the addition of new requirements from the customer late into the development cycle that would generally cause some significant rewrites of code which would cause a delay in completion. Agile seems to start at base functionality, then collaboration with the customers to get the rest of the functionality of the product worked out at each stage.
Amazing work in this channel across the board. In case you're open to suggestions: I would really like to see a full video about SAFe to hear your perspective on it
I love this as a pitch for continuous delivery! When I've gone into 'Agile isn't working' environments I always found terrible development practices. Teams could not release reliably, so they could not estimate and therefore product could not plan.
The grand process all falls apart because final step fails.
Once we get teams confidently executing they tend to not care about the 'big A' agile process because all of sudden work is flowing and efficiency is up.
I'm not saying all teams who love Agile are excellent developers , just saying that in my experience teams who fight agile are projecting engineering problems onto process.
I think the problem lies in how quick the industry moves. You're right in saying that it's probably from bad development practices a team can't have a releasable product every 2 weeks. But by the time everything gets solidified and the team can get their bearings after having development goals to meet while also trying to learn new technology, the next thing is already out and you have to learn that.
A lot of products I've worked on have been releasable every 2 weeks, but there was still a ton of tech debt because people forcefully writing pieces how they knew best. Not to mention having to work with old code bases and make them up to date without funding from starting from ground 0. So at what point during agile do you let your developers catch up? Your good ones pretty much live and breath software development so they spend a lot of time outside of work learning and researching, but that's not normal for most jobs.
agree with those words. "Once we get teams confidently executing they tend to not care about the 'big A' agile process because all of sudden work is flowing and efficiency is up." / "teams who fight agile are projecting engineering problems onto process."
Very nice and well-put thoughts. Kudos. But what happened to the Weyland-Yutani Corporation? Did they stop using continuous delivery? 😉
No, they are still strong supporters 😁🤣
As one who has met some of the original agile thinkers. I agree with you 100%. It was always about delivering software.
I think the term iterative development may be a better way of describing agile. One small step at a time. Continuous delivery from the first "hello world" to the finished product.
I also think solid thinking is encapsulated in the Rational Unified Process:
en.m.wikipedia.org/wiki/Rational_Unified_Process
This videos are small pieces of art !!! :)
Doesn't the whole agile thing miss the fact how contracts and customers work? Manifest says: "Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software." - well most customers have fixed schedule delivery written into the contract and aren't even interested in beeing flooded with CD.
Not really, any more than any other approach. The idea of fixing time and scope is an illusion. Sure, it would be great if you could, but you can't. Ever hired a builder or a plumber? Ever talked to a startup about when the venture will succeed? These are all guesses. Agile admits the reality of this, You can work to a fixed date, but vary the content, or you can deliver fixed content, and vary the schedule. This isn't new to agile, people have spoken about this in planning for decades before, it is just that many businesses run on superstition and magical thinking rather than reality.
There is a great quote from Matthias Fischer from Toyota, "Everyone wants to be lean until they find out what it takes." Same with Agile (they're kind of the same thing anyway).
For a realistic "post-Agile" view, I recommend listening to what Joe Justice has said about his time at Tesla. He mentioned that he now considers "individuals" to include robots and scripts, for example. Tesla supposedly has 3-hours sprints. I'm not sure about the specifics, but it does sounds like the Musk companies have had to go beyond what is currently considered Agile, although it's probably more of an extension/reinterpretation of Agile than a completely new thing.
I'm still trying to wrap my head around this from a small dev perspective whom is also a noob. Would "release working programs in smaller sprints and get feedback faster" mean say...if I were making a video game, perhaps release the game to the public after only having say a world to join and ability to move in it? even if there is nothing to do because it's not implemented?
You don't need to be agile if you know what you are going to create and have it worked out all the way up front. In a perfect world, you would only have one iteration and that would be it.
Users doesn't need to be external users. But the main point of the Agile manifesto is to get started - and adjust as you go. It doesn't hurt to have a plan up front, but as long as you have a rough idea of where you are going, that's often good enough to get started.
No, you don't have to follow Agile as it is an Intellectually and ethically bankrupt idea. Only snake oil sellers insist on it.
Great video. Enjoying your book too!
Do you have a list of employers who practice continuous delivery and scientific rigor as you describe?
I think you point about technical over management is an interesting one I believe that is why video game companies often have disastrous launches for games.
Preach it my friend!
Agile is an adjective. The agile manifesto set goals we should aim for in order to think agile and work agile. Linguistically there is nothing past agility. There can only be the opposite. Agile means 'move quickly and easily' or be 'quick, smart and clever' (Webster). The opposite is be stupid and slow. You can be more agile when you can deliver even quicker. But essentially, I am agreeing again with your video.
So amazingly on point. Refreshing talk! And despite all my expertise managed to further refine my insights :-)
Thank you! I'm glad it was useful!
Hello, RUclips Algorithm just sent me your video 😷. Great talk on True Agile, Scientific method and engineering. Thank you 🙏👍👍👍
Thanks for the feedback. I'm glad you enjoyed the video, and I hope you stay a while and find some of my other stuff useful!
Ok hear me out, I am not one of these anti agile guys however in my experience working in a big company (who funded a lot of r&d projects and mvps) many of them don't want to work agile. This starts that they don't check progress regulary and instead check progress on their internal milstones every other time. Often leading to frustration when it is not as they expected. My other experience is as a developer having customers who were often annoyed when they changed requirements and then recived a build with not much visible change and more progress under the hood. Also they often hate to write their requirements down and instead prefer long meetings where they tend to try and discuss everything.
No requirements while they expect Devs to commit to a very specific date a very specific and amount of work
Aaah, I enjoyed this one greatly!
Glad you enjoyed it!
Excellent video
I would hit like a thousand times in this video if it was possible. Amazing narrative, thanks for sharing.
Agile is like building a go-kart as you are rolling down the hill. Then at the end when you see another hill in front of you, you realise that you should have built a car.
Have you been watch SpaceX build their Starship. That is agile engineering in practice.
@@ContinuousDelivery Have you seen any of ThunderF00t's take down of SpaceX? That's Musk hucksterism in practice. SpaceX's main goal was to build a cheaper rocket, in fact it's more expensive.
Also SpaceX developed for themselves, not for an external customer... That makes a huge difference.
@@pejicandrej SpaceX would have gone tits up if it wasn't for DoD and NASA contracts. SpaceX lucked out with the retirement of the Space Shuttle.
Sure, but even if nasas contracts helped them, the core tech is their domain and they directly benefit from the developed product. Its more like amazon and their tech services then the normal software house where they dont benefit from the product itself.
the problems with Agile are:
1. rapidly releasing software to the customer often times results in a customer experience that is suboptimal because it feels unfinished and this then drives the customer away to a more finished product
2. prioritising value to customer can make it difficult to improve the developer experience which can drive talented engineers away and without talented engineers it is difficult to develop and release quality software
3. the entire process makes it extremely difficult to justify exploration of new technologies and tools which leads to bored engineers who leave the business or who just do the bare minimum leading to a suboptimal customer experience.
I think those things are what I would expect post-agile to address
iism.org/ has some interesting articles and takes on everything you mention. I don't know if I would consider them "post-agile", they certainly advocate for Agile, but also put forth many other principles and concepts of management, business, and organization, that are generally absent from Agile (as well as absent from the manifesto).
Yes, the main thing is that Agile says too little, it doesn't tell you how to improve your business correctly, it doesn't tell you how to innovate through technologies correctly, nor does it tell you how to retain talented engineers. This is both bad and good. Bad in the sense that it doesn't provide an answer on all those questions you pose; but good in the sense that if it were to try and provide an answer, it would over extend its reach and become more brittle, become outdated faster, and basically be wrong from the get go, since it'd be almost impossible for such manifesto to come up with the correct answers to all of these (even if such answers were to exist).
@@gonzalowaszczuk638 I wouldn't want Agile to dictate solutions to the problems it creates; I would just like it to not cause those problems in the first place. By stating it's mission in the way it does it leads to the interpretation that you must always release something of value to the customer at the end of each sprint. Changing this to "you must always release something that provides value (saving development time, increasing profits, increasing NPS, etc.)." means it would then be easier to justify new tooling, process changes, bug fixes, development pipeline enhancements or things that will eventually come together several releases down the line to provide customer value (in a meaningful and user-friendly way).
@@bicarbon8 If you want to get technical, the manifesto answers your question:
"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."
"Continuous attention to technical excellence
and good design enhances agility."
You should prioritize that new tooling, process changes, bug fixes, and development pipeline enhancements.
Rereading your original points:
- #1 is debatable, since without doing Agile your product would not exist, it would only exist 10 months from now after "finished", with Agile at least the customer gets something now. Foregoing Agile doesn't give you magical powers.
- #2 should be included in the above principles from the manifesto. The developers have to be motivated, the team has to be motivated. Give them the tooling that is necessary
- #3 If the team is self-organizing, the team can decide to perform these new explorations. Otherwise, this seems to perhaps be more of a R&D decision, and likely also include the whole organization outside the team too (depending on the reach of these "explorations"). However, I would advise against trying "new technologies" just for the sake of trying new technologies. If they are not accompanied by adding value to the customer or the business, then are they worth it? You are basically shuffling things around just to have developers try a new toy, that's not good engineering. You don't tear down a functioning bridge just because the civil engineer wanted to try a new type of cinder block that is becoming popular.
@@gonzalowaszczuk638 in response to your comment on #1 being debatable: you needn't wait 10 months to deliver your product, unless of course it requires 10 months of work to provide something valuable and user friendly, but providing a small piece of the end product to the customer each sprint doesn't solve their problem and risks leaving with the same feeling as not having anything would. If I want a car, giving me a skateboard doesn't solve my problem unless I only wanted a car because I didn't know skateboards existed and I'm young, fit and never need to carry much around with me. I simply think that encouraging constant releases containing customer value every 2-3 weeks results in value that might end up detracting from the overall experience because teams will seek out quick wins instead of delivering towards a unified experience and giving the customer access to something too early can negatively impact their impression of it.
With DevOps/CD approach, you don't need sprints
Bingo. The DevOps revolution solved many of the problems that various other methodologies failed to do
There is no doubt that Dave Farley is absolutely right in all that he is saying in this video. One should be guided only by the Agile Manifesto and its values and philosophy. And that means those values and philosophy should be burnt into your brain and heart. Everything else is just ceremony.
I believe Agile has been adopted largely because it is more useful for *management*. They can identify programs going off the rails more quickly. There is often no focus on what makes *developers* more effective. Teams living in a silo and not communicating, at the right level, with other teams is the biggest problem. Small talented teams that know each other need less Agile, larger and less talented teams need it more. Management just cares about tickets being closed while developers are bad at creating new tickets as a task is revealed to be more complex than originally thought. This can lead to being seen as "non-productive", which may not be the case. Many developers just see it as a constant distraction. I see a large benefit when a team has "analysis paralysis" - just DO something, learn, and iterate. I've done successful waterfall. I believe it depends on how well understood requirements are.
My team is highly productive. We have successfully completed many projects on time and follow agile very informally. In the last year, we have been asked to convert our legacy systems to be cloud-native. This means months of development that result in backward compatible APIs that doesn't result in customer-facing features. We have been criticised for not being agile, and I understand why; however, we are still delivering consistently. I feel that our current work steam is not conducive to agile, but we are still criticised for our agileness. At this point, I think agile needs a rebrand as it doesn't work for all projects.
Well, the way that you can tell wether you are working in an agile way is to take a look at the agile manifesto. It is not very proscriptive, but I think it is pretty universally applicable. Lots of people have a naive view of what a user-focus means. It is not just about user interface features, the usability and utility of your system is about more than that. So I am perfectly comfortable doing work that is "of value to users" deep in the stack.
@@ContinuousDelivery thank you for your insight. If only the corporate drones could see that the original manifesto wasn't about theatre but about how to deliver reliable software. Sadly I'm not very good at politics so we are at the mercy of our corporate overlords.
Would you concider making a video about how to handle databases in continous delivery? And also maybe infrastructure upgrades with as little downtime as possible. Are distributed databases the way to go?
I have already done a video on some aspects of this: ruclips.net/video/JPfbjKl9jbw/видео.html
@@ContinuousDelivery Awesome! Thanks for the quick response!
Its the classic problem. Devs are obsessed with code, DBA's are obsessed with databases, Infrastructure are obsessed with, well infrastructure. Nobody seems really interested in the system. The amalgamation of the 3 into a coherent working thing that the salesmen have sold. Agile was always a counter to RUP and its like , RUP was always a reaction to RAD and the early days of mass IT, If you have been in the business long enough its just a depressing circle.
RUP is much better than Agile to be honest. Anyway, I can live with a simple iterative/incremental process with proper requirements elicitation phase and design phase. I can't live with Agile in endless conversations pretending good stuff will 'emerge'from that like in fantasy because good design don't emerge from random talks from non -tech people
you are inspiring, though i came to think that a management can only ever pretend to be agile in that it is never the one that endorses in its mind and body the responsibility and burden of a releasable software.
What's post agile? Science! Love you man ❤ - I am your fan!
As usual, I agree with your overall sentiment, the same line of thought was applied to the criticisms of OOP.
But on that note, I don't think Einstein ever said that.
Yes! You’re absolutely right. People pooping on agile never really worked in agile way.
More.
Pls. Thx.
I really like this: Dave, Agile, CD and Pink Floyd in one video. (BTW I fully agree)
Where the Agile manifesto fails is that the authors did not include a list of underlying assumptions. There are some significant ones to be certain.
I 100% agree on that.
I think it is very convenient when a process fail to blame everything but the process. The reason a lot of teams fail to implement agile successfully is because agile itself is a flawed process that will never be the one size fits all solution some people would love it to be.
As I said in the video, agile is defined by the agile manifesto, so which parts of the agile manifesto are flawed?
@@ContinuousDelivery For starters: "Working software over comprehensive documentation" and "Responding to change over following a plan" - both which loosely translates to "tons of billable hours / works on my machine" and "I have no idea what I'm doing / let's bleed customer dry". Really, I thought it is channel for grown-ups. Agile was created to address VERY NARROW case where one can NOT define requirements in advance, not when everyone assumes that these are not needed. This is work organisation pattern for small tiger team NOT project management methodology and certainly not absurd on SAFe.
@@piotrd.4850 Well I have seen it work for about a thousand developers working on the same codebase, so not just for small teams. Commonly for teams of hundreds, composed of many smaller teams. I don't understand your translations at all, they seem non-sequitur to me.How does "Working SW over comprehensive docs" relate to "only works on my machine" the definition of "working", at least for Continuous Delivery is being useful to users in production. "Tons of billable hours" well only if you are crap at writing code perhaps, the teams that work the way that I describe produce measurably higher quality software more quickly, not less, so actually fewer "billable hours". Read the "Accelerate" book or the "State of DevOps reports". The companies that work this way are not "small agile tiger teams" they are often some of the more successful companies in their fields, Amazon, Google, Microsoft, Tesla, SpaceX, Ericsson, Volvo, US Air force UK Government, the list goes on.
@@ContinuousDelivery Aligned on everything you said in the above comment. But curious to know more about the last line. Do organizations like Amazon and Google practice any Agile frameworks like Scrum, Kanban ? If not, what do they have to ensure their way of working is Agile ?
@@sujithsukumaran8689 "agile" development isn't defined by "agile frameworks" it's defined by the agile manifesto. Following a framework like Scrum doesn't guarantee agility, in fact most teams that claim to follow Scrum aren't agile in the sense of the agile manifesto. Scrum, and any other "agile framework" are more like training wheels for agile practice.
Very interesting !
Not only has Agile not failed, it's ubiquitous. Build small, break small. In the real world, work processes are constantly evolving, so must the digital assets that we create to implement them. Anything that takes a year to ship will ship obsolete.
"Now, I'm a nerd" made my day.
The problem with "Agile" is that it is used as a noun, like something you can sell and buy, a fixed recipe you do implement, not as an adjective, which is a trait your processes have, if you design them with being agile as a target, i.e. questioning and shaping the processes itself.
Yes. Definitely. Next question?
The problem with Agile is that it means something different for every person. There is no definition of what it means to be agile. The whole trend started with a vague manifesto that set down some guidelines, then others ran with it and tried to turn it into these specific things. When that is your original source for your process of course everyone is going to do it differently.
This is why Agile is bad. There is no set definition. Everyone is able to make it whatever they want it to be. This is why people crave a post-agile world. They want a process that is well defined, and has a clear benefit.
The Agile Manifesto says all the right things, all the things that make people feel warm and fuzzy inside. The problem is those things are not always conducive to predictability. People crave predictability. Not just managers, but developers too. Unpredictability often results in poor results and delayed results. Usually what you need to get good results is a strong well-defined process that is flexible. People over priced sounds nice, but it's wrong. Working software over documentation sounds correct, but it's wrong. You need a process that values people. You need good documentation in order to create working software.
I also have a question do you think that there are situations when waterfall is a good approach to coding ?
It is still valid for building something to begin with and then using agile to maintain it. The first version of a finished product is difficult because frequently there is only an internal function that no one outside of development can see at the end of a sprint.
Yes it is. Don't listen to anyone telling you it isn't. Software development (proper software development) is plenty of methodologies: interative, iterative/incremental, evolutionary , RUP, and of course waterfall.
If someone insist too much on Agile, be careful it might be an snake oil seller. To this point such word is almost a red flag.🔴
@@ShadCollins not always agile. You can maintain it with iterative incremental. Won't mention RUP because for a one-person project it is an over kill just as Agile is an overkill.
When my manager told me that Agile is the "best" software development methodology, I asked him to prove that analytically or scientifically! There's always scope for improvement and who knows what the SW industry is going to adopt after another 25 years?
I don't think it's possible to measure agile in total isolation of things like trying to measure weight. A better question is to compare agile to not agile. It's it better to value prices over people? The agile manifesto is about qualities that good software development practices have.
There is also a book called Accelerate that does have data on this though.
@@folie-n3t I read Accelerate but I want a proof that Agile is the "best" like how it's proved in math and science...I do understand that it's not possible ;)
My experience is that a hybrid approach works best. It also depends on what sort of company you are. If you are a company that isn't a B2C offering or a tech-only company, then agile has a harder time getting started. I usually work for manufacturers, financial services, or retail. Their job is to sell their product, not build technology. They need technology to do it effectively but that isn't their core business. Starting off with waterfall and then maintaining with agile has worked pretty well but a lot of the younger coders think scrum is agile and that react is the only way to write websites. That is what they were taught a few years ago in school and they have plenty of ego but limited experience. A number I have run into have also never had to maintain their own code because they leave to go somewhere else for 20k more. They keep doing the same thing at different places. They aren't learning, they are repeating but at a higher salary. Other people probably have different experiences but this is been mine. I have had some wonderful developers but they have been coding since the 90s or earlier, are careful, and do their best not to repeat mistakes they have made when they had to fix their own bad ideas.
There are already better methodologies: incremental, iterative, RUP.
Anyone heard about six sigma? This was way back when GE was bigger than Microsoft in market cap. Then everyone started doing six sigma and everyone was six sigma certified until GE imploded and became an example of how not to do things.
Six sigma started in engineering and then slowly became management speak. With tech companies being top market cap, it's only logical that agile which came from software becomes the next six sigma and everyone and their dog being an expert at agile, the cool kids move away from it.
Agile was trendy when it was used in big tech but nowadays it's become a buzzword that's been muddied with $10 courses promising expertise and did I mention RUclips?
Have ever big tech used Agile? On the contrary, big tech and the most successful market leaders don't do Agile nor Scrum.
Imagine your job is to deliver mail, and suddenly management decides you have to justify, in agonizing detail, exactly where you are going to place each foot on your route. How far your are going to bend your knees during each step, your elbow during each time you reach into your bag. How long it will take to walk from each mailbox to the next. And: why, on your previous route, sometimes you ended up taking longer strides than predicted and sometimes shorter ones, and why the knee and elbow flex angles were sometime off, and how you are planning to fix all these problems.
Welcome to Agile.
Seeing how people go down a "SCRUM" path and comparing with what's actually in the Agile Manifesto ... there's often little resemblance.
Isn't the way we wrote software pre-AGILE more the engineering methodology? Agile seems to lend itself to putting out a lot of broken software due to lack of discipline on the team and the urge to rush everything out with a simple unit test written by the person who wrote the software (fox guarding the henhouse).
@@thisolddown I've never seen it not be like that. After people implemented Agile, the agile coaches told them they didn't need QA departments. The executives love that so they got rid of their QA teams. I saw this at a company I was at and also at my wife's company. Quality control is now terrible. It got so bad at my wife's company they started getting complaints from customers so they had operations people start doing QA on top of their normal jobs. Not that the operations people are well qualified to do QA work.
@@thisolddown One more bit Sean, I'm not looking for validation on whether to use Agile or not. I am looking to see if II am missing something. I have been in IT for 35+ years and you have to keep up. I keep being told Agile is the end all be all and I am just not seeing it for companies that I work with (e.g. real goods, services, financial, etc.) It seems like a great idea for websites but I can't figure out how to apply it to things with specifications and deadlines.
@@thisolddown Why would the CEO or the Board change the business model to accommodate what a group of individuals in IT want?
You are right. We need proper engineering methodologies to come back. Only thing Agile did was remove documentation, proper design and let non-tech people to make engineering decisions removing engineering from influence. A power grab.
Very few did anything close to agile. Most had Scrum imposed on them and the unlucky had it as SAFe. Agile was declared dead by those who made the manifesto years ago. We are still "pre-agile".
Agile is all well and good but it does not consider one aspect of software - can you tell me what that is?
where do i get that tshirt?
It took us many trainings and multiple tries to make agile (scrum) work. If it’s so hard to make it work, maybe there’s room for improvement?
I think one of the issues is that new developers think agilie is scrum. Scrum is its own thing on top of agile. You don't have to implement scrum to be agile.
I had to make a pipeline to always pass because Senior developers did not write tests. And organisation looked at me as a blocker of the progress.
It appears that "Agile" ignores the reason why bureaucracies even exist, and how they form: proficient people at the bottom, not the top, start to document what they are doing in order to improve the efficiency and working method of their colleagues, while the top - the bosses take those documents and shoe-horn the production to conform with these documents. This they do in order to get a slow organization that works however incompetent its workers are, because the organization grows and a bureaucracy is the easiest way to get an automatic competence improvement for newbies. Agile makes it almost impossible to hire newbies, so it becomes an isolated organism that cannot grow, and when people leave, the competence of the organism decreases.
In my experience, "Agile" has just been an excuse to throw process, design, and documentation out the window. The poorly-documented & unplanned code isn't released any faster, nor does it have fewer bugs, than any code created via a waterfall.
Well I suppose that may how some teams do it, but that is not what agile says or does. The highest quality system that I have ever seen, let alone worked on, was written using agile principles by the most disciplined team that I have ever worked with. We did some very cool stuff faster and with higher quality than I have seen before and solved some interesting and difficult problems along the way. Oh, and it was in a heavily regulated industry too. So I am afraid that I disagree with all of this.
@@ContinuousDelivery that's personal anecdote seasoned with some personal opinion. Science isn't built on anecdotes
@@rmworkemail6507 How do you know, I don't describe the science bit here? Science is an approach to discovering new knowledge, one take on modern engineering is that it is a practical application of scientific approaches to learning how to solve problems.
The scientific method is:
Characterisation Make a guess based on experience and observation.
Hypothesis Propose an explanation.
Deduction Make a prediction from the hypothesis.
Experiment Test the prediction.
You can apply this approach to development in a wide variety of ways.
C: The user has this problem
H: I think this test describes something that represents that problem.
D: When I run this test, I expect it to fail with this error message, 'cos I don't have any code to make it pass yet.
E: run the test and see if it matches the results.
There's a lot more that we can take from science...
Start by assuming that your guesses, designs, understanding is wrong, rather than right, and figure out how to falsify your ideas ratter than prove them.
Control the variables, so that you can clearly see the results of you experiments.
So I think it valid to talk about applying scientific style reasoning to SW and when we do, calling it "Engineering".
I think, agile failed in exactly one thing - it failed to convince developers, that it is pro-developer. No one knows that manifesto for agile software development was written by group of nerds, who wanted to have healthier working environment. People don't see connection between it and their everyday working routine. There are substantial stuff, that developers do, and there are "another innovative aproach", that managers happily demand from the workers and then show to each other in reports and presentations. And agile seemingly belongs to the second category. "How it can be about development? It does not say anything about architecture!" - that's what I heard from one of my colleagues, when we discussed this topic. Probably, it is because programmes like concrete, material stuff, they don't like philosophy (usually), and agile manifesto is anything but concrete. So, it was picked by people who haven't written a single line of code in their lives, but publish their opuses on deep meaning of "interactions" of "responding" and its implication on scheduling team meetings.
Hahaha. “…and have meetings without any chairs” 😂
LeSS of Scrum, please :)
Could someone help educate me here on Agile's origins? From what I can tell it was created by a bunch of guys that all worked for tech companies. Is that why it is harder to make work inside of traditional business that works on deadlines? Or is there something else I am missing? I have been doing the deliver fast and iteratively before agile existed but a lot of other things that go with agile seem geared for technology companies or startups.
@@thisolddown I guess that is part of the problem that I see with Agile. It seems to work best when there is infinite time and budget. Before I can get a project approved in most companies, I need to be able to tell the steering committee or board how long it will take and how much it will cost. I can provide a range but that is about all the allowance I am normally given. If it is a regulatory project, the deadline is fixed and it is just a matter of the best way to do it and how much will that cost. Regulators don't care how unreasonable their timeframe is, you simply must comply. I haven't found that Agile holds up well in these normal sort of business scenarios. If someone knows how to make Agile work in these situations, I am all for being educated on how to pull it off.
@@thisolddown I appreciate your thoughtful write-up. I think one of the challenges is that developers are trying to achieve what no other department in a business gets. Many departments are told what to deliver and by when. The only variables you control are how many people it takes and how long the hours are. It does feel like a situation where developers have decided they want their cake and to eat it too even though no one else gets to do this. Infrastructure is frequently given deadlines, budget constraints, no more staff and told to make it happen. I've seen plenty of internal legal teams told to get a deal closed and they only have so many people so they outsource pieces of it but the deadline and deliverables don't change. At times there are projects that are negotiable but a lot of our lives in corporate are ruled by constraints we didn't come up with.
@@thisolddown A) I really appreciate you talking back and forth with me on this. B) I think a lot of companies don't really fit in with agile. There are some great ideas from agile like talk to your customers, frequently and often. A lot of us were doing that pre-agile. My wife works at pretty big public healthcare company that has a huge tech arm. Among her hats is what would be a scrum master. They don't call it that but it is what she does among other things. They are frequently handed dates by either the federal government or sales that committed to something without talking to anyone. So they do agile and scrums but it doesn't matter because what they do is figure out how many two week periods between now and the deadline and break up the task to get it done into sprints and people put in as many hours as it takes to get the deadline,. It is a perverse implementation of agile but it is still labeled as agile and successful even though it isn't agile at all. Her company might as well not be agile and would achieve the same results but without all the religious ceremonies every day of stand-ups. They don't use burndowns because management won't accept those for project statuses so they keep a separate excel sheet for the project status maintained by a PM. But the company thinks it is agile.
There are some awesome concepts from agile but we did a lot of those pre-agile. There are some phenomenal mind-blowing sort of things from CI/CD if your company needs to do things at that velocity or is a B2C company. The hang up I get is it seems most of the devs treat agile as the bible and refuse to admit there is any other way to doing it or the young ones seem to be corrupted into thinking deadlines is not a thing.
I am still trying to figure out the middle path. I don't believe in dogma or holy wars. Just in doing the right thing and moving the company forward. Whether that is with agile, scrum, agile 2.0, post agile, water/agile, whatever. I am results-oriented.
@@thisolddown It seems like this sets up a constant fight between the developers and the business that pays them. Development, much like IT, use to be about being pragmatic. Now it seems that is gone and it is a my way or the highway from the development staff. Is this what you are trying to tell me?
The best tools are great to have, but with lesser skilled people they are practically useless. Conversely, great skill can do wonders with sub-par tools. Sometimes, you have to plan certain stages out, and it takes vision to know where the end goal is. Other times, its difficult to see the ultimate goal until you run 100 miles so you can see the next horizon. There are many tools in the toolbox, and agile is one of them. Bad communication will make any project fail. Haste often still makes waste.
I think that agile is more than one of the useful tools in the box, even more so if I am correct in thinking of agile as an informal adoption of some scientific fundamentals. None of that means that I disagree with what I take to be the thrust of your comment, sure, no process allows us to take our brains out of gear. If there was a cookie-cutter recipe for writing software, we could automate it, and do ourselves out of a job in the process.
Software development is a complex, difficult task. At the limits, it is one of the more difficult things that we as a species do. Sure, most SW dev isn't that hard, but some of it is, and one of the difficult things is that even when you are doing something simple, like a server less function or a web-page, you are skating on the surface of some genuinely difficult, maybe even profound, problems. Ideas like coupling and concurrency, for example are world-class difficult, and impact teams even when doing relatively simple things. So having some discipline, some organising structure around which we shape our ingenuity and creativity seems more important than just picking tools from the tool box. It helps keep the beginners away from the deep end, and it helps the experienced people to build on, and enhance their own work as their learning deepens.
I agree with you, I started coding in an "unworthy" language. Everybody said it was crap for what we needed to do but using sound design and a flexible architecture we ended up with a product that beat the competition in features, speed and robustness. We were always refactoring and making small improvements and always blowing people's minds on what we could do with such a technologically inferior language. It took 15 years and the advent of the SAAS model before that language was replaced by something webfriendly.
Your videos and software engineering are so good, I constantly want to share them with my students. Unfortunately, I have to keep inserting caveats that “this person is a complete philosophical ignoramus, so ignore every philosophical thing he says.”
I find that most people and organisation confuse Agile with Scrum. The two are mutually exclusive.
Who does Agile now?
Certainly NOT everyone who says they do.
We've seen it before, ad nauseum. In my career it started with Structured Programming. Everyone said they were doing Structured, but not many were.
Skip forward a decade or two and everyone said they were building Relational systems. Using an RDMS is not building a relational system.
And then it was OO.
Etc.
Just look at the relative popularity of Python and Eiffel to see how important correct software is to the majority.
Sigh.
Excellent presentation. Agile (and other development processes) often fail because the current popular object-oriented design approach has a multitude of serious flaws. One of the main keys to fixing software development is to address the rotten core of object-oriented design. Functional programming is teaching us how to overcome those failings.
The language paradigm used is hardly a major issue with code. The biggest issue with code usually boil down to poor organization, poor design choices, and lazy programmers. Those all exist in every paradigm.
@@evancombs5159 The ubiquity of object-oriented programming and its associated ills causes significant issues in many development processes. Object-orientation works against agile by making code more fragile than it should be, meaning that much more re-work and testing is required to accommodate new features.
@@paulcarter7445 poorly designed code is fragile no matter the paradigm you are working in. Stop being a zealot, and focus more on writing quality code.
@@evancombs5159 The issue is that object-orientation encourages poorly-designed code - it causes a proliferation of stateful objects to be spread throughout an app - a disaster waiting to happen - which frequently does. An increasing number of programmers are aware of those issues and use only the modularization part of object-oriented languages.
I think agile isn't going to be superseded quickly and wholly, because it aligns with the nature of reality and how our brains work best. A bit like reactive systems align with the workings of the computer.
Could you please provide an analytical proof please?
@@4yt158 Analytical perhaps not, but let me explain:
I believe the nature of reality is that it's chaotic or complex at best if you look at complexity theory. That means that planning doesn't work, because things are often not predictable.
To me, that means that predictions should be verified using real-world feedback. This is achieved through releasing early and often.
I believe that we're unable to oversee most things in advance. We don't know what we don't know. This means any estimations are probably too optimistic and that it makes no sense to design before writing any code.
I believe that the human mind works best when it's engaged playfully. For me at least, releasing early and the interaction with end-users, provides that sense of play. Every iteration feels like "the next move" in a chess game to find the best solution for this particular client.
@@RoelBaardman Having studied complex adaptive systems, I understand the intuition behind what you're saying. However, I'm looking for analytical proof that agile SW development is the best methodology...
I always thought to really be in contact with my customers. But just now realise from an agency/freelance perspective my customer is not the customer of the software. I have mixed up customer and consumer. And consequently maybe more often than not, listened to the wrong feedback.