Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, starting out with Logo turtles. With more than 15 years of developing commercial software, he has vast experience in software methodology and practices. Gil is the product manager at Typemock, working as part of an agile team in an agile company, creating tools for agile developers. He promotes unit testing and other design practices, down–to–earth agile methods, and some incredibly cool tools. Gil speaks locally in Israel and internationally about unit testing, TDD, and agile practices and communication. And in his spare time he kills dragons, for fun. Gil blogs at http://www.gilzilberfeld.com on different agile topics, including processes, communication and unit testing. Gil is a DZone MVB and is not an employee of DZone and has posted 60 posts at DZone. You can read more from them at their website. View Full User Profile

Painful Lessons

09.12.2013
| 7661 views |
  • submit to reddit
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, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)