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.