I have not always been agile. Throughout my career I have experimented (or been a part of experiments) with other development processes. However, this mix of success and failure has hardened my learning - maximum learning is generated when the probability of failure is 50%, not when your hypotheses are always correct (Reinertsen, Managing the Design Factory).

Over 15 years ago, I began working for Electronic Data Systems (EDS) on a massive project to replace all of a clients mainframe systems with a new client/server system. You know how the story goes. We used some good methods - we engaged our customer with Joint Application Design (JAD) sessions. However, we also used some poor methods - we developed an enterprise data model with over 1200 entities. We spent years analyzing and designing the whole system. Needless to say, nothing was ever delivered from that project.

A ways into that project, a team of three of us convinced our manager to break away from it and develop a core need component for the customer using another method - Rapid Application Development (RAD) and Class Responsibility Collaboration (CRC). We leveraged services of Rebecca Wirfs-Brock and the team learned Smalltalk. For a month we met at one member's basement and developed our initial architecture. We then proceeded back to the office and developed early prototypes. Within 3 months we had our initial system in front of the customer who was thrilled. The system eventually became the cornerstone of the new services we were providing. It felt good!

I knew there were better ways to develop software. I joined an early-stage company trying to improve it - Requisite, Inc. We developed a requirements management tool RequisitePro (we were purchased by Rational Software in 1997, purchased by IBM in 2002). Our philosophy was that requirements found later in the software cycle were 10x or 100x more expensive than properly documented and tracked up front. Our CEO, Dean Leffingwell, came out of the medical device field and knew the importance of proper requirements.

At Requisite and Rational we had many good methods - we engaged our customers in unique innovation techniques to determine product direction and priorities, we drove priorities by risk, we iterated, etc. We developed and experimented with the Rational Unified Process (RUP). We were also convinced that agile methods didn't scale - you needed a more well structured process. We'll, in my opinion, Rational struggled in scaling with RUP. And if Rational did, so to I imagine, did everyone else.

I eventually left Rational to join another early-stage company to return to agile methods. I also decided to move away from the developer tools space to get a view from the practitioners' side. With Roving Planet, a wireless network management and security provider, I had the opportunity to practice agile methods in a variety of contexts. I recognized early on that we had no tool to help us in our agile release and iteration planning. I hooked up with Ryan Marten's at Rally Software when they were still F4 Technologies (Ryan, I still have your old F4 business card!) and worked with them to develop a tool we could use. I also initiated an offshore development team using agile methods.

At Roving Planet we had some great success, but we also make some mistakes. Being early adopters and market originators, you tend to have more "learned experiences" than others. As the blog rolls on, I will continue to share my stories from past work experiences because I believe that by reading other experience reports, we can help each other without each of us having to repeat the same mistakes.

I am convinced that agile methods provide the best framework for developing the right product and developing the product right. From customer engagement, high collaboration, early prototypes and feedback, shorter cycle times, reducing waste, team empowerment and motivation, and higher quality - agile methods work. However, implementing agile methods that sustain productivity are not easy to deploy, manage, or replicate. That is why I am in the business of guiding companies to find the nirvana of self-organizing, lean development teams. It feels good!