Last week, several us from the office took a 60-minute jaunt down the road to Ann Arbor. No, we didn’t battle the torrential downpours for lunch at Zingerman’s or Blimpy Burger (still never been there). We actually took a tour of one of our industry peers and generous hosts, Menlo Innovations.
Menlo is a software development firm that primarily focuses on consulting-based projects. It started up in 2001 by four partners. One of those partners was Rich Sheridan, who is Menlo’s president and guided us on the tour. Upon arriving (despite the heavy rains) we all piled into their “lobby” area. We were greeted by Rich who gave us a brief history of how Menlo started and some of his background about why he started the company. Then, at 10:00 on the dot, a buzzer went off in the back area where we heard constant hustle a bustle the whole time we were up front. Stand-up time!
And Now For Something Completely Different
We were brought back as everyone was working themselves into a large circle that was forming around the work area. Our group of 15 was assimilated, almost adding half again the size of the entire Menlo staff (could be off here, didn’t actually count, but sure seemed that way). Passing a large-horned Viking helmet around, pairs of people stated what they worked on since the last stand-up (i.e., the day before). Once all the Menlo people were done, it was our turn. Being we already do stand-ups everyday, we gave our status update and passed the helmet without skipping a beat. Oddly, no one really flinched at me saying I “nuked the current sprint” for one of my teams as part of my report. 12 minutes and 45-50 people later, we were done. Everyone went back to work. Rich started in on the meat of the tour.
Now as people were sitting back down, we got to take stock of their office arrangement. It was literally just tables, computers and chairs. No cubes, no doors, no offices, no walls period… Okay, I mean internal walls… in their work area. It’s a VERY open environment, which explained all the “noise” we heard during the tour introduction. You can basically hear what anyone is saying from anywhere on the factory floor, as they call their work space. Definitely different from all the environments I’ve ever worked in, but certainly seemed kind of neat to be setup that way. My first thought was that being a relatively small company certainly helps to allow that, but I’ll get to the biggest element of their “seating chart” in a moment.
Primarily acting as a ScrumMaster in my current role, having a PMP cert and being generally interested in process related to creating software, the next part is where I really wanted to hear about how Menlo works. Rich proceeded to walk us through how Menlo Innovations creates solutions for their clients. Amazingly, it’s not just sit down and bang out a bunch of code. There is a TON of process behind their efforts.
Menlo practices a form of software development known as Extreme Programming (or XP). XP is one flavor of what are known as Agile methodologies and it has several key traits. Menlo adheres to those traits very judiciously, keeping in line with XP’s mantra of “if some is good, more is better.” No production code is written without having a second person working with you at a paired workstation. In fact, with very few exceptions, there are only paired workstations across the entire company. There are no personal workspaces, desks, what have you. The team working on a project or even as a pair are liquid, and there is at least weekly shuffling of resources to adjust for the various project schedules.
Menlo is also extremely disciplined in the other areas of XP. Comments are not put in code; the code needs to speak for itself. Unit tests need to be wherever and whenever possible (they claim95% code coverage with their tests). Additionally, they make use of continuous integrations for their builds, QA follows immediately behind development. Work is organized as prioritized and estimated user stories which are written on paper and pinned up to a cork board in 1-week iterations (increments). There are other elements and nuances, but those are the big ones in my mind.
I suppose your initial reaction could be: Woah! That’s a lot of rules for a process that calls itself “Agile.” On a cursory glance, I get that, but let me dig in a little further after I wrap up the tour. The whole time, we were constantly peppering Rich with our questions. He either fielded them with thoughtful answers or handed several of them off to other employees; usually questions from developers to developers. Everyone at Menlo knows their process very well, so they all could generally deliver the answer Rich was expecting, even if it took them a moment to catch their bearings to be interrupted and put on the spot. And as Rich declared when we first began, we would have more questions than time. But, I would declare we ended up with a great conversation between us and them considering the relatively short time we were there.
Field Trip in Review
As already noted, what it was that Menlo shared with us on the tour, is exactly the type of stuff I’m interested in professionally. Just seeing another company in action creating software and trying to do it on time, while accomplishing the right goals and solving the right problems was extremely cool and insightful. I believe it’s safe to say everyone from our group had the same impression, albeit for potentially varying reasons. Big hats off to Menlo for their generosity in opening their doors, which they’ve done since the company’s inception. (Fun side note: they codename all their projects that have wall boards up on the walls so they don’t reveal actual client names during tours. Clearly a bit of creativity was put behind picking the codenames.)
As far as major takeaways from the excursion, I’m still trying to pin down specific things I feel I could try with my teams. I think something’s there, I just don’t know what that is and I don’t want to force anything if it doesn’t make sense. Granted, teams at my company are usually actively working on improving our processes and learning new ways, which is why so many of us went to Menlo in the first place. There are a couple items worthy of note, though.
Menlo as an entire organization seems to be quite tyrannical with itself in maintaining discipline over the key elements of their process. And from my view, that’s a good thing. Rich shared a story of an intern yelling at one of the company’s first employees over putting a comment in the code. They keep every single sheet of paper that has a completed user story from every week-long iteration of every project they’ve ever worked on. What I glean from that is really the discipline of using their process is what makes Menlo successful. They could using a totally different methodology (Scrum, RUP, Lean, Kanban, etc.) and as long as they maintained that same level of strict discipline, I bet things would work just as well for them. I couldn’t get myself to say that out loud while we were there, though. They’ve been doing XP since Day 1, and I wasn’t exactly sure how sheltered their lives were in knowing about the existence of other ways to do what they do. 
Second, their frequent shifting of resources from one project to another seemed cool. It’s the mandatory pairing that enables that shifting. Having one person you can immediately sit with who has context/knowledge to share with you essentially eliminates pure ramp-up periods. That even goes for new hires, who get a 5-minute introduction then start writing production code right away. We’ve done some of that resource sharing of late. It’s been more along the lines of a person or two, or creating an ad hoc team from different existing teams to research, but I think it’s still in the same vein and has provided benefits in every recent case.
A final thought is that while the general concerns are the same (e.g., make great software), a primarily consulting-focused environment as opposed to making commercial software products presents some differences in how effective specific approaches can be. As far as determining what to work on for the next iteration, it’s relatively easy to go directly to the specified stakeholder on the client side to get that priority set versus divining from hundreds of thousands of users who may or may not be giving you their feedback as to what they want in the next version. Likewise, the notion of billable hours lends itself to more clearly defining accountability to get planned work done.
I don’t say any of that to make excuses, build up a wall of differences or even say Menlo has it “so easy”… I’ve done consulting, so I would never say it’s easy. I’m merely pointing out that’s a current hang-up I have in translating elements of the process in their environment into reasonable facsimiles in my environment. Obviously, things like pair programming and unit test coverage don’t need a lot of translating, but I’m looking for more subtle tweaks that will continue our forward progress. Maybe I shouldn’t. I’m also not looking for a silver bullet. Not even Menlo claims those exist.
Conclusion
Menlo Innovations is indeed extreme about their Extreme Programming. But despite all my ramblings, you should really see it in action for yourself. They provide free monthly tours of their operation, and I highly suggest you take them up on the offer. We got a special “just us” tour, but I’m not sure how that all worked out. I was just along for the ride and rather enjoyed it.
Plus, I’m intentionally keeping some of my thoughts about the trip to myself. I don’t want to even attempt to recreate the whole experience and spoil it for you. I would be very interested to see if some of your observations line up with mine or if you completely disagree. If you are so incited either way, drop a comment below or hit my contact page to send me a message.
This probably would have been written better if I was paired with someone, but thanks for reading anyway!
