Painful Lessons

DZone 's Guide to

Painful Lessons

· Agile Zone ·
Free Resource
These days, when I'm asked about what Agile is, I say that it's the ability of an organization to produce software that customers want on a frequent basis. This is very close in principle to The Agile Manifesto, as you can probably see.

With that in mind, I’d like to take you on a trip down memory lane, to ten years ago. I didn’t know what Agile was,  and had to learn about it the hard way. In fact, years later, I only understood what had 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 the time. The software project was part of a very big project that included hardware, firmware, chemicals and all kinds of stuff. It was a 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 any big organization we started from an MRD (marketing requirement document) written by a product manager half a globe away, which was later transformed into an SRD (Software requirement document). We had also developed a UI spec, all without writing a single line of code.

That’s not completely true. We hadn’t written a line of code in the UI because we knew it would change. We had started working on infrastructure that we knew we’d need later. We hadn't heard of 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, and 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 had planned to build, at 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 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 a 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 of 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 discussion, 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 weren’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?


Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}