Comments by "" (@JinnGuild) on "Scrum DOES NOT Equal AGILE" video.

  1. 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.
    16
  2. 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.
    4
  3. 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.
    3
  4. ​ @brandonpearman9218  Long story short, yes, that is exactly what they were saying. And exactly as you mention, "Continuous" back then was LOFTY to imagine every couple weeks or months. That was like imagining a Gigabyte of RAM in the 90's!! But just as we have home machines with tens or hundreds of gigabytes of ram now, we also have redefined "Continuous" to literally mean Continuous. No time frame. Just whenever something is done, it goes! If a team 22 years after the Agile Manifesto was written is literally delivering every few weeks because that was the standard set by the Agile Manifesto, they are obviously a couple decades behind the curve. Similarly, when they talk about Face to Face communication, keep in mind they didn't have Smartphones with 5G video, or Slack. They were still working on paper and using E-Mail. "Face to Face" absolutely includes Emojis and Chat today, though I'm sure we'd all agree it absolutely includes Meet/Zoom/Teams/etc. I am actually disappointed in this video for not pointing these things out more clearly.
    3
  5.  @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.
    3
  6.  @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.
    3
  7. 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.
    2
  8. 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.
    2
  9. 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.
    2
  10. 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.
    2
  11. Please do expand. Toward deceptive companies claiming Agile but doing Waterfall? Toward the industry or Agile in general? Toward this video/channel? Why?
    2
  12. I can slightly agree with this. But keep in mind that the vast majority (which is a lot) of companies doing "Agile" and mis-interpreting them have never even opened the Agile Manifesto. Or if so, the teams are being run by individuals who refuse to let go of their Gantt charts, and so will purposely misinterpret to suit their needs. Any person who is either tenured enough with Agile, educated on the subject, or new enough to not have been tainted by working within waterfall companies has no trouble at all reading the Agile Manifesto and interpreting it crystal clear.
    1
  13. 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.
    1
  14.  @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.
    1
  15. 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
    1