(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.

Scrum?

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.

Iterations?

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.

Our schedule

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:

3 comments until now

[…] Part two in the series begins to explain how our team is implementing agile processes: how we meet, the weekly atomic work cycle known as an iteration, and why we think meetings are toxic. Plus, it’s got a great parenthetical reading list: (… 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.) […]