When people talk about what agile looks like, why it’s effective and that agile is no more than a formalizing name to a collection of methods that were being practiced well before the practices had a name, what does that mean?

It’s 1988. I’m a freshout, having been minted with a CS degree from William & Mary. During college I spent 2 years with an elite group of hackers (in the old school meaning), much of what I learned about teams, computers and software came from a group of about six people. Most of them prodigies in their own rights – at age 16, one successfully hacked admin rights to a unnamed company’s DEC server from a dial-up line, which landed him his first paying job; others went on to receive Ph.D’s and some today run high tech startups.

For a first real job, I decided to find work on UNIX machines, for the simple reason that I was fascinated with UNIX and the hardware on which it often ran. Having played with AT&T 3B2’s, Sun 2’s, a taste of C, scripting and pipes – I was hooked.Fast forward to a number of interviews: I end up at a small company having met a senior engineer over beers; he discovered that I had apprenticed to a Master Craftsman while in college – his father was a carpenter. Six weeks later he called and asked if I was working yet. A quick “no” followed with an invite to interview with the team. When I asked if he needed a resume, he said he knew all he needed to know about me from the discussion about working with the master craftsman. Turns out the guys at this company had hired each other from past gigs. Half way through an interview with two of them, they segue into a heated discussion about the software they are working on. The interview is in suspended animation, as if I’m not there. They were an eclectic bunch – one an artist growing up in Santa Cruz with no CS degree, another blind and having designed hardware and drivers to support computer interaction without sight. Add in others with backgrounds in atmospheric physics, and two that went to high end colleges at age 16 and had masters degrees in comp sci by 22. This is the place I want to be – at the bottom of the totem pole and soaking like a sponge.

Between 1988 and 1992, there were 6-8 people on the team. We built an early BI system involving text search, document image rendering and other capabilities. The data storage on the back end was large for its time, in fact argued to possibly be the largest based on Sun and Arix multi-processor UNIX servers. We also built and supported a OCR pipeline to convert data from paper to digital which was fully staffed and operated 7×24. Given the sensitive nature of the work, data conversion had to be 99% correct – no small feat in 1988. Our search system was a stateless client/server where we wrote software for four platforms – Windows, Sun and NeXT – and the System V server. We created our own build environment, our own deployment and delivery system. We specified, designed and ran 3 hardware/network/storage environments: development, OCR pipeline, and the operational analytic environment which included a data center. 20+ scientists with PhD’s worked with our software.

Coding was some times done side by side with the users. We lived with our users and the consequences of our errors. Making critical recommendations based on data analysis and correlation with our system, the scientists didn’t appreciate errors as it sullied their reputations. We wrote all the data handling software, drivers for optical jukeboxes, the test harnesses for the API’s as well as extensive data validation software. The online operational system was monitored by software we wrote which checked the status of all operational points and provided up-to-date reports.

We designed software with APIs between boundary layers – across computing hardware and functional layers, such as to presentation. This allowed us to support several different client platforms with one small team – that was a feat for those days, when Big/Little Indian translation issues were not yet abstracted out. I spent about one-third of my time writing test code, to verify both data and what software functionality I wrote. I probably spent 20% of my time writing the build and (what we call today) automation environments that allowed us to create, package and deliver software with frequency to production. This was 1989. Agile did not exist. Scrum did not exist. XP did not exist. Six to eight people had to get all this work done and software was a tool not just for our customers but for ourselves.

Our team had a boss. Good guy. We never got an assignment. The team knew what it had to do. We divvied up the work amongst us and went at it. We spent hours pairing up on subjects. Acceptance tests were often written before we ever designed any code, simply so we focused on the target functionality. Never was a core design implemented without someone else looking at it. Not because we had meetings constantly scheduled, but because that was how work was done. There were never meeting ceremonies, which seem so prevalent today in IT Land. Team meetings occurred frequently and informally and were short and sweet. With a group of people all within 20 seconds of each other, communication was fluid and constant, yet not distracting. You knew when people were knee deep (because you knew what was going on). UNIX chat was used by some of us to exchange information while working together from different locations. If someone had to be out of town for a week, one or two people would know the absent person’s code well enough to continue progress and solve problems, albeit not at the same rate of the primary developer.

We loved Post-It’s. Work product was described on them and moved from door to door on the hallway as we worked on items. We dropped software into production every month or two. We wrote designs in e-mails and 1-2 page documents, work snippets on Post-It’s and documented anything necessary from as-built software. Acceptance Test Plans were written in advance – that is, we determined with our customers what core tests the system had to pass before we designed it.

When we had to hire, it was on consensus. If everyone didn’t agree, the candidate didn’t see an offer. We hired the right people as best we could, and as a team dealt with the consequence of being short and carrying the load until Ms. Right came along. The team was responsible for decisions as a team and accountable to one another as a team. We never fired anyone – we didn’t need to. If someone didn’t pull their weight, team members would help them out. If they didn’t come up to speed it was not a comfortable place to be. Not pulling one’s weight and being accountable to a whole group of people, versus just one boss, was an untenable social situation to sustain.

That characterizes my first four years building and running systems. I never knew there was any other kind of work – where one didn’t interact with customers, or build software at their side, spec the hardware, build it, fix it, run it, write test code. The word “done” meant it was in production solving the customer’s problem. My time coding between 1988 and 1998 was always like that. I didn’t know work could be done any other way. It’s only in the latter half of my career that I’ve been to other environments and come to see the more hierarchical (command and control) team models.

So when people talk about Scrum and Agile practices such as Self Organizing Teams, Pair Programming, Test Driven Development, User Stories and say that early agile process folks formalized pre-existing practices and gave them names, lots of people don’t understand what that statement really means. Hopefully the above description gets specific enough to give a sense of what “agile” was like in 1988.