Comments (5)

By Rich, June 21, 2010 10:36 am

I often hear the phrase, “We hire the best and brightest.” It leaves me wondering who hires the “worst and dimmest.”

In order to experience real success every team needs to determine how they can achieve extraordinary results with ordinary people. When I teach our Agile Explained class, I reference the six focus areas of Six Sigma. These include Environment, Measurement Systems, Methods, Materials, Machines, and People. My belief is most management teams first look at the people as the key to solving their most pressing problems.  “If we only had better people things wouldn’t be this bad.”

Don’t believe it. We have good people in our industry. The people in our industry are smart, dedicated, educated, and diligent. It’s not about the people.

When the Standish Group measures our industry and catalogs the top reasons software projects fail, competent staff often falls toward the bottom of that list. This resonates with me.  In fact, the Standish Group suggests that replacing your staff with even more competent people might only move your Successmeter by 5%.  Why? Because we already have competent staff on our teams. It’s not about the people.

One of the most intriguing stories I’ve heard along these lines is the story of the NUMMI Plant in Freemont, California, a joint-venture between Toyota and General Motors. Anyone who is interested in the effect of process on results should listen to this NPR story. This story outlines how in the 1980s the worst performing plant in GM history became the best performing plant.  Same people. Same machines. Same plant. Different methods and different measurement systems made all the difference.

We see the same effects here at Menlo. We often refer to ourselves as a refugee camp from an industry gone very very bad.  We are able to take members of  teams performing below industry standards and quickly assimilate them into our team. Their enthusiasm, energy, motivation, and productivity immediately rise. Same people, different process.

It’s not about the people. As you consider how you might make things better at your company, don’t start by looking at the people. Start by looking at yourself and then look at your process. The payoffs aren’t just in higher productivity and better quality, but also in a better life for you and your team.

We believe it is possible to have joy in software design and development. We hope the same for you.

Comments (0)

By Rich, April 5, 2010 11:19 am

One of our more enjoyable activities here at Menlo are the near-daily tours we give of our space to those who are curious about how we operate. One particularly memorable public tour occurred a couple of years ago. The tours are always highly interactive, with lots of questions and discussion about our unusual approach. This particular tour was memorable because one visitor in particular sat unusually silent throughout the entire tour. It didn’t take me long to notice that this particular visitor was both quiet and passive.

That doesn’t happen very often.

I figured the tour and the discussion just weren’t interesting to him.  Finally it happened. About 2 hours into the Q&A, as I was describing our vacation request “policy”, he blurted out, “Stop! I can’t take it any more!” and stop I did.

I looked at him and said, “What’s up, Scott? What’s on your mind?” He said, “I can’t take it. I don’t want to go to work tomorrow knowing there’s a place that uses this much common sense. I don’t want to believe it exists because it will make my day tomorrow that much more difficult.”

I could see it in his eyes. His passiveness was not about disinterest, but rather about disbelief. I’ve kept in touch with Scott. He has since changed jobs, but I believe he was forever changed by his experience here that evening.

You see, common sense is anything but common. Treating people the way they want to be treated and the way you would hope others would treat you — with respect, dignity, and understanding — is vital. So is acknowledging that they want their work to be meaningful and they want a life outside of work.

The process and methodology we use inside the Menlo Software Factory™ has many industry labels: agile, extreme programming, iterative and incremental, visual, test-driven, user-centric, flexible, even democratic. We have laughingly considered trademarking Common Sense™ as the official name of our process. Quite frankly we don’t really care what it’s called. We are far more interested in the positive effects it has for the people who work here, and how those effects translate into great results for our clients.

We’ve had hundreds of visitors in the last few months who we believe are seeking the same “common sense” that Scott saw a couple of years ago. We are blessed to be able to enjoy this rare “common sense” and are delighted to share it with others.

We’re not certain why it is called “common sense” given how seemingly uncommon it is. Our hope is that we can play some small part in putting the “common” into “common sense.”

Comments (1)

By Rich, February 16, 2010 8:37 am

Visitors to Menlo are often amazed at how excited I get about pairing. You can only begin to imagine how many questions I get about the value and how I justify its cost and how I explain to clients why they would want to pay Menlo to put two people on one computer.

Inevitably a common question arises: “Rich, who do you pair with?”

Quite frankly, up until a few months ago I had only a modestly good answer to that question. I would often declare that James Goebel and I pair in a variety of business development functions, public presentations, and noodling about how to move the business forward. But that was probably nowhere near as good an answer as it could have been as James and I are often so busy we can go days or weeks with just glancing off of each other, much to both our disappointments.

Recently though I did find a pair partner who sits right next to me, sharing a five foot table, much as the rest of my team does with their partners. Her name is Lisamarie and we affectionately refer to her both as “Frau” and “Menlo’s Evangelist.” It is actually her hands on the keyboard right now.

The secret is out.

Lisamarie and I pair in creating this blog. Honestly, this blog would not exist if we didn’t. We have wanted to do a blog for years and somehow we just never got around to it. Lisamarie wouldn’t have felt confident speaking “for Menlo” alone, and by myself I could always find another thing to do, another e-mail to answer, another phone call to make… But we now have committed time to each other to pair twice a week to generate this blog.

Last Thursday I was reminded of the power of pairing. Lisamarie and I had put together a powerful post about Menlo’s (and my) connection with Edison. It’s a story I’ve told for years and I was excited to tell all of you on the occasion of his birthday. We put it together Wednesday afternoon with the intention of publishing it on Thursday (February 11th, Edison’s 163rd birthday).

Did I mention I was very excited?

I spent Thursday morning e-mailing and tweeting and posting to LinkedIn Groups, a very personal and special story. Unfortunately, my pair partner was out of the office. I didn’t need her though, because this was just a simple set of e-mails with a link pointing to the story. Why would I need to pair to do something as simple as this?

I’ll tell you why.

In all of my excitement and efforts, I put out a couple of dozen postings WITH THE WRONG LINK. Ouch.

By the time I discovered this, Lisamarie was back in the office. I’m not sure she’s ever seen me that upset. I felt like an idiot.

Enter the true value of pairing.

I was so upset with myself I couldn’t see straight. Lisamarie quickly calmed me down and said, “Why don’t you just tell everyone that you made a mistake?” She pointed out to me that the biggest sign in our room is “Make Mistakes Faster.” I got the mistake part right. She guided me through the process and text of sending out followup e-mails and the results were magical. I received some very nice notes from people first telling me that yes, they were confused by the bad link, but they also appreciated my humility. That humility was injected into me like pain medication by my pair partner, Lisamarie.

I left that day feeling pretty darned good about getting the story out. Lisamarie left for the day feeling pretty darned good that she rescued me during a difficult moment.

One of our themes when we interview here is that the goal during our Extreme Interviewing is to do whatever you can to make your partner look good. Lisamarie knew I’d made a mistake and she knew I was upset about it. That didn’t distract her from not only wanting to help fix the mistake, but do it in such a way to make her partner look good.

I often walk out of here on a given day feeling very proud of what we’ve created here. Thursday was a very special version of that feeling.

Thank you, Lisamarie, for making your partner look good. (You’re welcome, Rich!)

Comments (3)

By Rich, February 11, 2010 8:00 am

Growing up in Southeastern Michigan, a visit to Greenfield Village was an annual rite of summer for me as it was for many other kids growing up near Henry Ford’s historical park. Two exhibits I found fascinating were the Wright Brother’s bicycle shop and the Menlo Park, New Jersey lab of Thomas Edison.

This youthful experience had an impact on me far beyond anything I could have ever imagined at eight years old.

Zoom ahead to 1999 and the Java Factory at Interface Systems. This radical experiment on my part was a combination of team, process, project management, and workspace.  The entire company at Interface began to take notice, and one day while IBM was visiting, our VP of Sales asked the visiting IBM VP if he would like to see our process at work. It was the first official tour of the Java Factory at Interface Systems. When Ed, the IBM VP, exclaimed to my peers on the executive team that this was the most amazing thing he had ever seen, I became tour director at Interface Systems for every one of our clients, partners, and prospects.

Having a bit of Irish storyteller in me, I began to enhance the tours with little anecdotes. At some point I embellished these anecdotes by commenting that this was exactly the way Thomas Edison worked in his Menlo Park, New Jersey lab.

I had no idea if this was true. I was only recalling those youthful visits to the Greenfield Village recreation of that lab. That was in fact my only connection to Mr. Edison.

Then the NASDAQ crashed, the Internet bubble burst, and for the first time in my career, I was out of work. The amazing experiment at Interface Systems was a great success, but it was no more. I had built a really great engine room. Unfortunately, it was inside the Titanic.

I could build another great engine room. I needed a new ship.

So I got together the people who helped me create it in the first place and we founded a company that would be centered around those principles that we’d had 2 years to archetype at Interface Systems. It was now time to name the company. Recalling my tours at Interface Systems and my references to Thomas Edison, I thought it would be clever to connect our company name to Mr. Edison.

Clever verbal anecdotes on walking tours is one thing. Baking that story into the name of our company, your web address, and your business cards, is quite another. I needed to become a student of Mr. Edison, quickly. I began reading books. I was stunned by the parallels between my experiences at Interface Systems and the experiences of Edison and his team at Menlo Park.

I was now convinced that this was no coincidence, but rather a compelling revisit to one of the most prolific invention factories in the history of mankind.

A couple of years after starting Menlo Innovations, a visitor stopped by. He said, “My wife told me I had to meet you.” I asked, “Why is that?” He said, “You have all these Edison connections and I just wanted to give you a book.”

He handed me a copy of Edison: A Life of Invention by Paul Israel. I excitedly said, “Yeah! That’s one of the books I read when deciding to name the company.” I then had an oh-my-gosh moment when I realized he was the author of the book. He said, “Yeah. I’m Paul Israel. I run the Edison Papers project at Rutger’s University.” Paul is probably recognized as the world’s foremost expert on Thomas Edison. He is dedicating his career to assembling all of Edison’s papers and artifacts.

Paul now visits Menlo once or twice a year. I have had him here with William Pretzer, a former historian at Greenfield Village, and John Bowditch, a former curator of the Henry Ford Museum. I’ve had the pleasure of watching these three men bring Edison back to life as only historians can, while sitting in our space at Menlo Innovations. These gentlemen have confirmed that we have captured the magic of the Menlo Park, New Jersey lab experience.

I’ve also come to know, through this Edison connection, Sarah Miller Caldicott, the great grand-niece of Thomas Edison and author of the recent book Innovate Like Edison. We are honored to be mentioned in this book and I have had the pleasure of co-presenting with her at innovation conferences.

In William Pretzer’s book Working at Inventing: Thomas A. Edison & the Menlo Park Experience, Pretzer describes Henry Ford’s goal in creating Greenfield Village (it’s official name – The Edison Institute):

“[Greenfield Village] would use the past to encourage visitors, especially the young, to aspire to great achievements of their own. While Ford’s goal for the Edison Institute may have been extremely optimistic, it embodies a faith that remains compelling in a society that appears to have lost confidence in its future.”

Menlo shares this vision. The near-daily tours we give are intended to inspire others in our industry who have lost confidence in their future. We also host many school kid visits from pre-schools to middle schools to colleges, seeking to inspire them to great achievements of their own.

Thank you, Mr. Ford, for inspiring the eight year old in me so many years ago. Your dream and your goal are kept alive every day in this wonderful environment we call the Menlo Software Factory™.

And happy birthday, Mr. Edison.

Comments (0)

By Rich, February 9, 2010 8:00 am

People who get to know us often find our mission statement intriguing if not humorous. It is to “end human suffering in the world as it relates to technology.™”

Most of us have had the experience of being tortured by a piece of software and we think it just has to be that way.

It does not.

The most common form of suffering in our industry is that which is experienced by end-users of software systems and products that they must use every day and which they had no voice in designing. This voice-less community typically has this software foisted upon them.

So how do we alleviate this suffering?  What we say at Menlo is that there is something fundamentally missing in the software process. It is the link that connects this voice-less community with homo logicus. Homo logicus are the software engineers who understand how the computer works. The typical user does not care how the computer works. Let me give you a simple example.

We’ve all had the experience when working on an important document or presentation, that suddenly the lights went out or the computer crashed and fear was struck into our hearts because we are now at risk of having lost all the hard work we’ve put in.

Why?

Homo logicus would explain to us that since we have not pressed the “Save” button, the contents of Random Access Memory had not been transferred to the hard drive. Most of us at this point acknowledge that yes, in fact, we are a stupid user.

We are here to free you from that, forever. It wasn’t stupid user, it was stupid design.

There is no reason that a modern computer should ever lose more than one keystroke, ever. Homo logicus would explain that that would make the computer work very hard, and that if we just teach users to save often, they won’t have this problem.

To truly alleviate this pain and eliminate the disconnect between the end users and homo logicus, we need another set of people to bridge the gap. These people need skills not only in observing human behavior, but also of empathy, sympathy, and compassion.

At Menlo we give them a special name: High-Tech Anthropologists®.

Some teams take a different approach. They advocate having the user always in the room. We did not adopt this approach based on two concerns: 1) users that are willing to sit in the room with a technical team all day long are probably themselves “closet programmers”, 2) even if they are “regular users” the Stockholm Syndrome will kick in and they will begin to identify with their captors.

There’s probably a far more important reason though, to observe users in their native environment as our High-Tech Anthropologists® do. This is because most of the information we need to collect is non-verbal.

Let me illustrate with an example from our work here at Menlo.

Our team was engaged by the local county government to design the user experience for the people who man the desk of the County Vital Records Office. People go to this office to obtain copies of things such as birth certificates and death certificates. I happened to see the final designs just before the presentation to the end users. I laughed when I saw them and said something like, “You can’t be serious. Why are there pictures of idyllic beach scenes on the home page of this application?” Our High-Tech Anthropologists® assured me that this was very important. I asked them why.

They described the environment of the County Clerks who handled these requests and when they followed them back to their desks, they noticed the picture post cards on the wall. They wondered if this group was in a travel club. They said, “Nope. We’ve never been to any of these places…”

Why the post cards then?

They went on to explain that as public employees, the public often comes in with the attitude that “I pay my taxes, therefore you work for ME.” And they’re not always nice. They said they used the post cards to calm themselves and to think about being in a far away pleasant place after these stressful interactions. Thus, our team decided to add this therapeutic tool to the screens the clerks would be using when talking to their customers.  The clerks looked at our team, some of them with a tear welling up in the corner of their eye, and commented, “No one has ever listened to us like this before. Thank you.”

The beautiful thing is, of course, we didn’t listen. We observed. We used empathy, sympathy, and compassion to design a great user experience.

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 (3)

By Rich, November 16, 2009 12:23 pm

I’m going to reveal a truth to you that many in business would prefer you not know: Fixed price bids are a lie, especially in IT.

A few years ago I had the opportunity to explore the world of fixed price bids with an architect (a real architect, someone who designs buildings). I told him I was intrigued about “fixed bids” on construction projects as I am constantly challenged by people, particularly those critical of agile, that business requires fixed price bids for software projects. So I asked him, “How does fixed price work in construction?” What he described fascinated me, particularly for government projects.

He said the process is quite simple and straight-forward. An RFP is issued, sealed fixed bids are collected, the sealed bids are opened and the lowest price wins.

Puzzled, I said, “It couldn’t possibly work this way.” He said, “That’s exactly the way it works.”

Applying my engineering mindset, I said, “Then the specs in the RFP must be incredibly detailed.” He smiled and said, “No. In fact, the more ambiguous the spec, the lower the bid.”

I was incredulous, how could it possibly work this way? He went on to explain by simple example: “Let’s say the spec called for toilets on every floor. It didn’t say flush toilets. So we lower the price.” Thinking this through, I said, “That must mean lawyers get involved every step of the way.” He said, “Absolutely. We change order them to death.”

Thinking about this I realized why fixed bids do not work in the software industry. We don’t have the stomach for such conflict. If the spec called for toilets, we’d put in electronic toilets that give us health reports every time we use them.

Herein lies the power of agile: fixed budget projects that focus on scope management in order to achieve the highest possible business value within a budget and time frame. What does it take for this to work? A real and authentic relationship between the technical team and the business team. No longer do spec documents, stage gates, and committee meetings give both teams places to hide while projects spin out of control.

The lie of fixed price bids for software projects starts at the very beginning. A business sponsor approaches a technical team and begins to describe how simple the project is going to be. The technical team does just the opposite. Somewhere in the middle lies the truth, but the clever negotiator carries the day and believes they’ve gotten away with something. Once the negotiation is complete, the sponsor walks away believing they have successfully contained all of the risk of the project. Sadly we have watched this play out over and over again in our industry to the tune of billions and billions of dollars spent on failed software initiatives.

Most people want to believe that a firm and fixed price can be established for an innovative new software effort at the beginning of the project when we know the least. The advent of inexpensive off-shore labor made this problem worse rather than better. Business sponsors, armed with a new, inexpensive tool for software development, paid even less attention to the intermediate artifacts of a project. Let me describe an example.

Menlo was approached to respond to an RFP for the rebuild of an existing system. Our first response was to tell them that we do not respond to RFPs, which intrigued them.  They knew enough about us to implore us to respond. Before we invested too much into a response, we provided them an estimate of effort for the project of between 8,000 and 20,000 hours, based on what they had described. (We were able to do this because we track all actuals on every project we work on. We have 8 years of data we can use to establish comparable projects.) They assured us they had done their own internal estimate and had a prominent offshore firm confirm their internal estimate of 4,000 hours for this project.

We declined to bid.

That project was supposed to complete in six months. I have spoken with them recently and it still isn’t finished four years later. They have invested thousands of hours of their own time doing just the quality assurance on the work performed offshore. In personal and painful discussions with their CEO, he has commented to me, “Rich, I will never choose the lowest bidder again.”

Our experience tells us that our best clients are ones who have experienced this pain somewhere in their careers, often at a former employer who is no longer in business. Designing and building software requires full spectrum engagement and relationship-building that typically does not exist in business. When properly applied, agile gives us that opportunity.

Comments (0)

By Rich, September 21, 2009 11:53 am

As I mentioned in my previous post, my pre-Menlo career spanned 25 years and progressed from programmer to Vice-President throughout that time. It was during that time frame that I lost the joy for what I did as a profession. During that time I began collecting a list of things that seemed wrong to me:

• schedules that never made sense
• long hours and broken promises (both at home and at work)
• projects that never saw the light of day
• software products that were difficult to use
• project scope that was always out of control
• difficulty in adding more people to my team when I needed them most
• senior team members trapped in their towers of knowledge
• programmers surrounding THEIR CODE with gun turrets and razor wire
• coding standards that became religious wars
• code reviews that no one wanted to be at
• meetings that everyone hated
• programmers sitting idle
• programmers with too much to do
• people who ask me to build them X when they needed Y
• QA teams tortured at the end of the process with code that didn’t work
• Tech writers who couldn’t “make” the software easy to use with their manuals
• Trainers who “enjoyed” the wrath of new end users
• software that didn’t meet business goals
• new team members who were demoralized before I could make them productive
• executives who had no idea what my team was doing
• often I didn’t know what my team was doing
• forcing good technical people into managerial roles they didn’t want
• new feature requests that had to wait for the “new architecture”
• the anxiety around crazy customer support right after a release
• the rush to create the service pack immediately after release
• the lack of connection between the technical team and the business sponsors
• and on and on and on…

For much of this time I thought it was just me. I thought I was the only one having these problems. I came to learn through my reading and visits with other technical teams that my story was a common one. It seemed crazy to me that our whole industry was suffering from these challenges. I’ve always believed that software design and development should be a joyful activity. I could no longer find the joy. There had to be a better way.

In the coming posts I will talk about what I’ve discovered in the last 10 years, not only to work on the problems listed above, but also to reveal solutions to problems that I simply assumed were unsolvable. I look forward to your comments and feedback as we go through this journey together.