When Agile was rogue

I once worked on a project that was extremely successful, but highly unorthodox. It was an outlier in almost all respects. It was the early 1990s, way back before the internet!

The team was very small. Over years of work the coding team was never more than a handful of people, all physically colocated. The only formal processes at the time were variants of waterfall. The first legitimate iterative processes began to be defined a few years later. The development team was given the choice to define our own process. We were extremely informal.

The absence of structure would be disastrous in most circumstances. However, strong cohesion within the small team prevailed. We rapidly evolved a set of best practices which made everything work smoothly. If it hadn't worked I'm sure structure would have been imposed from above, but as long as we succeeded we could do what we wanted.

The conditions which allowed this to occur were also outliers. The direct manager was Doug, who allowed all this to happen. He had a great working relationship with his Product Manager, John. John had a deep understanding of the industry. Ultimately John came to inherit the development team when Doug moved on to the rest of his steeply ascending career.

The extended team was also very strong. We had excellent technical writers. In addition to creating the introductory documents and user guides for our products, they provided usability feedback and would point out any bugs they noticed. There was an in-house team of users who were excellent beta testers. They provided really useful feature requests.

We were working on a tool set for planning optical telecom networks. The team I was in had tons of experience building planning tools to solve various telecom problems. I was new to network planning, but had object oriented programming experience, which was unusual at the time.

A new technology for fault tolerance called SONET optical rings had just been invented. Northern Telecom had an early lead in optical rings technology, but sales team were having difficulty selling them because the network planners in the customer companies didn't know how to use them.

They came up with the idea of a Ring Planner. It would be a computer aided design tool that allowed network planners to test hypothetical deployments of rings within their networks.

Doug gave the team all the leeway we wanted to make the decisions that mattered to us:

For a programming language we chose an object oriented C variant. C++ hadn't been defined yet, Java didn't exist. Object oriented languages were just more powerful tools, so that choice was obvious.

We chose Macintosh for our platform. The problem and solution are highly graphical so this was easy to justify. This was before Windows 95, so the PC made GUI programming really awkward. The fact that Macs were so much nicer to use and just cooler might not have been mentioned when Doug justified this decision up the management tree.

We had no code repository. We shared code via the network and kept our own copies locally. Any time we did a release, I would back up copies of working code to floppy disks, with dates and version numbers written on them. That way, we could always verify bug reports from the field against an older code base. This couldn't scale, but we didn't need it to, so that didn't matter.

We documented as needed. There was a polished User Guide provided by the technical writers. Code was written to be self documenting. We wrote documents for anything elaborate and clever. For example there was a brief document describing the breadth-first search algorithm, guides for integrating with the persistence framework, implementing undo and redo for new features, etc.

The first release of the Ring Planner was a big hit with the Northern Telecom sales team. They could work with their customers to show them exactly how they could save money and improve the reliability of their network by buying SONET rings.

Many improved releases of Ring Planner followed. We eventually wrote a Transition Planner so that customers could figure out how to deploy more and more SONET ring systems over the years. After all, we wanted them to be able to buy lots of products for a long time. You could even plan to deploy products that weren't available yet. There were variants for other optical standards in different markets as well, since we wanted to sell everywhere.

Overall, the project became one of the most successful ones I was lucky enough to be a part of in my career as a software developer.

Years after I left the project it was still being maintained and extended. I learned this when I interviewed a junior programmer who had worked on the code. He told me my code was very readable, but he tried not to modify it. I was both flattered and dismayed. Code ages if it is not constantly refreshed by those who inherit it. He didn't get the job.

It is worthwhile to identify the factors that made such a highly unorthodox project so successful.

In retrospect, these factors are consistent with the modern way of developing software, in particular the Agile approach. The Agile Manifesto would have been heresy at the time.

Empowerment

The team was allowed to make key decisions on aspects of the project which were important to them. This removed barriers to success. It also enabled the rest of the success factors to evolve naturally. The credit for this empowerment has to go to the leadership team. Minion empowerment only occurs in the presence of strong leaders.

Communication

The team communicated constantly. Since we were colocated we would "scrum" whenever needed. While not prescribed, it would happen at least once a day, usually in the morning.

Egos were kept out of things, and issues were resolved with detailed and substantive discussions.

Continuous Integration with frequent releases

The code was always working. We didn't "submit" code, since there was no code repository. We simply would not share code until it worked. Bugs crept in as they always will, but we never broke anything fundamentally.

When we built something complex, we would get the minimum possible subset working, and then add to it with meaningful working increments. Eventually we had a feature worth demonstrating to the stakeholders. Doug and John would drop by frequently to see the latest features.

When we had a big enough increment to be useful to the internal network planners, they would have a look. If they liked it, they kept it. If not, we fixed it.

Management could make a release externally whenever they wanted, because the code always worked. A little double checking and polish was all we needed to ship.

Nostalgia may have coloured my memory. Nevertheless I cannot report that our lack of a code repository was a success factor. Today we would use git to accomplish exactly the same thing, with less risk and much easier stream management.

Constant feedback from stakeholders

We did regular demonstrations for Doug, John, and the team of in house network planners. Their comments were recorded and folded into the backlog of work to be prioritized.

We also received regular feedback from the sales team and customers via John.

Backlog management

The backlog of work was regularly reviewed. We would organize our work into manageable chunks to plan our next releases. The development team would further break that down into smaller meaningful pieces.

The development team managed technical debt on their own, folding it into the development where it made sense.

Review of practices

When something wasn't working in our workflow or our team dynamic, we would address it early and make adjustments to improve things. We didn't do this formally, but it occurred as needed. Reviewing and adding to your best practices is a best practice.

Cross-functional team

While each team member brought their own skills, we all contributed wherever we could:

Everyone was responsible for quality. When someone noticed a problem, they would make sure it was recorded if they couldn't fix it themselves.

Everyone reviewed the documentation.

Everyone attended the demos, and was free to provide feedback.

Anyone could come up with a feature idea.

Shared code ownership

Developers constantly reviewed each other's code as it was written, and before submissions were shared. Feedback was immediate and acted upon promptly. It didn't take long to say "Hey Gary, does this look ok to you?", and it was quicker than finding out later that there was an issue.

The consensus on any general issues became precedents defining our coding standard. The standard was pretty loose, but it covered what was important to us.

A strong product owner

While we didn't use the term "Product Owner" to describe John, he filled that role. He provided the broad requirements, and any feature requests we received directly were reviewed with him. He prioritized the work from a business perspective. He had a deep and broad understanding of the industry, and sound judgement when tradeoffs had to be made.

Teamwork

A cohesive team who communicate respectfully and frequently is fundamental to success. Each team member should feel personal ownership for the overall quality of the product, and free to suggest improvements anywhere. A diverse set of skills across the team is ideal.

Of course, it helps when the team members are all good individually, but without the other ingredients, you can't have a strong team.

What I learned

The factors I outlined above are key to any successful project. The processes you follow should create these factors, starting with empowerment.

Whatever a process is called, if the factors above are present, the project has a great chance of overall success. Conversely, you can use all the right words and go through the motions of Agile without creating these factors.

The difference is good leadership. Remember, minion empowerment only occurs in the presence of strong leaders.