Menlo Tour - How Agile Software Development is Done at Menlo

Last month, I visited a software consulting company called Menlo Innovations located in Ann Arbor, Michigan. Menlo has been using Agile methodologies in their Software Development processes for last eight years. Menlo hosts the tours every month at their company office to show the visitors how they do agile software development.

James Goebel was our host at the meeting. It was a very good experience to see a team of teams doing the agile software development and how they have perfected an unique development process that works for them to be successful in their software development projects.

They use several eXtreme Programming (XP) development and testing techniques.

Here are some high-level details of their agile process:

• Iteration Length = 1 week
• High-Tech Anthropologists (HTA's) write the user stories working with the client and the project team. They write the stories through the eyes of the customers. User designs are also done by HTA's.
• They use big white papers, charts, and tasks with color coded statuses to make the project progress visible to every one in the team w/o having to dig into several different project management software tools.
• Their projects range from 1-day to 4-years in length and all different business domains in nature.
• The Daily stand-up meeting is at 10 am every morning and every one in the building (all project teams, HTA's, QA team, clients, vendors if they happen to be in the office at that time) attend the meeting.
• They review the story cards every day to monitor the progress and identify any roadblocks to complete their tasks. They follow the strict rule of, if there is no card on the board for a specific task, the project team must not work on that task. So, "No Card, No Work, No Money".
• Their revenue model is based on the royalty and partnership based (on some projects) so they take the quality, customer satisfaction, and long-term health of their software products very seriously.
• If a pair has to stop a particular task because of some dependencies or roadblocks, they put a red dot on that task indicating that the work has been stopped on that task, and start the work on a new task (with yellow dot on it showing that it's in progress).
  

Fail Fast:
They believe in the concept of make small mistakes faster and often. James gave us an example of how they managed a previous project in an iterative manner to successfully deliver what the customer needed out of the project. It was a small project with 1-day deadline. The first time they worked on the project, they worked on for the whole day and didn't finish it on time. Then they worked on the same project again in 1-day with great success, the only difference is this time they followed a eight 1-hour iterations rather than one 8-hr iteration. And on the second day, after 2 hours into the project, they found where they got stuck the previous time, and made the necessary adjustment (following the "Inspect and Adapt" philosophy we hear in the context of the Agile project management)

Color coded status tracking:
They use a color coding system to track the status of project tasks.

• Red = Task Stopped
• Yellow = In Progress
• Green = Completed

Projects don't move, people do:
They have dedicated areas (basically a corner of one big office room) for each project where the project tasks, information reports and charts are displayed on the wall. Since the project status reports and other artifacts in a specific area, it's the team members who move to the project area when they need to work on a project, rather than the other way around.

Pair Programming:
Change the partners every week so the pairs don't get used to each other's poor development practices (for example, not writing unit tests).

Test Driven Development:
They religiously follow Test Driven Design/Development (TDD) philosophy.

Build is Broken - Uncommit Your Code:
If someone's code caused a unit test or the whole application build to fail after code check-in, the team has to either fix the build errors in a reasonable time or "Uncommit" the new code so the build will succeed and the other developers can move forward with testing their features on the Integration server.

Time Estimates:
Every one in the project team estimate all the tasks and the project lead uses the most common estimates (by taking away the lowest and highest time estimates). The time estimates range from 2 hours to 1 week (i.e. 2, 4, 8, 16, and 32 hours). If a task is estimated to be higher than 32 hours (e.g. 64 hours), those features have to be split into smaller tasks so they can fit in a single iteration.

They also use different sizes of the paper for tasks with different estimates, so they know how many tasks can fit in an iteration. For example, they use 8.5 x 11 paper size as the 32 hours. And the team can only have use one 8.5 x 11 sheet to fit the tasks for one iteration, meaning they can put one 32-hour tasks, or two 16-hour tasks, or one 16-hour and two 8-hour tasks, you get the point. This approach sounds very interesting and it works great if you think about it.

Every thing (estimations, development, unit testing, show & tell, and the delivery of CD) happens every week.

Show and Tell: For Customer, By Customer:
At the end of each iteration the project team creates two CD's of the working software and gives one CD to the QA team and another to the client. The QA team's job is to verify the health of the overall software package, not just test each feature in isolation.

And when it's the time to demonstrate the software created in an iteration, the team works with the client to install the software on the client's PC and let the customer show (demonstrate) the software product to the team.

They don't really use any software tools for the project management purposes. Other than Microsoft Excel to keep track of the time spent on tasks and the project, every thing else is done on a piece of paper. It was amazing to see how they are able to be agile without really using a tool for writing user stories and other tasks. This is the proof that the agile development teams should focus on the results and not the tools.

Other Observations:
Their software development process is created around the social constructs of the team. For the new prospective team members, they look for the ability to learn and team player skills.

James said that we should ask the following question to ensure that what we are working is going to add value to our company goals:

"How does your job impact the bottom line of your company?"

Conclusions:
They have been following the mantra: "Continue doing what works & Stop doing what doesn't work".

If I have to pick two things that Menlo teams seem to be following, they would be: "Team Collaboration" and "Collective Discipline".

James was an excellent host of the tour and he is also a great speaker. I learned a lot about how Agile Development Process works @ Menlo and apply some of the ideas in my projects.

Like said, it was a very good learning experience for me to be part of the tour and I encourage every one who lives in the southeast Michigan area to sign-up for the next tour which is actually the coming Wednesday.