Comments (2)

By Rich, May 6, 2010 6:00 am

A typical question we ask during the project kickoff meeting with new clients is, “How would you define success for this project?”

More than once we have received the same frightening answer: “Oh that’s easy. Success is I get to keep my job!“ This is a neat outcome, but a horrible goal. This answer portends a difficult project, one defined by avoidance of risk, lack of innovation, and ultimately an absent sponsor at the first sign of trouble. A project needs a champion. Carlson and Wilmot said it best in their book Innovation: The Five Disciplines for Creating What Customers Want:

“Each project is driven by a passionate advocate to advance the value creation process. We believe having a champion for each initiative is critical to success. At SRI, if there’s no champion, there’s no project.”

Simply put: No champion, no project, no way.

The “I get to keep my job” answer defines the anti-champion. This is the person who will be there every moment the project is going well, but disappears the moment trouble arrives. These projects will fail. A champion wants to win. An anti-champion wants to avoid losing.

So what should success look like? The simple phrase we use is “widespread adoption.” We choose these words very carefully. Widespread means we hit the heart of the target audience. Adoption implies people love it. We adopt what we love. It makes our lives better. It ends some form of human suffering at the hands of technology. Note that we didn’t say widespread learn-to-get-along-with-it, or widespread I-use-it-because-the-boss-told-me-to, rather widespread I-love-this.

The only way to get to this outcome is by systematically and methodically saying, “No.” No to features that the target users don’t need, no to technology that is “cool” but doesn’t increase value, no to voices who like to register opinions without commitment to the outcomes.

The champion protects their project. The champion nurtures the project in its infancy and stays with it during the equivalent of the terrible-twos and the horrible-fours and even worse, the teen years.

True champions find a great home here at Menlo. Here they find a team that embraces the goals they share. My job as Menlo’s CEO is to either find champions or direct anti-champions to our competitors.  The result is products that thrill end users, champions who are friends as well as clients, and a team that enjoys the satisfaction of someone somewhere saying, “Thank you for making my life better.”

Comments (2)

By Rich, April 22, 2010 6:00 am

Courage is a value important to building an agile development team. Although frequently underappreciated, courage is essential if you want to dramatically improve your team’s performance, and it is actually not all that hard to muster the courage required.

For many years, I managed a software development team the “traditional” way. My software developers did everything, from project management, to interface design, to coding. I relied on heroes and heroic effort as a process. I catered to my heroes and looked to hire more whenever I had the chance.

Then I changed and my team changed along with me.

The change wasn’t easy, wasn’t cheap and wasn’t greeted with open arms by all stakeholders. However, every bone in my body told me it was the right thing to do.

After several months of operating my team under a completely different paradigm, one of my team members came to me and asked: “Rich, where did you get the courage to change everything?” They knew that I was risking EVERYTHING to make this change, my reputation, my role as Vice President, and my job.

The answer was stunning in its simplicity, and may be at the heart of true courage: “The risk of changing was actually FAR less than the risk of staying the same.”

You see, staying the same and continuing to struggle and fail in the same ways also entails risk. It is the risk of building a piece of software that users won’t use and sales people can’t sell. It’s the risk of a project being cancelled in mid-stream with jobs, departments and whole companies being shut down in the process. It’s the risk of losing our entire industry to India, China and Russia.

I implemented and now promote implementing an agile process that includes paired-programming, collective code ownership, co-location, simplicity of design, and metaphor for architecture. Our planning is done on a large flat table top with folded sheets of paper indicating scope. Believe me, all of these practices were controversial to someone.

So, although it took a degree of courage to make the changes I made, it wasn’t actually all that hard. I’d already decided that if I couldn’t improve our process, that if change wasn’t going to happen, or wasn’t possible for some unforeseen reason, then I didn’t want to be in this business anymore anyway. The current insanity that has become our industry just wasn’t interesting anymore.

I submit that in our current environment there is NO risk to change, the only risk is in staying the same. Be bold, perhaps even brave in other people’s eyes. Although it looks like courage, reason and logic are actually driving us to reformulate our teams and our approach to software development.

Each of you has to make your own assessment of the risk of changing. My experiences can help, but YOU must be the one to lead.

There are books we recommend to help you in this change, but ultimately it isn’t what you read that will assist you in making dramatic change. It’s what’s in your heart that will make the difference. And listening to your heart often is the most courageous thing you can do.

Comments (0)

By Rich, April 12, 2010 9:35 am

There’s a common question I get with first time visitors to Menlo. It usually occurs about an hour into the walking tour. It’s something along the line of, “How did you come up with this?” My typical response is that Menlo was born out of 16 years of pain. As I have described in earlier posts, my early career looked quite successful from the outside, but inside I was very frustrated.

Thus began my search.

I wasn’t sure what I was looking for, I was simply convinced that I would know it when I saw it. I began reading many books, but not books on software development, rather books on organizational development, teamwork, and management.

In 1999, it happened. I saw the future and I began running towards it when I was first exposed to the ideas of extreme programming (XP) by reading a wiki by Kent Beck. The final mental tumblers fell into place for me later that year when I saw an ABC News video about a Palo Alto industrial design firm called IDEO. The picture in my head was now crystal clear.

I went to the executive team at Interface Systems and showed the video. When I told them this is where I’m heading with my team, their reaction was both surprising and encouraging: “Rich, how soon do we knock down the walls?” It took six months from that point to transform my team to a new way of working. I got another 18 months to refine the archetype before the Internet bubble burst.

Those two years convinced me that I had discovered a new model for designing and building software. I had built a great engine room; sadly it was inside the Titanic. I knew I could build another great engine room. What I needed was a new ship: Menlo Innovations.

There are many times visitors, unfamiliar with our historical roots, will ask, “Rich, have you ever heard of a company called IDEO?” It’s always a proud moment for me when that happens because I feel we’ve captured the real spirit of a company for which we have great admiration.

Last Thursday, it finally happened. Tim Brown, the CEO of IDEO, stopped by for a brief visit after he gave a talk here in Ann Arbor.

“It feels like home,” was his first comment upon entering our space. It was a proud moment for me and perhaps an important confirmation of the spirit that we intended to create so many years ago.

We still have a long way to go to have the kind of impact that IDEO has had in the world. They continue to inspire us with examples of great design combined with an amazing company culture.

Thank you, IDEO. Thank you, Tim.

Comments (1)

By Rich, March 29, 2010 11:37 am

One of the most common questions we are asked when people are learning about our process is “How do you control scope creep?” Scope creep defeats more software projects than probably any other single cause.

Once upon a time I worked for a company whose CEO attempted to apply “control” in order to defeat scope creep. His rule was a simple one: if any sales or marketing team member was ever caught talking to a software developer, an immediate $50 fee was levied against the sales person. The effect was dramatic. There were no conversations between the business side and the technical side. Problem solved.

Not.

I understand the motivation of such an approach. It’s goal is valid. It’s implementation is awful.

Enter the story card.

Imagine a world where ideas and inspirations can flow freely. The team can speculate wildly about potential new features AND YET they will not vary from the authorized plan. How can this be?

Rather than control, the best way to avoid unintended scope change can be summed up in one word: discipline.  So what does discipline look like in the Menlo Software Factory™?

Each weekly iteration’s tasks are unambiguously chosen during planning game. The tasks are selected collaboratively with the project sponsor. The selected tasks are then posted on a wall near the project team in a public, transparent display. Our team will not vary from this plan during the course of the week. This discipline exists because the team knows that the sponsor will return at the end of the week to see the team’s results.

Our sponsors have been taught the same lessons that our team has learned. There should be no surprises in regards to which tasks were attempted during the week. We go so far as to say if we work on things that the sponsor didn’t authorize, the sponsor doesn’t have to pay for the work. (Note: You can probably guess how many times we’ve done this in the past nine years… Hint: it ain’t many.)

This might feel like control-bordering-on-tyranny, but in effect it creates an unprecedented freedom to operate for our team and our clients. The team knows what’s expected of them. The sponsor knows what to expect from them. All other conversations that generate wild or speculative ideas are simply captured on story cards so that they are not forgotten. Those story cards can be estimated and presented at the next weekly planning game. The sponsor may choose to divert resources away from old ideas and toward new ones. This isn’t scope creep; this is what embracing change looks like. It means being willing to trade away tasks of lesser value in order to allocate resources on tasks of greater value.

This may seem like clever rhetoric for giving scope creep another name. In fact, that can be true. Improperly used, the weekly the planning game can turn into the managerial equivalent of doing donuts in the parking lot. In order for all of this to work, discipline needs to be applied not only by the team but by the sponsor as well.

The desire to follow a process is the most powerful tool that a good process can wield. That desire effortlessly produces the discipline of which most teams can only dream.

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 (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 (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 Rich, December 28, 2009 8:00 am

My first brush with “cheap offshore software development” occurred shortly after the acquisition of Interface Systems, where I was VP. My new boss came to meet with me from California and told me about the success he was having with an offshore firm. He described the low rates and the skilled talent and made it sound like things were going really well. He went on to describe, however, that the projects they work on often fail the first or second time, but because they are 60% cheaper than the US talent, he’s still ahead of the game even after two failures.

I asked him, “What about the time that’s involved? Are we at risk for missing market windows because of the failures?” He said, “Yeah, that’s a problem, but we’re still saving lots of money.”

I describe this approach as a CFO win that leads to a CEO disaster. The CFO feels like saving money is the #1 goal, and therefore this feels like a victory. The CEO is trying to increase top line revenue and market share, and missing deadlines is a disaster.

How did we get here?

I’m sure there have been many papers written and theories espoused about the effectiveness of cheap offshore labor. I will offer my own theory, one that James Goebel and I have talked about often.

Leading up to Y2K there was a tremendous need for extra hands to help with this immutable deadline. Many programmers were brought in from India to help with this gargantuan project. Just about the time Y2K came and went, the IT economy melted down and the Indian programmers were sent home. This story is told quite well by Thomas Friedman in his book, “The World is Flat.”  As things started heating up again, the companies that used those Indian programmers found they could continue using them without bringing them back to the US. I believe this worked for one simple reason: There was an existing relationship between those resources and the teams they worked with here in the US. Once that human relationship was built, it was much easier to work with someone who was 12,000 miles and 12 time zones away.

Somewhere along the way someone leapt to the conclusion that the human relationships didn’t matter and software development resources were a commodity that simply needed to be bought at the lowest price. It might be worth noting that Y2K may well have been the best example of a commodity-like software project, the likes of which we may never see again. This American experiment of procuring commodity-priced software development resources has been going on now for a decade.  About a third of the companies that show up at our door are people who tried this approach. Their statement to me is, “I will never do that again.”

This is not a reflection or judgment on the talent that exists around the world, but rather a statement about the need to create true teams that have personal relationships in order to build complex software. CFO wins probably feel like battlefield victories, but the CEO needs to win the war. In an age of hyper-competitive global markets, bringing a high quality product that thrills end users to market in a timely fashion is the only way to win. There are no short cuts. It’s just plain hard work.

Now go out and win!

Comments (0)

By Rich, December 23, 2009 10:59 am

While we would never even suggest there aren’t competent alternatives to using Menlo Innovations for user experience design and software development, I want to give you some insight on some common “pathologies” we see when people come to us.

Imagine Menlo was the not the first place you approached.  This is often the case with many who find us after they’ve tried one or more other avenues before they discover us.

Here are some common scenarios:

1.  They found a family friend who had some extra time and was willing to work very cheaply or even just for equity.

Common results:

a.  Friend’s life changed in the middle of the project (married, moved to another locale, etc.) and the project stopped mid-stream.  Because the friend worked alone, no one is quite sure where the latest copy of the software is located.  The friend was a brilliant programmer, but not very organized.

b.  Wasn’t actually that good a friend, more of an acquaintance of a friend and the business relationship wasn’t that well defined and now there are serious IP ownership questions.  It’s amazing to us how often the question of “who owns the code” is not an easy one to answer.

c.  Friend was willing to do the work for a low fixed price (say $20K), with half up front and half upon completion.  Things got off to a good start and then the friend stopped returning phone calls.  Then another friend was found who made the same promise.  The same results occurred the second time!  When they approached Menlo, they asked if we would do the same thing.  We said no and informed them it actually looked more like a $200K project.  They were adamant it was a $20K project because these two friends told them it was.  We interpreted the prior behavior and told them them that both friends eventually told them just the opposite when they realized they were working for less than minimum wage!

2.  Competent, well-know India offshore firm is contracted once client realized that Menlo’s estimate was 20,000 hours when offshore firm said they could do it in 4,000 hours.  The client needed the project done in less than 6 months.  India firm promised fixed price within timeline.  That was 4 years ago.  Still not done.  Client has had to invest thousands of their own team’s hours just doing QA testing.  I think they managed to avoid getting the lawyers involved, but it was touch and go.

3.  Friends scoff at Menlo estimate, saying they can do the project in less than 10% of the hours we predict.  We suggest they use those friends.  Friends say they are too busy right now.

4.  Friends point to myriad of open source tools available to make this a project of snapping together publicly available (and free) software components.  After $2M of development to “snap pieces together” project collapses under the weight of the competing bugs in all of the open source pieces.  Its not that open source can’t work … its just not free and you have to decide which of the hundreds of reported bugs you can live with, which ones you will choose to fix yourself, whether you wish to donate those fixes back to the open source community or keep them to yourselves, thereby inheriting the code to extend and maintain yourself, or whether you can simply wait for someone else in the community to fix them.

5.  Friends point to other systems that are already up and working as evidence of how easy this is to do.  We ask for an estimate of the effort to build those other sites and the friends aren’t sure, but they are certain is was easy.

The stories I reference above are real stories we have directly heard from people who have walked in our door over the years.  This is only a small sampling of them as well.

Our goal is not to frighten prospects away from pursuing their own projects. It’s just that professionally building software that works well, scales and is easy to navigate and thrilling to use is just plain old everyday hard work.  There are no short cuts to quality and software is just as hard as any other engineering discipline.

Take heed! There be dragons!

Comments (1)

By Rich, December 21, 2009 12:42 pm

When people take tours of Menlo and learn about our pairing practice, they’re intrigued. When they learn that we switch the pairs every week, they’re astonished. A flurry of questions ensue.

“How do you maintain continuity week-to-week?”

“Isn’t it inefficient?”

“Aren’t you tempted to leave a pair together who are working really well?”

“Does everyone have the same skill sets and knowledge?”

“Are you always pairing a junior person with a senior person?”

“Do you ever have customers who don’t want to pay for this?”

After the initial shock and awe questions above, their ultimate reflection is expressed in the following question: “How do you know this works better?” This is where I reflect on the pain of my earlier managerial career.

When I became VP at Interface Systems in 1997, I was invited to make a product development road map presentation to the Board of this public corporation. As a newly minted VP, the Board members were very excited to meet me and welcome me to the executive management team. One of the longtime Board members came up to me, threw his arm around my shoulder, squeezed it and said, “Welcome aboard, Rich, how’s Seth doing?” I was mortified. This longtime Board member knew the name of one of my programmers and I knew why.

Seth had all the key knowledge about our main product offering. This Board member was delivering a very clear message to me: “Rich, take good care of Seth. Your future here depends on it.” He didn’t have to say that, I knew it was true.

I had been managing Seth for a while and it was clear that no one knew what he knew and that he was always so busy he didn’t have the time to cross-train or mentor anyone else in his area of knowledge. Each time Seth took a vacation, I panicked just a little bit. I hoped that nothing would break in the area of the product for which he was solely responsible.

While many people assume that this is job security for Seth, this “Tower of Knowledge” problem is actually a prison from which Seth cannot escape. Seth was not allowed to join new projects in new technologies, nor could he even easily quit and go to work somewhere else. His new employer would look at the twenty-plus years of experience and want to employ him in the same way we did.

What’s interesting to me when I tell this story on a tour is how many people can easily relate to it. I then ask them if they have a Seth on their team. They always nod yes. I ask them what his or her name is. They can always give me a name. What’s amazing to me is this occurs in organizations both large and small. A Tower of Knowledge is a bottleneck for the organization. I have witnessed dozens of organizations that have allowed their entire development process to be bottlenecked by a single individual. There is often animosity on both sides of this equation. The organization doesn’t like being held hostage by their Tower and the Tower is usually a very dedicated, loyal, long-term employee who gave and gave and gave over the years and is now typically punished for that loyalty by having vacation requests denied and always having to prioritize work over personal and family goals.

It doesn’t have to be this way.

One of the most satisfying aspects of pairing is the ability to knock down these Towers of Knowledge week in and week out. In this way knowledge is spread throughout the team. One of the most tangible effects of this at Menlo is that we have never had to deny a vacation or time off request no matter how long the request or how short the notice. This is true even on our most critical projects at any point right up to a deadline or release.  The result is a happier, healthier, more engaged workforce that produces much higher quality work.

Reflecting back on the question “How do you know this works better?” — I can see it in the eyes of my team members and in the quality of the work we do for our clients.