Fred Brooks’s law of ‘adding manpower to a late software project makes it later‘ is one most of us have tried to prove wrong…….and failed!I was at Agile 2008 and saw an interesting session, “Breaking Brooks’s Law” from Menlo Innovations, a Michigan based Java development company. They claimed to disprove this law and demonstrated their working environment and techniques that allowed them to do so.Although the presentation was only 45 minutes, we were in the room for almost 2 hours asking questions to determine how robust their techniques were, and to gain more insight into the conditions developers work under.Menlo’s results are based on a 3 year project that the customer had a deadline to demonstrate at a show. More features were required for the show than currently in the plan. So rather than re-prioritize, Menlo decided to add more developers to attempt to complete the work. They managed to complete the Project on time with all added functionality.The environment at Menlo is quite unique. All developers are co-located in the same large room (no offices or cubes) and pair program 100% of the time - they follow strict XP practices. A scheduling team determines which projects developers work on and who they pair with on a weekly basis. So developers work with different team members and possibly different projects every week.Also, as part of the contract, the customer comes to Menlo every week to prioritize the work for the next sprint.These techniques may appear somewhat draconian (100% paring for example). I managed to catch up with the team and interview them to discuss this project further, bug rates, staff attrition rates and how Project Managers can push the message of pairing to Senior Managements/Directors (see video).I thoroughly enjoyed talking with the team from Menlo and they invite anyone passing by to stop in and take a look at how they operate. They also have an interview process which involves a large number of candidates performing a number of tasks including Pair Programming, with an appointment you can observe this too. A detailed paper about their techniques and contact details are here.

Last week I was at SD West in Santa Clara, and on Tuesday night I had the privilege to attend Stelligent’s round table event. Around 40 people were there including industry celebrities such as Alistair Cockburn, Neal Ford, Scott Ambler and Jeffrey Fredrick.An hour was spent on the subject: “What is Agile?”; an agreed definition for which eluded everyone (even with this august group in the room).Neal Ford asked people to define agile in two words: “have fun”, “speedy delivery” and “driving quality” were popular answers. Someone commented: “selling the quality helps get agile projects underway.” Andy Glover quickly responded, “quality doesn’t sell! Speed does!”This is an interesting point. At first, the idea of focusing on speed may seem to violate many agile principles. But the speed comes from injecting quality into the development process. At first, teams new to agile techniques will be slower at producing artifacts for the customer because agile often requires a change in culture, which takes time to adapt to. However, the quality built-in will ensure that over time, releases will be quicker as the foundation of the software is a much more robust.Many times we have seen products released too soon, because time to market has been considered the most important factor, but over time code has been ‘layered’ onto this brittle foundation, causing cost to be incurred later, necessitating refactoring (or even completely re-writing) these products.The two words I would use to describe agile are “better communication”. This is something I believe is a constant in any team using agile practices for any length of time. Whether it is pair-programming in XP or stand up meetings in Scrum, communication between developers has improved with the result that (a) most team members are aware of what issues are cropping up in other parts of the project; (b) they have a better understanding of the whole system and the business benefits of what they are producing; and (c) More synergy is created and morale within the team is almost always improved.By the way, the 2008 Jolt Awards were presented at the conference, and our congratulations go to Stelligent as Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall (CTO), with Andy Glover (President) and Steve Matyas book won the Best Technical Book category.