foomonger's blog

I've been using Agile software development methodologies on a variety of teams over the past few years, often playing the ScrumMaster in addition to a full-time developer. In this post I'll describe notable lessons I've learned.

Planning Meetings

I don't know anyone that enjoys 8 hour planning meetings. I used to find them useful for getting the entire team on the same page but it's painful. Now I prefer something more scrum-ban style and hold weekly 30-45 minute planning sessions. Just enough to fill out the backlog for a week or so.

Reality Check

Agile doesn't alter reality. I think it just helps expose it. In the end some of the variables you have to work with are still the same: people, time, and scope. If your product owner sends out an email telling the team to work harder to hit a deadline because scope is no longer negotiable ... reality check. If you uncover some technical debt that makes what you thought would take about a day to take more than a week ... reality check. At each hurdle I've encountered I make sure to take a step back, unemotionally embrace reality, looks at my choices, and then more forward.

Fine-grained or Coarse-grained User Stories

Having gone both extremes when fleshing out a backlog I now lean towards coarser-grained user stories. I found that while finer-grained stories help expose what's exactly being worked on, it's at the cost of a cluttered backlog which makes it more difficult to determine the progress of overall business value. The downside of coarser-grained stories is that tickets may hang around longer than you'd like and look stagnant. I think it's an art and I find that regular communication through daily scrums and team chat rooms helps keep an eye on detailed progress.

Defining "Done"

I used to think I was cool wanting a firm and awesome definition of "Done" for a user-story. Code complete, design reviewed, unit-tested, QA'd, etc. Don't get me wrong, I still like the idea of Done. In a recent project we didn't have UI designs for a while. I defined Done to include design of course. But after a while the design bottleneck caused the list of in-progress tickets to grew unbearably. Tickets were code-complete and QA'd, but the designs just weren't applied yet. It was difficult to quickly see how the team was doing. I later decided to remove the design requirement for Done and created separate chore tickets (in Pivotal Tracker) to address designs later. When design was no longer a bottleneck, it was added back as a Done requirement. It wasn't perfect but in that situation my desire to improve flow and process trumped my desire to have concise and perfectly Done tickets.

I can't claim these lessons as absolute fact, but I hope someone fines them helpful. Happy Agiling.