Agile Chronicles #6: Tools, Extra Merge Day, and Postponed Transitions

The Agile Chronicles is a set of articles documenting my experiences using an Agile process (Scrum) in software development on my current Flex project.

1. Part 1 – Stressful
2. Part 2 – Code Refactoring
3. Part 3 – Branch Workflow
4. Part 4 – POC, Strategy, and Design Challenges
5. Part 5 – Acceptance Criteria & Punting
6. Part 6 – Tools, Extra Merge Day, and Postponed Transitions
7. Part 7 – Bugs, Unit Testing, and Throughput
8. Part 8 – Demo, Burnout, and Feature Juggling
9. Part 9 – Scope Creep
10. Part 10 – Conclusions

This entry is about defining what the tools we use for communication in a geographically dispersed team, why we added an extra day for merging code into trunk amongst a branch, and why we’ve postponed the development of transitions.

Background

A reader asked me to describe the tools we use to communicate, and thus use Agile processes remotely on our current project.  If you read about Iterative Development, Continuous Integration, and Scrum the common theme that keeps popping up is “communication”, not just amongst developers, but team members.  Good communication at best results in a good project, or at least, no surprises during bad ones.

To recap the process, we are using an Iterative Approach in our Agile development process.  We have 2 week working cycles, called Sprints, where we work towards having a real-world, near production ready piece of software at the end of the Sprint.  On the first Monday in our Planning Session, we plan out what the priority user stories are for the Sprint, do task & time estimations for those user stories, and prioritize them.  The first Thursday is our first merge day (read below), followed by another one the following Wednesday.  On the 2nd Friday, we do our UAT, User Acceptance Testing, and go through what we did/did not complete.  Excluding the Planning Session and the UAT, we have our Scrum meeting everyday around 10 am PST / 1 pm EST.  On this meeting, we explain what we’ve done, what we plan on doing for the (rest of the) day, and any potential blockers (things preventing you from making progress).  They last 5 to 10 minutes.

The client is made up of a CEO/programmer, a senior architect, and two front & back-end web developers.  They are located in California (except one member who is another state I forget).  The rest of the team is in Atlanta, Georgia.  Although both teams have offices, the Designer and both Flex Developers typically work from home.  We have a 3 hour time difference; aka 4 different time zones.  Makes debugging dates fun.  At project start, we had one Biz Dev, one Market Analyst, one User Experience Designer, one Designer, and the existing Project Manager.  Now that we’re in development, it’s the same Project Manager, the same Designer (occasionally involved), a Flex Developer, and me, another Flex Developer.

Tools of the Trade

There are a lot of tools that make up the process, so to ensure I’ve covered everything, I’m going to cover everything (except for the server stuff because that’s my not forte, nor responsibility).

The 2 Flex Developers utilize Flex Builder 3 as the primary coding tool.  We develop all of our ActionScript, MXML, and CSS in it, and compile both our debug and release builds in it as well.  Our GUI test harnesses and (budding) unit tests using fluint all run from the multitude of main level Application.mxml files.  We manually swap which main files to mark as the main application.  My co-worker uses 2 Windows XP PC’s with the standalone Flex Builder install, and I to use the standalone Flex Builder 3 on 1 Windows XP PC and 1 MacBook Pro with OS X 10.5.5.  I believe he is utilizing the Flex SDK v3.1 and me v3.2.

On our PC’s, we both utilize Tortoise Subversion client for checking in our code.  On my Mac, I utilize Versions.  We’ve talked about implementing Cruise Control or another one that starts with an H on the server for automated builds, but just never get around too it.  On my PC I utilize BeyondCompare to merge my code into the repository, and merge his code into my local build.  I use the same thing on my Mac running through CrossOver (allows you to run Windows applications on your Mac without installing Windows).  For debugging web traffic, I utilize Charles HTTP proxy.  It helps me see the AMF Flash Remoting calls I’m making to Python, which uses PyAMF.

Our Designer utilizes Flash CS4 and Illustrator for all of our skins.  He’ll save out for CS3 since my co-worker and I are still using CS3.  He’ll also send us copious amounts of PDF’s, and a few SWF’s or MOV’s illustrating more complicated application transition states.  We used to utilize Basecamp for assets for like one week, but no one on the development side seems to use it.  Most of our skins are vector in the FLA; very few are bitmap unless they have to be.  As usual, we’re using custom fonts, and again, as usual, it’s a complete pain the ass.

We’re all attempting to utilize Jira for bug tracking, which is challenging to write defects into Version One, and then transition over later.

We are using Django on the back-end.  Each developer has their own sandbox which usually runs on it’s own port.  A sandbox is it’s own instance, and each developer can hit their own sandbox without worrying about some other developer’s sandbox interfering.  Each sandbox has it’s own version of the server-side and client side code from subversion.  It’s up to the developer to deploy the code, and start/stop the instance from Django’s web interface.  I’m not sure if each sandbox gets its own thread, but I do know once we got Apache wired up, we could all hit the same sandbox without issue.  Before Apache, it was single-threaded, and the app would slow to a crawl if we all hit the sandbox at the same time (during UAT’s).  What I usually do is export a release build, check bin-release into Subversion, log into the web interface, and click “Deploy Code” for my sandbox.  I’ll then clear my browser cache, and go test the app at http://server.com:9002.  I made the Flex app capable of figuring out what port it’s on, and to utilize that for the ServiceLocator like so:

if(Application.application.url.indexOf("file://") == -1)
{
        DebugWindow.debug("Application.application.url: " + Application.application.url);
        var path:String = Application.application.url;
        var sub:String = path.split("http://")[1];
        var main:String = sub.substring(0, sub.indexOf("/"));
        var finalURL:String = "http://" + main + "/gateway/";
        ServicesLocator.instance.setRootURL(finalURL);
}

We all utilize Instant Messaging as our primary way to communicate, with phone secondary, and email third.  The majority of us have accounts on AIM, MSN, Yahoo, Skype, and Gmail (except me, I refuse to use my Gmail account for chatting, need to get a new one… and Skype too).  Us Mac users utilize Adium, and the PC users typically utilize Trillian.  These programs allow us to consolidate all of our IM accounts, excluding Skype, into one program.  We all have 1 or 2 phone numbers to be reached at, usually 1 being a cell phone, and another a land line.  Our email is usually company provided, and we either use Google Domains for the company, or route through Gmail’s interface (since Gmail can connect to any POP account).  This allows us to consolidate our emails into one interface, and utilize Google Docs.

We all utilize Google Docs in some shape or fashion.  While their word processor and spreadsheet applications aren’t always the easiest to work with, they have three compelling features that have drawn us to use them.  First, they are free.  Second, they allow us to collaborate in real time, or on our own time.  Since we can share documents and edit them together in real-time, this helps immensely in API documentation and later reference.  The same can be said for task & time tracking using spreadsheets.  It’s what I’ve used for the past 3 years, porting my times to whatever application some company is using for me to track my time (SAP, NetSuite, VersionOne, etc.).  Third, it integrates with our Gmail email interface, making it easier to keep track of.

For project management, we utilize Version One.  I’ll document what I’m working on, and when I start & stop something during the day in a Google Docs spreadsheet.  At the end of the day, I’ll document my time spent on tasks into Version One, and create new tasks for any task I didn’t plan for during the Planning Session.  I have to use Firefox since it doesn’t work in Safari nor Camino.

Adding a Merge Day

Two problems have happened the past two sprints, and we’re solving it next sprint with a new Merge Day.  The Project Manager cannot ascertain the status of user stories without some quick QA on the latest build.  If he cannot ascertain the status of user stories, he cannot set client expectations and give them transparency as to where we are at in the status of the application.  While Version One should be able to give you this metric, assuming your developers are consistently & accurately inputting their tasks & times, it does NOT ensure the task / user story meets the acceptance criteria.  Since the Project Manager is on the hook for delivering completed user stories, he’s the one doing the initial QA testing to ensure user stories are in fact completed, and if not, either finding out why, and/or keeping the client informed on accurate progress.

He can only do this with a working build.  Now, being my first introduction into an Agile process, it wasn’t my first time doing Iterative builds.  I started doing this on my own after seeing how getting builds into someone’s hands early resulted in a higher degree of actually shipping a decent product.  Regardless, now that I had an ordained 6 full days where I could code to my hearts content and not worry if something didn’t compile was actually causing problems.  The PM couldn’t keep the client 100% informed without whole-heartedly trusting the developers to give an accurate assessment of where we were at with our user stories.  It’s not accurate for us to say “good” either because things always change on Merge Day such as things breaking, or not working “right”.  Having one day to give an accurate assessment that may not necessarely align to the past week and a half is not good for the client, not good for the PM, and generally not good for the project.

Secondly, the client is the one doing the web service work.  Since we’re a small team, they wanted to ensure the majority of the web services they’ve created for us are in good shape so they can feel comfortable moving onto other things.  I couldn’t give them a solid answer because I was busy on other User Stories, and couldn’t get a build up fast enough for them.  This caused them insecurity because they never knew if they work they did really did work, and stressed them out whilst working on other user stories.  It’s one thing when a server-side guy bitches at you; it’s another when it’s a client.  Technically, there shouldn’t be a difference since you’re on the same team, and trying to help each other.  This is what gave me the idea to merge earlier.  Since my screw up last week, the lack of fully working web services over the weekend made me desperate to salvage working over the Thanksgiving Holiday weekend, and to have something to show for my efforts.  So, I merged early.  This greatly simplified Merge Day from the normal 2 hours to 15 minutes, and was a lot less stressful (well, the merge was less stressful, I was still stressed about losing a lot of time in the first week of the sprint).

I brought up the suggestion in our post UAT where we usually talk about what went well, what didn’t, what can we implement to improve things, and what haven’t yet implemented that we said we would in a past sprint.  The PM & my co-worker were down, so I suggested we do the first Thursday in the Sprint under the context of, “It’s reasonable to assume you can have a working build in 4 days.”  Technically it’s 3 full days, but whatever.  That way, the PM can have an accurate assessment of where they are in the first 4 days, and see confirmation of their assumptions on the following day before the weekend.  This gives a more confident feeling of giving accurate updates to the client and having an earlier grasp of how the sprint, or just how 1 or 2 user stories are going.  Additionally, this allocates time for me to ensure the server-side developers can get closure on their user stories.

Postponed Transitions

Transitions in our application serve an important purpose.  Our GUI is very dynamic, and we have multiple views for viewing the same data with higher fidelity.  From the subtle transitions to indicate change, the verbose used to draw the user’s focus, each has its place.  Just as they are important, they are also extremely hard.  I’ve given the (albeit overly dramatical) metrics of “10% of my time is spent getting something working, whilst 90% is spent getting it to transition correctly”.  They are a real time sink, even using Flex’ built-in transitions.  This is because of the following reasons.

First off, they aren’t defined.  The Designer has them in his head, and he articulates during design comp reviews.  I then forget what he said since I’m focused on too many things, and either don’t implement it right, or just don’t implement it with confidence.  My co-worker has done a better job of creating quick mock-ups to ensure he has the visual right, and then having an informal call to get feedback.  I’ve been trying to get these in a real build instead, which while noble, takes too much time.  For some of the more complicated ones, the Designer created a a Flash SWF, and for another a Quicktime Movie in AfterEffects.  These were immensely helpful in communicating how something should work.

Regardless, as the design changes naturally over Sprints, so to does the need to constantly re-address how something transitions, if at all.  It’s not like Wireframes or Design Comps which are more easily documented; transitions are fluid, using real components so it’s not something that you can quickly create, or quickly create yet justify the work.  My guess is this is part of what Adobe is hoping Catalyst will help with.  The Designer can create the transitions, which in turn produces MXML that the Developer can use.  Seems like a pipe dream to me, but I’m still keeping an open mind.

So, we’ve decided to forego all transitions for now, and allocate time later to implement them once the design has solidified a little more.  No point in spending a lot of time fading something, and timing it well with others if it’ll change next Sprint, thus negating all the time spent.  Better to get something working first to ensure the design even works once actually developed.  Besides, the Designer is more accurate when I actually have something to show; he can more easily articulate how it transitions, and I can better understand since I already know how that something works… or doesn’t work (yet).

The good news is that I won’t have to fear the time sinks that transitions are in Flex.  On the flip-side, I’m really paranoid about how I can architect for them.  Right now, I’m of the opinion that once the PM allocates some time in a future sprint, I’ll remove all the damn Containers and replace them with Canvas’s, and layout everything by code that I write; code that’s smart enough to handle the timing of multiple transitions and different states.  Even that sounds too easy.  And if it sounds too easy in software…