Get Agile!

Well here at Sportsvite, we are working on getting agile. We've had a new team member join us (Jeff), and with him he brought a bunch of ideas about software development and process. He is a pretty strong devotee to the Scrum process (to which I am quite open), to Spring (which I think is in many cases overrated, but maybe I am just being stupid), and to the New England Patriots, which I suppose we can forgive.

As a small team that is spread out across multiple offices with different work schedules, we are truly hitting some edge cases when it comes to Scrum/Agile implementation. As we navigate the process, we can talk more about how it's going, but here are the issues that I see up front:

1) Multiple Responsibilities

We have one platform, but many streams of work. How can we reconcile sprints to the timelines that exist based on external client demands? While the core product timeline may say that we plan on delivering some software on March 20, but a client says March 6, how do we address this - theoretically we will have a bunch of half-done stuff going out live. Normally, this can be addressed by using source control branches, etc, but what if there are platform dependencies? Just a matter of careful planning, but there is the definite potential for trouble here.

2) Verification

On a small team without dedicated QA, how can you really verify that things work? So part of this problem is not having a dedicated quality team, but you can obviously make do. The issue here is that in a perfect world you have QA folks working in lockstep with the developers and UI designers writing test cases and readying for the verification step - in our case if the developers have to do this, they aren't developing nearly as much, and then they have to stop dead in their tracks to test, rather than getting folks testing while the developer can finish up more tasks. Not a shortcoming of agile, just another hurdle in general.

The idea that we came up with is a two week sprint of work, with a one week verification sprint. This sort of violates the spirit, to me, as a sprint should theoretically result in 'finished' work, but it's an adaptation that seemed to be the best compromise available in our situation (comments and suggestions always welcome)!

3) Heavy UI Requirements

Part of the big idea with agile is to coordinate effort and get everyone on the same page that things are ready to deploy in a timely and high-quality fashion. Here, and at many places where you develop a world-facing site, you have a heavy reliance on UI designers. Here we get templates and we apply them once the server side work is done, turning HTML into JSP. This is okay, but now we want to make it all cohesive. How can we do this, when the UI needs to be done ahead of the developers? We can have the UI team working ahead of the engineers, then catch up with them towards the end of the development sprint in order to do any cleanup and browser testing fixes. This is okay, but one of the best benefits I see in this is that the sprint planning session should take place before the UI work starts, so we aren't hurrying through last minute requirements on the UI, and I am not sure if this is going to be the case if the UI folks are already making templates.

4) Geographical Issues

We have developers in Washington, and non-technical staff and UI designers in New York city. Traditional scrum is very hands on and paper/white board based. We obviously can't all be in the same room, can't all physically watch people manipulate the task list, and whatnot, but we do have technology to do it. We just need a way to manage the 'state' of our project. To that end we can use tools, but we haven't found one that is all the way there and reasonably priced. We are using Scrumy for now to see how it goes - it's pretty nice, but there are definitely shortcomings.

I am hoping that people out there who are agile pros have run across things like this. Obviously the positives outweigh the negatives. We will be able to plan out our work better, get a better idea of how long things take, to prioritize more effectively, and hopefully to deliver better software on tighter timelines. We just can't do the vanilla agile implementation.