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!