A perennial problem for a custom software development company is having the right number of team members for the amount of work at any given time. At Menlo we adapt ourselves to meet client needs, which often means varying project start and end dates and handling week-to-week fluctuations of how much work has been authorized. As a result, how many people are needed to complete the work each week also changes.
In a perfect world, Project A, staffed with 3 developer pairs would wrap up just in time for us to spin up a new Project B that also needs 3 developer pairs. But, so far, the real world has not aligned with that ideal. Project A decides to extend their statement of work and scale up 2 more developer pairs to add even more features to the existing product. Or Project B has postponed starting their project until after a critical internal meeting with stakeholders. And Project C has just shown up and wants to start next week with 4 pairs.
To further complicate things, people take vacations, get sick, have doctors appointments, run into car trouble, or one of so many other examples of what we bucket on the Menlo schedule as either a “planned out” or “unplanned out” pops up. As a result, Menlo needs a certain amount of slack in the schedule in order to meet our clients needs.
Menlo staff is made up of many roles–developers, project managers, quality advocates and High-Tech Anthropologists. Many team members often wear multiple hats–such as helping with HR, marketing, accounting, and presales. I, for example, have “developer” in my email signature, but I was scheduled to write a blog post today. Developers make up the majority of our workforce (currently around 60%), and developers are the ones we most often need ready and available to help scale up projects or cover outs.
But what happens when no one is on vacation? No one calls out sick? Or the new projects aren’t ready to start just yet? What will those extra team members “on bench” work on that day?
Our usual solution to this problem is Internal Projects. Most of these are small, proof-of-concept applications where team members get a chance to practice new technologies and prepare for an upcoming project. However, internal projects, being only occasionally staffed, have a tendency to flounder, especially if they lack an external stakeholder and a real-world outcome.
Menlo cares about providing meaningful work to team members and creating throw-away demo apps often lacks that engaging and real-world experience. For a one-day or one-week long project, quick demos work okay, but they aren’t projects that the Project Managers can easily schedule anyone on week-after-week. For that, we need something with more structure like a traditional client project.
This is where partnerships like ours with the Ann Arbor Hands-On Museum come in. Menlo’s relationship with the AAHOM goes back many years – we are a proud sponsor of their work and they regularly assist us as a stakeholder when we host High Tech Anthrology workshops. So when Menlo had the idea to reach out to the AAHOM to see if there was development work we could do for them when we have extra capacity, they eagerly requested we help them with upgrading some of their older exhibits.
The team started by focusing on one exhibit in particular: Michigan Nature Sounds.
This exhibit allowed museum visitors to select Michigan animals and play audio clips to hear each animal’s sound. Menlo developers dutifully drafted up a bunch of story cards to recreate each screen in a new technology stack. And then, as we like to say, we “got James-ed.” If you haven’t had the pleasure of being “James-ed,” what it means is that our co-founder and Solution Architect James Goebel came in, asked some leading questions, and quickly blew away our previous preconceptions.
What problem were we actually trying to solve? Were we just going to rebuild each exhibit one at a time? Were all future edits to those exhibits going to now require more Menlo development work to change? Should we instead be finding a way to help make the AAHOM more self-sufficient in creating, updating, and maintaining exhibits on their own–without reliance on Menlo having dev capacity?
So we went back to the drawing board and started talking to our project sponsors–Charles Stout and Dylan Larkin–about the new direction. What we heard were examples where an expert might visit the museum with their children and notice a mistake in an exhibit. Perhaps ”That’s not a white throated sparrow, that’s a song sparrow in that audio clip.” Or sometimes there was newer science out there that an exhibit could be updated to reflect. Being able to quickly go in and update a caption or swap out a picture or video without having to go through the volunteer who originally built the exhibit would be great!
Thus, the Exhibit Builder was born. The project was code named Brooklyn–after the Brooklyn Children's Museum, the world’s first children’s museum founded in 1899. The java application was designed to allow AAHOM staff to build a touch screen exhibit themselves. Initial designs for a drag & drop GUI were pretty quickly discarded as our primary persona was software-savy and the project sponsor wanted to invest development time and effort into being able to make pretty new exhibits–not having a pretty exhibit builder that wasn’t going to be visitor-facing.
Just like any billable Menlo project, work is broken down into story cards: “Charlie can add a video to a screen,” or “Dylan can define custom fonts for labels”. Each of these user-centric cards gave quality and meaningful work for on-bench developers to work on. As an added bonus, the highly-interactive GUI was a nice change of pace for many team members. Some of our projects are fairly abstract (think “I moved data from one system to another and validated its shape”). We had a lot of fun making demo-exhibits to test features (even if other developers nearby got a little sick of hearing the same bear audio clip played over and over again).
Development work on the Brooklyn project stalled during the pandemic, but Dylan was able to take the version of the application he had from before the project stopped and build out for himself a whole interactive catalog for the Lyon’s Country Store. Museum visitors can click on any item and see more details about that piece of the exhibit.
When Menlo and AAHOM met recently to talk about resuming work on Brooklyn, we were thrilled to hear that the Lyon’s exhibit had been “rock solid” for 2 years without any crashing or need for debugging.
Our next phase of work will be building out additional features like videos and adding support for the arcade-style physical buttons that are often used instead of touch screens in exhibits. To provide some added inspiration, we thank the AAHOM team for allowing our devs to the museum, see the Lyon’s Country Store exhibit in person, and climb up to the bell tower! Even one of our team members who was remote that day, Sebastian, was able to join the tour via iPad.
All in all, the project has proven a perfect match. Ann Arbor Hands-On Museum gets an exhibit builder application with expanding features that will benefit our whole community and Menlo has a solid project we can schedule to when we have extra developer capacity.