It’s 2014, and I’m sitting in a conference room in Rotterdam with a guy named Andy Barker. We’re building a project status update for the Iron Mountain REIT program, a global de-merger run by PwC across the US, UK, Europe, and Australia. Proper waterfall. Hard deadlines. A Gantt chart with four hundred line items.
Andy is the project admin for the Netherlands. I’m the project manager for Germany and the Netherlands. Between us, we have a PowerPoint and a problem: how do you make a steering committee actually understand what’s happening across two countries?
We take our creative freedom. We build a flow chart. It has tentacles. Leadership takes one look at it and calls it “the octopus.”
We’re thinking outside the box. At a box company.
That Iron Mountain program opened a dimension for me. PwC doesn’t play around. Strict project reporting, central program board, milestones tracked to the day. The kind of environment where your highlight report better be accurate, because someone three time zones away is reading it before you’ve had your first coffee.
Andy more or less ran the Netherlands by himself. One of his recurring tasks was updating that massive Gantt chart with current status. Every week. Hundreds of line items. Cross-referencing actual progress against the plan, flagging deviations, updating dependencies. The kind of work that takes discipline, attention, and about forty-five minutes of your life that you never get back.
Nobody liked doing it. It’s tedious. It’s error-prone. And it’s essential, because the moment your project data is stale, your decisions are based on fiction.
That was twelve years ago. I’ve been a project manager for fifteen years. PRINCE2 Practitioner, PMI Certified Associate, Management of Risk certified, Level 7 in Professional Consulting. I’ve run programs across countries, managed stakeholders from shop floor to board room, and compiled more status reports than I can count.
Here’s the thing I’ve learned about methodology: almost nobody follows it completely.
There’s a pattern I’ve seen in nearly every team I’ve worked with. I call it “agile waterfall.” You pick the comfortable parts from Scrum. The daily standups, the sprints, the board. Then you drop the uncomfortable parts. The retrospective actions that actually get implemented. The Definition of Ready that gates what enters a sprint. The rule that velocity is for forecasting, never for measuring performance.
What you end up with looks like agile. It feels like agile. But it’s not agile, because you left out the parts that make it work. Waterfall has the same problem. Teams that track milestones but skip the formal change control that gives those milestones meaning.
It’s human nature. When things get tight, you take shortcuts. You skip the retro. You let a ticket into the sprint without acceptance criteria because someone said it’s urgent. You average your RAG status across dimensions so the red gets diluted by all the green.
It takes discipline to stick to the methodology. More discipline than most teams have on a Tuesday afternoon with a deadline on Friday.
Twelve years after the octopus, I built an agent called Funley.
Funley is a project management assistant. You talk to it on Telegram, text or voice message, and it reads your Jira board, applies methodology logic, and writes a fully formatted status report to Confluence. The entire cycle takes less than ten seconds.
But the speed isn’t the point. The point is what happens between the Jira read and the Confluence write.
Funley has methodology embedded in its DNA. Not as a reference manual it can look up, but as a constitutional layer it cannot bypass. Before it generates any output, it verifies alignment with the active methodology. Scrum or PRINCE2, depending on the project.
The architecture has three layers.
The first is constitutional. Fifteen standing orders for Scrum, fourteen for PRINCE2. Loaded every interaction. Non-negotiable. RAG status uses worst-indicator-wins, never averaging. Velocity is for forecasting, never weaponized as a performance metric. Backlog items without acceptance criteria are not ready for a sprint. Period.
The second is the skills contract. Each report skill reads the methodology’s report template and RAG logic before generating output. The report isn’t a data dump formatted to look professional. It’s the data processed through genuine methodology thinking.
The third is the full library. When you ask Funley “what does the Scrum Guide say about adding scope mid-sprint?”, it cites chapter and verse. It doesn’t paraphrase. It doesn’t give you a vague best practice. It gives you the specific principle by name.
Every number in a Funley report comes from an actual Jira API call. Not from memory. Not from what seems plausible. The Python scripts execute, calculate, and format. The agent orchestrates and communicates. This is architectural, not just a prompt instruction. The agent literally cannot fabricate data.
Think about what that means for the “agile waterfall” problem.
A human PM knows the methodology. But humans take shortcuts under pressure. They let things slide. They round up. They skip the uncomfortable conversation about why the sprint carryover has been three consecutive sprints now.
Funley can’t do any of that. It can’t average away a red indicator. It can’t let an unestimated ticket pass as “ready.” It can’t pretend velocity is performance. The methodology isn’t something it refers to. It’s something it is.
That frees the human PM to do the work that actually matters. Stakeholder engagement. Creative problem-solving. Building the relationships that make projects actually move. The octopus moments, where two people in a room find a way to communicate something complex in a way that lands.
That was always the real work. The Gantt chart updates and the weekly highlight reports and the status compilation were overhead. Necessary overhead, but overhead. And now it takes ten seconds instead of forty-five minutes.
I haven’t shown Funley to Andy yet.
We met in that conference room in 2014 and somehow, during the project, managed to get in the water for a surf together in Scheveningen. We bonded. And ever since, we’ve had a weekly call. Over ten years now of catching up, professionally and personally. He has his own consultancy these days. He’s a major figure in the Atlassian ecosystem. Fun Inc, and if the name Funley sounds familiar, that’s not a coincidence.
He’s aware of agents. I’ve shown him Justec, my personal assistant that manages a Trello board through Telegram. He liked that. But Funley is a different level. Methodology-aware, Confluence-native, built on the same Atlassian stack he works in every day.
Scrum and PRINCE2 are live. Kanban, SAFe, and PMBOK are on the roadmap. The methodology engine is pluggable: same data pipeline, different rules. The platform architecture separates input, processing, and output. Jira today, Azure DevOps or Linear tomorrow. Slack integration is next.
I built Funley because I know the pain. Fifteen years of compiling reports, updating Gantt charts, sitting in meetings without the right answer immediately at hand. But I also built it because I’m in a rare position: certified in the methodologies, experienced in the field, and now building agents that can encode both.
I think it’s time he meets Funley.
Our octopus had tentacles. This one has standing orders.
Leave a Reply