In part 1, I wrote a bit about the origins of agile, without going into how it translates into a day to day practice. So, what do you do once you buy into the principles of agile software development? Get ready for some rules.
(Disclaimer: If you’re at an organization that’s ready to take the plunge into agile, please please please don’t use this blog as a guide. I will present an incomplete list of things we’re doing, which is an small subset of things we ought to be doing, presented by a guy with a teensy tiny knowledge of the full canon of agile practices. If you want to do this right, read Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin, and The Pragmatic Programmer, by Andy Hunt, and Dave Thomas. Or even better, go to Ann Arbor and learn it from the badasses at The Menlo Institute.)
(Also, read Getting Real by the folks at 37signals. Please, just trust me on this one. It’s important. Much more important than reading this silly blog post, that’s for sure.)
At the beginning of this project, I presented to the team a set of rules by which we all need to abide. The following is a subset of those rules regarding our weekly schedule.
- We will scrum every morning.
- We will work iteratively, regrouping and correcting our course once a week.
- At the end of each iteration, we will have built and deployed a working piece of software.
- At the end of each iteration, we will demo our work to the entire team, including stakeholders at the client.
- Following an iteration, we will gather feedback from end users, stakeholders, etc., and we will adapt.
A scrum is a five-minute long, stand-up (no sitting!) meeting with everyone on the team in attendance. (Not just the worker bees. The boss. The client. Everyone.) We go in a circle and briefly recount what we accomplished in the previous day, and what we will to do today. Keeping everyone in the loop might be the most important thing we can do to make this work.
We work in iteration: tight, discrete chunks that usually a week or two, tops. This way, there is always a working product, just in varying stages of completion, that can be loved, hated, and rated by the folks who matter most: the users. (Software joke: Name the other industry that calls its customers “users.”)
This is also about keeping everyone in the loop, but we work this way for many other reasons. It makes it much easier to change direction. It prevents the development team from bullshitting everybody else. (Sure. It’s practically done! All we’ve got to do is write the code!) And it lets the stakeholders (client, instructor, your boss) see what they’re getting for their investment of time and/or money.
We meet Tuesday thru Friday. So we’re doing 4 day iterations (pretty short, but we’re making due with what we’ve got) resulting in a weekly schedule for everyone on the team that looks like this:
- Scrum, 5 minutes, 9:30 a.m. Tuesday thru Friday
- Iteration Kickoff, 30 minutes, 9:35 a.m. Tuesday, following Scrum
- Iteration Review, 1 hour, 11:00 a.m., Friday
All other meetings will be held in accordance with the rules defined in Getting Real: Meetings Are Toxic (<– click this!):
For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:
- Set a 30 minute timer. When it rings, meeting’s over. Period.
- Invite as few people as possible.
- Never have a meeting without a clear agenda.
So, that’s it for today! Stay tuned for more on our agile process. Next week: how we break down big scary problems into little tiny problems that aren’t scary at all.