What do you do when you get a project that’s been going on for a long time and hasn’t delivered value? This is the story of how my team and I collaborated with our customer on my first project, doing agile when the Agile Manifesto wasn’t invented yet, to deliver high-quality software.
My First Project
When I became a project manager my line manager told me that there was a project which he wanted me to finish before getting a “real” project. It would probably just take one or two months to finish it …
Diving into this project I found out that it had been going on for more than a year already without success. The project produced a lot of documentation and some code, but the solution that had been developed failed most of the time. The developers tried to solve the bugs, but that only made it worse. They had big quality problems. The customer was about to give up, as he didn’t believe that the project was able to deliver something valuable to him.
The project manager and the team had been pulled off the project and I was asked to finish it with a new team. I quickly decided that my first priority was to deliver a first working part of the solution as soon as possible, something that we could show to the customer to gain trust. The team and I sat together to divide the functionality in increments.
In the first increment, we addressed one of the main risks so that we could deliver core functionality. We excluded everything else to focus on the problems and were able to deliver a piece of software running on a PC (the application was embedded software for a CNC Milling machine). Something that actually worked!
Our customer was happily surprised when we showed him the software when he visited us a couple of weeks after the project started. He took it back to his company to play with it. The next day he called us, and told us that he had tried it and found out that worked well, except for one situation. Going through the failure on the phone we immediately understood the problem, and agreed that it would be solved in the next increment.
Each increment we added new functionality and solved problems that either the team or our customer found. We would demonstrate the product to our managers, the customer, and anybody else who was interested to get feedback and improve it.
Building a relationship with our customer by delivering the product in increments was beneficial for both of us — resulting in high-quality software. I recall a situation where the team discussed a problem and concluded that there was no feasible solution. It would need very complex software that would deal with lots of exceptions.
I called our customer, explained the situation, and asked him what the system should do. His answer was: “If this happens, just give an error message to the user and abandon processing”. If we would try to execute it, it would damage the CNC machine!
We could have wasted many days or weeks trying to solve it, now it took us less than an hour to find out what the system should do by just asking our customer. In this case, the requirement was to make sure that the CNC machine wasn’t damaged.
Agile wasn’t Invented Yet …
As you might guess from some of the grey hairs that I have, my first project has been a while ago. To be precise, this was in 1990 when I was working as a consultant for Philips. Agile hadn’t been invented yet, there was no Scrum with sprints planning and product reviews. I took the approach to deliver value to my customer in increments because it made sense to me and my team.
To complete the picture: My team was distributed over two locations. We worked at the same site one day each week where we merged the software and synchronized (using floppy disks to transfer source code). We used version control and automated testing, did design and code reviews, pairing, and tried to improve our way of working as much as possible by reflecting and learning from the things that happened in our increments.
All of the projects that I’ve managed or have been working in used increments — I’ve never been in a waterfall project. For me and for the people that I worked with, delivering in increments is the best way to work together. Maybe I’m spoiled, but it strengthened my belief that working in increments works :-).
When I got the early manuscripts from Alistair Cockburn on Agile Software Development and heard about the Manifesto for Agile Software Development, that all made a lot of sense to me. The values and principles are exactly those things that I’ve been doing throughout my career. Now they got a name :-).
I was (and still am) inspired by a couple of people. One is Tom Gilb, I got a lot out of reading his books Principles of Software Engineering Management and Competitive Engineering, both books have great ideas for understanding what your customer needs and how to deliver high quality.
The book Peopleware by Tom DeMarco and Tim Lister helped think about how I could create the best environment for my team members. I also learned a lot from Watts Humphrey regarding viewing software development as a process and finding ways to improve quality.
I started writing down the above story on my first project when I was interviewed by Noopur Pathak for Innovation Roots. It’s a while ago but I still remember how we worked together. Last year I spoke with one of the members of this first team where we recalled how we did it and why it worked. We had some great memories and we’re still proud of the high-quality software that we delivered.
I’d like to hear from you. How did you start with agile? What made you decide to do it? Let me know by commenting on this article!
Originally published at Ben Linders.