For this blog entry I decided to choose something related to Agile. In the blogpost, Agile Principles: The Complete Guide To All 12 Principles For 2025 written by Sean O’Connor, he goes over how Agile’s flexibility gives it real world benefits for businesses, development teams, and customers. Much like how with what we went over in class, Sean O’Connor explains that Agile’s strengths aren’t so much about speed of delivery of a product, but in it’s efficiency in producing a working project, with speed as positive byproduct. As someone who’s never been good at long term planning, what was explained in the blogpost really resonated with me. Things like catching problems early when it hasn’t become a core “feature” of the software, building what the customer actually needs rather then wasting time, and especially the part of creating quick wins, are some things that I value in a game plan. The blogpost then goes into 12 principles that makeup all Agile methodologies, a couple of which really stood out to me.
One of the principles was delivering working software frequently. I like the idea of real progress you can actually see and use, not just what it could potentially be. It’s nice when you get to see something that actually works early, even if it’s just a rough version. This approach makes more sense to me than spending weeks or months planning something that might not even be what was wanted, which is just a huge waste of time and energy. So to me being able to get instant feedback, learn faster, and fix problems before they turn into something major, is huge.
Another principle that ties into that is measuring progress by working software. That line really sums up Agile’s idea of “cutting out the chaff”. It’s easy to get caught up in planning, documentation, or presentations that sound good but don’t actually move the project forward. A working prototype says more than any report could. I think that same logic applies to class projects too, seeing your code actually run feels like a real measure of progress, not how well it’s outlined on paper.
The principle of simplicity, or “maximizing the amount of work not done,” also hit home for me. It’s about focusing on what truly matters and using just enough time and energy needed. I tend to overthink projects at the start, but this mindset reminds me that getting the essentials working is more productive than building unnecessary features. Fewer moving parts also means fewer ways for things to break (something I know all to well).
All in all, it’s reassuring to see that my “slacker mindset” can be the basis for something actually productive.
From the blog CS@Worcester – CS Notes Blog by bluu1 and used with permission of the author. All other rights reserved by the author.





