Comments (0)

By Rich, February 4, 2010 8:00 am

Whenever I give a tour of Menlo and describe our approach, I know I’m connecting with the audience when I start getting laughs or painful groans at just the right moments. People come here to learn from us and they attempt to find things they can take away that day that could make their lives better.

One of the key moments comes early on in the tour when they’re looking at our open and collaborative work environment and I just happen to mention that we don’t use e-mail to communicate with each other. This is almost always followed by a painful groan as my guests consider how much of their day is consumed by reading and responding to e-mail from their peers. Of course at this point they’re curious about how we do communicate with each other. I go on to explain that when we communicate with each other we use High-Speed Voice Technology™.

It usually takes a second for this to sink in and then the laughter starts. I explain to them that this technology comes built-in to the operating system and is pre-configured for use. I believe the laughter comes from the overwhelming amount of common sense and the stark efficiency this represents. At this point they begin looking more closely at our team and they see these constant, active conversations going on at each computer where two people are paired together working on the same task at the same time. It is not unusual at all to hear laughter and see smiles while the team is working through difficult problems.  Our screens have lots of fingerprints, arms are often lifted in the air pointing at screens, and the keyboards are moving back and forth frequently between the pair partners.

I believe this is the first point where people truly grasp what we like to call “The Menlo Magic.”

The energy, the noise, the collaboration suddenly come into view and it is not rare that some of our tour guests will say, “Wow. I would love to work in an environment like this.”

When most people talk about wanting to improve their “teams” they often talk about team building exercises like white water rafting trips, ropes courses, or trust falls. We have a better idea. How about building software together? It’s such a simple concept but in our environment we get to practice it every single day. Most visitors wonder if we’ve somehow cornered the market on extroverted software engineers. I’m often asked this on a tour. At this point I typically ask the team for a show of hands of how many would give themselves an “I” in their Myers-Briggs score indicating they are an introvert. More than half of my team raise their hand. I believe that it’s not that introverts don’t like relationships with other people, rather they simply prefer fewer, deeper relationships. We give them that opportunity in our environment.

And yes, the result is magical.

Comments (0)

By Rich, February 1, 2010 11:24 am

Estimation is always a hot topic in software development. An even more important topic, and usually ignored, is not how to estimate but rather how to size a project. So what’s the difference?

By now you can probably imagine our world here at Menlo. When people walk in our front doors or send us an e-mail about their project, their first question is usually “How big is this?” It’s at this point that we know the least about the project and yet we know it’s important to be able to give someone an idea of the size of the project before we ever engage them in actual work.

People often ask us, “How can you do that?” The answer is actually quite straight forward, and it’s amazing to us how few people can actually do this.

We start by getting a basic description of what they’re trying to accomplish. We then seek to find other comparable projects we’ve done in the past. Now comes our favorite “parlor trick” — once we’ve found comparable projects, we look at the actuals. We’re able to do this because we collect “actual actuals” for all the projects we work on so we know — down to the quarter hour — how much time we’ve spent on previous projects. This becomes an amazingly powerful tool when doing these early project sizings.

While this process is straight forward, the ensuing discussions with our potential clients are anything but. When presented with such real data they almost always respond by saying, “There’s no way our project’s that big!’ We then ask them how big they think it is. They respond, “We’re not sure, but we know it’s not that big.” Perhaps what’s frustrating about this stage of the discussion is that many of the projects we are asked to size are to rebuild an existing system with new designs, new technologies, and extra features. When we ask them how much effort it took to build their existing system, they have no crisp answer because they’ve never tracked actuals.

As an organization, Menlo is still learning how to best convey these early sizings because we know that our reality-based sizings conflict with the fantasy-based sizings our industry frequently produces.

Many times we lose these projects because our potential client finds another resource who agrees with their perceived project size. Our experience, however, also tells us that we were better off for the loss. I’ll explain this with two examples.

The first was a project that someone was convinced was only a third of the size we predicted. We didn’t get the deal. Years later I ran into the new CEO of the company that did get the deal. He shared with me the experience of inheriting a painful project where his company’s commitment meant that they had to fund 2/3 of the total cost of the project on their own dime to complete the work. It was the same project Menlo had “lost.”

The second was a project we referred to in an earlier post when we talked about “Fixed price is a lie.” Our sizing for the project indicated it was somewhere between 8,000 and 20,000 hours. Our prospect said they had another firm that could do it in 4,000 hours. We declined to bid. The project was supposed to complete in 6 months. It is now over 4 years later and it is still not complete. I’ve had many discussions with them and it turns out that they have invested thousands of hours of their own time just doing QA on the resulting software.

The question we’re left with revolves around human nature and it is simply this: why is it that when people are presented with two competing sizes, they will always chose the smaller of the two, disregarding all other factors?

Menlo’s answer has been the same throughout our history: the only way to make this work is to educate our prospects about the process we use. We find that our best clients are those that have frequently chosen the smaller size estimate in their past, suffered the consequences, and have committed to never suffering that pain again.

Comments (0)

By Rich, January 28, 2010 6:00 am

When we hire students fresh out of universities — like Michigan, Michigan State, Yale, Albion, Illinois. Indiana and other prestigious institutions — I can only imagine the stark terror in the minds of their parents when they hear their child is going to go work in a “Factory.”

Consider the story Lisamarie shared with me this morning when I told her I was going to write about this topic. She told me that when she was in high school, her friend’s dad took his son to work with him. His dad worked at a steel mill in one of the hottest and most intense environments it had to offer: the blast furnace. He stood Michael on the edge of the blast furnace and told him, “This is why you’re going to college, so you never have to work in a factory.” The message hit home.

We admit that it might not be our finest marketing moment to call our unique open and collaborative work space “The Menlo Software Factory™”. We could have called it “The Studio”, “The Boutique”, “The Loft”, “The Café” or even simply “The Agile Team Room.” Our desire though was to communicate both internally and externally the notion that what happens in this room is actually WORK. Factories, when they are well run, produce measurable, repeatable, predictable results. We never want to be confused about the value that our clients are counting on from us.

In a future post we will discuss the historical connections we have with Thomas Edison’s original Menlo Park, New Jersey lab. Edison referred to his lab as an “Invention Factory.” He believed, as we do, that it is possible to create a systematic environment of sustainable innovation. In fact, the brass plaque outside the recreation of his lab at Greenfield Village says it best: The goal of Thomas Edison’s Invention Factory was to create a minor invention every ten days and a major one every six months.

Sounds a bit like “Agile,” doesn’t it?

Most people imagine that invention and innovation are rare “EUREKA!” moments that happen only a few times in a lifetime. However, like Edison before us, we believe that if you create the right environment and apply the right processes, invention and innovation can be regular occurrences.

As we’ve said before, the first word out of most tour visitors’ mouths is “Wow!” They’re responding to the energy, the playfulness, and the noise of our team as they work. On closer inspection they are surprised to learn of the rigor and discipline that drives our processes. They’ve mistakenly been taught that fun, inspiration, and invention will be thwarted by rigor and discipline. In fact, just the opposite is true. By having a process that the entire team understands and adheres to, freedom becomes the norm.

I don’t  know if our team members proudly tell their parents they work in a “factory”.  What I  do know is that they are proud to tell their parents all about us and bring them in to visit where they work.  “Pride in workmanship” is almost a lost art these days.

It is very satisfying to see it applied every day at the “Menlo Software Factory™”.

Comments (0)

By Rich, January 25, 2010 2:35 pm

How many of us would love to get this kind of e-mail from the sales force of a client?

Dear Rich,

We’ve met a few times, but in case you don’t remember me, I’m one of the Sales Directors for Accuri reporting to Jack Ball. I was speaking with an old colleague of mine this morning, and he remarked that the software for the product he sells is not very user friendly and this hurts sales. I explained what Menlo Innovations does, and how our software was put together by studying users, etc., and he was quite intrigued. And when I told him he could be running samples in 20 minutes without any experience with flow cytometry, he was astounded (as are the vast majority of our customers).

This gentleman is in the Chicago area, and he said that he would be looking at your website to see exactly what your company does. He’s early stage at this point, but would you like me to give him your contact information? Just let me know.

Best regards,

Greg

Most businesses acknowledge that they thrive on word of mouth references.  Our goal is to help our clients achieve widespread adoption of the products and services we design and develop for them because it is widespread adoption that creates the opportunity for word of mouth advertising. Beautiful designs, clever implementations, and cutting edge technology are not the essentials ingredients to success. Rather, it is the intense focus on the needs and goals of the target end-user audience that will win every time.

We haven’t yet explored our High-Tech Anthropology® practice in this blog, but it is this part of our process and our team that leads to powerful results. I can tell you there is no greater thrill for a team like ours than to hear stories such as Greg’s come back from our clients.

Many people mistakenly believe that software developers are satisfied by simply writing code. However the spirit and energy of a software team is sustained when their work actually sees the light of day and is well received by users and customers. Further, they are buoyed by knowing that they have improved the lives of their users because the users can spend less time fighting with tools and more time doing real work.

This friend of Greg’s wants what Greg got: easy to use software that helps sales rather than hurts it, and users who get to do their real work rather than complain about their tools.

We don’t know everywhere that Accuri will be selling cytometers, but we do know that this is an important tool for researching cancer and other deadly diseases. If through our efforts we are able to assist these scientists and researchers in achieving the true goal of their work, our team can be very proud that we have helped mankind in some important way.

Comments (0)

By Lisamarie, January 21, 2010 8:00 am

People who come to Menlo Innovations or take our classes are often fascinated with the power and simplicity of our paper-based planning game. When we first introduced this planning game process at my old company, Interface Systems, my boss/CEO Bob Nero was thrilled to see us planning and revisiting our plan every two weeks. He saw a level of productive interaction between the business and technology teams that he had previously only dreamed of. This had gone on for several months when one day Bob came in and expressed a grave concern about this process. I believe Bob uttered words that no business executive had ever spoken to the head of a technical team:

“Rich, I have a great concern about this system you’ve created.”

“It’s too flexible.”

“What do you mean, Bob?” I asked.

He said, “Rich, every two weeks we gather together for this planning activity and we lay out the stories we want you to work on and you follow exactly the plan we lay out.”

I said, “Yes. That’s how it works.”

He said, “We could come back two weeks later and completely change the plan going forward and you would once again follow that plan.”

I assured him that was true.

He said, “Rich, we could use this tool to do the planning equivalent of ‘donuts in the parking lot’ and your team would follow our lead.”  I saw where Bob was heading.

I tried to coach him through a metaphor. I said, “Bob, tonight when you drive home in your Lexus, down I-94, do you realize you are holding in your hand a steering wheel that, should you so choose, you could jam the steering wheel to the right or to the left, tumbling your car, killing yourself, and probably several others?” To which he responded, “Yeah, but I would never do that!”

I said, “Precisely!  So don’t do that with this process. This process requires a responsible driver at the steering wheel.  If major changes are necessary for the business, we will follow.  But if only minor tweaks are needed then that should be the order of the day.”

The planning game is a powerful tool and a dangerous tool. If the business chooses to do ‘donuts in the parking lot’ and loses sight of the vision and direction for a project, nothing will be accomplished. However, having a simple tool that allows the business to steer, married to a process where the team will actually follow, we create an opportunity for a powerful collaboration between two teams that far too often have never learned to communicate in an effective manner.

Simple tools can provide profound results.

Comments (0)

By Guest Blogger, January 18, 2010 8:00 am

I arrived at Menlo as the fifth of six international interns. Before leaving Austria for this 11-month internship I graduated with my masters in computer science and economics. I wanted to gain international experience after graduating and the possibility to work in the United States seemed to be perfect. Before starting my internship I got a lot of background information from Martin, a former intern at Menlo. He told me about the way Menlonians work and he really supported me to take this opportunity. From Martin I knew too that it’s usual to start working right away, the minute you enter the doors. But I was still surprised how quickly I sat down with a pair partner and started working on our first task after I walked in.

I got to know some of the people working at Menlo, and I was told on which project with which pair partner I would be working. This was absolutely fascinating for me, how easy it was just to walk in, say hello and feel comfortable right from the beginning.

My first pair-partner was Karlis, an intern from Latvia, who had already spend nearly three months at Menlo. While getting started with our first task, Karlis gave me a brief overview about the project. He explained to me which part of the code we were going to work on by showing me the actual problem they had worked on the day before. It didn’t take us more than five minutes until we typed the first lines of code. And the special thing about these lines is, they were test cases not production code. I learned about test-driven-development and pair-programming at university, but I never saw a company realizing these concepts in real projects. I have to admit that I was skeptical about how this could work successfully, but after some time it was obvious that there is no reason to be worried, it works great.

I got to learn details about projects, tasks of other pairs and how the whole Menlo-world is structured and organized just as I needed to know them.  There was nothing like a big get-to-know-how-to-work-in-our-company thing by reading some documentation or hearing one long speech including a lot of information I couldn’t attach to something I had never seen or done before. At Menlo it was like getting to know more people every day and with this I learned everything about the organization and idea of the company. There are no strict rules or a rigid structure written down on some paperwork, the people you are working with are all the rules and the structure you need to know. And the best and easiest way to learn this is talking to employees and the other Interns, just asking them what you are interested in. There is nothing you cannot ask and there is no one you are not allowed to ask. That’s what makes this system work very well.

I really liked the way of working here from the first moment on. I had a task to work on together with my pair-partner, we developed in the new-for-me test-driven environment and we produced code used in a real project on my first day. This was a very good start for me, I felt like we really produced something what was needed and so I looked forward to come back the next morning when leaving Menlo at the end of my first day.

Comments (0)

By Tracy, January 14, 2010 8:00 am

The first thing people notice when you walk into our space is it is one big room and everyone is talking.  Eventually they ask one of the most common questions we hear; “How can you work with all that noise?”  Now there is a scientific explanation for why we don’t notice the noise.  It has something to do with your brain and how it processes information but let’s not get scientific.  Let’s talk in reality.  A sound only becomes noise when it is a sound that bothers you.  A sound that is bothersome is a sound out of the ordinary.  When you work in total silence any sound is a sound out of the ordinary, thus is bothersome, thus is noise.

On the contrary when you work in an environment where there are lots of similar sounds (people talking, computers humming, typing, etc.) there are very few sounds out of the ordinary.  If there are few sounds out of the ordinary, there are few sounds that are bothersome and thus less noise.

It is really quite simple.  Louder environments produce less noise than quiet environments.  Run the test.  Attempt to hold a conversation at a restaurant.  You’ll see what we mean.  Some companies are even selling white noise as a way to get people to be more productive and are touting it as a way to enrich your work environment. For example:

• Speech Privacy Systems
• Steelcase Blog
• Steelcase Press Release

Let us save you the money.  For a reasonable fee we’ll teach you how to generate your own white noise, be more productive, and enrich your work environment by communicating with each other all day via our very own voice technology.  Oh, and we can teach you how to design and build software too.

Comments (0)

By Rich, January 11, 2010 8:00 am

It’s been almost 40 years since I typed in a 2 line program on a 10 CPS Teletype and the computer responded, “Hi Rich.”

I’ve witnessed many magical moments since then and even though I understand how computers work, there are still times that take my breath away when it comes to technology. The first one of those occurred in 1994 when my wife asked me to “search the Internet” for an article on “knowledge workers.” I assured her that was not how computers worked. To humor her request, I fired up the brand new Mosaic browser (as part of the Prodigy service), and typed in “Knowledge Workers.” To my amazement she got exactly what she needed. She asked for a printout and thanked me for my help. I tried to explain to her that a miracle had just occurred. She was confused, “Isn’t that the way computers are supposed to work?” I said, “Yes, but they don’t.” Having spent much of my career trying to get IBM mainframes and personal computers to do the simplest of communications in the most complex ways imaginable, the elegant simplicity of the Web astounded me.

A few years later I came home and was greeted excitedly by my oldest daughter, who was sitting at our home computer pronouncing, “Dad! You’ll never believe this! You can get any song you want for free!” I assured her that was not how computers worked. She ignored me and said, “Tell me the name of a song…” Determined to convince her that what she thought she was seeing wasn’t true, I picked an oldie but a goodie, “Bend Me, Shape Me” by the American Breed, one of my favorites from the sixties. She asked me which of the 35 versions that appeared did I want to download?

Just recently I witnessed an equally powerful, albeit not quite so “magical” moment. My oldest daughter had just bought her first car and she was looking for insurance. While I was imagining a Saturday trip to AAA, she had a different approach in mind. She went to the Web and brought up the AAA website.  She was convinced she could buy auto insurance online. I was dubious. AAA proved me right, she needed to visit the office to complete the transaction. Undaunted, she tried State Farm.  This experience was much better, and yet, at the key moment where she pushed the button to purchase the policy, the website failed and the transaction was not completed. At this point she brought up the website for Progressive. It seamlessly and effortlessly completed the transaction in just a few minutes. The experience was so smooth and enjoyable, I believe Progressive has a new customer for life.  At 25 years old, she is likely going to spend a lot of future dollars with Progressive; dollars that won’t be spent with AAA or State Farm.

The lesson of this experience is fundamentally important to all business. The cost of switching now approaches zero. The only effort my daughter had to expend was the effort to type in a new web address for a different company. Her expectations, set over the years by her experiences with Google, Apple, and yes — even Napster in the early days — have created a very sophisticated and demanding user. Companies that get this will thrive. Companies that don’t will not survive.

Menlo’s High-Tech Anthropologists® understand this fundamental principle of modern commerce. The world has changed and we must change with it. Failure to understand this change will bring down mighty institutions, even ones that have lived for decades.

Comments (0)

By Tracy, January 7, 2010 8:00 am

My very first day working at Menlo I walked in, said hello to a few people, then James Goebel told me I was going to go with Carol Morton over to the client site to observe someone using software for the first time.  Without skipping a beat I turned around followed Carol out the door to her car and headed off to do the observation.

Looking back on this experience it occurs to me I was unusually calm.  Calm is not a word generally used to describe me and my personality type.  Calm is something for those weird people who embrace change.  Yet the idea that I was going to Menlo’s biggest client to observe someone using software I had never seen before for an instrument I knew nothing about, didn’t bother me on that day.  The only possible explanation to this hiccup in my personality is I had a pair partner leading the way.  I trusted that she would help me.  She had been on the project and knew what she was doing.  All I had to do was follow her lead.  That’s easy.  I can do that.

Mine is not an unusual story.  Most Menlonians can fondly recall the crazy situation they were thrown into on their first day.  This is the power of pairing.  Rather than being left alone to feel stupid and less than useful, I was empowered and productive on my very first day!  I want to feel this way everyday.  I want to help others feel this way.

Pairing is an opportunity to learn, teach, and collaborate.  When it goes well, it feels effortless.  When it feels like a struggle, that’s when you know you aren’t truly pairing.  It is a skill that must be practiced.  Most of all, pairing makes work fun.  It is amazing how much work can get done in an eight hour day when you are having fun.  Try it sometime.  The next time you find yourself stuck on a problem, staring at a cube wall grab someone on your team, share your keyboard, draw pictures, share your thoughts, dare to be wrong, listen to the ideas of others.  You might surprise yourself.

Comments (0)

By Rich, January 4, 2010 1:26 pm

For most of my career I was a party to a religious war that was being fought by members of any team I was a part of.  It all had to do with the exact “proper” placement of the curly braces in the C programming language. The battle lines were clear and can be best expressed with two snippets of code:

On one side of the battle line was the symmetry sect:

#include <stdio.h>

main()
{
  for(;;)
      {
          printf ("Hello World!\n");
      }
}

On the other side of the battle line was the efficiency sect:

#include <stdio.h>

main(){
  for(;;) {
     printf ("Hello World!\n");
  }
}

There were multiple factions within each major sect. For example, was indentation done with 4 spaces or an entire tab stop? Should the opening curly brace be on a line all by itself, or can it include code? And so it went.

The sense of every team I was a part of was that there could be great benefit if we could standardize. Code would be easier to maintain and popular source code control tools could powerfully indicate real coding changes instead of simply identifying artifacts of “coding standard wars.”

Lisamarie had similar experiences with her team. One of her programmers (named removed to protect the guilty) applied the “auto format” feature of the particular coding tool they were using to the entire code base…then checked in the code.

Yeah. The whole code base. What do you think happened?

Holy h*ll broke loose. The religious war escalated to jihad.

About 15 years into my career I realized this was an unwinnable war. I simply acquiesced to inconsistency being the coding standard. This at least reduced wars and battles to skirmishes and diplomatic encounters.

Then in 1999 a magical thing happened. We began the Java Factory at Interface Systems and began coding in pairs. The pairs switched often. The first remarkable transformation in this process change was the migration from code ownership to code stewardship. What made this remarkable was the prior behavior of my team was to build gun turrets and razor wire around “THEIR code.”  Now they were sharing their code with everyone.

The team itself quickly came to the realization that the lack of a coding standard was interfering with this new model of work. The religious wars reared their ugly heads once again as an ad hoc committee began putting together a proposed standard. Agreement was impossible. The mindset of everyone on the committee was the same: you can have any standard you want as long as it’s mine.

James Goebel, who helped me in every way to create this wonderful new environment, proposed a solution to the committee. He sent them out to search the web and report back on a coding standard that everyone would agree was the worst possible version of code formatting. This assignment took little time and they gleefully showed James the ugliest coding format anyone had ever seen. Now armed, James pulled the committee aside and declared, “You have 1 day to come up with a standard that everyone can agree with, or I will declare that the ‘ugly example’ will be our coding standard.” It was amazing how quickly the team came to agreement.

That was 10 years ago and every team I’ve managed since then has faithfully and without acrimony adhered to a coding standard. In addition to settling on standards around variable and method names, they typically also find an acceptable auto format feature of whatever IDE they’re using. I often hear my team declare how hard it is now to tell which pieces of the code they personally had a hand in creating.

To those who have never coded, this may seem like much ado about nothing. To those who have coded, this may seem a miraculous achievement. I lean toward the latter. An adopted coding standard means greater ease in bringing new people on board, more flexibility in applying resources to projects that need them, and the practical elimination of Towers of Knowledge.

When the team focus moved from “me” to “we,” coding standards were a natural outcome.