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.

- The Beatles “A Day in the Life” (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 ROI (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, the focus is a Scrum management and an XP engineering process that utilizes local (co-located) 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 re-balance 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/Coach who maintains the Agile process and a Client Manager who represents the stakeholders.  The team observes the key Agile communication practice of co-location where the ScrumMaster and developers are situated in a large Agile room at shared desks.  Continuing with another Agile practice, the Agile room has a large collaboration white board 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 AM
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 10 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 their 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 AM – 9:30 AM
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 15-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 (burn down chart) against this Iteration’s feature/story point estimations.  In other words, the Stand-Up is a status meeting time-boxed to 15 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 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 (15 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 15-minute Stand-Up easily turns into a 30+ minute Stand-Up.

9:30 AM – 9:50 AM
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 20 minutes we’ve prototyped a solution, thus there’s no need to re-estimate the tasks.

9:50 AM – 10:50 AM
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 refactor the code to clean it up.  Repeat.  These mini-iterations of test-driven development take no more then 10 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 AM – 11:00 AM
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 co-location.  The ability to turn to your co-worker and share ideas, ask questions or just listen in on a conversation is vital for a successful Agile team.  Also, the co-location facilitates the building of interpersonal relationships that are invaluable for creating a unified team.

11:00 AM – 11:55 AM
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 AM – 12:05 PM
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 PM – 1:00 PM
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 stay out for lunch.  The others make us feel guilty by going to the gym.

1:00 PM – 3:02 PM
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 4-hour estimate.  We go back to the pair programming workstation and this time I take strategic and Pavel takes tactical.  We fervently working 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 15 minutes debating the CGI quality.  Conclusion: Amazing!

3:02 PM – 3:12 PM
The work progresses as 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 4 hours to 24 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% 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 him quipping, “Best idea I’ve heard all day!” and us 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 PM – 3:25 PM
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 PM – 5:30 PM
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 un-prioritized 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 it’s 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 fueling 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 over all 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 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 burn-down.

5:30 PM to 5:45 PM
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 PM
Time to go home.  We work hard and consistently produce a lot.  The intensity of an Agile work day 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 mid point of an Iteration cycle.  We have seen the developer’s responsibilities, challenges and gratifications.  Furthermore, we have looked that 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., & Warden, S. (2008). The Art of Agile Development. O'Reilly.

Trackback(0)

TrackBack URI for this entry

Comments (2)

...
written by David M., November 30, 2011

How do you make this work when the tech leads are located in US but all the developers are in Asia? The 13 hour time difference requires there to always be someone who has a 10pm meeting.

• 
• +0
• 
• 

...
written by Tushar Kharbanda, June 21, 2010

This is a very refreshing article (different from all the typical bulleted Agile power points that I have read) as you described some of basic Agile principles in a way that they are implemented.

Good to know that senior people like you still have the insight into the developer's world.

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview