This blog is no longer being updated, follow us on Twitter
How we work: A detailed look at one of our development iterations
November 12th, 2008
As good agile practitioners, we like short iterations; effort is easier to estimate and it gives us a sense of focus, a limited amount of work that we can motivate ourselves with while we forget about future bridges that might or might not need crossing. We work on weekly iterations that run from Friday to Thursday and we finish on Thursday because often we find ourselves working harder at the end of each iteration, sometimes going late in the day to try to accomplish what we set out to do in the first place, and allowing this to happen on Fridays is bad for morale and bad for the quality of the product, since naturally everyone wants to go home early on Fridays and this can lead to rushed decisions. We force ourselves to finish on Thursdays and that way we can have a relaxed Friday, wrapping up the iteration, going through it in detail, noting bugs if we find any and carefully planning and starting the next iteration. As much as we can, and this is not easy, we try to avoid big efforts at the very last moment, since we have realized these hardly ever make any difference in the customers’ overall impression on what we have accomplished and it does however have a negative impact on us.
We try to work interface first, which means that we try to work out in advance what the simplest possible web interface would be for the features we seek to implement. For the last couple of weeks we have been very lucky to count for that with who I am sure is one of the best interaction design companies out there (Programa Vostok, with Javier Cañada and Mark MacKay), who come in once a week to spend the day with us, review the work done in the previous week and work on the UI for the following week’s features/user stories. You could say this is the kick-off for each iteration.
We first talk in general about what we want to implement in this iteration and why, whether it is absolutely necessary for the app to have these things and whether our customers could live without them or not; we try to make sure we implement only (and this is the hardest part) what is a “must have” and not what is “nice to have” and Javier and Mark focus on making the “must haves” kick ass, really easy to use features that add value to the application. They do this first on paper, and then they switch to Fireworks and prepare some PNGs; once they are done, they walk us through it, we discuss it, and we generally nod in awe and amazement, although we sometimes (rarely…) boldly offer some suggestions too.
This happens generally on Wednesdays, while the current iteration is in progress, which leaves us roughly two days to implement the HTML/CSS and write down the acceptance criteria for the corresponding stories/features.
In our Presentation in the Conferencia Rails Hispana, Luismi Cavallé and I will explain how we go about writing the acceptance criteria for each of the stories to provide a a “ubiquitous language” (as Dan North described it originally in his introducing BDD) for stakeholders, developers and customers, how all our development and testing gravitates around them, how we Pair Program for best results and how we use Behaviour Driven Development (BDD) principles to guide us in the design of the application code, step by step, feature by feature.
Allí nos vemos!!
Originally published by Jorge Gómez.
Filed under Programming