Agile before it was cool

In the 100th episode of This Agile Life the hosts talk about their first experiences encountering Agile development and how they first used its concepts without knowing it. Musing about the start of my career in IT, I realized that I too first used concepts of Agile and Lean software development years before I even heard those terms. Usually, when people ask me how I learned about Agile, I say that it was at my current job about 5 years ago. Well, I’ve been lying all this time. The first time I applied Agile concepts to software development was a full 12 years ago at my first job out of university.

I graduated in 2004 when the job market wasn’t at its liveliest. I thought very little of my own skills (a topic for a different post) and basically had no idea of how to go about finding a job in IT. After a month or so of futile searches I got a job through an employment agency as a temp office assistant at a small department at the Ministry of Health. I had to answer phones, make photocopies, file and do other routine office things.

Bureaucracies are renowned for being inefficient, slow and lazy. At this department, though, there was always plenty to do and the six people working there rushed around to finish their commitments by deadlines. They were responsible for distributing funding for research projects in the province and a large part of their work was reviewing proposals from various organizations. I would start this process when I unpacked a document and put it in a thick folder to which I attached a piece of paper that listed stages with checkboxes to be ticked as the document travelled through the office. Sometimes a folder got lost, I’d look for it and eventually discover it buried on someone’s desk, the person blissfully unaware they even had it or filed away without anyone knowing.

This system wasn’t a complete disaster and it wasn’t like anyone’s life depended on it, but it definitely could be better. Since my duties as an office assistance took only about half of the time I actually spent there, I decided to program a system to track these documents.

Customer collaboration over contract negotiation

The manager of the department I reported to was up for it if I could keep doing my actual job. She agreed to provide input and to let the department use the software if it made them more efficient. The others were willing to try whatever I built, but they were cautious. After all, I was an office assistant – not a big time, expensive consultant.

For the first time in my career I set about figuring out how to solve a real life problem for real customers. My project had some interesting features:

• No budget other than the time I was willing to put into it
• No upfront requirements or scope
• No deadlines or release pressures
• Real customers a few steps away
• Cross functional team (me)

I thought I was doing it all wrong. I imagined that I should be spending a long time collecting requirements, getting approvals, designing the architecture, writing code, testing, etc. Instead, I had to quickly build software my customers would want to use.

Individuals and interactions over processes and tools

I had a lot to figure out but the only way I saw to succeed was to start small. I refined my overall understanding of the problem by talking to my co-workers and decided to mimic the paper based process through a desktop UI that would store the data in a centralized database. I sketched out the lifecycle that documents went through and a simple UI. Since there was no one to approve this plan, I approved it myself and moved on to the next step: implementation.

Here I ran into an issue: I had plenty of theoretical knowledge about writing code, databases and UI design, but little idea about how it all fit together. I needed expert help. Luckily, my dad is a programmer and has always been very supportive of me. He enjoys coding and is a great mentor. So I recruited him to be a sounding board for my ideas and he helped me work out the technical details.

Working software over comprehensive documentation

I spent a couple of weeks coding in between answering phones and at night. Soon, I had a working prototype. The backend ran on an Access database and the front end was a VB form. I demoed it to my clients and they thought it was the coolest thing ever. They gave me feedback and asked me to change a few things. Overall, they couldn’t wait to use the software I wrote! I was even more excited than they were!

After a couple more weeks of refining, testing and fixing bugs, I was ready to deploy. Now came the really hard part – I had to figure out how to install this stuff in a government organization. After a bit of haggling with IT, I put the app on people’s machines and got the database up and running. In a matter of weeks I achieved the stage many software projects never live to see – I was in production!

Responding to change over following a plan

Of course, more bugs surfaced once people were using my app on a daily basis and more features they wanted to add or change. I ended up deploying another two or three versions, but none were disruptive or lost information. The crucially important thing was that customers liked using my product and saw the benefits. It solved a real problem for them, was easy to use and was reliable. And they got it in a matter of weeks for very little cost.

I didn’t know about Agile or Lean software development and yet that is exactly what I was doing. I used common sense to get the best out of limited resources available to me with a lot of motivation and got great results.

Despite all this the next project I worked on at the Ministry of Health was a total failure. Why wasn’t I able to extend my successful execution to the next stage of my career? I will write about that in my next post.