Creating Scrum
My first job was at Litton Itek Optical Systems in Lexington, Massachusetts. Itek's business was mostly defense oriented (This was true when I was there. During the 1970s and 1980s Itek was a much larger more diversified company). The most I can say is that Itek built land and space-based reconnaissance systems. This was during the Regan Star Wars craze. There was lots of money being spent on lots of esoteric research programs. There technology and tools were very cool, and I had the opportunity to work with some of the very brightest scientist in the world. It was a very fun place for college grad to land. This is where I cut my teeth on software technology and process. I saw first-hand how software could be harnessed to do amazing things and I learned how important quality and reliability is. Bugs in my software could do millions of dollars in damage and in worst case scenarios injure or kill someone. While we weren't practicing test-first development, the attention to process and quality was acute. My accomplishments in this area were recognized by senior management and I was assigned to a team responsible for defining and deploying software methodology and standards. As a result, I learned more about TQM, DOD-STD-2167A, and ISO-9000 than any 25-year-old engineer should! While the intense technical environment of defense-oriented engineering was very rewarding, I left Itek in 1991 for Easel Corporation to learn a bit about what this business application stuff was all about.
Easel Corporation was a small software tools company located along the 128-technology belt in Burlington, MA. I started off in there consulting organization. There, I was immersed into their Fortune 500 customer base and got exposure to an amazing variety of business systems and applications. I worked in the field for three years and in 1993 I came off the road and joined engineering to lead a team of Smalltalkers that was blazing a trail on the bleeding edge of software technology and process. Client-server development was the rage, and several vendors were developing tools at a frantic pace. We could see the PowerBuilder office across the street from us. They we're bigger, better funded, and we could feel the heat. PowerBuilder chose the 4GL approach. Point, click and watch your application go. We wanted to do it right. We wanted to do it with objects. We did it right, PowerBuilder ate us for lunch.
The ride was fun, and we learned many lessons, some of them painful. The highly productive Smalltalk development tools and environments we were using allowed the developers to churn out features at an incredible pace. This allowed for rapid time to market and allowed the team to explore (prototype) many different alternative approaches. Analysis and specification were just not practical when it was quicker to just code it. The developers loved it. The testers hated it. And other downstream disciplines, like technical documentation, were just in a mad scramble trying to keep up. In retrospect, it now easy to understand why it had to be this way. The speed of development and innovation was so great that other non-code-oriented aspects of product development were left in the dust.
I had the great fortune to work for a very supportive boss, Jeff Sutherland, who took a keen interest in not only moving our products and technology forward, but also the process we employed to construct the software. Additionally, we employed Jeff McKenna as technology, process and business consultant. Jeff McKenna's involvement with Smalltalk and object-oriented design since the early 1980's was invaluable in determining our technical and process approaches. Together, we developed an agile software development approach we called Scrum.
Comments
Post a Comment