Agile Manifesto Through the Eyes of a PO
Picture this: I just wrapped up another long, pointless corporate meeting, an hour spent debating something that I forgot the moment the call ended. And somehow, the Agile Manifesto pops into my head. Don't ask why—it just does that on Monday mornings. So let's break it down, corporate-style, from the perspective of an "agile" company, of course.
(Disclaimer: Take this as a grumpy old PO rant—Monday morning mood, written on a shiny Saturday.)
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Yeah, right. As if anyone cares about the customer. It’s all about the money! Who’s the real "customer"?
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
More mandatory requirements for "customer satisfaction". Just keep it in the same budget, quality, and of course, deliver it a little bit sooner. Twice the work in half the time, isn’t it??
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Wait, what? Try convincing the stakeholder that an unfinished product may work. They heard about MVP, and they think it means Massively Vast Product.
Business people and developers must work together daily throughout the project.
Hmm, all developers should speak “business,” otherwise they are bad developers. Of course, we have two solutions:
- More meetings for Devs—we all know how much they love meetings.
Pair programming Dev & Business; It’s like the start of a joke: One dev and one business person walk into a bar...
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
😂 This one gets me all the time. I mean, sure, we trust them—right after the biweekly status reports, daily standups, stakeholder check-ins, Jira updates, and an "alignment" meeting. What can be more motivating than that?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Face-to-face like Confluence, Jira, Git PR mandatory comments format, PV, PR, PRD, Competitive Analysis, GTM… wait, what was the topic again?
Working software is the primary measure of progress.
I think there’s a typo here. It should be Partially working software because we delivered the “increment” only for search—without the further steps like processing, change, and save. Right?
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Let’s start with the first part: “Agile processes”. Isn’t it nice how this "process" turned out? Like when I add a topic for the team, it MUST have all the “face-to-face” documents above, plus acceptance criteria, and of course, everything should pass the Definition of Ready.
For the second part—constant pace means we need to “improve ourselves” and deliver better results with a lower budget?
Continuous attention to technical excellence and good design enhances agility.
This is spot on! We provided training for our developers in ML, AI, DevOpsSec, blockchain, and microservice architecture! Too bad our systems run on tech from the early 2000s, but as soon as we decide to move everything to a new ecosystem, we are READY!
Simplicity—the art of maximizing the amount of work not done—is essential.
Ok, Ok, this one is simple. No rant about it.
The best architectures, requirements, and designs emerge from self-organizing teams.
Totally agree with this one. Architecture is done by the self-organizing Architecture Team, requirements by the self-organizing Product Team, designs by the self-organizing UX Design Team. Did I miss any self-organizing teams?
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
It’s called mid-year and end-of-year self-evaluation, correct? I saw some retrospectives too, but let’s be honest—those are neither regular, nor do they adjust or tune anything.
So, should we burn the Agile Manifesto? No, of course not. But maybe—just maybe—we should stop pretending that sticking "Agile" on a PowerPoint slide or call a project “Agile” makes us magically aligned with its principles.
- D. Scope
Comments ()