As part of my recent trip to the UK I got a chance to participate in GiveCamp UK. Gibraltar Software was a sponsor, but more than that we like to really participate in the community. I got selected as a team lead which made it doubly interesting – leading a GiveCamp team is always challenging but made that much more so when you account for leading a team of UK developers.
When talking with the charities that were interested in having something done at GiveCamp a common thread showed up – many needed a basic customer relationship management (CRM) capability to replace their existing paper or Excel process. Nearly every charity has the need to track donors, volunteers, and people they help. Additionally, these charities often have little or no in-house IT talent so self-hosting an option of any complexity wasn’t a good option. Instead of helping one or two of them by implementing an existing CRM option (like SugarCRM or a commercial option) we saw an opportunity to use GiveCamp to kick off a greater initiative: A free hosted CRM tuned just to small charities.
The core idea is to provide just what small charities need in the easiest to use fashion through a software-as-a-service platform. This way the charities wouldn’t have to worry about security or backups and could shave off a lot of time that otherwise went into basic recordkeeping. In many ways, this CRM would be distinguished by what it didn’t do more than what it did. The primary goal is simplicity of setup and operation and setup, not flexibility to handle any scenario.
Before GiveCamp UK started, I’d had a range of conversations with the organizers to make sure we had a clear reason for why we weren’t taking something off the shelf. We looked at a few open source offerings to see if we could just make a customization engine on top of them but in the end it was clear that the risk and complexity of those options overweighed the head start they would give us. We didn’t want to risk suitability for small charities in exchange for capabilities they wouldn’t need.
What’s a Minimum Viable CRM?
The initial requirements we got from charities were, not surprisingly, very general. Fortunately, we had a few members of our team that had experience developing CRM solutions and were able to give us a starting point that made a lot of sense. Our goal for the weekend was to get just far enough to handle the most essential requirement: track donors and campaigns.
Besides making the application useful we had to make it easy enough to set up that individual charities could create their own CRM instances. Immediately this pushed us to design it as a Software-as-a-Service (SaaS) to eliminate the need for installation and deployment by the charity. Instead, they would just go to a web site and enter the bare minimum information to get going and receive instructions.
Once we had the functionality outlined we wrote out exactly what we wanted to demo on Sunday. You don’t want to end up with nothing to show at the end of the weekend, so it’s useful for everyone to have clarity on exactly what you’re going to show. Things that the application will ultimately need but aren’t part of that demo are lower priority.
Have a demo plan before you start building the application so everyone knows what you have to get done.
Building the App
Day One (Friday night)
At first it appears that you have 43 hours to get it done – from 5 PM on Friday through to Sunday noon. But, knock out the time to form the teams (about two hours, including the introduction) and then six hours a night for sleep (sleep is a weapon!) plus another 5 hours total for eating and breaks and you’re down to 24 hours. Given that, we broke it down into requirements, planning, and framework (Friday night), construction (Saturday) and integration/defect fixing (Sunday morning).
With one day to build out the user interface and process flows it was essential to make sure we had the foundation set up Friday night. We worked largely from back-to-front with the database and data access layer as well as a generalized Excel import/export capability being done by the end of the day Friday while the rest of the developers worked out the exact flow and wireframes for the UI. I made tea and asked for status updates.
Break your project into independent modules that can run in parallel. The Team Leader should keep a close eye on whichever module is currently the critical path.
Day Two (Saturday)
Saturday morning began bright and early with most of the team in before breakfast. We had made our goal for Friday with a complete data access layer for the application set up and tested. It’s very tempting to drop parts of your normal development process when working in such a hurry, but basic unit tests put in as you go dramatically reduce the odds you end up with nothing to show on Sunday because things don’t work when you put them together.
The main applications were being built using ASP.NET MVC3 which most of the team was at least somewhat familiar with. Since we expected the system to have significant data storage requirements that would grow over time we opted for a SQL Server back end. For data access, Simple Data was selected over other options in part because Mark Rendle was on the team which made it emphatically the fastest way to get our goals accomplished. Several of the team were impressed with it and I suspect will use it on some of their future projects.
Saturday is the long day where you want to end with each of the components of your system feature complete and working at least in isolation. Once you leave on Saturday you’ll only have a few more hours available on Sunday to get everything wrapped up. As the day progressed things were looking up that we’d be able to deliver on our goal for the weekend.
To help with testing and prove that our application could scale we wanted to load it up with test data that would feel like the real thing. There were two approaches that occurred to us – write a programmatic code generator to run on top of the data layer, or use a data generation tool (like Red Gate’s SQL data generator). We weren’t sure if the off-the-shelf tool would get us good enough results in time, particularly since no one on the team had used it. Alternately, it wasn’t clear how much time it’d take to generate plausible data on our own. So we did both for a while – running down both paths for a few hours to see which would bear out. In the end we found the Red Gate tool did great with people and addresses, but our custom coded tool did better with donations and more interesting edges of the data.
When you aren’t sure which way to go – do both. You have more people than time. Pick a winner when it’s indisputable or you can’t spare the effort any more.
Around dinner time we did a walkthrough of the complete demo we’d laid out and noted the missing elements and problems. We’d come a long way, but there were several minor changes that appeared useful for the best experience. With the user interface coming together, I went around to other teams to find a graphic artist that could make us a logo for our project. We’d settled on the name GiveCRM and a logo would be a great touch for the demo. Fortunately another team was already done and was willing to lend us a hand with a family of logo graphics we could incorporate. Meanwhile, I made tea and asked for status updates.
Day Three (Sunday morning)
Sunday morning was a later start for most people since they’d stayed late to accomplish our Saturday goals. Once there was no more tea to make I’d left and gotten a good night’s rest so I was able to whip up a presentation on Sunday morning for our demo later that day and review where we were. We started off the day with another demo walkthrough to see what gaps remained. It was clear one thing we wanted to have done – a proper authentication system – was not going to make it in time. Instead of risking the demo we decided to have that team continue working on a branch while we finished up the rest.
About every hour we continued this pattern – do a demo walk through, note the issues, make progress. Naturally, I made tea and asked for status updates. By the time it was pencils down at high noon we had the whole thing put together, along with some extra bells and whistles that weren’t in the original plan.
Keep tracking your progress against your demo. This keeps you looking at the whole picture instead of just the individual modules and function points
Well, that didn’t work
The monkey wrench that got thrown into our plans was challenges with configuration management. We’d opted to use GitHub as the central repository for the code despite very few on the team being familiar with it. This was my mistake – it was mentioned by one person and I assumed I was the only one that was in the dark on how to use it on a real project.
DVCS tools are very powerful for distributed development but can get you in real trouble. Several times we had to stop work and enlist a Git expert (Ben Hall) to rescue us from merge oblivion. Ultimately we addressed this with external locking: I had a squeeze toy which you had to come get if you were going to change project or solution files (or add a new file to the solution). Combined with a fair bit of manual coordination we mostly avoided merging problems going forward, but it did cost us a lot of time.
Think hard before relying on tools your team doesn’t know. Time is your greatest enemy.
Where’d we end up after one weekend?
When I originally discussed the project with the organizers of Give Camp UK I didn’t give us much odds of having an interesting demo at the end of the weekend. Our first goal was just to make progress that could be built on in the future. After our Friday night planning it seemed quite possible we’d have something ready for charities which was quite exciting indeed.
The main application was in pretty good shape: You could import data, export it, create and manage campaigns. Donors could be individually added, donations recorded, and an easy-to-use campaign generator let you build up a filtered list of donors. Even the authentication system that had been such a concern earlier had picked up its pace and was ready to be merged in. We decided not to do it for the demo in case it introduced a problem, but it was checked in and ready for merge.
The provisioning system was similarly looking good: It gathers the necessary information, creates the right database entries, generated a nice introduction email (in HTML and text formats no less) and could import initial donor data from Excel. Like the main application it too needed to be merged with the authentication system which we left out for the demo.
There were a few things missing before we could release it to charities for use. Most notably, there are some back end features missing in the provisioning system for creating new charities and you can only have one account for each charity. For the most part these issues will be straightforward to address and the team is set up to get these handled.
Before we go live, we need to find the right place to host the system. We have a test server up and running at GiveCRM.org.uk but we need a real home – one that can scale up to handle hundreds if not thousands of charities. Our goal is that the service is free for these small charities. The incremental cost to host each will be quite small, but any charge will shift how charities will approach a decision to adopt it.
Interested in Helping Out?
This is just the beginning of the development of GiveCRM. Our goal is to continue development with a volunteer team to refine the existing features (and address the gaps we need to go live) but then at each of the coming GiveCamp UK events add another module to the system. While we believe we’ve hit the most critical feature charities need, it’s far from a complete solution. If this is interesting to you, be sure to sign up to hear more about the schedule for the next Give Camp UK event.