Jack R.’s Post

First of all, the best way to do waterfall is to run short increments. Been there, done it 20+ years ago. That doesn’t make it Agile, but of course, but if you get 45% improvement in things you care about, awesome. That’s already worth doing it. Additionally, adopting Agile mindset into miniwaterfalls is great. Adopting Agile development techniques is even better. It all might actually lead to proper Agile, and further improvements in outcomes. So, Scrum-like miniwaterfalls may be a great starting point for many teams, especially if there are strong traditional org structures, policies, and behaviors in the organisation. It will still struggle with the typical waterfall outcomes - like missed Sprint commitments, incomplete items at end of Sprint, low quality code and incomplete testing, difficult refactoring, etc. Again, been there, done that. But it can be really good waterfall.

Agile/Scrum often feels like it's run like Waterfall when organizations prioritize fixed deadlines, rigid scope, or sequential phases (e.g., design, development, testing) without proper iteration or flexibility. This happens due to: Lack of true Agile adoption—teams may follow Agile rituals but still operate in Waterfall mode. Misalignment with business expectations—pressure for upfront scope definition and delivery dates. Poor sprint planning—leading to minimal iterations and late-stage testing, as in Waterfall. Yes, this creates unnecessary pressure on developers and testers, as they are forced to deliver quickly without enough time for quality assurance, leading to potential compromise in both code quality and testing outcomes.

Agile, like any methodology, must be tailored to the product environment and company. Initial formalized training is crucial to establish a solid foundation, but continual evolution is essential for Agile to adapt and succeed within an organization. For example: > The SAFe Agile framework can be highly effective for scaling Agile across large projects and managing product roadmaps, but care must be taken to avoid unnecessary bureaucracy. > Kanban is ideal for handling dynamic requirements, such as sustaining engineering, as it supports continuous delivery and flexibility. > XP is well-suited for delivering high-quality value in fast-paced environments through its technical excellence practices like test-driven development and pair programming. Evangelizing Agile across cross-functional teams is equally important. This involves not only communicating Agile principles but also engaging teams through workshops, collaborative sessions, and hands-on training. Teams must understand the values, principles, and guidelines (rather than rigid rules) to leverage Agile effectively, allowing scrum teams to deliver adaptable, high-quality deliverables.

We use Agile. Based on what? Because all our user stories are in Jira. Can I see your user stories? *BRDs copied from a Word document and pasted into a Jira ticket of type Story

10 years ago worked in bugfix team. Management decided/force scrum/agile is perfect for my team. Due to "issues" with burdown chart (no option to predict time we need to fix a bug), we endup planning tasks we really do this sprint, in the next one (small shift). So, burndown chart was perfect after that and management advertise big success. We were wasting 2-3 days each sprint - but management was happy. That was "funny" experience.

I've observed a concerning trend where key proponents of Agile are compromising its core principles. Some Agile trainers, particularly in local WhatsApp groups, are promoting practices that deviate from Agile's intent, often justifying them with reasons such as budget constraints or the need for faster delivery. Additionally, there seems to be an increasing number of job openings with titles like 'Technical Scrum Master,' 'Agile Project Manager,' or 'Scrum Master with DevOps experience,' which further blurs the lines between Agile roles and responsibilities. God bless these companies and God bless Agile.

Sprint planning with standups (not necessarily dailies) is just a way to check whether things are going as needed, and make corrections. If I don't have a sprint, I need some other kind of regular check mechanism. We can call them biweekly galactic council meetings with daily roll call agile sessions, doesn't matter.

This "Wagile" approach has been all too common in most (if not all) the robotics companies I've worked with. Agile adoption and transformation is hard, especially areas with hardware, but it's possible. I'd say often, waterfall in sprints is a good stepping stone for companies & teams using traditional predictive project planning methods (aka waterfall), as long as you keep going with devops, lean, and/or agile concepts to continue transforming. Also, many "agilists" have the goal of transformation, but the organization & its leadership may not have this goal. Thus, waterfall with sprints may be the company goal, which is 100% ok (for some orgs), but just don't taint the term or hallucinate this as being agile.

I often encounter in various projects that an agile mindset exists only at a very low maturity level. One of the outcomes of this is that Scrum is applied in a pseudo-agile way, where teams are essentially following a waterfall approach with milestones set every two or three weeks.

I think there is no one true way. I've worked a few places where Agile has clearly become waterfall, just like above. The key I think is to be flexible. In the real world, battle plans don't survive first contact with the enemy, but you can't have no plan either. Too much plan is a problem just as much as too little. The moment there is subscribing to a doctrine, I get concerned.