Comments (5)

By Rich, August 2, 2010 11:39 am

When I tell people the story of the transformation of my old team at Interface Systems, I often comment that problems I assumed were unsolvable began falling by the wayside. One I’ve written about before is the hiring of new people. I actually hated having to hire new people because my challenge was always “how do I get them productive before I demoralize them?”

Completely off my radar screen in those days was the notion of hiring an intern. In my managerial view, the effort to bring an intern up to speed felt both counter-intuitive and counterproductive to ever getting any useful work done.

At Menlo Innovations we bring in at least 6 interns per year. The majority of them come from a wonderful international internship program called IAESTE. At this time of year we are saying goodbye to the IAESTE interns who have been with us for the last year and greeting the new interns who will be with us for the next. I often include a conversation with the interns on a walking tour of Menlo. My favorite question to ask them is “How long after you arrived were you doing productive work on a real project?” Their answer is usually expressed in terms of minutes rather than days or weeks.

When I ask them to clarify for the visitors, they describe walking in our front door, being greeted by Carol (the Menlo Software Factory™ Floor Manager) and then being introduced to their pair partner. Their pair partner pushes the keyboard in front of them and says, “Let’s get working.” It happens that fast.

What is really fun to watch is how fast our team becomes enamored with these bright young minds. They are adopted quickly and become treasured members of our team. It is hard to say goodbye as we just did last week with Judith from Austria, however, the flipside is saying hello to Maruska (Slovakia) and Gary (Hong Kong).  Four more will be arriving in the next few months from Switzerland, Tajikistan, Croatia, and Macedonia.

We often win awards here at Menlo. One quality of many of those awards is our focus on diversity. The IAESTE program gives us an effortless way to enhance the cognitive diversity of our team.

Many who come to visit us assume we hire a steady stream of University of Michigan grads, given our downtown Ann Arbor location. While we have many Michigan grads here, they are a minority. Being a Michigan grad myself, I certainly appreciate the quality of the output of my Alma Mater, but I don’t want everyone here thinking the same way. Drawing from other universities and countries around the world gives us another significant competitive advantage.

The spirit and energy of our interns, whether domestic or international, adds to the joy of the Menlo Software Factory™. Student visitors often lament that torturous conversation with potential employers who tell them “Come see us when you have 1 or 2 years of experience.”

“Where are we supposed to get that?” they wonder. They can get it here at Menlo Innovations.

We are both better off for the experience.

Comments (0)

By Rich, June 18, 2010 10:25 am

I attended the Agile Roots conference in Salt Lake City earlier this week. It had a feeling of returning to an ancestral homeland. While I wasn’t part of the original Snowbird gathering in 2000, I am thankful to the group that gathered there to change our industry.

A tweet after my talk there said, “Impressed by @menloinnovation’s successful long-term record as an XP [Extreme Programming] contract programming shop…”

Yes, we are agile. Yes, we use Extreme Programming. However, neither of those are goals of the organization. They are tools to pursue a dream.

We believe that software design and development should be a joyful activity. For a good portion of my career it wasn’t. It got to the point for me that I either had to change or leave. I chose change.

The group that gathered at Snowbird in 2000 gave me the path to change. Thank you.

The tools of agile, Extreme Programming, Alan Cooper, Lean, Six Sigma, RUP, and PMBOK were simply means to an end. What I desired was joy, energy, creativity, imagination, quality, collaboration, work-life balance and enthusiasm, each and every day. Those tools gave me those things.

I was honored to be able to share those successes and passions with the gathering at Agile Roots. I have had the great fortune of experiencing that joy for the last 11 years. I hope in some way the talks from me, James, and Kealy and Ted will inspire others to chase a similar mission.

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

By Rich, March 11, 2010 11:56 am

Not.

We received a comment the other day on the Do Cubicles Kill post where an assertion was made that one of the key challenges with adopting agile is that you can only make it work with experts. The implication of this statement is that you can’t make it work with mere mortals.

Our experience is just the opposite. We have found more challenges in trying to integrate “experts” into our team regardless of their experience with agile. Given we’ve been practicing agile for nearly 9 years, it’s probably worthy of exploring this topic and reflecting on how we make it work without only experts.

What are the ingredients? Here’s what we believe we do that helps make this work.

We invented and practice Extreme Interviewing. During this process we screen first for kindergarten talents — do they play well with others, know how to put away their toys, do they not swear or bite — then for technical talents. This allows us to be very intentional about our culture.

We practice pairing, all day, every day and we’ve expanded pairing beyond programming. It’s the most powerful managerial tool I’ve ever discovered.

We choose who you are going to work with for each iteration. This was a tool we used when we were first teaching the team the value of pairing. They later came to us and asked us to continue the practice. They valued avoiding the social awkwardness that might happen if they were the last kid on the playground and no one wanted them on their team.

We maintain experts within earshot. We love having experts in various technologies and techniques. We also love having experience on the team. We expect our experts and experienced team members to be good mentors. Our goal is to not have our experts work in their area of expertise, but be available when needed (i.e. they’re working in other domains with their pair partner). This means our experts also get to learn new things, which keeps them growing and learning.

Our weekly kickoffs, estimation, and show & tells ensure that the entire project team has a common understanding of the work being done across the entire project.

The most thoughtful process we go through every week is resource planning. This is where we decide who is going to be on which projects, and who is going to pair with whom. This is an opportunity for us to ensure we’re getting cross pollination across projects, across pairs, and throughout the organization. Essentially this means we get cross-training and mentoring for free, every moment of every day. Most teams dream about “continuous improvement.” We get to experience it.

We practice on-boarding new talent every year through our internship program. We bring in 6-8 interns each year from around the world. This gives us an opportunity to check how we’re doing in terms of teaching our culture and practices to new people.

Finally, this is made a lot easier by co-locating and working in an open space. As we’ve joked before, it is true that we do not use e-mail to communicate with each other, we use High-Speed Voice Technology™. This creates an energy and enthusiasm that keeps all the other pieces working well together.

We understand the concern that many have that agile can only be done with experts. We would never consider building such a process ourselves because of the peril of dependency on individual heroes. For those who wish to see a working alternative, stop by for a tour. Many people do.

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 4, 2010 1:26 pm

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

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

#include <stdio.h>

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

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

#include <stdio.h>

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments (2)

By Lisamarie, November 12, 2009 2:35 pm

Before I came to work at Menlo, I was Director of Development for a small software firm in Southfield, MI. Though I enjoyed the challenges the job offered, and had an absolutely great team, we were all more than a little tortured by the process of creating software.

The cycle typically went something like this:

1. Dev team would work many long hours, late nights, and weekends to meet deadlines
2. Dev team would throw the release candidate over the wall to QA/QC
3. QA/QC would find bugs and throw the release candidate back to the dev team
4. Dev team would work many long hours, late nights, and weekends fixing bugs
5. Dev team would throw the release candidate over the wall to QA/QC
6. QA/QC would find bugs and throw the release candidate back to the dev team
7. Sales team would start screaming bloody murder because of release delays
8. Dev team would work many long hours, late nights, and weekends fixing bugs
9. Dev team would throw the release candidate over the wall to QA/QC
10. QA/QC would find bugs and throw the release candidate back to the dev team
11. Technical support team would start screaming bloody murder because of release delays
12. Company owners would step in and demand release happen, regardless of number of bugs.
13. Release happens. I am not happy.
14. The phone immediately begins to ring as customers find bugs. Customers are not happy. Tech support team is not happy.
15. Work begins on the first service pack to patch the release. Team is not happy as they have to work many long hours, late nights, and weekends…

Sound familiar?

When I came to work for Menlo, my first role was software developer. Now it had been many years since I’d worked as a software developer. The last language I had spent any real time programming in was MUMPS, which was of little help when I came to work at Menlo.

My partner, Aparna, was very patient given many of my “navigator” directions consisted of statements like, “Don’t we need one of those thingies that’s a lot like one of those [pointing at the screen], but different?” Perhaps to call her patient is the understatement of the Century.

Not only was I learning a new programming language, but I was learning about unit testing, too. At the time, I was fairly convinced that it was going to break my brain to think in this new way, but I worked hard to learn. Eventually I came to feel more confident in my rusty skills. Somewhere in that gray matter of mine, a long slumbering portion of my brain was beginning to stir.

Though I could write a unit test, I can’t say that I really understood the point of unit testing yet. I wrote a test (with my partner, of course). Wrote a little code. Wrote another test. Wrote a little more code. Thankfully it was a small project, so I was able to see the process through from beginning to end. After about a week, we were done and released the software to the client.

It was at this time that I started to feel an looming sense of doom. I was nervous. I was a little agitated. I felt like I was waiting for something ominous. Finally it occurred to me: I was waiting for the phone to start ringing.

Except the phone didn’t start ringing. Not the day of release. Not the next day. Not the next day, either.

I was dumbfounded.

It wasn’t until I reflected on the experience with my partner that I really started to understand the power of unit testing. The phone wasn’t ringing because all those red bars and green bars we’d seen during the project meant we’d ferreted out the problems before they ever made it to the client’s hands.

That was a powerful realization, not only as a programmer, but as an executive too. Having seen this same scenario play out time and time again at Menlo — on projects both big and small — I now “get it.” It isn’t about testing quality in at the end, it’s about building quality into the product every step along the way.

We’re not perfect. We do make mistakes. But even after 8 years, Menlo doesn’t have (or need) a tech support department.

And that’s a beautiful thing.

Comments (0)

By Guest Blogger, November 9, 2009 8:00 am

Agile and Project Management
A few weeks ago, I was fortunate enough to attend the Project Management North America Conference, at which Rich Sheridan presented the topic of “Agile, Innovation and the Project Manager”.  Agile is a hot topic, and there were 10 sessions at this conference on Agile versus 2 last year.  But a provocative title doesn’t count for much except to get you in the door.

A Wonderful Surprise – Finding An Extraordinary Presentation and Presenter
You never know what you’ll get at a conference presentation – some are bad, some have modest value – a nugget or two that is new – and a precious few feel revolutionary.  I’m happy to say that Rich’s presentation was in the latter group.  It’s as if you were back in school and heard the parable of the King’s new (invisible) clothes – you had that sense you were getting some true insight that gave you permission to challenge the status quo.  My colleagues and I agree that Rich’s session was among the top two at the entire conference.

Making Agile Work While Invigorating Employees
It’s not only that Rich is an inspiring, eloquent and charismatic speaker, but that he’s made Agile work in an environment that also enhances his employee’s satisfaction.  He’s had the courage to take leaps of faith with his own business, work through the pain points, and blaze trails to better ways of working.  While he may argue that his ways aren’t new – that many are inspired by Thomas Edison’s and transferred to the 21st century, I believe he’s taken Edison’s ideas further and made them work for software development.  So when he speaks, it’s wise to listen.

Possible Solutions for Problems we all Grapple With
Nike, despite its DNA of innovation and “just do it”-ness, struggles with the typical big corporation IT demons – lack of speed, business engagement and quality.  Quality does get achieved, but it requires an inordinate amount of testing resources and time.  So, another colleague from Nike and I followed up with Rich after the PMI session.   And as if our lucky stars were all aligned, Rich was able to visit Nike about two weeks after the conference while out in Portland for some other meetings.

Rich “Rocked the House”
Rich gave a two hour presentation to 100+ people (an excellent turnout on very short notice) and he simply rocked the house.  The energy and buzz were palpable as people got a taste of his vision, humor and insight – everyone stayed until the end and he could have gone on for another hour answering questions.  We loved it and we’ve heard a lot of positive comments from those who attended.  Many more who missed it wish he would return for another round.

So what did Rich say that resonated so strongly at Nike?

• Iterative (Plan-Do-Check-Adjust) cycles allows you to find problems sooner, when they are cheaper and easier to fix.
• Detailed planning is done at the appropriate time – it’s not all front loaded.  It should be iterative and flexible.
• Co-location and the beauty of immediate interaction combine to create energy, ideas, enjoyment and fun. Don’t discount the value of serendipity (through overheard conversations.
• High touch, constant engagement with customers work best. Sponsors meet with Richard’s IT team weekly to “show and tell” the software and help plan the next weeks work – including prioritizing work.  Feedback is constant.  Involvement is high.
• Pairing and re-pairing of resources vastly improves quality, cross training, ideas, communication and focus on specific deliverables, while raising the skill-sets for all involved.  A fresh set of eyes is a good thing!
• Quality at the source speeds iterative development.
• Automated unit testing is vital to iterative development.  Writing the test scripts before coding helps in understanding exactly what is required.  It is a cornerstone of Agile.
• Visualization and tactile engagement can speed understanding.  Simple, non-tech tools can be highly effective when paired with the right behaviors.  Richard demonstrated their non-tech story cards/WBS, status, planning and other approaches.
• Permission is a powerful managerial tool.
• Avoid sub-optimization (which creates “towers of knowledge”).  Build a “learning organization) where learning happens every day, every moment through open communication and sharing.
• Lean and Agile are aligned in many ways.  Eliminating waste is a consistent goal, and Agile can address these wastes in interesting ways.
• Remove waste.  Think broadly about waste – what would it be like to have no email and instead engage in real time communication/problem solving with the appropriate people?
• Standards are necessary at the right levels to increase creativity while building quality in at the source – Agile is not a free for all.