When asked about what is agile these days, I say: the ability of an organization to produce software that customers want on a frequent basis. It’s very close to principle of the agile manifesto, as you can probably see.

With that in mind, I’d like to take you a trip down memory lane, something like ten years ago. I didn’t know what agile was,  and had to learn about it the hard way. In fact, only years later, I understood what has happened, which was quite a trauma for me and my team. But I’m getting ahead of myself.

I was a software project manager at a time. The software project was part of a very big project that included hardware, firmware, chemicals, and all kinds of stuff. Big multi-year, big bucks project. Our local software team consisted in the beginning of myself and a requirement manager, and later we grew the team with developers and testers. As with a big organization we’ve started from an MRD (marketing requirement document) written by product manager half a globe away, which was later transformed into an SRD (Software requirement document). We’ve developed also a UI spec, all without writing a single line of code.

That’s not completely true . We haven’t written a line of code in the UI, because we knew it would change. We’ve started working on infrastructure that we knew we’d need later. We haven’t heard about YAGNI yet.

We were working along with the firmware team, which was located not far from us. The firmware was developed on another site, where both the communication software, hardware, biology and chemistry were developed. In fact, this was the site where the idea for the product actually originated: a start-up, which was later bought by our big firm. These guys had a burning motivation to succeed (and sold to our firm), for us it was another project. Motivation is important, but not the main point of our story.

Everything was clear – who’s doing what, project timelines and budget, what we needed to deliver. That’s why we were so painfully surprised when the firmware team, out of nowhere, showed the software that our team was planned to build, on our halfway mark. Plus with what they had to build. We had at this time lots of infrastructure work, they had working software.

After that, we’ve lost the project to them.

We worked in a waterfall manner. They were agile. At least according to my definition above. Let’s look at the agile manifesto for more clues:

• Individuals and interaction over processes and tools – We were used to working in heavy process, licensed tools environment. They had no process and open source tools.
• Working software over comprehensive documentation – They got working software with the instrument first. Results count. We spent time on documentation, a lot, time we could actually be spending on building and modifying the software.
• Customer collaboration over contract negotiations – They had a customer on site, no translation needed. For us, every feature would be a new discussions, layers of translation, and sometimes fighting with the customers.
• Responding to change over following a plan – They evolved the software with the instrument. We followed our MS Project plan. ‘nuff said.

We were in shock for about a month. While we were still on contract, that was only for the first release. They continued from there.

For months and years I thought that was unfair. After all, we were working by the book, and they didn’t.

In the end, they worked correctly, we didn’t and that was the important thing.

I don’t want to fail again this way.

Do you?