Comments (0)

By Rich, August 30, 2010 11:25 am

In the world of private pilots the phrase “Box Canyon” has a special and dangerous meaning. Pilots unfamiliar with local terrain may be enticed to fly into a canyon to which there is no outlet. They find out too late and can neither turn around nor climb fast enough to get out, leading to their ultimate demise.

Sadly, this is an appropriate metaphor for many careers in the tech industry. A recent blog post on TechCrunch discusses Silicon Valley’s Dark Secret: It’s All About Age. I want to offer hope today to avoid this type of Box Canyon in your career.

The seeds of career destruction are often planted very early. Young hotshots are brought in to a project and quickly specialize in a given domain, technical area, or technology. They quickly begin to adopt a strange vocabulary about their career. They refer to themselves by such titles as “front-end developer”, “middleware developer” or “database developer”.  Sometimes it becomes even more specific such as “Oracle developer”, “Ruby developer”, or “java developer”.

Kealy and I recently presented at the Agile Roots conference in Salt Lake City and overheard a dinnertime conversation where two programmers were sharing their titles with one another. One said, “I’m a java developer,” the other, a “Ruby developer.” I looked at Kealy and said, “Isn’t it weird?” She said, “Yeah, why do they do that?” Our two dinner companions overhead this and asked what we thought was weird. Kealy said, “You refer to your job by a kind of technology.” They looked at her with a bit of an eyeroll, “Of course we do! What technology do you work in?” She answered, “Whichever one is right for the project.”

My personal pursuit in starting Menlo was to create what Peter Senge describes as a “learning organization.” There is a profound business purpose behind my goal: I want Menlo to be as relevant 10 years from now as it is today. The side effect of our approach is that every developer on my team is facile in all of the current technologies. This makes them incredibly marketable. The irony of course is they don’t want to leave. Sneaky, eh?

The unnatural competitive advantage this gives me is that I can flex any of my team members into any project without concern for the attributes of their resume. Lisamarie and I reflected that our entire industry is sadly stuck in this Box Canyon. If you look at the way jobs and resumes are posted on such sites as Monster.com and CareerBuilder.com, you will see people who match only specific skillsets and technologies. This perpetuates the problem.

My experience in leading technical teams over several decades is that professionals in our industry yearn to keep up and learn new things. Most never get a chance to do this in their current jobs. They must actually quit and move elsewhere to get these new experiences. It’s hard to even do this because their new employer wants to know how much experience they have with the new technology. It’s a sad and vicious cycle that ultimately ruins careers.

It doesn’t have to be this way. We have witnessed nine years of fun, energy, excitement, and career growth while working in all of the latest technologies. Old and young alike work side by side, transferring knowledge and making the team just a little bit better every day. This is possible for anyone who has the courage to organize their efforts in a different way.

Comments (1)

By Rich, July 28, 2010 2:51 pm

I gave a talk today on creating a culture for innovation. I made a comment during the talk that resonated with a lot of people. During the talk I reflected on a time of great change in my career when I moved my team out of their offices and cubes and into the big open space we called the “Java Factory.”

There was great resistance during this change; however, within 6 months I had successfully changed the paths in the carpet and now the team was far more productive and energized than I could have ever imagined at the beginning. A long time member of my team came to me one day and asked me an important question. He said, “Rich, when you embarked on this program 6 months ago there was no way you knew it was going to work out as well as it did. Why were you willing to take that risk?” He was right. It was an implausible risk for a guy in my position. I had the title. I was a VP. I had the seniority. I’d been there for 16 years. I was well-regarded by both my team and my peers, and yet inside I knew there had to be a better way of doing what we were doing.

After reflecting on his question, I answered, “It was quite simple. I came to a point where I realized that the risk of remaining the same was far greater than the risk of changing.” Once you cross that bridge in your mind, you run towards change and run away from staying the same. Sometimes the risk of staying the same is the far greater risk.

It’s a very powerful moment that not many of us ever get to experience. I was fortunate to be one of the few who did. These last 11 years have gotten me back to where I want to be personally. I’ve gotten back to joy.  I see it every day in this wonderful place we call the Menlo Software Factory™. The energy, the creativity, the imagination, and the innovation are at a level most only dream of. We get to experience it every day.

We’re not perfect, but we typically expose our imperfections more quickly than others and then work on those imperfections. We’re still trying to change the world from our little perch here in in Ann Arbor. The tours we do every day give us a chance to change minds and show people a different approach to organizing teams of people towards a common goal. We want to give permission to everyone who visits to take a moment and think differently about how they do what they do.

If you get a chance, come visit us. We always enjoy the chance to share our passions with others.

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, May 24, 2010 12:03 pm

Many of Menlo’s projects are “start from scratch” greenfield development.  However, some potential clients approach us about enhancing an existing piece of software.  They wonder whether we can work with code our team hasn’t authored.

Early on in this discussion there are two fundamental questions to consider:

Will we know if we broke your existing application?

Will you know if we broke your existing application?

Without straight-forwarded ways to answer these questions, these type of projects can quickly become intractable.   This challenge is not new to agile software development, but an agile approach can expose this problem sooner than other approaches.

There has never been the software equivalent of “national building codes.” There can be no standard expectations when working with a piece of code you didn’t write yourself. This begs the question “How can a team write code that can be maintained by others?”

I often jokingly ask tour visitors, in particular programmers, “How many of you write maintainable code?” Almost everyone raises their hand, some half-heartedly. I then ask them, “How many of you have co-workers who write maintainable code?” Almost none of them raise their hands. That’s when the nervous laughter starts, since many tours include their co-workers.

So what practices can help a team write maintainable code? Some of the practices that have worked for us include automated unit testing frameworks, test driven design, code stewardship, pair programming, continuous integration, and code that is so readable that it doesn’t require comments.

It’s usually at this point that our potential clients are beginning to feel a foreboding as they begin wishing their software was written in a different manner.  “This Old Software” projects can be slow and expensive as you get a new team up-to-speed where they can confidently make changes without fear of breaking something undetectable.

When Menlo takes on these types of projects we look for ways to “firewall” our efforts by writing unit tests around the subsection of code we are making changes to. This gives us a chance to answer the above questions.

Not all software sucks and there can be good answers to the above questions for existing software. It’s one of the reasons we’re so excited to share our approach with others.

We take our mission of “ending human suffering in the world as it relates to technology™” quite seriously. We are spending more time these days interacting with universities and colleges in an attempt to foster new teaching at the beginning of careers in the hope of making a difference in the world. We hope, in some small way, our blog, our books, our classes, our tours, and our enthusiasm might be making a difference in your world too.

Comments (0)

By Lisamarie, May 11, 2010 6:00 am

Awhile back I received an e-mail from a headhunter asking if I was interested in joining their Agile leadership team. I shared it with Rich, then politely declined their offer. I didn’t think about it again until I was talking with Rich later that week.

He said to me, “I didn’t leave work that night worrying that you were going to go because I knew that’s not where your passion lies. And if it is, then it would be right for you to go.” It turned out to be a great launching point for a conversation about what it is that we do at Menlo, and why we do it.

It all starts with Passion. Passion for the work we do. Passion for sharing what we do with others.

When we started exploring all the ways we share our passion, we started scribbling on an index card.

In reflecting on the things we discussed, I have to admit that I was a little surprised. After all, we’re a custom software design and development firm — what does all this other stuff have to do with software design or development? What do we get out of public speaking, tours, books, training, this blog, Twitter, etc… ?

For me, it’s that I get to share the joy and passion I have for my work with other people. Really, it’s that simple.

I’m fortunate in that I’m asked to do a lot of public speaking. I’ve traveled around Michigan, around the country, and even around Canada and Latin America sharing what I’ve learned over the years, particularly what I’ve learned from the Agile movement and how we apply it here at Menlo. Always the reaction is the same: disbelief that work can be joyful, tons of questions about how we make it work, and finally a glint of hope in their eyes as they really start to grok what they’ve heard.

That’s why we write this blog. That’s why we wrote our book. That’s why we tweet. We want to restore belief in joy.

Joy is infectious. Pass it on.

Comments (0)

By Rich, April 29, 2010 9:56 am

At Menlo we combine High-Tech Anthropology® with agile software development. We find that agile teams allow us to deliver our projects faster and with better results – including increased adoption of the software by the user community.

I’m often asked, “Shouldn’t we spend more time writing requirements?” The subtext to this question is “If creating usable software is so important, shouldn’t we spend more time getting the requirements and user interface specification perfect before writing even a single line of code?” The obvious answer would seem to be yes, spend months or years, however long it takes to get the requirements right. Unfortunately, this answer is wrong. Too many times I’ve heard the story of a “year long specification process” that ended in no results at all.

“We had one of those kind of projects”, lamented a student once at a class I was teaching. “We spent $18M and a year developing the specification and when we got done, we threw it away.” Sensing the entrepreneurial opportunity, I quickly responded that I would be happy to write the next throwaway spec for half that price! “That’s only the half the story” he went on. “The first time we spent $30M with the same results.” I asked if the story was really accurate and another student replied “Rich, the real question is, which one of our four projects that failed like that was he referring to?”

One organization spent close to $100M to gather requirements, that resulted in no working system. There are many reasons efforts like this fail. One I would like to focus on today is that fact that many organizations spend too much time and money writing requirements without getting working systems in front of real users. This is one problem that agile software development seeks to solve.

Users vote with their keyboards. If they don’t like a piece of software or if it doesn’t produce better business results, they won’t use it. If user’s don’t use it, sales people won’t be able to sell it (at least not for long). This is also true for in-house IT projects where “selling” the results of the project can still be a difficult proposition.

What we’re ignoring in all of this is human nature. It’s why anthropology is such an important element. Anthropology is the study of human behavior. Without studying the humans, the machines cannot be programmed properly. And we can’t just ask the users what they need, because they can’t always express it. This is an important point worthy of repeating – the users don’t always know what they need! We must observe them and then show them what we discover as we go along. Early on, we may be wrong no matter how well we listen. We may be wrong because the users only discover their real needs incrementally, as we tease it out of them with early mockups, prototypes, and incremental releases. Only as they see and work with real systems will their true needs be fully revealed.

The results can be stunning. We’ve seen competitors literally exit a market upon the release of such a product design effort. We’ve seen users thrilled and businesses achieve a dominant position in their chosen market.

“Shouldn’t we spend more time writing requirements?” No, most of you are already spending too much time writing requirements without getting feedback from real users. Instead, embrace an agile development process that allows you to get feedback by putting real working results in front of real users. This isn’t easy, because it’s so different. It’s difficult to break the mold of our old behaviors. But it is possible. We just need to start acting differently, now!

Be encouraged, be courageous, be strong, and be agile.

Comments (0)

By Rich, April 15, 2010 6:00 am

We win a lot of awards here at Menlo. People often ask us how that happens. My pair partner, Lisamarie, is responsible for making sure that we apply for appropriate awards. That doesn’t guarantee we win, but it sure increases the odds.

We are pleased when we receive recognition for our financial performance. Awards such as the Inc. 500 or the Fast Track Award are significant achievements. We have been called a Michigan Economic Bright Spot and a Michigan 50 Company to Watch, too.

The awards that produce that greatest amount of satisfaction are those that recognize the spirit and culture of our team. These include the Wall Street Journal’s Top Small Workplaces, WorldBlu’s List of Democratic Workplaces, the Alfred P. Sloan Award for Workplace Flexibility, and even a bronze award for our breastfeeding-friendly workplace.

Some ask the value of these awards to our organization. We certainly appreciate the recognition and the team feels a certain amount of pride for that recognition. Sometimes it results in something more. For example, during the last week of March, we received a call from the Light House.

Oh wait. It rhymes with Light House.

The White House invited approximately 60 business leaders from around the nation to join the President and First Lady to discuss important issues around workplace flexibility and work-life balance. We were honored to be part of this group and to be part of an important conversation related to healthy workplace practices. What is especially satisfying about such gatherings is that we find ourselves surrounded by like-minded people.

The discussions covered a lot of topics, but an important theme surfaced. It was simply this: creating a healthy workplace might appear to be costly, but the tangible benefits far outweigh the cost.  Higher levels of employee engagement, decreased sick time, better quality products and services, better customer retention, better word-of-mouth in the community, and overall job satisfaction are just the tip of the iceberg.

At Menlo we see this in many forms. One is our “negative attrition rate.” Some people leave Menlo for various reasons, but often return. When they do, they are even more engaged the second (or third) time around. Another is we don’t employ a separate sales force. (And yet, we have still made the Inc. 500/5000 list three years in a row!) Word-of-mouth is a powerful (and inexpensive) advertising tool. Our best sales people don’t work for us. Often our best proponents are former Menlonians and sometimes, strange as it seems, people who interviewed with us but never got the job.

It’s often the simplest rules in life that produce the greatest results. The Golden Rule of treating others as you would like to be treated is timeless and powerful.

Thank you Mr. President and Mrs. Obama for allowing me to be part of this gathering. Hopefully this is just the beginning of a very important national conversation.

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, April 8, 2010 6:00 am

The software development team at Menlo does not comment their code.

This revelation confirms the greatest suspicion most newcomers have about agile: “Agile means you no longer have to do documentation.” Given the mainstay of our business is creating intellectual property for others, this is often surprising to those who marvel both at our business success as well as the unprecedented level of quality and maintainability of the code we write.

The best way to describe this is to tell a real-life story.

I was teaching our one-day Agile Explained course to an IT team from a large financial services firm.  This firm has over 7,000 employees in their IT team. A question arose about our team’s coding standards. I explained that our team does not comment the code they write.

“If they don’t comment the code, how can anyone maintain it once it’s in production?”

It was a great question and one I decided to let their own team answer. Several students in the class were part of the company’s so-called “break-fix” team. Their job when the code breaks? Fix it.

I asked them, “When the code breaks, I assume you have 3 sources of information to inform your fix. Documents on the shelf. Comments in the code. The code itself.” They agreed. Did they run towards the documents? No. “The documents are always out of date.” Did they seek to understand the code by reading the comments? No. They’ve had too many experiences where the comments didn’t match the code because there wasn’t time to get them back into sync. The only documentation they could trust was the code itself.

We agree.

Our goal is to make the code humanly readable. We do this by using long variable names, long method names, methods that never span more than 1 screen, having a common coding standard that everyone follows, pair programming, practicing code stewardship (as opposed to code ownership), and refactoring mercilessly to increase understanding.

Simply put, no comments does not equal no documentation. The combination of automated unit tests and humanly readable code (created by a team that believes in this approach) results in higher quality and more maintainable code than any other system we have encountered in our careers.

What evidence do we have that this works? We’ve talked about it before: our phone doesn’t ring with support calls and we receive great word of mouth from people who use the software we create. We consider these our best measures of success.

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.