Agile Developer’s Journal: A Day in the Life


9:30 a.m. – 9:50 a.m.
An interesting follow up came out of today’s daily stand up: How do you dynamically resize a portfolio allocation pie chart when the browser is resized? OK, interesting for some of us. Pavel, our graphics developer, the ScrumMaster, the client manager, and I gather around the white board in the agile room to brainstorm (with the rest of the team in the room listening). We determine that an exploratory spike is needed, which means we don’t know the technical answer, so we will experiment to find an appropriate solution. If the spike is known during planning or requires a sizable effort, an estimated task will be created. The pie chart problem seems small; within twenty minutes we’ve prototyped a solution, thus there’s no need to re-estimate the tasks.

9:50 a.m. – 10:50 a.m.
Pavel and I pair up to work on another portfolio-related allocation task. At Re-Balancing Act we practice XP’s pair programming, meaning that pairs of developers write all code. Although we have individual workstations, the “pair” sits at a designated pair programming workstation with two monitors, two chairs, and enough room for two people. We take turns handling tactical (typing at the keyboard) versus strategy work.

Test-driven development is another important practice we follow. First, we write a simple failing unit test case for the functionality (fails because there is no code yet), then write code to pass the unit test followed by refactoring the code to clean it up. Repeat. These mini-iterations of test-driven development take no more then ten minutes and we perform one after another. Once you get the hang of test-driven development, you’ll find it an incredibly powerful programming technique that produces “modularized, flexible, and extensible code” (Wikipedia).

Pavel and I write some nice framework code for the portfolio allocation, so we check the code into the version-control system SVN. Within a few minutes, CruiseControl, a continuous integration tool, builds the code and notifies us of the result—all good! The frequent check-in and build feedback is essential for maintaining a low-integration overhead.

10:50 a.m. – 11:00 a.m.
Billy and Sally heard during the stand up that Pavel and I recently completed a commission fee method. They also need to calculate the commission fee and can leverage our method, so they stop by our workstation to discuss. Agile is big on collaboration, so we happily share what we’ve done and point them in the right direction on integrating. Billy mentions a method he created that we might be able to use in our portfolio allocation task. Thanks Billy!

The agile process facilitates communication through collocation. The ability to turn to your coworker and share ideas, ask questions, or just listen in on a conversation is vital for a successful agile team. Also, collocation facilitates the building of interpersonal relationships that are invaluable for creating a unified team.

11:00 a.m. – 11:55 a.m.
Pavel and I are on a roll: create a unit test, code, test, refactor, and repeat. We perform several code check-ins and integration build. We are rocketing though the effort and, as lunch draws near, we are close to completing the task.

11:55 a.m. – 12:05 a.m.
Build fails! Build fails! We just checked in our code and almost immediately got an automated email saying our build failed. Looks like the interface for the commission fee method has changed. We turn to Billy and Sally and sure enough, they had changed the interface on the method, not realizing we were implementing based on the old version. No worries. We have a quick collaboration and compromise on the interface. The new check-in and integration build works like a charm.

User Comments


AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.