December | 2009 | a gross salute

Thanks to my friends in [AIT](http://aset.its.psu.edu/ait/) for bringing learning tree training on agile software development Methodologies to PSU this past November. It has altered the trajectory of my thinking, perhaps by accident, about how the programmers in ETS do things.
So far in ETS we have mainly practiced the no-methodology methodology wrapped in some light project management. The projects and teams we have in ETS have allowed us to be fairly successful with this approach. The main reason this has worked for us is that most programming teams in ETS consist of one programmer. Still, there are certain times when this introduces a small amount of chaos into the system. Sometimes we go too long without having a review with the stakeholders. Sometimes we are not sure how close we are to finishing a project. We don’t have enough redundancy in staff that can handle maintenance issues. While most of what is written about [agile methodologies](http://en.wikipedia.org/wiki/Agile_software_development) (XP and Scrum) compare it to the strict [waterfall approach](http://en.wikipedia.org/wiki/Waterfall_model), I am looking at going from more of a wild-west arena into something more disciplined.
I went to this training with two other programmers from ETS, and we all saw that using these methods would address the problems mentioned above.
Here are the challenges we face with using an agile methodology like scrum. I am not sure what it means that these are the same challenges that lead to the occaisonal chaos I mentioned above.
1) Teams of one – This does have the advantage that team communication is easy. It has the downside that programmers don’t learn from one another, project schedules get thrown out of whack as personal schedules change, and most importantly, there is no redundancy in staff coverage. If someone is at a conference when a system has a problem, other programmers at ETS can work to solve the problem, and generally can, but it is a stressful situation. Being thrown into some code whose structure, environment, and maybe even language, is something you are not familiar with is not easy, and takes a lot of time.
2) Multiple Projects – Many of our projects have overlapping schedules which has led to programmers working on two or more different products in the span of a week. This is not efficient. It also makes planning very difficult as each project affects the timeline of the others in a way that is difficult to track. If we are to make use of scrum, I see each team (whether they be of one person or not) focusing on a single project for at least an iteration cycle, and hopefully for at least a release cycle.
3) Multiple Roles – The programmers in ETS are not just programmers. They are asked to take part in other activities as well. In most of these cases they programmers are asked to be consultants in a certain area of technical expertise for non programming projects. I hesitate to even mention this, because this is a small problem here and something that we can’t do away with. This is why, in my guess, that some programmers around PSU complain of having too many meetings. Here at ETS, the amount of meetings for programmers are rather manageable, in my estimation, but it does throw a small wrinkle in estimating time for programming projects.
In the new year, I hope to cut through some of the confusion and be able to focus my team more on single goals for small pieces of time and have teams of more than one person per project. This has nothing to do with agile methodologies per se, but I do plan on trying scrum. We will see well this can work in our real world.
We are already doing some practices of agile. Here is how we are organizing in basecamp, with agile terminology attached:

I am not as interested in following the letter of the law when it comes to using scrum, but more interested in making things run smoother. The challenge of any chaos-reducing effort is to not become inflexible, having allowed a methodology to become a straight jacket.