Justin Welsch is the lead developer on Screencast.com and has been with TechSmith since 2001.
First I'll give you some background. Screencast.com is TechSmith's answer to a long standing problem our users have. Once you have created your content with SnagIt or Camtasia how do you deliver it to your viewers? After all, you don't create a shiny new tutorial video for yourself! Screencast.com was designed to be a hosting solution that is integrated with our desktop products. This closes the circuit from content creation to delivery.
TechSmith has traditionally created desktop software that runs on Windows. So when we were given the green light to design and implement a hosting solution it was a large task in itself to figure out how we were going to build a full-featured and robust web application.
We drew on resources from all over the company. We pulled in web developers who maintain our corporate website. We had UX (user experience) specialists to help design a user interface. We brought in documentation and training people to write help documentation and create tutorial videos. Initially, Screencast.com was to be a hosting site for Camtasia Studio videos so we had members of the Camtasia Studio team to represent that product's interests. There was a quality assurance team member who kept everything in line. Finally we had some of our desktop developers to round out the team (I was part of this group).
In order to manage this hodge-podge of a team, the company decided to use an agile development methodology. We did this for two reasons. The first is that TechSmith wanted to move away from the traditional waterfall method now that we were getting bigger. It just was not efficient enough for our size and was not a good fit for the product development culture at TechSmith. The second reason we used agile development was that it was thought to be a good fit for a web-based product. Desktop applications generally have development cycles of several months. For many reasons including lead time for marketing and pressing discs, once a new version is released it might be a while before another version is released. In contrast, a web-based application has the ability to be updated a lot more quickly. Since the files that contain the application actually reside on our servers (rather than on your desktop, as in traditional applications) we can change the code when we want.
The "agility" of web applications demanded a software development cycle that was flexible and able to have a quicker turnaround time. The answer lied in so-called agile development practices. If you're wondering what "agile development" means, so were we at the time. Basically, it comes down to keeping the actual team responsible for creating the product in control. The theory is that since the team is the closest to the product they are the best judges of how to implement features, fix bugs, and deal with issues that should arise. In practice this means that the team gets a great amount of autonomy to operate as they see fit within a block of time (called a "sprint", which is anywhere from 2 to 4 weeks long). Each team member is assigned tasks and is accountable for their completion by the end of the sprint. If a task ends up taking more time to complete than originally estimated or there are emerging issues that have to be dealt with, the team has the authority to either reduce the scope of tasks or drop them altogether. You can see how agile development looked like a good fit for creating a brand new application that was outside the core competency of the company.
We started out with an agile development implementation called Scrum. It is a team-based approach to agile development. It attempts to facilitate communication between team members and people outside the team (such as the marketing and executive groups). Items that need to be worked on are entered into a backlog, which is then prioritized. Since this is agile development, the priorities can change. For each sprint, items are selected from the backlog and presented to the team. The team then decides what can be done in the given timeframe of the sprint. Once a realistic amount of work has been identified, team members are assigned tasks and then work begins. To keep everyone on track and up to speed on the team's progress one of the main components of Scrum is a daily meeting where each team member gives a status update.
We started our first sprint in June of 2006. We were given a launch date of around 3 months in the future, which coincided with the release of Camtasia Studio 4.0. Our web developers concentrated on the front end and the help portion of the site. Our desktop developers worked on the back end, web API, and client communications from Camtasia Studio. As you can imagine there were many issues to be dealt with right from the get-go.
One of the biggest was whether to use a LAMP stack or Microsoft stack. LAMP stands for Linux, Apache, MySQL, and PHP. It is the defacto open source solution for web applications. The Microsoft stack generally uses Windows, IIS, SQL, and .NET. Our web developers were more comfortable using LAMP where as our desktop developers were more familiar with a Microsoft solution. For better or for worse (and you could argue it was for worse), we came to a sort of compromise. We would use PHP for the front end and IIS and .NET (running on Windows, of course) for the rest. If you talk to almost anyone who deals with web systems, they'll tell you that while a solution like what we did is theoretically possible it is not even remotely recommended. Alas, given our launch time frame and the resources we had to work with this is what we went with.
Another huge issue that we had to overcome was inter-team communication. This was to be the first time two product teams (Screencast.com and Camtasia Studio) were to work together in a concerted effort. We solved that problem by having the developer working on the Camtasia Studio client that would communicate with Screencast.com be an active participant in our daily scrum meetings.
Team management became another looming issue. We had three major obstacles. The first I already mentioned: inter-team communication. The second was figuring out how Scrum worked and adjusting the team and the company to work within the Scrum framework. The third was pulling together two differing development cultures. The web development staff and the product (desktop) development staff had evolved in different ecosystems and under different sorts of leadership. We tried to take the best of both worlds, along with the new idea of Scrum and mix them together into something that could help us meet our goals. It was quite the challenge and something that turned out to be an iterative refinement. As I write this we are still refining agile development in terms of the Screencast.com in particular and TechSmith in general.
Work progressed throughout the summer of 2006. As our launch date approached it was evident that the amount of work left to do was too much to accomplish by the established launch date. Camtasia Studio felt the same and so our launch dates were pushed back. This gave both teams breathing room to finish up some features that were taking more time than anticipated and to do thorough testing to ensure a quality product.
Finally on October 17, 2006 Screencast.com was launched to the public. The launch was coordinated with Camtasia Studio 4.0 and we saw Camtasia Studio customers taking advantage of the integration of Screencast.com.
The birth of Screencast.com was a learning process for the company. Everything about Screencast.com was new to TechSmith. Agile development, inter-team coordination, and this being a web-based application were all unknown quantities from a development standpoint. From the perspective of the rest of the company, marketing and selling a web application and working with a team using agile development were all something everyone had to learn. The fact is TechSmith is still learning about what we have created and we will continue to grow from this experience as a company.
