After training as a Certified Scrummaster earlier this year, I've had the opportunity to run a fairly large Agile project. Along the way I've learnt a few things about what really helps your sprints be sucessful.
Write good stories
Far and away the best guarantee of a good sprint is having good stories. I found the biggest learning curve from theory to practice is getting to those good stories, because stories are hard.
Having four hours of planning for a two week sprint may seem like a lot, but it quickly becomes apparent that you'll need all of that time. It can be a long process when you walk through every story and acceptance criterion, but the most painful sprint planning sessions have resorted in our best stories.
A good story and acceptance criteria sets the expectations of both the team and the client for the feature, and should be refined until there's no ambiguity as to what functionality is to be delivered (but not how it will be delivered).
Software isn't a substitute for a board
Initially we started out without a physical task board, relying instead on our software tracking system. After a couple of sprints we implemented a physical board, and it made a huge difference to both our productivity and task visibility.
I feel the biggest difference is how tangible a physical board is. It's very easy to see what's happening and move things around, and it's very satisfying taking off completed tasks.
The downside of the physical board is that it takes someone's time to maintain, but I feel that the benefits to the team are completely worth it.
Dig deep in standups
Keeping standups brief shouldn't happen at the expense of surfacing issues. The Scrummaster's job in a standup is to ask questions, and probe into how tasks are going.
Sometimes team members might have issues that they aren't surfacing, or are going to run into impediments that haven't been identified. Everyone should talk about what has and will happen on all of their tasks.
One of the big symptoms of this is if you keep having standups without anyone announcing impediments. Of course, in an ideal world this would be the case, but in the real world this signals that you aren't digging deep enough into how tasks are going. The outcome is that the impediments happen anyway, and you aren't in a position to intercept them.
Agile is fun
Agile can be hard to get started, but once you've hit your cadence it's a really fun way to work. You don't hit the soul-destroying slog that I'm sure everyone's experienced on a Waterfall project if things start to slip, since any slips only affect a single sprint.
I've really enjoyed my experience of Agile so far, and I'll write another one of these further down the line with any more lessons I learn.