Comments (0)

By Rich, March 4, 2010 6:00 am

In the previous post we began to explore the question of “value” as it relates to our practices. We left off a second part of that e-mail exchange with a recent visitor. Today we will explore the other aspect of the exchange. Our visitor stated:

…There are two objectives in business. One is to make money which is directly linked to the metrics. The [other] is employee satisfaction which probably ends up with more profit eventually…

I responded:

I enjoy business philosophy discussions as well.  Our focus of attention (the only real metric we are concerned with) is the “widespread adoption” of the products we build for our clients.  This denotes true value (i.e. we worked on something and someone thought enough about our efforts that they were not only willing to pay money to buy it, but they also found so much value in its use that they actually ENJOYED using it!).  Our assumption is that profit will fall out of this equation as a natural by-product.  So far, so good.  Eight years in business, eight years of healthy profit (in Michigan! with almost entirely Michigan customers! all Michigan-based talent who enjoy competitive pay and great benefits).

To reinforce the above point, I’ve captured below an unsolicited testimonial from the customer of one of our clients. I can’t think of a better way to express value for our efforts than the quote below from a happy user of the Accuri C6 flow cytometer and the CFlow software Menlo created for Accuri.

…You guys have done an AMAZING job so far, the Accuri software is wonderful.  I have passed along some suggestions to Grant as I find little bugs and quirks that need fixing, but as a first time out of the box, it really is a home run.  I’ve been in the field for longer than I would like to admit and have seen some pretty horrible software over the last 25 years!  Please pass on my congratulations to everyone on your team.

Kind regards,
Steve McClellan
Senior Biological Scientist
University of Florida
Interdisciplinary Center for Biotechnology Research(ICBR)-
Flow Cytometry Core Laboratories

Thanks to Steve McClellan and Accuri Cytometers for giving us permission to use this quote. Quite frankly, it made our day and we’re glad we can share it with you.

Comments (3)

By Rich, March 1, 2010 1:13 pm

Even the most skeptical of our tour visitors sense both our passion and our enthusiasm for what happens in the Menlo Software Factory™.  However, a common question they ask is, “Do you have any data to show me that this actually works better than traditional approaches?”

I must admit my first reaction to this question is usually an unspoken emotional response along the lines of “You’ve got to be kidding. Can’t you just see the difference?” Sometimes it moves from emotional to reactionary as I want to ask them, “If I collect the data and show it to you, what will you compare it to in your world?”

I never actually verbalized either of these emotional responses and it wasn’t until last week when I received another version of this question via email, did I actually go and get some data and report it back. I thought you might enjoy peeking in on the interaction:

Hello Richard.

…  I would be interested in any metrics you may have collected on your teams performance. Such as defect rate (defects per KLOC [defects per thousand lines of code]) and output performance (i.e. lines of code per day).

To which I responded:

Interesting question about lines of code per day.  As part of our engineering practice, we actually value fewer lines of code rather than more.   By analogy, it is like the old quote “I was going to write you a short letter, but I didn’t have time, so I wrote you a long one.”

We often are able to add features by reducing the number of lines of code.  Counter intuitive, but powerful in both elegance, simplicity and quality.  Fewer lines of code to maintain, fewer “moving parts”, etc.  The other interesting statistic is that about 50%-60% of the “lines of code” we write are automated unit tests which are written BEFORE we write the production code they are going to test.  In addition to this being a phenomenal automated test approach, this is also a powerful act of very intentional design (i.e. you can’t devise a test strategy without conceiving the design of the code and that design most be modular so that it CAN be tested).  These lines of code are not shipped with the production product.

Regarding defect rate, I asked one of our project managers to take the total hours of one of our larger projects and separate out the number of hours spent working on “bug” cards.

Here’s the calculation:  669.25 hours working on bugs divided by 17,592.50 hours working on all (features and fixes) development.  Total percentage of time working on bugs is 3.8%.   Thanks for asking the question, as we’ve never had one of our clients ask for this.   Even I was impressed with the result!  I am going to ask this question of our other projects.  Happy to share those answers with you if you like.

Hope this helps.  Best wishes to you as well!

I’d be interested in hearing your thoughts on these performance metrics. What measurements have you done to demonstrate the effectiveness of your team? What measurements would you be interested in hearing more about?

Comments (10)

By Rich, February 22, 2010 1:19 pm

This morning during our Open Book Management meeting, we were reviewing the “Number of Visitors to Our Blog for the Past Week.” It was 254 visitors.  James prodded the team about ways we could get that number over 300 on a consistent basis.

It generated an interesting discussion amongst the team about our blog and blogs in general. Questions like What makes a good blog? Do we know who comes to our blog? Do we think our content is interesting to anyone other than us? One team member asked, Should we ask our visitors for feedback?

That seemed like a really obvious thing. So obvious, we completely overlooked it.

So here we are.

We would love to get any comments, short or long, encouraging or critical. The key question we want to ask is this: As a visitor to Menlo’s blog, are you getting value from the content?

As our thanks to you, we will randomly choose 5 people (from those who comment) to receive a free copy of our book, Innovative Exploration: A Visual Tour of the Menlo Software Factory™. In addition, one lucky commenter will receive a complimentary seat in an upcoming Agile Explained class at Menlo Innovations in Ann Arbor, Michigan (a $675 value).

Thank you for your help with this!

Comments (2)

By Rich, February 18, 2010 7:00 am

We hate meetings.

I often describe Menlo as a refugee camp for an industry gone bad. Approximately half of our team has worked a substantial portion of their careers in traditional software development environments. Menlo is anything but traditional.

As we described in an earlier post, our open and collaborative work environment often gets a “Wow!” reaction when people arrive for the first time. They notice the lack of barriers, the noise, the smiles, the energy of our team. Most wrestle with the idea that software development can actually be done in such a noisy environment, but they are intrigued with the focused energy they see as they look at my team.

At some point during the walking tour, I demonstrate our all-company meeting technology.

“HEY MENLO!”

“HEY RICH!”

And the place goes dead silent in an instant.  All eyes are pointed at me as they wait to hear why I have called this particular all-company meeting. No one has left their chair, no one has gathered in a conference room, everyone is sitting in rapt attention waiting for the meeting to begin.

I then use this opportunity to introduce our guests, and end the meeting by thanking the team for their attention. They go back to work and total meeting time is less than 20 seconds.

This all-company meeting technology is not for me alone. Anyone on the team can call an all-company meeting at any time. I’ve even had guests brave enough to try it themselves.

Just so we’re clear, this type of meeting happens less than once a day.

As I’ve said before, I know when I’m connecting with my tour visitors when they groan and laugh at just the right moments. This is usually one of those moments because they are contemplating the cost of an all-hands meeting at their company. Our meetings are started and over before most companies could get everyone gathered in one room.

It’s at this point that visitors are beginning to grasp the power of what they’re seeing. They cannot yet imagine the cultural shift that would be required within their organization, but they are already beginning to think, “I want something this powerful where I work.”

We use this same technology when calling project team meetings. “Hey Dawson!” is the way to call a meeting specific to everyone working on the Dawson project and everyone else in the room ignores the request and continues working.

It even works on an individual level. “Hey Carol!” is the way to call a meeting with an individual — though two people are unlikely to continue to yell across the room, and will instead come together after the initial “call.”

There are many components to “Hey Menlo” meeting technology. A big open room, with no walls or cubicles. Air. Vocal cords. Tympanic membranes. Auditory nerves. A team that is willing to work in such an environment. It’s powerful in both its efficiency and its conservation of team energy.

Stop by for a visit and I’ll show you how it works.

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 (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™”.