One of the things we take pride in here at OpenSource Connections is what we like to call the OpenApproach.  The OpenApproach is our implementation of best practices for software development and project management, and is largely based on the concepts of Agile and Scrum.  In addition to providing development services to our clients, we often coach our clients on OpenApproach techniques so that they can improve their own development environment and learn from our success on other projects.

Most recently, I participated in a Scrum team on our own internal software development project:  AeroWebOnline.com.  This was a very time sensitive project with various OSC developers going in and out of the project, geared towards a product launch at the AAAE conference in New Orleans.  That project was a definite success, although one Scrum lesson we re-learned was that 1 week sprints really are too short, and 2-4 week sprints are much more effective.  As both a developer and a project manager, I really find Scrum rewarding because it keeps me aware of what’s going on in the project as a whole, as well as very focused on my own development tasks.

Currently I’m with a new client of OSC, and we’re on another time sensitive project with up to 8 developers (though most also have other project obligations), an architect, a project manager, a business lead, and 2 QA/build staff.  It’s a big project with a tight deadline and for several reasons I felt Scrum was the perfect approach for this project:

1)      The team needs to have improved communication and a real time sense of how the project is going and what everyone is doing on it, without introducing a heavy process.

2)      The business needs strong insight into the project, because the deadline is very important to them.  If the timeline doesn’t go well because developers are on too many other projects, they need to be able to see that effect directly.

3)      Developers need to be encouraged to trade tasks and to cross train, because since many of them will be called on for other projects or production support, it’s essential that the project not be too dependent on any one developer.

So I pitched the idea of Scrum to the team leadership, and we’re going forward with it.  I’ll record here some of our experiences so far, how Scrum is helping us, what we can improve on, and the team’s reaction to a different process.

We have essentially a one month timeline for the project, so we decided to split it into two sprints of two weeks each.  Last Friday we had our planning meeting for Sprint 1.  Since this was the first introduction of Scrum to the whole team, I started by giving a talk about Scrum and showing examples of past burndown charts and task lists in other OSC projects, and talking about the responsibilities of each Scrum role (developer, scrummaster, and product owner).  I used this “Scrum in 5 minutes” document as a set of talking points for the presentation.  But no, it didn’t take me 5 minutes.  It actually took about an hour of me talking and the team asking questions.

But after that, we went right into planning for Sprint 1.  I setup the sprint planning spreadsheet in Google Docs as we do with most of our OSC projects, and I served as Scrummaster in the planning meeting.  However, my goal is not to be the Scrummaster myself, but to train the client’s project manager on how to be a Scrummaster so that they can continue this process on other projects.  So while I served as the Scrummaster for the first planning meeting, she is now leading the daily stand ups, and I expect she will lead the planning on the next sprint with my guidance.

The architect for the project had already prepared his own set of goals for the sprint, and so we used those as a starting point with the team, which the rest of the development staff added to.  The team as a whole came up with their own list of sprint tasks for those goals, which took us another hour and a half probably.  There was of course much discussion about the tasks, but it was my job to make sure that discussion did not go into “implementation details” so that we did not get into too technical or indepth of a discussion.  That was a real challenge, but for the most part we did it.

After all the tasks had been laid out, we moved into task estimation.  To do this, Eric Pugh strongly suggested that we try Scrum poker.  I was a little skeptical how well that part might work, but I was really pleased with the results.  We didn’t have time to order the official Scrum poker cards from Sweden, so I cut a stack of index cards in half and everybody got cards with these values on them:

?,2,3,5,8,13,16,20+,donut.

Some of the developers also had fun adding their own cards to the mix.  Chris added a pizza card when it got close to lunchtime.

So how does it work?  As the Scrummaster, I would read the next task off the list, and ask everyone to pick a card from their deck.  When everybody had set a card face-down on the table, I would say “flip” and then I would read off the estimates given around the table.  The 20+ card was used to indicate you think the task will take longer than 2 days and it probably should be subdivided into other tasks.  The donut card was used to say “my brain hurts, pass the donuts.”  And the question mark card was used to indicate you didn’t know enough about the task to make a reasonable guess.

Those who gave the lowest and highest estimates would be asked to make a quick case as to why they made that estimate.  Sometimes those defenses would lead one or the other to realize they had made an incorrect assumption about the task, and the team would quickly be able to agree on a reasonable estimate.  Other times, it brought out important points about the task that we then used to make a better estimate with.

Scrum poker addresses a real problem in task estimation, and I was really pleased with the results.  Normally, if you have a group of developers and ask them how long it will take to do a task, someone will speak up first and throw out a number.  No matter whether that estimate is really high or low, the fact is that most other developers are now going to give estimates somewhat similar.  Even if they would have guessed a much higher estimate, they will now downgrade theirs because they don’t want to sound like a slacker compared to the initial low estimate.

I think that would have definitely happened with this team, because I observed that the developer who was probably the most confident in his estimates was also the most optimistic in his estimates.  Without Scrum poker, I think we would have had a much lower set of estimates and we would be less likely to hit them.

Estimating the tasks took about 2 and ½ hours, and was the longest part of the process, though I think the end result was good. 

The final thing we did was to assign the tasks.  In Scrum, the best way to do this is to go “round robin” around the room and each developer picks one task at a time, until no tasks are left.

However, we had been meeting for a long time at this point and people were fading.  The project manager asked if we could just print out the task list and pass it around our desks to assign the tasks.  I acquiesced, but in retrospect I should not have given in.  At that point, I essentially lost control to enforce the process, and instead of people signing up for one task at a time as they were supposed to, developers signed up for multiple at once.

The end result of this Scrum “faux pas” was that developers stayed in their comfort zones too much, and that there is not enough cross-training among members in my opinion.  The architect took all the tasks around a rules engine, and a senior developer took most of the tasks regarding how the workflow would be implemented. 

This was a definite downside of the process in my evaluation, and one that could have been avoided had I not allowed meeting fatigue to get the best of us.  However, I think this will fix itself to some degree because some of these tasks will have to be traded around over the course of the sprint in order for everything to be done.  It’s nearly a week into the sprint and that is exactly what’s happening.

All in all though, introduction of Scrum into this team has gone very well so far.  The developers have responded well despite the fact that I introduced Scrum to them in something of a top down fashion (Ideally a movement to adopt Scrum would start with the developers, not with management, although I felt in this particular case it was critical that I get buy-in from the management of the team first).  The project manager seems to really like the process, and commented to me that “this lets me manage projects the way I want to anyways.”  And the business seems excited about it because they get to keep their finger on the pulse of the project without being too intrusive on the developers.

Two days ago one of the senior managers in the company came up to me and was talking positively about Scrum and what we are doing on this team.  Although he had not been in our Scrum meetings, word about the process is getting around the company.

Finally, since we’re nearly halfway through the first week of sprint 1, I’ll show the burndown chart as it stands right now.  You can see that the first few days very little apparent progress was being made.  This did not surprise me, because at this point all the team’s developers except one are still being assigned small tasks or even large tasks on other projects, and so they keep having to divert attention away from this project.  Just in the last day that is starting to change and more work is getting done, so now we are starting to see a steeper drop in the burndown chart.  I think having that chart is helping to communicate the effects of side projects and reinforce the deadline of this sprint.

Ultimate success of a process is determined primarily by the end result of a project, and so it will continue to be interesting to see how this sprint and subsequent sprints will go.  But so far, Scrum is working quite well!

This week I was at the AAAE Conference in New Orleans, showcasing the AeroWeb product that we have just released at OpenSource Connections. Everyone who saw our demo seemed to be very impressed. I think that many of the airport executives I met realized they needed the better website that AeroWeb offers, with features like Flight Tracking, Online Booking and Airfare Deals (with referral bonuses for the airport), blogs, inline content editing right from your browser, custom directions, flash maps, and more. All wrapped in great designs customized to each airport.

But one reaction I got several times was “this looks great, but our county/city controls our airport and our website, and they want us to use the county IT staff and web page.” Basically they liked what we offered, but felt like they are locked into a single page static web page occasionally edited by County staff.

As an example, compare the Charlottesville Albemarle Airport website GoCho.com with this static web page of a regional airport in Hawaii, which is part of a larger state web site. The differences should be obvious. GoCho is a dynamic site providing real time information of immediate interest to passengers, and gives them incentives to fly through Charlottesville. The Hawaii site provides a single paragraph of generic information about the airport. As a passenger, it doesn’t really tell me anything of value about whether or not this is an airport I would want to consider using during a trip to Hawaii.

If you’re an airport executive, you inherently understand this. But how do you convince your County or governing authority to give you the freedom to create and manage your own site? Here’s a few ideas for discussion points you can bring up with them. When you’ve convinced your board to build a new site, please make sure to contact us at AeroWeb so we can submit a bid!

1. Show passengers you have great deals too! If you are a regional airport competing for passengers with nearby larger airports, then you know it can be a struggle to convince passengers that they can get good prices through you. Perhaps not all your airfares are cheaper, but with our Flight Deals tab, great deals targeted to your airport will be displayed from Kayak.com. Especially with rising gas prices, if you can show passengers that they are going to get a comparable airfare through your airport, they will skip the longer drive to larger airports.
2. Give passengers the information they need. When passengers enter your airport, the first thing they probably do is check the arrivals and departures board. With our online flight tracking, you can give them the same experience on your website. We can integrate our tracking widget with your internal FIDS or with one of our online data partners.
3. Easy content management. With our inline editing tool, you will be able to manage all the content on your website, without involving AeroWeb staff or your County IT staff, and without any technical knowledge! One reason your County’s IT department may be reluctant to let you have your own website is out of a fear that they will have to maintain all the content for you. With AeroWeb, you can manage the website yourself, so there is no burden on other IT staff!
4. Managed hosting. We will host your AeroWeb site for you, which removes another area of concern your IT staff may have. They don’t need to worry about the database or server uptime, or providing you with traffic reports and other analytics about your website. We do all of that for you - so there is no extra burden on your County IT staff!
5. Provide updates to media and passengers. Since editing content on your site and blog is so easy, it can become a communications channel for you directly to your passengers and even local media. By providing the latest news about your airport online in a timely fashion, you may reduce your customer service calls and keep passengers happy!
6. Your airport website is not the same as the county landfill site. No disrespect meant to your local garbage collectors, but the fact of the matter is that your airport has more specific website needs than the local landfill. So why are they both using the same boring static pages on the County web site? The landfill is not competing for customers like you are, and they don’t need to provide timely and updated information to passengers who expect you to have a great website.
7. Providing the latest functionality on your website. AeroWeb is tuned in with the features that airports need. In addition to the features described above, we offer other widgets for weather, customized driving directions, advertising tools, and more! We can do custom development to meet your airport’s unique needs, and we are working on adding additional features too!

I’ve uploaded some photos to Flickr of the debut of AeroWeb at the AAAE Conference in New Orleans.  You can see photos of our booth, as well as some of the fun we had at the Mardi Gras World event on Monday night.  It’s been a great conference, and I want to thank everyone who stopped by our booth to discuss AeroWeb!

You can view the photos here.

It’s Tuesday morning, which if the final day for exhibitors at the AAAE conference for airport executives in New Orleans. Eric, Riley, and myself, along with my wife Lauren, have been here since Saturday talking to regional airports around the country about OpenSource Connections new product AeroWeb.

The reception has been really great so far. While I think exhibitors always wish that there was more traffic by the booths, the quality of many of our leads has been very good. We are demo’ing the websites on our laptops, and have a screencast of AeroWeb running on a large monitor at the front of the booth. The screencast has certainly helped bring people into the booth, and our demos have been running very well so far and everyone who sees them seems to be impressed.

We’ve had conversations with a wide range of airports, with airport consultants who could conceivably recommend AeroWeb to their clients, with other vendors we could potentially partner with, and with industry journalists. We’ve also made a few contacts with companies who may be interested in the software development skills of OpenSource Connections, outside of our airport product.

The features we are showing airports for the most part seem to be right on. A couple of ideas that attendees have brought up have been interesting. One attendee noted that the main reason he felt people go to his airport website currently is not passengers, but vendors who are looking for information about RFP’s. So he wanted a content section with a lot of information about RFP’s. After looking at the websites of some other airports we’ve talked to, they also have at least a page with current RFP’s listed on it, and PDF downloads of the RFP’s right there. Of course, this is easy to do in AeroWeb, but we hadn’t put a page like that in our demos.

Another interesting observation made by a trainer from a small airport was “Can you schedule content to be published at a certain date?” The answer to this is also yes when you are editing content and blog posts through our back end Expression Engine administration tool. However that functionality and content versioning is not currently exposed through the inline editing tool we are primarily demo’ing to clients.

I’ve got some photos to post, so I’ll post those and more comments later today after the show ends. For now, I’ve got to run back to the booth for exhibiting hours!

Recently, I completed my first Ruby on Rails application, which you can see here. It’s not a complex application, basically it’s a survey of political candidates with three data models: candidate, question, and answer. Pretty straightforward.

I built the Ruby app using Scaffolding, which was very easy and I liked alot. Scaffolding gives you the nice pre-configured classes and pages for adding, editing, and deleting records, but my survey doesn’t line up exactly to that model (ie, I don’t want anyone to go edit or create the questions on the survey, and I wanted to create a flow from creating your candidate record to then answering each question in the proper order). With some help from Eric, I soon got into the REST mindset and got the application working properly. That was cool.

I didn’t consider deployment too much until I had the app completed and working on my local instance. My plan was to just deploy it to my DreamHost account, which I assumed would be easy. I’m used to deploying .NET applications, which is extraordinarily simple, and it didn’t occur to me at first that Ruby might not be as easy. After copying my files out to DreamHost, I found this wiki page of theirs. I was a little bit annoyed at first after reading that, because I realized I would have to run a bunch of commands to get rails running and the permissions correct.

Fortunately, as Eric pointed out to me, DreamHost already has a solution. Now they use mod_rails, and all you need to do is copy out your code, check the box for mod_rails, and then use their configuration panel for that domain to point to the public directory used by ruby on rails. After doing that, everything worked great and I have to say that I am now pretty sold on Ruby on Rails. One thing I’ve always liked about .NET is that it’s pretty easy to deploy. Now that I’ve seen Ruby on Rails can be easy to develop and also easy to deploy (at least with DreamHost), it’s a much more attractive language to me.

Today I’m attending beCamp at the offices of CBIC on the downtown mall in Charlottesville.  There have been some very interesting sessions already and attendance is great.  I suggested one session, which we just had this morning.  I titled the session “How to choose languages - .NET vs Ruby vs Java vs Php vs ?”.

At OpenSource Connections, we have a wide range of skillsets covering all the major languages, and we have the pleasure of working with a wide variety of clients where we get to use all those different skillsets.  It’s a lot of fun and something I really like about OpenSource.  Often times for our projects, the client’s needs specifically dictate a particular language, but other times they have no preference or are building a system from the ground up and we get to help choose the language.  I have my ideas of the various benefits and disadvantages of the languages, but I proposed this session to hear other people’s feedback as well.

We had a great group of about a dozen people in the session, with skill sets that covered c, c++, perl, .net, php, java, ruby on rails, cold fusion, and even Delphi.  This wide range of experience brought some interesting perspectives.

I started the conversation by stating that all development languages are just tools, and the important thing is what we build at the end.  The important thing is not necessarily did we build it in .NET or Ruby, but did we meet the customer’s needs?  I prefer to be technology agnostic, and most everyone in the session seemed to agree with that sentiment.

One of the first things said in the session was probably the most observant:  the choice of language is often presented to us as developers, and that decision is actually made by the business, not development.  I think David from the Darden Business school at UVa was the one who pointed that out first, and it’s certainly very true.  The group seemed to agree with that, but with some reservation that we wish we could have more control over the language used.

Mike from Fabjectory pointed out that in reality, the framework may be more important than the language chosen.  Ruby on Rails may be the best example of this, because it’s an easy to use framework that encourages you to do good development practices.  Microsoft has release the MVC framework to accomplish a similar goal. 

There was some discussion at the beginning when Caleb expressed a hope that there would be fewer different development languages in the future so that developers don’t have to try and keep up with so much, but others pointed out that competition and having many diverse languages is part of what encourages innovation and new features.  For example, Jim pointed out that Ruby on Rails is great for web development in part because it’s geared specifically towards that process, whereas ASP.NET has procedural carryovers in the language from the old classic ASP and VB days.  Likewise, Jim expressed the opinion that C# has become a better language than Java because it is more fresh and doesn’t have as many legacy features as Java.

Your final deployment server will also drive the choice of language naturally.  If you company will only run Windows servers, then you probably don’t want to try and run Ruby on Rails on top of SQL Server on a Windows server.  You should probably stick with .NET.  Likewise, if you are going with an Apache server, you should probably consider Ruby on Rails or PHP.

Who will maintain your application after it has been deployed?  If you are a consultant, than the skills of your client need to be considered.  How much do they want to modify it themselves, and what skill sets do they already have that will make this easier.  I suggested that because of the development tools and the fact that it’s a compiled language, I feel .NET is a much more scaleable and better language than PHP.  However, if a client wants to tweek small parts of the code themselves, then Php may be a better choice because it’s easier to modify and perhaps easier to understand to a non-developer but tech savvy person.  But with that ability to make changes easily also comes risk:  If the people making the changes don’t know the whole system as a whole or good development practices, then the easily “hackable” nature of PHP may actually get them in trouble.  A more object oriented structure in .NET that needs to be compiled may be more stable and less susceptible to mistakes.

Considering how to make modifications in the future is also important.  David from Darden expressed his opinion that when using Java web development frameworks, Struts is easier to make modifications to than Tapestry.

Towards the end of the session, we also briefly touched on a few other topics which I will quickly summarize people’s opinions here.  So here are more random thoughts from the session:

•   .NET is the best option for building windows based desktop applications, but you should consider QT if you want a more cross platform compatible application.  Java Swing according to one anonymous attendee “still sucks 15 years later.”
• One of the great things about Ruby on Rails is the built in testing and framework scaffolding.
• Mono can be used to make .NET applications run on other OS’s.  Though there wasn’t much experience with actually doing that in the room, that is what some major companies are doing like MySpace.
• Building webservices is very easy in .nET, REST based applications are also easy in Ruby.

We ended the session on a funny note, when Jim made the statement that a lot of very large companies still use C for development.  Though the people he is thinking of are older developers and so they may just be tied to older languages, they are still some of the brightest minds he’s known.  I believe it was pointed out that Amazon’s services are built with C.  So we’ve come full circle through C to .NET, Java, and Ruby, and perhaps ultimately back to C!  (just to be clear, I state that with sarcasm.  Although you can undoubtedly do all kinds of things with C, the value of all these newer languages and frameworks is how much easier they make it).

Thanks to all those who attended for a great discussion (completely devoid of any fist fights about which language is best), and I’m looking forward to the rest of beCamp this afternoon!

You can see a slideshow of my pics from beCamp 2008 here

This week I spoke at the LSP Conference at UVa, and while I was there, I got to attend several other speeches that were very interesting.  One that I particularly enjoyed was on Building Facebook applications, and the potential privacy issues surrounding them.  Adrienne Felt is a graduating fourth-year student at the University of Virginia’s Computer Science department in the School of Engineering and Applied Science (also my alma mater).

She first talked about how to go about building a Facebook app, which was interesting because I have been curious about it, but I hadn’t had the chance to look into it yet.  But the second half of her talk was more thought-provoking, because she discussed her research into the privacy issues of Facebook.
Those privacy issues are particularly relevant because of this article today in the Silicon Valley Insider, titled “Facebook Borks Blockbuster: Beacon Turns Into A Lawsuit”

The short description of what happened apparently is Facebook and Blockbuster video had a deal where you could put an application on your Facebook profile, and this application in turn was broadcasting to your friends what movies you are renting.  When a lady by the name of Cathryn Elaine Harris rented a pornographic movie, she was apparently pretty embarrassed to see it broadcast on Facebook and now she is suing.

Now go back to the Alley Insider article and read the comments if you haven’t already.  Once you get past the crude jokes, you’ll see a reply by a poster named Roy stating that:

“You did not need to do any type of opting-in to get this behavior. Simply being logged *into* Facebook was enough for Beacon to push my Blockbuster rentals to my Facebook news feed. There was no “do you want to opt-in” email, there was no “do you agree to send information from one site to another” option … it just happened one day.”

That quote really rings true with what I learned from Adrienne at the LSP Conference.  Check out her site on Facebook Platform Privacy.

She is mainly talking about how when you build an application for Facebook, you can force people who install your app to let you get access to all their Facebook data or they won’t be able to install that app.  Most applications require you to let them have access to all your data, even though according to Adrienne’s research only about 6% of them use it.

Now this is a little different than the court case mentioned in Alley Insider, because that was a case of a company providing presumably private customer information to a public data feed without that customer’s consent (or at least that is what her pending suit will allege).

But nonetheless, the article reminded me of Adrienne’s presentation and her work at UVa on privacy issues because it highlighted how willing we are to give up control of our private information to anyone on Facebook who asks for it, just so we can install a Facebook app like Zombie Killer and play an online game with a friend.

While Zombie Killer is considered “safe” and is probably not doing anything bad with your Facebook info, the fact of the matter is that Facebook allows me as a developer to write an application, encourage you to install it, and then I am allowed to pull any information I want (except your email address) from the profiles of Facebook users of my application.  I can then store that data on my own server indefinitely and use it for anything I want.  Most uses of this will probably be for more direct marketing of products to you as a Facebook user, but frankly is still creepy to me.

There have been a couple interesting blog posts this week that highlight a webinar presentation given by a Google engineer this week about innovation and collaboration, and how they manage a company with 16,000 employees. The first post I found was Blogoscoped noting the presentation, and referring to the beu blog which provided a more in depth set of notes about the presentation. Better yet, the beu blog provided a pdf of the actual presentation which has screen shots of the applications I mention below. You can also see a replay of the webinar for a limited time.

Some parts of the presentation are just showing off Google Docs and how that can be used for collaboration. Cool stuff, but I’m not sure there was anything new in there. But here’s four things they use internally which are pretty neat, and also remind me of various projects we’ve either done or speculated on at Open Source Connections:

1) Weekly Snippets

Every week developers are reminded to send an email to a specific address at Google with a status update of everything they’ve worked on that week, and what they plan on working on next. It’s a virtual stand up meeting. Then this is all archived and you can see what anybody in the company is working on. This is a type of application that has crossed my mind before, and Michael has considered building a project management framework for us internally that could include a similar feature. As consultants, we stay highly connected with our clients, but not always as well connected with what other consultants in our company are doing. We have some ways of maintaining that connection with our fellow consultants, but Google has formalized that within their company and made it automatic to some degree. Something like this would be a great way for us to keep in touch with each other, although it would not replace the value in getting together regularly for lunch, coffee, or beer!

2) Google Ideas forum with voting

Internal to Google they have a forum that allows employees to suggest new product ideas, and for others to vote on and comment on those ideas. A great example of encouraging a flat management hierarchy and inspiring innovation.

3) Expert Directory

Got a question and need to find a domain expert who can answer it? Google allows employees to search what sounds like a skills directory and see other employees who may be able to help them with that topic. This sounds very similar to a project Open Source worked on with one of our clients who is also a large company with lots of technical experts in remote locations, and needed a way to help those employees stay more connected.

4) Google Sites

We currently use a Trac based wiki site for managing our various projects and centralizing a lot of the information about them. Google Sites may be an interesting way to collaborate with clients as well, especially since it would allow for a central repository where our clients can upload their documents to us without any wiki knowledge or special permissions. The big advantage of keeping with Trac is being able to enter bugs/enhancements and giving the client a real time insight into the “roadmap” and progress of those issues.