I still remember when our team was just starting to take shape. We were a small group of developers and analysts, trying to figure out how to work together—and how to build something meaningful. Somewhere along the way, we signed up for an “Agile and Scrum Leadership Workshop.”
I didn’t know it then, but that workshop would completely change the way I thought about software development. It was also where I earned my first certificate at work, which felt like a small but exciting milestone. If you want to see my certificate I included the link below
Before Agile, development sometimes felt like a mix of intuition and chaos—a lot of guessing, hoping, and redoing. But Agile introduced something different: a process that brought structure, predictability, and continuous improvement. Suddenly, it wasn’t just about writing code anymore; it was about building systems that build better software.
Breaking Big Things into Small Wins
One of the first lessons that stuck with me was how to break down big, intimidating tasks into smaller, clearer goals. We learned how to write user stories, estimate the effort based on complexity or scope, and prioritize them with the help of our Requirements Analysts.

And then there was Planning Poker—one of my favorite Agile rituals. Everyone would “vote” on how complex a task felt using story points: 1, 2, 3, or 5. What made it fascinating were the discussions that followed. When someone’s estimate stood out from the rest, it usually sparked deeper insights. Maybe they saw a hidden risk. Maybe they noticed a dependency the rest of us missed. Those moments of disagreement often led to our best planning decisions.
By the end of each session, we didn’t just have numbers on a board—we had a shared understanding of the work ahead.
Walking the Board and Staying Aligned

Once the sprint kicked off, the real rhythm began. Every morning, we’d gather for our daily stand-up, using the “Walk the Board” approach—starting from the right (Done) and moving left (To-do).
It might sound small, but this simple routine kept us aligned and aware. If someone hit a blocker, we’d catch it early and adapt before it snowballed into a bigger issue. Those short daily conversations built trust and accountability in ways that no long meeting ever could.
Demos, Feedback, and Honest Reflection

At the end of each sprint came Demo Day—our chance to show what we built and get feedback. Sometimes the feedback confirmed we were on the right track. Other times, it completely changed our perspective. Either way, it helped us build the right thing, not just the thing we thought people wanted.
Then came the Sprint Retrospective, my favorite part of the process. It wasn’t just a meeting—it was a safe space for reflection. We’d talk openly about what went well, what didn’t, and what we could do better. Those conversations often unlocked simple but powerful insights that made our next sprint smoother and faster.
The Power of Repetition
Over time, this cycle—plan, build, reflect, improve—became our rhythm. It taught me that consistent quality doesn’t come from perfection. It comes from iteration, feedback, and the willingness to keep improving, sprint after sprint.
Looking back, Agile didn’t just shape the way I work—it changed the way I think. It taught me that progress isn’t about doing everything at once. It’s about taking one small, meaningful step at a time, learning as you go, and trusting the process.







