Dear Past Me,
I know you’re about to embark on that finance project, armed with user stories and good intentions. You’re thinking, “We’ll write everything down perfectly, and it’ll all work out.” Spoiler alert: it won’t. But here’s what you need to know before you learn it the hard way.
The User Story Experiment That Wasn’t
Remember when we decided to write user stories for a strict waterfall project? Yeah, that was like bringing a surfboard to a skiing trip. Technically both involve balance and movement, but the context matters. A lot.
We thought we were being innovative – blending Agile user stories with technical specifications in a waterfall environment. In reality, we created something that combined the worst of both worlds. It’s like making a smoothie by throwing random ingredients together without a recipe. Sometimes you get lucky, but usually, you just get a weird taste that nobody asked for.
If you want to explore the differences between agile and waterfall check this guide here.
What Actually Happened (And Why Theory Isn’t Just Corporate Buzzword Bingo)
Here’s the uncomfortable truth I wish someone had told us: methodology theory isn’t bureaucratic nonsense – it’s the collective wisdom of thousands of failed projects distilled into guardrails.
When I finally sat down and actually read about waterfall’s disadvantages – not skimmed, but really read – every single pain point was staring back at me from our own project:
The Developer Disconnect:
- They didn’t read all the requirements (because there were too many, and no conversation to anchor understanding)
- They misinterpreted functions (because documentation without dialogue is just guesswork with better formatting)
- Feedback came extremely late (because that’s literally how waterfall works – you build, then you see)
The Hybrid Trap We Walked Into: We tried to be agile in spirit but waterfall in execution. In a fast-paced finance environment where regulations change faster than coffee gets cold, we built a system with zero flexibility. It’s like constructing a brick house on shifting sand while pretending the sand isn’t shifting.
The Real Issues (A Greatest Hits Collection)
1. The Requirements Black Hole Developers couldn’t find what they needed because user stories weren’t meant for waterfall. They’re conversation starters, not comprehensive documentation. We gave them appetizers and expected a full meal.
2. The Missing “Why” No one understood the vision. Developers were building features without knowing how they fit the big picture. Imagine assembling IKEA furniture without the final product photo – technically possible, theoretically frustrating.
3. The Capacity Crisis Developers reviewed requirements late. They had questions. Many questions. But we hadn’t allocated capacity for analyst responses. Result? A queue of confusion that grew like a snowball rolling downhill.
4. The Change Avalanche Issues discovered late in development forced us to redo completed work. In finance, legal requirements shift. Specifications we started writing two years ago became outdated. Developers weren’t happy about changes, and honestly, neither were we.
5. The Testing Nightmare Testing took forever. Fixes took even longer. Everything was sequential, everything was delayed, everything was painful.
The Lesson I Wish We’d Learned Earlier
We didn’t need a hybrid approach. We needed to pick one methodology and actually follow it.
If we’d committed to waterfall:
- Write comprehensive technical specifications upfront
- Include detailed design documents
- Plan for extensive review cycles
- Accept that changes are expensive
- Build in longer timelines
If we’d gone agile:
- Start with minimal documentation
- Prioritize communication over comprehensive specs
- Build in short iterations with continuous feedback
- Embrace change as part of the process
- Involve developers from day one
Instead, we tried to have it both ways and got neither. Our “hybrid” approach was really just chaos with better formatting.
What You Should Do Instead
Stop pretending theory is boring. Those methodology frameworks? They exist because people failed exactly the way you’re about to fail. Read them. Not because you want to follow them religiously, but because you want to understand why the rules exist.
Choose your framework based on your environment. Fast-paced finance with changing regulations? That’s screaming for agile. Stable requirements with clear endpoints? Maybe waterfall works. But make a choice and commit to it.
If you must mix methodologies, define clear rules. What are you taking from each approach? What are you leaving behind? How do they work together? Without answers, you’re just improvising badly.
Communication isn’t optional. Whether it’s waterfall documentation or agile conversations, make sure everyone understands not just what they’re building, but why.
The Bottom Line
Past Me, that project is going to be rough. You’re going to question your approach, your skills, and your career choices (probably in that order). But here’s the thing – this failure will teach you more than any successful project ever could.
You’ll learn that methodology isn’t just corporate overhead. It’s a shared language, a set of expectations, a framework for success. And when you ignore it, you don’t break free from constraints – you just create new, more painful ones.
So pick a methodology. Understand it. Follow it. And if you decide to break the rules, at least know which rules you’re breaking and why.
Your wiser (and slightly more cynical) self will thank you.
P.S. When the project starts going sideways, don’t wait to speak up. That uncomfortable conversation you’re avoiding? Have it six months earlier. Trust me on this one.