As with many innovations in the software business, if you look back in time, you can see glimpses of agile development long before it was “invented”. Even though we did not know of the term “agile development” at the time, the team I worked with on my first project for a software vendor, 25 years ago, was a more agile than many of the teams I see today.
I was the lead developer on an screen-based product that ran on the MVS, a popular IBM mainframe operating system.
Our team consisted of the following people:
- Our boss, who was a subject matter expert and a well-known speaker in the industry, with lots of industry contacts.
- An experienced MVS systems programmer, with some subject-matter expertise.
- Another experienced systems programmer.
- A young programmer of modest experience, but who was extremely sharp.
- An experienced technical writer.
- A secretary.
We were all new to the company, and we all sat together in our own room, separated from the rest of the development organization. We had a four-person cubicle, where the three programmers and the technical writer sat. The secretary had her own desk, and the boss had his own office, just off the main room.
Since our product was screen based, we started out by designing the screens, printing out the designs, and taping them to the glass wall of our conference room. We wrote the bare minimum of code required to display the screens, and mocked them up, using simple scripts to drive them with dummy data. We let a few potential customers, as well as several people from the greater development organization, try out the demo, adjusting things based on their feedback.
As we developed the production code to run each screen, providing real system data instead of the canned data from the mockup, we would replace the script, and mark that screen done in the conference room. Occasionally we would need to reorganize the hierarchy of screens based on the feedback we got. When that happened, we rearranged the pieces of paper taped to our conference room window. We continued this process until we had a shippable product.
Although we were not officially using agile development, what we were doing had a lot in common with them.
- Our boss served as our product owner. He had many years subject-matter experience, and a lot of connections in the industry, so he had a good handle on what the industry wanted.
- We made changes in small increments, demonstrated them to stakeholders, and changed our direction based on their feedback.
- While we did not have an official backlog or burndown charts, the printed-out screens on the window of our conference room, clearly marked when they were done, served as both.
- We met every day to discuss our direction and the status of things. These were longer than 15-minute standups; they frequently happened over a long lunch, and would include discussions of the design of new features. One could think of the design discussions as parking lot items.
- We were all in the same room. The fact that the room was quiet, since we were isolated from the rest of the development organization, and that we were all just one cubicle wall away from each other, meant that one usually didn’t need to get up to ask a question of a co-worker; one could just ask, and receive an answer through the cubicle wall.
What were we lacking?
- Mostly, the fact that we didn’t use formal sprints. What we were doing was probably more akin to Kanban: A free developer would pick a screen off the wall to work on, and usually was not working on more than one screen at a time. So the work-in-progress limit was generally one times the number of developers.
- A formal done-done criteria. A screen was considered done when the developer showed it to the boss (product owner) and convinced him (in other words, demonstrated) that it was done. So what we were doing was actually compatible with agile development; we just didn’t formalize it.
- Automated tests. Testing was done by the developers, but we did not have the capability to do automated testing of screens at the time, and I’m not sure we would have thought of that even if we had had the capability.
- Documentation was treated as a completely separate project, so screens were generally considered done long before their documentation was completed. On the good side, the technical writer attended all of our design sessions, so she could be a lot more familiar with the product than we are used to today, where we just send documentation changes to the writers.
- We didn’t have formal stories or burndown charts. The screens on the conference room window served as both.
- We didn’t do any formal estimation like planning poker. We would look at the screens, guess at the how hard it would be to implement them, and with the boss’s input, decide how to prioritize them.
Why did this work?
- The nature of the product, with its individual screens, made it very easy to create bite-sized stories.
- This was a new product, so there was no legacy code to get in the way of doing things the way we wanted to.
- This was a completely new development team, one that did not interface very much with the existing development organization, so we had no entrenched corporate culture to deal with.
- There were no existing build tools to deal with. The whole build environment was up for grabs, and we could develop whatever we needed to support us, and change it as we felt necessary.
Interestingly, the team became less agile once we got the first release out. We could no longer rely on our screen mockups taped to the wall to keep track of the work to be done, and how it was progressing. We were forced to change to the more traditional release-cycle-oriented model, and had to deal with the existing procedures and facilities for shipping products, and adopt the ways of the existing development groups. And we started having to do technical support as well as development, which interfered with our development schedule, just as it does today.