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.
First Delivery
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.
Collaboration
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 :-).
Agile Inspiration
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.
Interviewed
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!
In the early 80’s I worked for a small company doing mainframe 4GL product development. One year, it was decided to do a major overhaul of the query/reporting side of the product. It would be shown to customers at the annual customer meeting the next Spring (about 10 months away).
There were four of us (developers) working on this. We had our own office but were no more than about 30 feet away from one another. There was a lot of back and forth each day and sharing of code/ideas, but something different from other work was that the four of us met each week with the tester for the effort, the tech writer doing the user documentation, and the marketing lead for the work. This was a review of what we had accomplished that week, a discussion of our next steps, and information from the marketing lead about feedback from customers based on release of information about the high-level plans for the release.
We ended up basically rewriting everything in the query/reporting part of the system and finished a couple months ahead of schedule (no significant overtime was involved) allowing us to add some further features the customers weren’t expecting. It was my most memorable development experience (though I had other good ones). After doing some natural language query work, I left that company and got back into a couple strictly phased-sequential (waterfall) environments.
About 20 years after that early 80s experience, I read “eXtreme Programming Explained” by Kent Beck and encountered the Agile Manifesto that had been released the year before. That prior experience suddenly clicked with me. We weren’t really practicing XP or all of what the Manifesto recommended, but it seemed like a lot of it. My first experience really trying to apply Agile ideas was with a marketing team not doing software at all because where I worked (as a traditional process/metrics consultant) didn’t want me messing with the actual software process.
One year later I left, started working for a very small consulting firm doing regular software quality training/consulting, and began studying Agile frameworks and practices. A year after that I got my CSM by taking a class given by Ken Schwaber and Mike Cohn. I’ve never looked back after that so it’s been 14 years of taking an Agile approach to my training and coaching enriched by many of the good things about traditional quality and development ideas I’ve learned throughout my 46 years in software.
Thanks Scott for sharing your story on how you started with agile!