Comments by "" (@ContinuousDelivery) on "What is Post Agile?" video.

  1. Yes, that is an important point, and not just for PMs. There really is no place to hide in a well functioning agile team. If you aren't doing a good job, your team-mates will see that and know it. This is challenging for some people and some orgs.
    3
  2. No, they are still strong supporters 😁🤣
    3
  3. As I said in the video, agile is defined by the agile manifesto, so which parts of the agile manifesto are flawed?
    2
  4. I think that is a reasonable statement, I think of the Agile manifesto as a necessary step away from the big-ceremony failed approaches that were in play at the time (and still are in many orgs) they were an important step and a step in the right direction, the direction of working iteratively incrementally and experimentally. The next step beyond Agile is, to my mind, a step to genuine engineering, where we can measure things and falsify things. That is what my new book "Modern Software Engineering" is all about.
    2
  5. 😂 no offence taken
    2
  6. Did you see this one? https://youtu.be/0HMsh459h5c
    2
  7. Well, the way that you can tell wether you are working in an agile way is to take a look at the agile manifesto. It is not very proscriptive, but I think it is pretty universally applicable. Lots of people have a naive view of what a user-focus means. It is not just about user interface features, the usability and utility of your system is about more than that. So I am perfectly comfortable doing work that is "of value to users" deep in the stack.
    2
  8. Checkout the stuff on Refactoring on my course site - it's free, https://courses.cd.refactoring
    2
  9. I have already done a video on some aspects of this: https://youtu.be/JPfbjKl9jbw
    2
  10. Glad you enjoyed it!
    2
  11.  @piotrd.4850  Well I have seen it work for about a thousand developers working on the same codebase, so not just for small teams. Commonly for teams of hundreds, composed of many smaller teams. I don't understand your translations at all, they seem non-sequitur to me.How does "Working SW over comprehensive docs" relate to "only works on my machine" the definition of "working", at least for Continuous Delivery is being useful to users in production. "Tons of billable hours" well only if you are crap at writing code perhaps, the teams that work the way that I describe produce measurably higher quality software more quickly, not less, so actually fewer "billable hours". Read the "Accelerate" book or the "State of DevOps reports". The companies that work this way are not "small agile tiger teams" they are often some of the more successful companies in their fields, Amazon, Google, Microsoft, Tesla, SpaceX, Ericsson, Volvo, US Air force UK Government, the list goes on.
    1
  12.  @sujithsukumaran8689  "agile" development isn't defined by "agile frameworks" it's defined by the agile manifesto. Following a framework like Scrum doesn't guarantee agility, in fact most teams that claim to follow Scrum aren't agile in the sense of the agile manifesto. Scrum, and any other "agile framework" are more like training wheels for agile practice.
    1
  13. Thanks for sharing your experience!
    1
  14. Well as I believe described by one of Wittgenstein's contributions, philosophy isn't science.  Science is science, and science is based, in part, on being skeptical about everything - questioning things and that is what I was referring to.  "Science is the belief in the ignorance of experts" - Richard Feynman I am neither a philosopher nor a scientist, though I know a lot more about science than I do about philosophy. I aspire to be an engineer, and apply scientific (not philosophic) style reasoning to solving practical problems in software. I can only approach the world from my own perspective, I am rarely quoting other people on this channel, and when I am I try to make sure that I say so. These are my ideas and describe my approach. I think of it as applying the skeptical mind to ideas, questioning everything. I don't mean this in the, to me, rather dry terms of philosophy, I mean it in the more practical terms of science. I try hard to find the weakness in ideas, including my own, as a way to improving my understanding of things - so this is what I mean by "I question pretty much everything". I am a software developer, and I try my best to understand problems and how to solve them. One of the most common failings, not just in software, is the temptation to fall back on dogma, and received wisdom. So I think I do question everything, in that sense, ao thank you for sharing my videos with your students and I hope that they will question ideas in the same way that I assume we would both recommend.
    1
  15.  @Epilon  For CD the measures of success are pretty well established now, Stability & Throughput - the DORA metrics. I do agree with you though that any process if treated as some form of religion won't work.
    1
  16.  @joshuaswick  🤣 Thanks
    1
  17. Thank you! I'm glad it was useful!
    1
  18. Not really, any more than any other approach. The idea of fixing time and scope is an illusion. Sure, it would be great if you could, but you can't. Ever hired a builder or a plumber? Ever talked to a startup about when the venture will succeed? These are all guesses. Agile admits the reality of this, You can work to a fixed date, but vary the content, or you can deliver fixed content, and vary the schedule. This isn't new to agile, people have spoken about this in planning for decades before, it is just that many businesses run on superstition and magical thinking rather than reality.
    1
  19. Thanks for the feedback. I'm glad you enjoyed the video, and I hope you stay a while and find some of my other stuff useful!
    1
  20. Have you been watch SpaceX build their Starship. That is agile engineering in practice.
    1
  21. I think that agile is more than one of the useful tools in the box, even more so if I am correct in thinking of agile as an informal adoption of some scientific fundamentals. None of that means that I disagree with what I take to be the thrust of your comment, sure, no process allows us to take our brains out of gear. If there was a cookie-cutter recipe for writing software, we could automate it, and do ourselves out of a job in the process. Software development is a complex, difficult task. At the limits, it is one of the more difficult things that we as a species do. Sure, most SW dev isn't that hard, but some of it is, and one of the difficult things is that even when you are doing something simple, like a server less function or a web-page, you are skating on the surface of some genuinely difficult, maybe even profound, problems. Ideas like coupling and concurrency, for example are world-class difficult, and impact teams even when doing relatively simple things. So having some discipline, some organising structure around which we shape our ingenuity and creativity seems more important than just picking tools from the tool box. It helps keep the beginners away from the deep end, and it helps the experienced people to build on, and enhance their own work as their learning deepens.
    1
  22. Well I suppose that may how some teams do it, but that is not what agile says or does. The highest quality system that I have ever seen, let alone worked on, was written using agile principles by the most disciplined team that I have ever worked with. We did some very cool stuff faster and with higher quality than I have seen before and solved some interesting and difficult problems along the way. Oh, and it was in a heavily regulated industry too. So I am afraid that I disagree with all of this.
    1
  23.  @rmworkemail6507  How do you know, I don't describe the science bit here? Science is an approach to discovering new knowledge, one take on modern engineering is that it is a practical application of scientific approaches to learning how to solve problems. The scientific method is: Characterisation Make a guess based on experience and observation. Hypothesis Propose an explanation. Deduction Make a prediction from the hypothesis. Experiment Test the prediction. You can apply this approach to development in a wide variety of ways.  C: The user has this problem H: I think this test describes something that represents that problem. D: When I run this test, I expect it to fail with this error message, 'cos I don't have any code to make it pass yet. E: run the test and see if it matches the results. There's a lot more that we can take from science... Start by assuming that your guesses, designs, understanding is wrong, rather than right, and figure out how to falsify your ideas ratter than prove them. Control the variables, so that you can clearly see the results of you experiments. So I think it valid to talk about applying scientific style reasoning to SW and when we do, calling it "Engineering".
    1
  24. Thanks for the feedback! 🔕
    1