Agile Developer’s Journal: A Day in the Life

Woke up, fell out of bed,
Dragged a comb across my head
Found my way downstairs and drank a cup,
And looking up I noticed I was late.
Found my coat and grabbed my hat
Made the bus in seconds flat.

“A Day in the Life” — The Beatles (Lennon/McCartney)

People are creatures of habit, particularly programmers: We seek consistency, whether it is the tried-and-true waterfall/SDLC method or our morning routine of reading the newspaper with a hot cup of coffee. Companies or projects looking to adopt an agile process usually begin by asking, "What is the return on investment?" and "Will projects be delivered better, faster and cheaper?" While these are excellent management-focused questions, they neglect the fundamental concern of an individual developer: "What will my day-to-day look like working in an agile environment?"

People are creatures of habit, particularly programmers: We seek consistency, whether it is the tried-and-true waterfall/SDLC method or our morning routine of reading the newspaper with a hot cup of coffee. Companies or projects looking to adopt an agile process usually begin by asking, "What is the return on investment?" and "Will projects be delivered better, faster, and cheaper?" While these are excellent management-focused questions, they neglect the fundamental concern of an individual developer: "What will my day to day look like working in an agile environment?"

Let’s ease this concern by walking through a typical “day in the life” of an agile developer. Specifically, we’ll look at a typical mid-iteration day (agile prescribes a planning/demo session followed by a one- to four-week-long iteration). We will examine the developer’s responsibilities, challenges, and gratifications. We will also look at typical daily interactions the developer experiences. While there are many forms of agile, our focus is a Scrum management and an XP engineering process that utilizes local (collocated) team members.

Background
At the personal finance company “Re-Balancing Act,” I am a developer working in a dynamic team tasked with delivering a Web 2.0 financial application. The application will allow clients to enter in their current portfolio (stocks, bonds, etc.) and will provide a suggested rebalance based upon criteria such as age, income, and risk tolerance (with all the fancy visuals Web 2.0 technologies offers). The agile team consists of six developers, a ScrumMaster who maintains the agile process, and a client manager who represents the stakeholders.

The team observes the key agile communication practice of collocation where the ScrumMaster and developers are situated in a large room at shared desks. Continuing with another agile practice, the room has a large white board for collaboration and an office across the hall is well stocked with snacks and drinks. However, even with the allure of food, the client manager decided to keep his large corner office and is sitting down the hall. Diagram 1.1 depicts our office setup.

Diagram 1.1 – Office Setup

Tuesday, Mid-Iteration
8:30 a.m.
As an early bird, I arrive before the crowd to catch up on my email and other administrative tasks while enjoying my bagel and coffee. I take the quiet time to review the overnight PMD report (similar to Lint) that shows I have some dead code and poor use of Java’s String class. In about ten minutes, I’ve fixed the issues, run my unit tests, checked in the code, and verified the build.

Agile breaks down a project’s work into small increments called tasks (e.g., “Allow user to spell check his entered text”). The agile team estimates the duration of the tasks and keeps track of them in the product backlog. The product backlog is subdivided into the tasks for the given iteration, aptly called the iteration (Scrum) backlog. Last night, I completed a task from the iteration backlog, so I head over to the storyboard that contains all of the remaining task cards and choose another task. I pick a relatively easy task (estimated time length required: one hour). I create unit tests, code, and refactor until I complete the task and have a successful integration build. Within half an hour I’m done and mark the task as complete.

9:15 a.m. – 9:30 a.m.
Around 9:15 there’s a buzz in the air. People stand up at their seats and mill about. Our ScrumMaster (i.e., manager) enters with the client manager (i.e., business), and we gather in a circle. The fifteen-minute daily stand up has begun. The daily stand up is the opportunity for the entire team to succinctly sync-up on everyone’s individual progress (burndown chart) against this iteration’s feature or story point estimations. In other words, the stand up is a status meeting timeboxed to fifteen minutes.

Everyone shows up on time today since yesterday the ScrumMaster enforced the rule, “You’re late, you’re lunch.” Let’s just say I didn’t enjoy going out into the cold to pick up lunch for everyone on my tab. We begin the meeting by everyone's answering four questions (traditional Scrum has three similar questions):

Diagram 1.2 – Stand-Up Questions

* This is the opportunity to revise estimates. For example, we are four hours into a task that was estimated at eight hours, but now find it is a bit more difficult and there is another six hours of work left.

Stand ups are kept focused and short (fifteen minutes). These questions create a structure to deliver status updates quickly and efficiently. Follow ups are noted and discussed immediately following the meeting or later that afternoon.

A developer named Cynthia begins and halfway though her update Bill interrupts her to discuss his related status. Our ScrumMaster gently reminds everyone that “one person speaks at a time and no side conversations,” and currently Cynthia has the floor. I’m grateful for this reminder, because when we don’t adhere to this practice, the fifteen-minute stand up easily turns into a thirty-plus-minute stand up.

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.

12:05 p.m. – 1:00 p.m.
At noon, we all head out to a local sandwich shop across the street. We often switch between eating at our desks and sitting down at a restaurant. It has been a good morning, so today a few of us decide to go out for lunch. The others make us feel guilty by going to the gym.

1:00 p.m. – 3:02 p.m.
Pavel and I need a new task to work on, so we head over to the storyboard where all the remaining tasks for the iteration are posted. We choose the simple but important task of building a framework for the dynamic tab navigation. The team gave this task a four-hour estimate. We go back to the pair programming workstation and this time I take strategic and Pavel takes tactical. We fervently work on the task with frequent check-ins and integration builds. By this point, we have about a dozen unit tests written.

Suddenly, from behind us, someone loudly declares, “I saw the movie Avatar last night and it was awesome!” Our inner geek takes over, and we spend the next fifteen minutes debating the CGI quality. Conclusion: Amazing!

3:02 p.m. – 3:12 p.m.
The work progresses at a fantastic pace, and it looks like no problem to finish by the end of the day. Hold it one second; do we need to entitle the navigation tabs? If so, this task just went from four hours to twenty-four hours, and there isn’t enough bandwidth to fit this in by Friday’s iteration end. Pavel and I give each other knowing looks and get up to find our client manager. On the way, we grab our ScrumMaster since she likes to always be kept in the loop. Our client manager is only 50 percent dedicated to this project, but always tries to make himself available when we have questions. We relate our question of entitlements and a quick discussion ensues. We decide to add a new entitlements task as a low priority in the product backlog (a list of all the tasks that may or may not make it into an iteration). We have a strong relationship with our client manager, so a running joke is his quipping, “Best idea I’ve heard all day!” and our responding, “First idea you’ve heard all day?”

While we are in the client manager’s office, he mentions that one of the acceptance tests he wrote and ran on a completed task failed (a responsibility of the client manager). No worries. That’s what the tests are there for. We quickly discover that we had a misunderstanding on one of the calculations: We were to divide not to multiple. It takes all of three minutes to update the unit test, make the change, test, and check-in.

3:12 p.m. – 3:25 p.m.
It is time for a coffee and snack break. Most of the team heads over to the corner office we’ve commandeered for feeding. The room is well stocked with predominately healthy fare (though there is a soda and candy machine down the hall for those with a sweet tooth). We find this break time with a designated area important to have non-work related chat and to take a break from work’s intensity.

3:25 p.m. – 5:30 p.m.
Pavel as tactical and I as strategic return to our pair programming workstation and continue with the tab navigation task (minus the entitlements, since a new unprioritized task was created). The work is going fairly well and we check in twice more with successful builds until the downside of pair programming rears its ugly head. “You’re not listening to what I’m saying,” Pavel tersely states. I heatedly reply, “I certainly am, and we need to use an interface, not an abstract class. Change it.” “No,” is his response.

Agile is a fast-paced process that tries to remove inefficiencies from standard development methodologies, such as waterfall/SDLC. Agile’s collaborative, communication-focused mantra helps yield higher quality and greater business-aligned products. However, there are two sides to every coin. Agile’s intense environment can magnify interpersonal conflicts and pair programming’s close partnering further fuels disagreement.

We continue to argue until our ScrumMaster comes over to investigate. Pavel and I each hold our ground and state the reasoning behind our viewpoint. Our ScrumMaster says, “Let’s look at the long term. How will these classes fit into the tab navigation’s future flexibility and integration with the overall project?” Agile often focuses on the current iteration, so it’s necessary to stay focused on the “Big Picture.” Pavel and I were so stuck on “I’m right, you’re wrong” that we lost sight of it. Almost simultaneously we come to the realization that we were building complexity when simplicity was the answer: an inner class.

We’re almost done with the task after a few more sessions at the white board and a few more classes are developed. We take some camera snapshots of the design on the white board and put together some documentation on the tab navigation API for our team members who will be using the navigation. We do a final build, upload the snapshots and documents to the team’s SharePoint directory, and mark on task complete on the burndown.

5:30 p.m. to 5:45 p.m.
Pavel and I return to our individual desks to catch up on some email. I don’t get much of a chance to check email during the day, so I use this time to clear out my inbox.

I’m in a good mood and feel pretty relaxed. A nice part about continuous integration is that, at the end of the day, you either successfully integrate or throw the code changes away and try again tomorrow. Wait a minute. Throw the code changes away? That’s right. A rule is that you must always check in working code … don’t break the build. At the end of the day, if the integration fails and it isn’t readily fixable, take a step back by revisiting the problem tomorrow. Either check in working code or revert to the previous check-in. Of course, this doesn’t mean you can’t keep your non-working code local and see if inspiration strikes tomorrow. Why is this nice? Every successful build is an accomplishment, and by day’s end there are typically several. Sure, the failed build might require more work, but you’ve had so many successes today that one more makes no difference. Leave work with a clear mind.

5:45 p.m.
Time to go home. We work hard and consistently produce a lot. The intensity of an agile workday requires that we leave at a decent time and have a work-life balance, or else we run the risk of burnout. I say goodbye to a few of the SDLC team members and head to my car knowing that I had a successful and productive day.

Final Thought
We have walked through a typical “day in the life” of an agile developer, specifically at the midpoint of an iteration cycle. We have seen the developer’s responsibilities, challenges, and gratifications. Furthermore, we have looked at the different interactions the developer experiences, such as with the ScrumMaster, client manager, pair programming, and daily stand ups. Also, we have seen the reliance on continuous integration. The intensity of agile might seem foreboding, but the resulting quality, productivity, and satisfaction makes agile well worth it.

Bibliography
Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional.

Llopis, N. (2006, 02 06). A Day in the Life. Retrieved from Games from Within: http://gamesfromwithin.com/a-day-in-the-life

Manifesto, A. (2001). Manifesto for Agile Software Development. From The Agile Manifesto: http://agilemanifesto.org/

Schwaber, K. (2003). Agile Project Management With Scrum. Microsoft Press.

Shore, J., amp; Warden, S. (2008). The Art of Agile Development. O'Reilly.