At Agile and Development conferences this year some sessions have been looking at how to improve Agile techniques using failed projects as examples. Discussing some of these issues and reading blogs and articles it appears that a significant percentage of Scrum projects have failed and it is not quite the silver bullet many expected it to be.In this weeks video blog I asked some of the leading Scrum experts (Dan Rawsthorne, Alan Shalloway, Sanjiv Augustine and Ken Pugh) what they thought the most common reasons for failing Scrum projects is and what advice they can give to resolve this. In their opinion, it appears management and managing the Product Owner are currently areas to improve upon.I believe that many organizations that practice Agile techniques do not strictly follow Scrum, XP, Crystal or any of the other flavors of Agile directly, but instead adopt a hybrid ‘Agile-esque’ practice using parts of these methodologies that they feel work best for their projects. This was reiterated at Bob Martin’s keynote at Agile 2008 where he also stated that ‘Agile’ will be the term used as a practice rather than the umbrella for the individual practices such as Scrum, XP etc. Will this see an increase in Project success? Only time will tell.One opposing theory is; teams will adopt whatever practices they can implement easily and quickly to comply with senior management edicts so they can claim their organizations are ‘Agile’ (whatever that means to them?!?). The reality is, underneath they will really be working in a Waterfall manner with little change to project success.Such proponents of this theory will state that only by following the practices strictly, can you achieve project success repeatedly (as demonstrated by Menlo Innovations).

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.