A dry sense of humour - the hallmark of any good IT person. It shows experience, it shows wisdom, it shows the capability of responding to a question after the person asking it has left.
@@ainocorry3004 (or @ whoever wrote the script) - Great video. Overdue, and perhaps under-done. I think there was a lot of value lost in just reading the 22 year old (99% correct) manifesto. The second half of the video didn't make up for it quite enough. You can see in the comments the pushback that the Agile Manifesto says to deliver every couple months. Being who you are, and the namesake of your channel, it was a huge missed opportunity to mention how the Manifesto is over 20 years old, and the definition of "Continuous Delivery" has a more concrete or well-known meaning these days. Namely; that Continuous doesn't mean Iterative. Iterative is part of the SDLC and Teamwork, but Continuous is part of the Integration and Delivery. Wow would I love to have a chat and collaborate on working these types of details out, because I love yours and Dave's videos for the most part, and have such respect for you all.
@@JinnGuild I was very much in doubt about reading the principles aloud, but decided it was a pedagogical point to do it, to show how long it takes, and underline why people probably haven't read them (or forgotten them). I am still not sure it was the right choice. And I am sad that the rest did not make up for it. I really like my "scar tissue" analogy... :-) Also, I think it is less interesting that the manifesto is over 20 years old, because to me, the principles still hold true (granted, they did not foresee that we can deploy every minute if we want to). What I thought about mentioning was that it was defined based on the experience on a bunch of white males... But I did not want to go into THAT discussion. It could be interesting to discuss some of this with you!
@@ainocorry3004 Absolutely to everything you said -- I don't mean to assert that anything in the manifesto has become untrue, just that engineers in our industry have refined some of the meanings. I also think it was a good idea to read the manifesto as-is, but I'm commenting on glancing by a few obvious refinements in the context of today. For example, we define "Face to Face" FAR different today, especially after 2020's events. And we define Continuous differently, though I'll leave it to this epic channel to really touch on that, which is actually the main value I was aching for when I saw this video release.
Ha. Every company I've worked for that implemented some "Agile" methodology flashed before my very eyes during this vid. Aino is so correct here. Companies love to adopt these new ways of working, but fail to change everything else to use it. I've worked for many engineering teams where they were agile, but the company was still stuck with releasing software in one go, at the end, which always ended up with issues. Good vid
This was lifechanging! Recently I had a lively discussion with one of my colleagues, on our workflow, and how it is not agile enough. He was blindly quoting agile manifesto, clearly not understanding it enough. It seems I did not either. Thank you Aino, this is great insight about how you can be agile, while working in industry-enforced waterfall, that exist in many fields these days.
Thanks very much for this exceptional video! It resonates in so many ways. The principles behind agile go back much further than the 20 years. It explains how I as a single person could compete with entire dev departments when I had PC app business in the 80's by working directly with the people in the user department every step of the way. I think the first thing that determines whether an org is truly agile is trust. The second is a sense of humor
I liked that as well. This applies even in other industries outside of agile. I once left a job bc it was impossible to do anything due to myriad upon myriad of processes.
I've worked in multiple companies that claim to be working agile and not one of them could even explain the term. All of them had daily standups, that were exactly like what was described in the video, a status meeting with detailed information about what was done yesterday, which meetings to attend today, long discussions about details in specific tickets and implementations and so on and so forth. Lots of people point to "bad managers" but the developers are not better, they're usually the ones dragging on detailed discussions in these meetings. Most teams I've been on are just working ad-hoc, calling it scrum or agile and using that as an excuse to not do any kind of planning, even getting tickets properly prepared for development is rare.
Or alternatively the developers do not feel they can challenge the status quo - I imagine there are many places where the notion of (say) "learned helplessness" applies, sadly.
Great video, agree with everything! In the part about Agile Contracts, you say 08:36, "there's a lot of debate about agile contracts and I am not going to go into details here". In my experience, when the customer and the development team are not in the same company, the contract setup and the contract negotiations in many cases ruin the aspirations to work in an agile way. Customers used to have a scope described in a contract. Statements like "We will have a product backlog and prioritize it jointly and deliver frequently what is of the highest business value" don't convince them. They want to formulate more precisely what is that they are going to pay for. I have a question and a suggestion. Question: do you have good pointers to the discussions (better: solutions :) ) for creating balanced contracts for agile development? Suggestion: why don't you devote one of the episodes on the channel to the topic of agile contracts? I bet it is of great interest for many. Not being able to sell agile development properly ends up in a bad-old fixed-price fixed-scope contract that doesn't support agile. Agile books usually avoid talking about the contracts (and in general, avoid the situation of contractual development across company borders). Thank you very much and looking forward!
I agree this is a big problem for organisations like consultancies. The fact that attempting to fix time and scope in a contact is wholly irrational still doesn't seem to dissuade people from doing it. The most rational approach that I have seen is a kind of incremental financing model, something akin to a venture capital model. Agree some initial work, pay for that. Then review and see whether or not it is worth continuing to invest, invest a bit more and so on. It is a much saner approach, though still unusual, particularly between different orgs.
Going to share this video with my team! I think you did a great job explaining agile, I do think that agile is something that can be many things but I like that you boil it down to what it tends to always be at the base.
It really seems that a lot of the “hate” towards ‘agile’ is based more on inept managers, than anything in the principles or processes. Recently I saw a famous programming-youtuber rant against the concept of daily stand ups: “They are a waste of time, I don’t care about your weekendplans, or your kids’ school, all I want to know is what you have been working on since last, and if there are any problems we should be aware of!!” - almost the exact definition of a daily stand up 😊 …
I don't know how you can say that when there are such stringent standards for an organization to be able to call themselves agile. Damn it where'd my sarcasm font go.....
I'd say most people who use the word "Agile" around software development, or business in general, haven't got a clue what's behind it. They don't abuse it, they are just clueless and use the words to sound clever. Sadly many agile coaches abuse the term in order to get paid rather than to help.
I agree. I think the video title may be only a SLIGHT misnomer. Perhaps meaning something like - People abuse the power, cloud, and cult support behind the word "Agile" to sell tools, processes, and possibly to somehow misinterpret it to support their own misconceptions. sAFE is a perfect example, and Scrum is another, though I realize Scrum has been around slightly longer than the Agile manifesto, but I think it just hooked on like a leach.
i'll be real with ya, agile can be extremely frustrating sometimes. not always of course, but sometimes. makes me miss the good old days of waterfall. here's what happened recently: we created a feature after continuous development of 2 weeks and then 3,4 days of testing. after everything was done and we were going to release in the night, we got a call from management saying we need some changes. we said alright, we can do that just tell us what you need. and we find out that the entire workflow has changed. this is an entirely new feature now and there's No way to re-use a single module. Tried to push back that the team is already done, we have even cleared the UAT and all that's left is prod deployment. "We are working in Agile right? We should be able to manage changes". At that moment i reviewed my life decisions, and got an answer to everything except what possessed us to let management know the word "Agile". Agile is great when used properly. But it can also be a matchstick if you hand it over to a monkey. You gonna end up with a forest fire.
I don't know, this screams out to me that there is something wrong in the process - if your customer (whether public or internal) needs something different then you need to be able to react and manage those changes. Now if they said that you needed to have that new workflow already implemented that night, then definitely they're delusional, but if they're prepared to accept the time hit then what is the problem?
Waterfall is kind of an insane level of hubris: we can perfectly think out a program from the beginning and never make any design mistakes. We understand perfectly from the beginning what our customer really need, and we can communicate with the perfectly technical competent purchasers from the very beginning, to determine the exact need of their organization, because they are so powerful and smart so they know everything about what their organization really does. There are never any understanding mistakes on the way. Waterfall is the essence of stupidity of bureaucratic minds that care nothing about the quality of what they do.
fantastic video! Another method of documenting is setting up custom (or use existing) data annotations and make that use openapi or another system to read these to create documentation for internal use, then instill in the team that anything that is changed in the code needs the annotation changed on that function/file. The biggest issue I have seen is trust from managers in the dev team.
As someone who has recently had a company meeting where the first word of the new company mantra for 2023 is “agility”….yes, the idea of being agile is starting to be stretched in ways that seems silly.
When I consult for companies, I make it an absolute priority to touch on both Conway's Law, as well as the fact that "Agile" is a set of principles surrounding the SDLC. SD, obvious to us, means Software Development. Systems like "sAFE" are business processes that strive to hook business processes (not Software Development) into a hopefully "Agile"-Principled SDLC. If you aren't first Agile in your SDLC, then you can't claim to have Business Processes that "Hook into your Agile SDLC". A business can't be Agile. But as per one of the Agile Principles - They can support the Software Development team, give them the tools they need, and trust them. As they step back, the SD team needs to also provide those hooks where the business can be looped in, especially for demos, and possibly velocity reports if you subscribe to that.
Compelling story. My take-away is that, regardless what approach you're choosing or what the method is called, one should always strive to contribute as much as possible to achieving business goals and business success. Both through the way of working in the development process and the impact delivered software has on achieving business goals.
I remember one of the points of XP and planning is that planning can be very expensive and not very reliable. You can spend a lot time planning that will never be used.
Thank you for your Service. :D - The battles you have fought (as have I and a few others programming over 20 years) have brought us far. I hope that videos like this one really hope drive the concepts home for those companies and people who are doing Scrumfall or frAgile. Though we took a lot of great lessons from XP, such as Pair Programming.
Yes, too much, or detailed planning can be a waste of time. But I would still argue that the discussions that come up around planning (or estimation) can be really valuable in getting rid of misunderstandings or sharing experience with different strategies or technologies.
Sometimes I think so agile stuff are not in ligne with the personality of many software engineers which are doing the actual work. They say for example value interaction with people over process and tools but I for one is more of an introvert it can be difficult. I know it is the same for many others.
I'd want to add to the comment in this video about documentation -- Using TDD, we should absolutely be covering each explicit test case regarding the functionality of our code. Whether we're talking about the TDD a dev does using Unit Testing, or the TDD the team (Or SDETs or Automation QA etc) does with automated integration tests (functional, contract, whatever). Those tests describe exactly what is expected of the code, and those tests MUST CHANGE WHEN THE CODE CHANGES. Tests themselves are a form of documentation. Also, if we link test cases, cucumber, BDD, blah blah back to our User Stories, or Tickets, or other feature documentation, then there is a direct link of how the code is implemented to the feature being requested. Not to say that replaces 100% of code comments or other documentation, but it supports a massive amount of that requirement.
True for functionality. Don't forget that software function is not the only aspect of the code that people value. TDD doesn't necessarily address the users perspective of 'goodness'
I think TDD absolutely addresses the "user's perspective" if you do it well. The BDD/ATDD part of the process is ONLY about the user perspective, and TDD is less without that. You need both the technical validation and the validation of the user perspective.
@@ContinuousDelivery I think what @vegamorph is trying to say is that humans have emotions. when I Google user perspective - "User perspective refers to the perception of a given user and the way in which they are going to interact with the final product" How do you test that with TDD(write test first)? How do you get "validation of the user perspective", around whether the color and theme is enticing to your target market or if the amount of complexity is sufficient for your advanced users, or how the information is laid out in a way that the user can understand and utilize the system? This is more in the realm of UX, and they often do a lot of documentation around that stuff anyway. Not sure what other documentation software team should do on user perspective.
@brandonpearman9218 correct. I'm a big fan of TDD/BDD but have found a context-driven approach which blends technicality with humanistic approach to quality as much more appropriate, especially in a culture where FOMO can outweigh function.
@@brandonpearman9218 I agree that design choices such as layouts, navigation, and themes would ideally be tested prior to building a product by both UX and designers. This isn't just UX documentation, but ideally, some prototyping and usability testing as well to support decisions. And as the product continues to iterate, AB testing, canary testing, and replay testing should be used to ensure that changes are overall positive to both performance and usability. All the while the UX team should be continuing to do user testing to find issues and a more optimal experience, and work with designers and developers to implement changes.
@@BryonLape a poor implementation of any great concept, is no reflection on the quality of the concept but on the intelligence and ability of the people involved.
As someone who considers themselves a Lean manager there are a few things here that seem worth discussing. I really struggle with the comparison between Agile and waterfall that I see happening everywhere. Every time this conversation comes up the project managers pipe up "but I see waterfall in your agile". There is something inherently flawed in this conversation. Agile isn't about not having a plan, and waterfall isn't a management strategy. In my mind the connection is project management vs agile, and waterfall vs design thinking. These seem like more logical parallels. All agile (which is really just Lean, but only the part of Lean that deals with uncertainty) really says is to employ the scientific method. The real secret of agile is in how you think about planning, and it is both the easiest and the hardest thing to execute. What agile says is give us your best guess of what this is going to take to deliver and we aren't going to hold you accountable to that. Sounds pretty great right? Okay it's not quite that easy. Agile also says BUT when it changes, you need to explain how it changed and why it changed. That is how you employ agile using the scientific method, everything else is just good software development practices.
Yes, exactly; "everything else is just good software development practices" the 12 principles are just the good software development practices from the authors of the manifesto written into principles.
Agree with everything except the wording of the last part that you need continuous delivery to be agile. I would say continuous delivery is just another tool that would make you more agile, but I dont I see it as the foundation of agility. But it all depends on your definition of fast I guess. for example: group 1: has full CICD and deploys daily and gets daily feedback. group 2: developers manually merge and deploy their code every 2 weeks without any CI or CD. They get daily feedback from within the team, branched tests and branched demos. group 3: deploys every 6 months and does not get any feedback at any stage. I think it is safe to say, group 2 is still agile but group 1 is more agile. Therefore CICD is a tool to enhance not a foundation.(no doubt greatly advances agility)
Also I realize in the manifesto they mention "continuous delivery" but I dont think they were referring to continuous delivery as in through trunk based dev and a build pipeline etc.(or am I wrong there?) I think they were referring to delivering on regular basis but there is no timeframe specified to assert the bounds of whats considered agile. did they mean monthly, weekly, daily, hourly?
Agree. The third principle actually says ‘deliver working software frequently, from a couple of weeks to a couple of months..’ so daily releases weren’t even being considered back in 1999. I do think the agility benefits of having faster feedback in place are worth the effort though.
You are using the term agile in two different ways. The first one is as a "Are we Agile", the second one is "Are we developing more agility". You can do things that make your more agile, but not Agile, you can become more flexible, but still be inflexible, group 2 may be more flexible than group 3, but they are still very inflexible. Deploying biweekly makes any feedback close to meaningless, because you are not getting feedback based on the reality of your application.
@@jarldue123 yeah so I dont see agile as a binary but rather as a range. The problem is defining where along that range is one not considered agile anymore. And I think the answer is, its a relative. As mentioned already when agile practices started out, deploying every two weeks was considered extremely fast and agile. Just because we can do better than 2 weeks now does not mean they were not agile, it just means we are more agile now. My point being CICD does not form part of the definition for agility, regardless of how helpful it is toward that goal.
CI is process, and CD is process in this definition though. It was never the build tool. That's one way of doing it, and a bastardization of the original terms. Seems to me you are describing CI and CD at different levels with each example. CI is quick feedback (of how changes work together), and CD is regular deployments (which requires certain properties out of the software delivered/process used).
Aino, great video! A lot of food for thought... so I have a comment and a question: C: Agile sounds like how to walk the razor's edge well... but processes builds rigidity brick by brick... sometimes you get it right other times not. I think this is more squishy than rigid and it is not comfortable to managers that need structure and predictability... but that embraces the nature of software... which is funny because I hear it said that software is flexible, but somehow our processes are not. LOL Q: We use Jira to manage new features in our software/firmware, I don't like the way it is being used presently as they create one task and pass it around between developers and QA... this single task is not focused and can last several sprints before it is closed. I think that they need to decouple flows of developers from QA, but they want to manage the feature so they want to pass the task around between groups. I suggested to use a story to track the feature, in that story have a few subtasks: one for the developers to develop, bench testing, and code review to complete the development, then another task (in that story) for QA to do their testing of the feature and that task can ping-pong assignees as needed to remediate any issues and get it correct. So, what do others do? Is that a good idea? And any better ideas? Thanks so much.
I would advise against that, and rather bring people together into a single team and work together on stories to completeness. To achieve real agility, I think that you do need to be producing real releasable software often, and breaking work up into multiple sprints is an anti-pattern, however the team is organised. I made a video specifically about the role of QA here: ruclips.net/video/XhFVtuNDAoM/видео.html
@@ContinuousDelivery Thanks for a great reply! So there is some awareness that there needs to be improvements, I'll forward your video over to them, I think they need to rethink this because it requires a corporate change at a high level. I agree with the TDD and I do that on my projects in the limited environment I have. Presently The QA is used for a regression testing and Gate Keeper role... what we need is a differently level of QA that is closer to the developers to catch errors before it goes to the QA regression tests. Before bigger change can be implemented, the Tasks in Jira and the way the measure the developer's progress is coupled to how quickly the QA finishes their job... So I get dinged even when I do my bit of work! Because I took too long, but in reality, I didn't get feedback soon enough to correct an issue. It eats into my bonus of their incentive program... so I'm financially motivated to decouple from QA in the short term and fix the structure and make the system better in the long term. And like more engineers on the job...They don't listen to ME and I have the greatest amount of grey hair that I've pulled out of my head!
She also went through a whole permutation set, including "You can do Agile without Scrum". But seemingly explicitly excluding "You can do Scrum in an Agile way." Lol
Be careful what you wish for! 🤣 My bet is that if you didn't like it, what you were in before was probably closer to "waterfall in disguise" than true "agile".
"Process is scar tissue" is huge for me thanks. Meanwhile, triggered by the mentions of ado boards and Jira. Most agile I've ever run a team was co located with post its and a white board. We could spot an issue during a daily, draw a new sub board, add a column, add freehand notes or indications to tickets, and be running the modified system by the end of the daily; not to mention the ease of splitting or merging tickets mid sprint. Once Jira is centrally administered, the fast inspect and adapt is dead
I worked at a team where we had those 15 min stand ups and I hated that meeting and said it was completely useless. But not how it was described in the video but rather, it was a reporting meeting where no one ever asked for help so I thought there was no point in having it. If you want to know what I am doing just check JIRA any time. If you don’t ask any questions after you heard a “report” it means that you either superhuman and understand everything at first hearing or that you are uninterested
I can say that documentation should indeed live in the code because that's pretty much the only way to prevent it from becoming stale when written in some other place. That's pretty much happened in every org I've ever worked with. Also, daily meetings have turned into status updates for teams. We solved this by walking the board. Looking at the work, instead of the people, and asking if anyone needs help with what they're working on.
I try to toggle between going through the board and doing a question for everyone one at a time. Sometimes I ask if something is holding them back, if they have any questions or if they are wondering about something. The question about wondering is important to ask now and again, because people sometimes say after something has gone wrong that they were wondering whether this or that was the right thing to do but there was no good time to express that uncertainty.
Great video, however I do take issue with the comments in the code statement. Please don’t use comments devs, extract your code into small methods with meaningful names. Your unit tests will also be your documentation, and we are all practicing TDD aren’t we. Clean code and agile are a good match.
I refactor to remove all comments from Java code. E.g., by renaming variables and methods. (This requires self-testing Clean Code.) Documentation is User Stories in Jira and agile architecture diagrams and Use Cases in Confluence. Thank you for the insights Coach; especially about the primacy of the 12 Principles.
Amen! I heard this so often: "Oh, we are doing SAFe, we cannot committ to anything which is in two PIs." Of course you can! I have a business to run and I need that feature. I don't want to hear in 6 months that you can only tell me 6 months, that you need anoter 6 months. God Dammit!
I assume this is word play with perhaps a much-needed video titled: Do People Abuse The Word DEVOPS?? I think that is actually a great idea, and has HUGE alignment with this one. Because DevOps is a mentality, or a principle perhaps. It isn't a set of processes. The DevOps mentality should increase communication and provide both overlap as well as obvious separation. But I agree with you that a lot of companies have just renamed their Operations team.
@@PavelHenkin I agree with the sentiment. But unlike the satirical OP of this thread, and unlike the video, SDETs are a position with specific tools and processes. Agile and DevOps are principles that should be the foundation for processes. I have also seem some really good "Shift Left" movements that have either re-trained their "QA" departments, or unfortunately replaced some of them, with SDETs. Or "Automated Test Engineers", or whatever else you wanna call them. But TLDR; People who write tests alongside (or even before) development, instead of focusing on testing Post-Development.
Working software definition is important here, what is a working software? I say that it's that of which gives us sales/money to pay for the real world. If we iterate until we die then you can guess why agile is a joke nowadays, either with scrum or without it. Solid theories will never beat the harsh realities, and the harsh realities is that we estimate according to experience, when we have unknowns then it gets harder. Oddly enough i see too many projects, not enough architects involved in them. People think that we do Agile wrong, we do much more than Agile wrong.
I've worked several places that tried really hard to do agile scrum the right way. Consistently and without exception, we found the 'sprint goal' to be the most worthless, pointless waste of time The sprint goal was always 'finish the stories'
Part of the problem is that there is rarely such a thing as "Agile Scrum". Scrum by definition requires iterations. Iterations are GREAT! But mainly related to the Teamwork portions, the SDLC in general, if you will. Unfortunately, Scrum conflates that with Iterative Releases as well. That is, Release every couple weeks or so. Though that may match the lofty goal of 22 years ago, that does not match the current state of what "Continuous Delivery" means. Also, Scrum requires you to perform an abhorrent amount of planning and analysis. Though I have worked with a single client where they "started with Scrum" and, by 100% definition of Scrum (as I remember it from ScrumMaster training 15 years ago), they altered the process until they were no longer doing Scrum. So at some point a few months after starting, they fell into their own Agile stride, and it was wonderful, and Scrum helped them get there. But what they ended up doing was nothing like you'd see if you researched what Scrum is.
I think that Scrum fits in to the agile world as a kind of "training wheels to achieve agility", it is often not used that way, but that is its role. It is not enough, alone, to achieve agility, it misses everything necessary to support the engineering of the software, which kind of matters if we are building SW.
@@ContinuousDelivery I whole-heartedly agree! Scrum can be a very good framework to train for smaller iterations and more regular communication. And when you have that down, you can start working on the thing that works best for your team and organisation.
I really started to hate Scrum. Not the framework itself per se, but how it is applied in most companies. I think it only exists because most people have no clue how to implement the agile manifesto within a software project. People want to follow processes rather than think about its value. I also start to question the sprint system, because 90% of the time sprint goals are not achieved and either you running out of stories by the end of the sprint and pull new items in, or you don't finish all of them within this two week cycle. This results in having spillovers all the time, and then you have more meetings about the spillovers and I start to ask where is the value at all. We're done when we're done, only thing that is for sure when we have meetings about spillovers and sprint goals it takes the same time, plus the meeting time..... To agree to deliver finished features asap is fine but does it have to be in an time spot every two weeks? Agile manifesto gives a rough direction, but Scrum gives me a lot of constraints....
I completely understand. When used in the wrong way, it can be very harmful. To me, Scrum is a good framework to start training your agile mindset; it trains inspection and adaption with you, continuous feedback and a higher level of communication, also about things that do not go as well as planned. But most (read: all) places where I have seen people start with strict Scrum, they turn it into something that fits them better. Perhaps they change the roles a bit, perhaps they change the meetings, perhaps they take aspects of Kanban or Lean into it. And I know that when you do not use strict Scrum, you cannot expect to get all the benefits it can give you. In my experience it is often more valuable to see what works for this particular organisation, these particular people, this particular domain. There is great difference between a startup that creates an app from scratch and a hardware company that creates new, innovative wind turbines. The worst thing you can do, in my opinion, is to forget to inspect and adapt the process itself. To forget to ask "why" you do the things you do. So, yes, I agree with you 🙂
Scrum is a process with clear rules so you can sell courses and addons and "SAFE" and certificates and all that stuff. Then you send people fresh from university in the "project manager" career path for a scrum master training certification and there you go, agile company with agile projects. It's horrible. I have 3 agile coaches in the program wasting money by "implementing SAFE" and still every daily (even if they own it) is "i worked on a pull request for one of the stories, Eric will review it today, hopefully he will not find to much and then i have a meeting later", "i had many meetings yesterday and Joe wanted a report so i haven't done much for the project", "i have to pick up my kids later so i won't work on stories before 11. Then i will work on that terraform issue i found yesterday". 90% of that stuff is meaningless for the rest, never seen one at any customer where it isn't just a justification meeting. Even worse are the retrospectives with "ice breaker" games and a new format every week and many "we are great" statements, but never with a single actual implementable improvement with a name next to it, no "we should try to test better next sprint" is enough. The worst part is: people think that SCRUM produces high quality software. But without a couple high quality people, SCRUM is a safe way to have unmaintainable software in 12-18 month because SCRUM does not care at all about technical quality. In a picture perfect SCRUM project, developers can produce the worst, buggiest unmaintainable piece of garbage code ever. And all the agile coaches and scrum masters assume that they still don't do SCRUM scrumy enough because what other reason could there be that the teams need 60%+ of their sprints to analyze, fix and rollout bugs and new features take longer and longer and always overrun estimations. Story point estimations must be the problem! So done with scrum masters who never coded anything.
Compelling story and I think this is very close to the original intention of "Agile". In reality, getting there is challenging. You know, processes exist to replace and substitute competent people. I strongly believe Agile only works well when all developers are at least technically proficient and have decent people skills while managers should understand what developers are actually doing so they have the piece of mind to trust whats going on. That means everyone in the company should be able to review the pull requests themselves for example. This is impossibly rare. My point is really that Agile alone is simply not good enough and I think it is not Agile but instead highly competent people that make the difference.
RUP was not a waterfall process. It was poorly implemented by many organizations that never understood the principles of interativa, risk driven, use case centric development. People latched onto the artifacts of the process and ignored the principles. ,
Spot on. And furthermore, fundamental to RUP is the Development Case, and the Process Engineers who adapt the specific process. I think the vast majority of development projects that go astray are due to a defective development process being followed, irrespective of what might have been planned.
Just want to point out that the concept of "agile" has been around for a long time. The biggest difference here is that in the 80s and early 90s, most coding was not in java and you didn't have sophisticated build automation and version control tools like you had now. So the concept of "agile" evolved as technology evolved and things like Jenkins, git and so forth came about and most software development shifted from Unix, Windows MFC, C/C++, Cobol or other languages and on-prem data centers to java and web development along with the cloud. But things like extreme programming and team programming were around. However, in the 80s and 90s just getting people to actually use requirements and design was a big effort along with consistent and proper use of the version control tools that did exist. Meaning just getting people to consistently follow basic best practices was as a big issue beyond the model of development. Also, contracts for third parties are not inherently "agile", because the contract is a specification of required deliverables that can be built and provided within a certain agreed time frame and a certain price. And this has always been something that is a challenge no matter the model of development you are using. Many contracts still fail even if they claim to be agile and the reason goes beyond simply using "agile" development because there is no silver bullet in software. Many other factors are the reasons why projects will fail and agile practices when not under contract often provide the illusion of progress that only delays the realization that the project is failing to deliver. And with 3rd party contracts a lot of them are not going to be willing to hire staff to be available for weekly or monthly project demos to work in an "agile" way. They more likely would rather have those resources on hand at the end for acceptance testing. But of course that depends.
I am sorry to hear you have had bad experiences with what people called agile. Given that I think the core of agile is "inspect and adapt" I find it hard to fault that.
The daily standup has to be the biggest waste of time ever invented. If a team can’t plan out more than a days work before getting started you’re really micro managing everyone because someone is a control freak without any ability for the team to be autonomous.
Well I think that from you description you haven't been doing "daily standups" you have been doing "Dialiy Planning Meetings" which is a VERY different thing.Standups aren't planning meetings they are a chance for the team to organise how they are going to organise themselves for this day's work, "I can work with you on that", "I saw something similar Yesterday, I can help", or "I had this weird problem Yesterday and fixed it like this", "Anyone know anything about this API?" and so on. These all seem perfectly reasonable to me, and all very related to the work of the day and all may help me and every other member of the team to do a better job. I don't see how this compromises team auto9nomy or wastes their time. the standup is an internal intra-team meeting. other people from outside the team may be allowed to attend if the team agree, but are not usually allowed to talk. If you standups aren't like this then they aren't standups they are something else and you can't reasonably blame standups for something that your teams have chosen to do but that don't follow the practices that define a standup. That's like throwing rocks at dogs because you don't like cats. The problem is that many teams aren't very good at this stuff so get things like standups badly wrong, which is why listening to experts like Aino may help.
These principles are very simple and effective for those who understand them. Those who misunderstand them continue to miss out on the benefits. How is there a "fault" with the principles?
I'm inclined to disagree, people are very good at not understanding and fucking things up. Doesn't mean that whatever you try to teach them is not a good principle. Is TDD a bad principle? Many people dislike it after trying it, and I'd say (admittedly: my opinion) they've been doing it wrong
@@jangohemmes352 Yes TDD is a bad principle. If something cannot be taught, or if something is easily misunderstood at what point do you throw in the towel and change tact? Agile is 25 years old at this point. It's a failed experiment. It got abused, twisted around and "allegedly" misunderstood. That's because the original principals weren't really that good. Maybe they were a step in the right direction but surely the writing is on the wall at this point. At what point do we look in the mirror and say "this isn't working"?
@@temper8281 you've failed to follow the train of thought. The principle is successful for those who apply it. End of story. If you're unable to understand it, that is your loss, and no one is responsible to fix that for you.
Typical scrum project is like a waterfall without design phase. I think of it as a circle of poorly planned implementations followed by endless refactoring and bug-fixing. Scrum actually allowed and encouraged non-tech people to be directly involved in development process and it is one of the biggest problems with scrum. We can do scrum and it will work if we just replace non-tech SM and non-tech PO with Lead Dev who actually knows how development works and instead of having tons of useless meetings, just normally talk with our colleges during lunch or coffee. "Agile" should be just natural teamwork and cooperation.
Please don't, you'll regret it😂 I think managers use this idea as an excuse to not learn the technical aspects of the product on a high level. Instead, they want us to do their jobs
I would just mention a caveat to this which Im sure you do intuitively anyway. this is great if you have good well rounded engineers and they take ownership over delivery(not just code), but some brilliant engineers are specialists and are not good communicators (and don't want it). Adapting to your team and their needs is part of agility.
I can't recall where this concept originally came from, but I think it is already known to be a mistake. Though it depends on your definition of Engineer, and your definition of Customer. It isn't a horrible idea to hold your weekly (or 2-weekly) demos, managed by Product or QA, and having a dev there to take notes or answer questions. But those demos are specific customers, not the whole customer base. And your devs aren't acting as help desk constantly, it's one meeting every couple weeks, and they're generally meant to be fairly quiet. There's a line somewhere, and there is indeed benefit to doing demos.
@@JinnGuild Yes! I partly agree with the other comments that there are some engineers that probably should not talk with customers (for various reasons). There are also examples of software systems developed, where those meetings do not make sense. But I have seen many organisations thrive on having good demo sessions with customers (or other stakeholders) regularly. You will need to mediate this conversation, or will become a frustrating waste of time. Having someone who can speak "both languages" can have a very good effect on the development of software systems to users. I am working on a video about that as well.
Agreed, but also, even if we do view them as similar, if you organise your "Agile Team" as a mini-waterfall, I'd say that you are missing several important tricks and working very inefficiently and less effectively. Agile teams are much more effective if they organise their work so that work is done as early in the process as possible. For example, I don't want manual testers waiting for features to be finished before looking at it. I don't want ops people waiting for finished features before deploying them. Ideally we should be working collaboratively and all come to the conclusion that we are done at the same time.
I see your point, but I think that there are fundamental difference with the concepts and the mindset that you have when working in the different ways. As Dave also describes
@@ContinuousDelivery Maybe I misinterpreted - Did you just agree to the OP saying "Agile is Waterfall"? Or even that Agile can be viewed as Similar to waterfall? I'm fairly certain this channel has said multiple times that Agile is a set of principles. Maybe you are appeasing the OP by purposely conflating Agile with some of the typically bad applications out there?
@@Suamere My bad, I replied to the wrong post. I was responding to the comment that said "Agile is a set of principles, waterfall is a set of processes" not the OP - my mistake.
"Waterfall" isn't the same thing as having a plan. Overlord was planned, but it certainly wasn't waterfall, as most orgs practice it. For example, 'D Day' wasn't decided for months, and was postponed the day before, I think, because of bad weather in the channel. That sounds more like agile planning to me!
@@ContinuousDelivery Overlord was delayed due to weather but they had a rough idea as to when they wanted to go months out. They had the idea for a May or June campaign back in December of the previous year. AND they were doing requirements gathering a year out. All the hallmarks of the waterfall methodology was in full display. The front-loaded analysis and requirements gathering phase took nearly a year. Everything had to happen in a linear sequence. First the bombers went in, then the pathfinders, then the airborne troops, then the naval bombardment, then the amphibious assault, then armoured support, then the logistics and supplies. All planned down to the minute prior the D-Day itself and all of it consecutively executed. Agile was perhaps only exhibited on the squad or company level where small teams had to achieve previously defined objectives by improvising.
Please do expand. Toward deceptive companies claiming Agile but doing Waterfall? Toward the industry or Agile in general? Toward this video/channel? Why?
Sold on the anger management joke. Nice that the show is about more than one person. Smart move Dave
Appreciate that!
“There’s no real agility without technical agility.” YES 🙌
A dry sense of humour - the hallmark of any good IT person. It shows experience, it shows wisdom, it shows the capability of responding to a question after the person asking it has left.
Thank you!
This was great. Balanced, realistic, commercial realism.
Thank you!
@@ainocorry3004 (or @ whoever wrote the script) - Great video. Overdue, and perhaps under-done. I think there was a lot of value lost in just reading the 22 year old (99% correct) manifesto. The second half of the video didn't make up for it quite enough. You can see in the comments the pushback that the Agile Manifesto says to deliver every couple months. Being who you are, and the namesake of your channel, it was a huge missed opportunity to mention how the Manifesto is over 20 years old, and the definition of "Continuous Delivery" has a more concrete or well-known meaning these days. Namely; that Continuous doesn't mean Iterative. Iterative is part of the SDLC and Teamwork, but Continuous is part of the Integration and Delivery.
Wow would I love to have a chat and collaborate on working these types of details out, because I love yours and Dave's videos for the most part, and have such respect for you all.
@@JinnGuild I was very much in doubt about reading the principles aloud, but decided it was a pedagogical point to do it, to show how long it takes, and underline why people probably haven't read them (or forgotten them). I am still not sure it was the right choice. And I am sad that the rest did not make up for it. I really like my "scar tissue" analogy... :-)
Also, I think it is less interesting that the manifesto is over 20 years old, because to me, the principles still hold true (granted, they did not foresee that we can deploy every minute if we want to). What I thought about mentioning was that it was defined based on the experience on a bunch of white males... But I did not want to go into THAT discussion.
It could be interesting to discuss some of this with you!
@@ainocorry3004 Absolutely to everything you said -- I don't mean to assert that anything in the manifesto has become untrue, just that engineers in our industry have refined some of the meanings. I also think it was a good idea to read the manifesto as-is, but I'm commenting on glancing by a few obvious refinements in the context of today. For example, we define "Face to Face" FAR different today, especially after 2020's events. And we define Continuous differently, though I'll leave it to this epic channel to really touch on that, which is actually the main value I was aching for when I saw this video release.
100% agree. Thanks to Aino!
“I was young and I needed the money.” That’s what I say when asked about my JS experience.
Now that I'm in my 40s. I'm still young and I still need the money
no more sporadic jsjobs tho, only python for regulars, right? @@cockerswilde
This is a brilliant summary of how Agile should/can work in reality. Bookmarked and will be used as a reference quite often. Thank you!
Thank you!
Ha. Every company I've worked for that implemented some "Agile" methodology flashed before my very eyes during this vid. Aino is so correct here. Companies love to adopt these new ways of working, but fail to change everything else to use it. I've worked for many engineering teams where they were agile, but the company was still stuck with releasing software in one go, at the end, which always ended up with issues. Good vid
This was lifechanging! Recently I had a lively discussion with one of my colleagues, on our workflow, and how it is not agile enough. He was blindly quoting agile manifesto, clearly not understanding it enough. It seems I did not either. Thank you Aino, this is great insight about how you can be agile, while working in industry-enforced waterfall, that exist in many fields these days.
I am glad you like it!
Thanks very much for this exceptional video! It resonates in so many ways. The principles behind agile go back much further than the 20 years. It explains how I as a single person could compete with entire dev departments when I had PC app business in the 80's by working directly with the people in the user department every step of the way. I think the first thing that determines whether an org is truly agile is trust. The second is a sense of humor
Excellent video. Thank you for sharing your experience and insights.
Thank you, I am glad you liked it.
this is the best video on the channel, Sorry Dave, they are all great, but this is the topper.
Uhh, thank you!
Thank you for the scar tissue analogy. It's just what I've recognized for years but didn't have a simple way to describe it. Nicely done.
You are welcome. I heard it myself from someone years ago, perhaps Adrian Cockcroft, but I am not sure.
I liked that as well. This applies even in other industries outside of agile. I once left a job bc it was impossible to do anything due to myriad upon myriad of processes.
I've worked in multiple companies that claim to be working agile and not one of them could even explain the term. All of them had daily standups, that were exactly like what was described in the video, a status meeting with detailed information about what was done yesterday, which meetings to attend today, long discussions about details in specific tickets and implementations and so on and so forth. Lots of people point to "bad managers" but the developers are not better, they're usually the ones dragging on detailed discussions in these meetings.
Most teams I've been on are just working ad-hoc, calling it scrum or agile and using that as an excuse to not do any kind of planning, even getting tickets properly prepared for development is rare.
Or alternatively the developers do not feel they can challenge the status quo - I imagine there are many places where the notion of (say) "learned helplessness" applies, sadly.
I see the title and right way say to myself: Yes!
Wow, I really missed her.
Great video, agree with everything!
In the part about Agile Contracts, you say 08:36, "there's a lot of debate about agile contracts and I am not going to go into details here".
In my experience, when the customer and the development team are not in the same company, the contract setup and the contract negotiations in many cases ruin the aspirations to work in an agile way. Customers used to have a scope described in a contract. Statements like "We will have a product backlog and prioritize it jointly and deliver frequently what is of the highest business value" don't convince them. They want to formulate more precisely what is that they are going to pay for.
I have a question and a suggestion.
Question: do you have good pointers to the discussions (better: solutions :) ) for creating balanced contracts for agile development?
Suggestion: why don't you devote one of the episodes on the channel to the topic of agile contracts? I bet it is of great interest for many. Not being able to sell agile development properly ends up in a bad-old fixed-price fixed-scope contract that doesn't support agile. Agile books usually avoid talking about the contracts (and in general, avoid the situation of contractual development across company borders).
Thank you very much and looking forward!
I agree this is a big problem for organisations like consultancies. The fact that attempting to fix time and scope in a contact is wholly irrational still doesn't seem to dissuade people from doing it.
The most rational approach that I have seen is a kind of incremental financing model, something akin to a venture capital model. Agree some initial work, pay for that. Then review and see whether or not it is worth continuing to invest, invest a bit more and so on. It is a much saner approach, though still unusual, particularly between different orgs.
Going to share this video with my team! I think you did a great job explaining agile, I do think that agile is something that can be many things but I like that you boil it down to what it tends to always be at the base.
Awesome! Thank you!
It really seems that a lot of the “hate” towards ‘agile’ is based more on inept managers, than anything in the principles or processes. Recently I saw a famous programming-youtuber rant against the concept of daily stand ups: “They are a waste of time, I don’t care about your weekendplans, or your kids’ school, all I want to know is what you have been working on since last, and if there are any problems we should be aware of!!” - almost the exact definition of a daily stand up 😊 …
I don't know how you can say that when there are such stringent standards for an organization to be able to call themselves agile. Damn it where'd my sarcasm font go.....
Exactly! 🙂
I'd say most people who use the word "Agile" around software development, or business in general, haven't got a clue what's behind it. They don't abuse it, they are just clueless and use the words to sound clever. Sadly many agile coaches abuse the term in order to get paid rather than to help.
Yeah we hire people(SM) to organize self-organizing teams?!? because scrum.
I agree. I think the video title may be only a SLIGHT misnomer. Perhaps meaning something like - People abuse the power, cloud, and cult support behind the word "Agile" to sell tools, processes, and possibly to somehow misinterpret it to support their own misconceptions. sAFE is a perfect example, and Scrum is another, though I realize Scrum has been around slightly longer than the Agile manifesto, but I think it just hooked on like a leach.
I think managers think of it as a tool where they can get a status every morning.
Decades ago I had to do formal requirement specs. One strategy I had was to write the documentation as the requirements.
This is pretty much what BDD and Acceptance testing is about. We create 'executable specifications' from the perspective of users of the system.
i'll be real with ya, agile can be extremely frustrating sometimes. not always of course, but sometimes. makes me miss the good old days of waterfall.
here's what happened recently: we created a feature after continuous development of 2 weeks and then 3,4 days of testing.
after everything was done and we were going to release in the night, we got a call from management saying we need some changes.
we said alright, we can do that just tell us what you need.
and we find out that the entire workflow has changed. this is an entirely new feature now and there's No way to re-use a single module. Tried to push back that the team is already done, we have even cleared the UAT and all that's left is prod deployment.
"We are working in Agile right? We should be able to manage changes".
At that moment i reviewed my life decisions, and got an answer to everything except what possessed us to let management know the word "Agile". Agile is great when used properly. But it can also be a matchstick if you hand it over to a monkey. You gonna end up with a forest fire.
That’s not an Agile problem. That’s a bad manager problem.
I don't know, this screams out to me that there is something wrong in the process - if your customer (whether public or internal) needs something different then you need to be able to react and manage those changes. Now if they said that you needed to have that new workflow already implemented that night, then definitely they're delusional, but if they're prepared to accept the time hit then what is the problem?
@@secretchefcollective444 problem my friend is what you already described: They were delusional!
I have been having this feeling for a long time but since I'm not an expert on the subject I wasn't completely sure. Thanks for the video!
Thank you!
Waterfall is kind of an insane level of hubris: we can perfectly think out a program from the beginning and never make any design mistakes. We understand perfectly from the beginning what our customer really need, and we can communicate with the perfectly technical competent purchasers from the very beginning, to determine the exact need of their organization, because they are so powerful and smart so they know everything about what their organization really does. There are never any understanding mistakes on the way. Waterfall is the essence of stupidity of bureaucratic minds that care nothing about the quality of what they do.
fantastic video! Another method of documenting is setting up custom (or use existing) data annotations and make that use openapi or another system to read these to create documentation for internal use, then instill in the team that anything that is changed in the code needs the annotation changed on that function/file. The biggest issue I have seen is trust from managers in the dev team.
As someone who has recently had a company meeting where the first word of the new company mantra for 2023 is “agility”….yes, the idea of being agile is starting to be stretched in ways that seems silly.
When I consult for companies, I make it an absolute priority to touch on both Conway's Law, as well as the fact that "Agile" is a set of principles surrounding the SDLC. SD, obvious to us, means Software Development. Systems like "sAFE" are business processes that strive to hook business processes (not Software Development) into a hopefully "Agile"-Principled SDLC. If you aren't first Agile in your SDLC, then you can't claim to have Business Processes that "Hook into your Agile SDLC". A business can't be Agile. But as per one of the Agile Principles - They can support the Software Development team, give them the tools they need, and trust them. As they step back, the SD team needs to also provide those hooks where the business can be looped in, especially for demos, and possibly velocity reports if you subscribe to that.
Compelling story. My take-away is that, regardless what approach you're choosing or what the method is called, one should always strive to contribute as much as possible to achieving business goals and business success. Both through the way of working in the development process and the impact delivered software has on achieving business goals.
I remember one of the points of XP and planning is that planning can be very expensive and not very reliable. You can spend a lot time planning that will never be used.
Thank you for your Service. :D - The battles you have fought (as have I and a few others programming over 20 years) have brought us far. I hope that videos like this one really hope drive the concepts home for those companies and people who are doing Scrumfall or frAgile. Though we took a lot of great lessons from XP, such as Pair Programming.
Yes, too much, or detailed planning can be a waste of time. But I would still argue that the discussions that come up around planning (or estimation) can be really valuable in getting rid of misunderstandings or sharing experience with different strategies or technologies.
Thanks great video!
Thanks for this great video!
I really like pointing out that creating a process or organizational structure for a problem instead of talking is a big sign of missing agility.
very cool channel I have just discovered! subbed
Sometimes I think so agile stuff are not in ligne with the personality of many software engineers which are doing the actual work. They say for example value interaction with people over process and tools but I for one is more of an introvert it can be difficult. I know it is the same for many others.
I'd want to add to the comment in this video about documentation -- Using TDD, we should absolutely be covering each explicit test case regarding the functionality of our code. Whether we're talking about the TDD a dev does using Unit Testing, or the TDD the team (Or SDETs or Automation QA etc) does with automated integration tests (functional, contract, whatever). Those tests describe exactly what is expected of the code, and those tests MUST CHANGE WHEN THE CODE CHANGES. Tests themselves are a form of documentation. Also, if we link test cases, cucumber, BDD, blah blah back to our User Stories, or Tickets, or other feature documentation, then there is a direct link of how the code is implemented to the feature being requested. Not to say that replaces 100% of code comments or other documentation, but it supports a massive amount of that requirement.
True for functionality. Don't forget that software function is not the only aspect of the code that people value. TDD doesn't necessarily address the users perspective of 'goodness'
I think TDD absolutely addresses the "user's perspective" if you do it well. The BDD/ATDD part of the process is ONLY about the user perspective, and TDD is less without that. You need both the technical validation and the validation of the user perspective.
@@ContinuousDelivery I think what @vegamorph is trying to say is that humans have emotions.
when I Google user perspective - "User perspective refers to the perception of a given user and the way in which they are going to interact with the final product"
How do you test that with TDD(write test first)? How do you get "validation of the user perspective", around whether the color and theme is enticing to your target market or if the amount of complexity is sufficient for your advanced users, or how the information is laid out in a way that the user can understand and utilize the system?
This is more in the realm of UX, and they often do a lot of documentation around that stuff anyway. Not sure what other documentation software team should do on user perspective.
@brandonpearman9218 correct. I'm a big fan of TDD/BDD but have found a context-driven approach which blends technicality with humanistic approach to quality as much more appropriate, especially in a culture where FOMO can outweigh function.
@@brandonpearman9218 I agree that design choices such as layouts, navigation, and themes would ideally be tested prior to building a product by both UX and designers. This isn't just UX documentation, but ideally, some prototyping and usability testing as well to support decisions. And as the product continues to iterate, AB testing, canary testing, and replay testing should be used to ensure that changes are overall positive to both performance and usability. All the while the UX team should be continuing to do user testing to find issues and a more optimal experience, and work with designers and developers to implement changes.
As soon as a tech term becomes a buzzword to business people, it is doomed. Agile is dead.
@@BryonLape a poor implementation of any great concept, is no reflection on the quality of the concept but on the intelligence and ability of the people involved.
As someone who considers themselves a Lean manager there are a few things here that seem worth discussing. I really struggle with the comparison between Agile and waterfall that I see happening everywhere. Every time this conversation comes up the project managers pipe up "but I see waterfall in your agile". There is something inherently flawed in this conversation. Agile isn't about not having a plan, and waterfall isn't a management strategy. In my mind the connection is project management vs agile, and waterfall vs design thinking. These seem like more logical parallels. All agile (which is really just Lean, but only the part of Lean that deals with uncertainty) really says is to employ the scientific method. The real secret of agile is in how you think about planning, and it is both the easiest and the hardest thing to execute. What agile says is give us your best guess of what this is going to take to deliver and we aren't going to hold you accountable to that. Sounds pretty great right? Okay it's not quite that easy. Agile also says BUT when it changes, you need to explain how it changed and why it changed. That is how you employ agile using the scientific method, everything else is just good software development practices.
Yes, exactly; "everything else is just good software development practices" the 12 principles are just the good software development practices from the authors of the manifesto written into principles.
I giggled with the visual she gave about punching holes in the wall. :)
Aino is awesome!
Thank you!
Agree with everything except the wording of the last part that you need continuous delivery to be agile. I would say continuous delivery is just another tool that would make you more agile, but I dont I see it as the foundation of agility. But it all depends on your definition of fast I guess.
for example:
group 1: has full CICD and deploys daily and gets daily feedback.
group 2: developers manually merge and deploy their code every 2 weeks without any CI or CD. They get daily feedback from within the team, branched tests and branched demos.
group 3: deploys every 6 months and does not get any feedback at any stage.
I think it is safe to say, group 2 is still agile but group 1 is more agile. Therefore CICD is a tool to enhance not a foundation.(no doubt greatly advances agility)
Also I realize in the manifesto they mention "continuous delivery" but I dont think they were referring to continuous delivery as in through trunk based dev and a build pipeline etc.(or am I wrong there?)
I think they were referring to delivering on regular basis but there is no timeframe specified to assert the bounds of whats considered agile. did they mean monthly, weekly, daily, hourly?
Agree. The third principle actually says ‘deliver working software frequently, from a couple of weeks to a couple of months..’ so daily releases weren’t even being considered back in 1999. I do think the agility benefits of having faster feedback in place are worth the effort though.
You are using the term agile in two different ways.
The first one is as a "Are we Agile", the second one is "Are we developing more agility".
You can do things that make your more agile, but not Agile, you can become more flexible, but still be inflexible, group 2 may be more flexible than group 3, but they are still very inflexible.
Deploying biweekly makes any feedback close to meaningless, because you are not getting feedback based on the reality of your application.
@@jarldue123 yeah so I dont see agile as a binary but rather as a range. The problem is defining where along that range is one not considered agile anymore. And I think the answer is, its a relative. As mentioned already when agile practices started out, deploying every two weeks was considered extremely fast and agile.
Just because we can do better than 2 weeks now does not mean they were not agile, it just means we are more agile now. My point being CICD does not form part of the definition for agility, regardless of how helpful it is toward that goal.
CI is process, and CD is process in this definition though. It was never the build tool. That's one way of doing it, and a bastardization of the original terms. Seems to me you are describing CI and CD at different levels with each example. CI is quick feedback (of how changes work together), and CD is regular deployments (which requires certain properties out of the software delivered/process used).
What you said.
Thank you.
Dave
❤
Wonderful co-host!
Thank you!
Aino, great video! A lot of food for thought... so I have a comment and a question:
C: Agile sounds like how to walk the razor's edge well... but processes builds rigidity brick by brick... sometimes you get it right other times not. I think this is more squishy than rigid and it is not comfortable to managers that need structure and predictability... but that embraces the nature of software... which is funny because I hear it said that software is flexible, but somehow our processes are not. LOL
Q: We use Jira to manage new features in our software/firmware, I don't like the way it is being used presently as they create one task and pass it around between developers and QA... this single task is not focused and can last several sprints before it is closed. I think that they need to decouple flows of developers from QA, but they want to manage the feature so they want to pass the task around between groups. I suggested to use a story to track the feature, in that story have a few subtasks: one for the developers to develop, bench testing, and code review to complete the development, then another task (in that story) for QA to do their testing of the feature and that task can ping-pong assignees as needed to remediate any issues and get it correct.
So, what do others do? Is that a good idea? And any better ideas? Thanks so much.
I would advise against that, and rather bring people together into a single team and work together on stories to completeness. To achieve real agility, I think that you do need to be producing real releasable software often, and breaking work up into multiple sprints is an anti-pattern, however the team is organised.
I made a video specifically about the role of QA here: ruclips.net/video/XhFVtuNDAoM/видео.html
@@ContinuousDelivery Thanks for a great reply! So there is some awareness that there needs to be improvements, I'll forward your video over to them, I think they need to rethink this because it requires a corporate change at a high level. I agree with the TDD and I do that on my projects in the limited environment I have. Presently The QA is used for a regression testing and Gate Keeper role... what we need is a differently level of QA that is closer to the developers to catch errors before it goes to the QA regression tests. Before bigger change can be implemented, the Tasks in Jira and the way the measure the developer's progress is coupled to how quickly the QA finishes their job... So I get dinged even when I do my bit of work! Because I took too long, but in reality, I didn't get feedback soon enough to correct an issue. It eats into my bonus of their incentive program... so I'm financially motivated to decouple from QA in the short term and fix the structure and make the system better in the long term. And like more engineers on the job...They don't listen to ME and I have the greatest amount of grey hair that I've pulled out of my head!
I loved the part:
- How is this not agile?
- Because we're not doing scrum.
14:53
She also went through a whole permutation set, including "You can do Agile without Scrum". But seemingly explicitly excluding "You can do Scrum in an Agile way." Lol
After working in several Agile companies, I'd love to try working on a Waterfall project haha
Be careful what you wish for! 🤣 My bet is that if you didn't like it, what you were in before was probably closer to "waterfall in disguise" than true "agile".
Indeed ! @@ContinuousDelivery
"Process is scar tissue" is huge for me thanks.
Meanwhile, triggered by the mentions of ado boards and Jira. Most agile I've ever run a team was co located with post its and a white board. We could spot an issue during a daily, draw a new sub board, add a column, add freehand notes or indications to tickets, and be running the modified system by the end of the daily; not to mention the ease of splitting or merging tickets mid sprint. Once Jira is centrally administered, the fast inspect and adapt is dead
Oh, how I miss those boards.. It has been several years since I worked with a colocated team.
"I've worked on my anger management..." wearing a Darth Vader T-shirt. Nice!
Thank you for noticing 🙂
I worked at a team where we had those 15 min stand ups and I hated that meeting and said it was completely useless. But not how it was described in the video but rather, it was a reporting meeting where no one ever asked for help so I thought there was no point in having it. If you want to know what I am doing just check JIRA any time. If you don’t ask any questions after you heard a “report” it means that you either superhuman and understand everything at first hearing or that you are uninterested
I can say that documentation should indeed live in the code because that's pretty much the only way to prevent it from becoming stale when written in some other place. That's pretty much happened in every org I've ever worked with.
Also, daily meetings have turned into status updates for teams. We solved this by walking the board. Looking at the work, instead of the people, and asking if anyone needs help with what they're working on.
I try to toggle between going through the board and doing a question for everyone one at a time. Sometimes I ask if something is holding them back, if they have any questions or if they are wondering about something. The question about wondering is important to ask now and again, because people sometimes say after something has gone wrong that they were wondering whether this or that was the right thing to do but there was no good time to express that uncertainty.
I sometimes call it "wonder-time" which is a silly word that I can use because I am not a native English speaker 😂
Very informative thank you
Truly amazing, Thank you!
Thank you!
One positive thing that I've heard about cucumber is that it can be used as living documentation... presumably if done right.
Yes, it does work very well in that role.
Brilliant !!!
Thank you!
Great video, however I do take issue with the comments in the code statement. Please don’t use comments devs, extract your code into small methods with meaningful names. Your unit tests will also be your documentation, and we are all practicing TDD aren’t we. Clean code and agile are a good match.
I refactor to remove all comments from Java code. E.g., by renaming variables and methods. (This requires self-testing Clean Code.) Documentation is User Stories in Jira and agile architecture diagrams and Use Cases in Confluence. Thank you for the insights Coach; especially about the primacy of the 12 Principles.
Amen!
I heard this so often: "Oh, we are doing SAFe, we cannot committ to anything which is in two PIs." Of course you can! I have a business to run and I need that feature. I don't want to hear in 6 months that you can only tell me 6 months, that you need anoter 6 months. God Dammit!
Water-Scrum-Fall 😂 Love it!
I wish I could claim I coined it, but I heard it somewhere else...
LOL @ "never admitting to waterfall"
Thanks!
Thank you!
Thank you!
really good video 😊
Thank you!
Problems communicating between developers and operations? Rename the ops team to devops. Problem solved!
Always like an easy fix😂
Don't want let go/retrain testers? Call them SDETs!
I assume this is word play with perhaps a much-needed video titled: Do People Abuse The Word DEVOPS??
I think that is actually a great idea, and has HUGE alignment with this one. Because DevOps is a mentality, or a principle perhaps. It isn't a set of processes. The DevOps mentality should increase communication and provide both overlap as well as obvious separation. But I agree with you that a lot of companies have just renamed their Operations team.
@@PavelHenkin I agree with the sentiment. But unlike the satirical OP of this thread, and unlike the video, SDETs are a position with specific tools and processes. Agile and DevOps are principles that should be the foundation for processes.
I have also seem some really good "Shift Left" movements that have either re-trained their "QA" departments, or unfortunately replaced some of them, with SDETs. Or "Automated Test Engineers", or whatever else you wanna call them. But TLDR; People who write tests alongside (or even before) development, instead of focusing on testing Post-Development.
Well, I have kind of done a version of that already 😉😎
ruclips.net/video/1Mcpir3Frtw/видео.html
Managers are OBSESSED with meetings.
Working software definition is important here, what is a working software?
I say that it's that of which gives us sales/money to pay for the real world.
If we iterate until we die then you can guess why agile is a joke nowadays, either with scrum or without it.
Solid theories will never beat the harsh realities, and the harsh realities is that we estimate according to experience, when we have unknowns then it gets harder.
Oddly enough i see too many projects, not enough architects involved in them.
People think that we do Agile wrong, we do much more than Agile wrong.
I've worked several places that tried really hard to do agile scrum the right way.
Consistently and without exception, we found the 'sprint goal' to be the most worthless, pointless waste of time
The sprint goal was always 'finish the stories'
Part of the problem is that there is rarely such a thing as "Agile Scrum". Scrum by definition requires iterations. Iterations are GREAT! But mainly related to the Teamwork portions, the SDLC in general, if you will. Unfortunately, Scrum conflates that with Iterative Releases as well. That is, Release every couple weeks or so. Though that may match the lofty goal of 22 years ago, that does not match the current state of what "Continuous Delivery" means. Also, Scrum requires you to perform an abhorrent amount of planning and analysis.
Though I have worked with a single client where they "started with Scrum" and, by 100% definition of Scrum (as I remember it from ScrumMaster training 15 years ago), they altered the process until they were no longer doing Scrum. So at some point a few months after starting, they fell into their own Agile stride, and it was wonderful, and Scrum helped them get there. But what they ended up doing was nothing like you'd see if you researched what Scrum is.
I think that Scrum fits in to the agile world as a kind of "training wheels to achieve agility", it is often not used that way, but that is its role. It is not enough, alone, to achieve agility, it misses everything necessary to support the engineering of the software, which kind of matters if we are building SW.
@@ContinuousDelivery I whole-heartedly agree! Scrum can be a very good framework to train for smaller iterations and more regular communication. And when you have that down, you can start working on the thing that works best for your team and organisation.
I really started to hate Scrum. Not the framework itself per se, but how it is applied in most companies. I think it only exists because most people have no clue how to implement the agile manifesto within a software project. People want to follow processes rather than think about its value. I also start to question the sprint system, because 90% of the time sprint goals are not achieved and either you running out of stories by the end of the sprint and pull new items in, or you don't finish all of them within this two week cycle. This results in having spillovers all the time, and then you have more meetings about the spillovers and I start to ask where is the value at all. We're done when we're done, only thing that is for sure when we have meetings about spillovers and sprint goals it takes the same time, plus the meeting time..... To agree to deliver finished features asap is fine but does it have to be in an time spot every two weeks? Agile manifesto gives a rough direction, but Scrum gives me a lot of constraints....
I completely understand. When used in the wrong way, it can be very harmful. To me, Scrum is a good framework to start training your agile mindset; it trains inspection and adaption with you, continuous feedback and a higher level of communication, also about things that do not go as well as planned. But most (read: all) places where I have seen people start with strict Scrum, they turn it into something that fits them better. Perhaps they change the roles a bit, perhaps they change the meetings, perhaps they take aspects of Kanban or Lean into it. And I know that when you do not use strict Scrum, you cannot expect to get all the benefits it can give you. In my experience it is often more valuable to see what works for this particular organisation, these particular people, this particular domain. There is great difference between a startup that creates an app from scratch and a hardware company that creates new, innovative wind turbines. The worst thing you can do, in my opinion, is to forget to inspect and adapt the process itself. To forget to ask "why" you do the things you do. So, yes, I agree with you 🙂
Scrum is a process with clear rules so you can sell courses and addons and "SAFE" and certificates and all that stuff. Then you send people fresh from university in the "project manager" career path for a scrum master training certification and there you go, agile company with agile projects. It's horrible. I have 3 agile coaches in the program wasting money by "implementing SAFE" and still every daily (even if they own it) is "i worked on a pull request for one of the stories, Eric will review it today, hopefully he will not find to much and then i have a meeting later", "i had many meetings yesterday and Joe wanted a report so i haven't done much for the project", "i have to pick up my kids later so i won't work on stories before 11. Then i will work on that terraform issue i found yesterday". 90% of that stuff is meaningless for the rest, never seen one at any customer where it isn't just a justification meeting. Even worse are the retrospectives with "ice breaker" games and a new format every week and many "we are great" statements, but never with a single actual implementable improvement with a name next to it, no "we should try to test better next sprint" is enough.
The worst part is: people think that SCRUM produces high quality software. But without a couple high quality people, SCRUM is a safe way to have unmaintainable software in 12-18 month because SCRUM does not care at all about technical quality. In a picture perfect SCRUM project, developers can produce the worst, buggiest unmaintainable piece of garbage code ever. And all the agile coaches and scrum masters assume that they still don't do SCRUM scrumy enough because what other reason could there be that the teams need 60%+ of their sprints to analyze, fix and rollout bugs and new features take longer and longer and always overrun estimations. Story point estimations must be the problem! So done with scrum masters who never coded anything.
I love the scar tissue analogy
Compelling story and I think this is very close to the original intention of "Agile". In reality, getting there is challenging. You know, processes exist to replace and substitute competent people. I strongly believe Agile only works well when all developers are at least technically proficient and have decent people skills while managers should understand what developers are actually doing so they have the piece of mind to trust whats going on. That means everyone in the company should be able to review the pull requests themselves for example. This is impossibly rare. My point is really that Agile alone is simply not good enough and I think it is not Agile but instead highly competent people that make the difference.
Yes they do
:-)
I call it watergile :)
Daves hair looks nice, he must have gone to the hairdresser! 👍
!!! I love you !!! (Ähm... I mean I do like Continues Delivery... and you saying that this way...) 😀
RUP was not a waterfall process. It was poorly implemented by many organizations that never understood the principles of interativa, risk driven, use case centric development. People latched onto the artifacts of the process and ignored the principles. ,
Spot on. And furthermore, fundamental to RUP is the Development Case, and the Process Engineers who adapt the specific process. I think the vast majority of development projects that go astray are due to a defective development process being followed, irrespective of what might have been planned.
I have had a box seat at Agile Theater for 20 years.
Just want to point out that the concept of "agile" has been around for a long time. The biggest difference here is that in the 80s and early 90s, most coding was not in java and you didn't have sophisticated build automation and version control tools like you had now. So the concept of "agile" evolved as technology evolved and things like Jenkins, git and so forth came about and most software development shifted from Unix, Windows MFC, C/C++, Cobol or other languages and on-prem data centers to java and web development along with the cloud. But things like extreme programming and team programming were around. However, in the 80s and 90s just getting people to actually use requirements and design was a big effort along with consistent and proper use of the version control tools that did exist. Meaning just getting people to consistently follow basic best practices was as a big issue beyond the model of development.
Also, contracts for third parties are not inherently "agile", because the contract is a specification of required deliverables that can be built and provided within a certain agreed time frame and a certain price. And this has always been something that is a challenge no matter the model of development you are using. Many contracts still fail even if they claim to be agile and the reason goes beyond simply using "agile" development because there is no silver bullet in software. Many other factors are the reasons why projects will fail and agile practices when not under contract often provide the illusion of progress that only delays the realization that the project is failing to deliver. And with 3rd party contracts a lot of them are not going to be willing to hire staff to be available for weekly or monthly project demos to work in an "agile" way. They more likely would rather have those resources on hand at the end for acceptance testing. But of course that depends.
Never admit a problem in the Agile itself.
I am sorry to hear you have had bad experiences with what people called agile. Given that I think the core of agile is "inspect and adapt" I find it hard to fault that.
The daily standup has to be the biggest waste of time ever invented. If a team can’t plan out more than a days work before getting started you’re really micro managing everyone because someone is a control freak without any ability for the team to be autonomous.
Well I think that from you description you haven't been doing "daily standups" you have been doing "Dialiy Planning Meetings" which is a VERY different thing.Standups aren't planning meetings they are a chance for the team to organise how they are going to organise themselves for this day's work, "I can work with you on that", "I saw something similar Yesterday, I can help", or "I had this weird problem Yesterday and fixed it like this", "Anyone know anything about this API?" and so on.
These all seem perfectly reasonable to me, and all very related to the work of the day and all may help me and every other member of the team to do a better job. I don't see how this compromises team auto9nomy or wastes their time.
the standup is an internal intra-team meeting. other people from outside the team may be allowed to attend if the team agree, but are not usually allowed to talk.
If you standups aren't like this then they aren't standups they are something else and you can't reasonably blame standups for something that your teams have chosen to do but that don't follow the practices that define a standup. That's like throwing rocks at dogs because you don't like cats.
The problem is that many teams aren't very good at this stuff so get things like standups badly wrong, which is why listening to experts like Aino may help.
If a set of principles are susceptible to be misinterpreted or abused then the principles are at fault not the people.
These principles are very simple and effective for those who understand them. Those who misunderstand them continue to miss out on the benefits. How is there a "fault" with the principles?
@@jcamenisch You've answered your own question. If they are misunderstood then they aren't very good principals.
I'm inclined to disagree, people are very good at not understanding and fucking things up. Doesn't mean that whatever you try to teach them is not a good principle. Is TDD a bad principle? Many people dislike it after trying it, and I'd say (admittedly: my opinion) they've been doing it wrong
@@jangohemmes352 Yes TDD is a bad principle. If something cannot be taught, or if something is easily misunderstood at what point do you throw in the towel and change tact? Agile is 25 years old at this point. It's a failed experiment. It got abused, twisted around and "allegedly" misunderstood. That's because the original principals weren't really that good. Maybe they were a step in the right direction but surely the writing is on the wall at this point. At what point do we look in the mirror and say "this isn't working"?
@@temper8281 you've failed to follow the train of thought. The principle is successful for those who apply it. End of story. If you're unable to understand it, that is your loss, and no one is responsible to fix that for you.
"anger management" is the key to success 😆
Typical scrum project is like a waterfall without design phase. I think of it as a circle of poorly planned implementations followed by endless refactoring and bug-fixing. Scrum actually allowed and encouraged non-tech people to be directly involved in development process and it is one of the biggest problems with scrum. We can do scrum and it will work if we just replace non-tech SM and non-tech PO with Lead Dev who actually knows how development works and instead of having tons of useless meetings, just normally talk with our colleges during lunch or coffee. "Agile" should be just natural teamwork and cooperation.
Agile is astrology for management.
My mission is to put engineers in direct contact with customers. On my 4th company in this effort, getting close
Please don't, you'll regret it😂 I think managers use this idea as an excuse to not learn the technical aspects of the product on a high level. Instead, they want us to do their jobs
I would just mention a caveat to this which Im sure you do intuitively anyway. this is great if you have good well rounded engineers and they take ownership over delivery(not just code), but some brilliant engineers are specialists and are not good communicators (and don't want it). Adapting to your team and their needs is part of agility.
I can't recall where this concept originally came from, but I think it is already known to be a mistake. Though it depends on your definition of Engineer, and your definition of Customer. It isn't a horrible idea to hold your weekly (or 2-weekly) demos, managed by Product or QA, and having a dev there to take notes or answer questions. But those demos are specific customers, not the whole customer base. And your devs aren't acting as help desk constantly, it's one meeting every couple weeks, and they're generally meant to be fairly quiet. There's a line somewhere, and there is indeed benefit to doing demos.
@@JinnGuild Yes! I partly agree with the other comments that there are some engineers that probably should not talk with customers (for various reasons). There are also examples of software systems developed, where those meetings do not make sense. But I have seen many organisations thrive on having good demo sessions with customers (or other stakeholders) regularly. You will need to mediate this conversation, or will become a frustrating waste of time. Having someone who can speak "both languages" can have a very good effect on the development of software systems to users. I am working on a video about that as well.
One thing for sure, scrum is bad... stop it people
Agile is waterfall just the cycle time is much shorter.
Absolutely not, and I hope you are just trolling. Agile is a set of principles, waterfall is a set of processes, which do not follow Agile principles.
Agreed, but also, even if we do view them as similar, if you organise your "Agile Team" as a mini-waterfall, I'd say that you are missing several important tricks and working very inefficiently and less effectively. Agile teams are much more effective if they organise their work so that work is done as early in the process as possible. For example, I don't want manual testers waiting for features to be finished before looking at it. I don't want ops people waiting for finished features before deploying them. Ideally we should be working collaboratively and all come to the conclusion that we are done at the same time.
I see your point, but I think that there are fundamental difference with the concepts and the mindset that you have when working in the different ways. As Dave also describes
@@ContinuousDelivery Maybe I misinterpreted - Did you just agree to the OP saying "Agile is Waterfall"? Or even that Agile can be viewed as Similar to waterfall? I'm fairly certain this channel has said multiple times that Agile is a set of principles. Maybe you are appeasing the OP by purposely conflating Agile with some of the typically bad applications out there?
@@Suamere My bad, I replied to the wrong post. I was responding to the comment that said "Agile is a set of principles, waterfall is a set of processes" not the OP - my mistake.
Operation Overlord was waterfall. Just sayin'...
Until they hit the beaches, then it became agile AF.
@@jcc4tube Sprints, literally XD
"Waterfall" isn't the same thing as having a plan. Overlord was planned, but it certainly wasn't waterfall, as most orgs practice it. For example, 'D Day' wasn't decided for months, and was postponed the day before, I think, because of bad weather in the channel. That sounds more like agile planning to me!
@@ContinuousDelivery Overlord was delayed due to weather but they had a rough idea as to when they wanted to go months out. They had the idea for a May or June campaign back in December of the previous year. AND they were doing requirements gathering a year out. All the hallmarks of the waterfall methodology was in full display. The front-loaded analysis and requirements gathering phase took nearly a year. Everything had to happen in a linear sequence. First the bombers went in, then the pathfinders, then the airborne troops, then the naval bombardment, then the amphibious assault, then armoured support, then the logistics and supplies. All planned down to the minute prior the D-Day itself and all of it consecutively executed. Agile was perhaps only exhibited on the squad or company level where small teams had to achieve previously defined objectives by improvising.
We need more agile coaches and less scrum coaches.
points are biased and inconsistent with what scrum and agile are.
Honestly, my ears are bleeding from all this what is agile and not agile debate, posts, videos on the internet.
Agile gets abused like the red-headed step child.
Are you the daughter of the guy of this channel?
No, not that I know of anyway 🙂
INTP doesn't like planning.
Language police is here I guess 🤷♂️
Women talking about tech = no
just looking for excuses to use buzzwords
Writing comments for code is a bad idea, unless your code is low-level. Otherwise it means you are not writing clean and maintainable code.
I believe in voodoo programing
This channel makes me feel a strong cognitive dissonance.
How do you mean?
Please do expand. Toward deceptive companies claiming Agile but doing Waterfall? Toward the industry or Agile in general? Toward this video/channel? Why?
Why did youtube recommend this video after watching kittens smoking cigars ?
Great Video Thanks