I met a new team member (we'll call him Jerry) in our department today, and he offhandedly mentioned something that blew my mind. We're on the verge of a sea change in my organization, and only now am I becoming aware that the Agile process I thought I'd been doing was actually just a illusion, a mirage in the distance that obscured a regular Waterfall. And I didn't even realize it.
Elakala Waterfall, West Virginia by ForestWander, used under license
Face, Meet Palm
For the entire time I've been employed at my current job, we've had the usual teams of people: development, quality assurance, project managers, business units. That's the way it has been at each of my three jobs, so I'd unconsciously assumed that's just how software development went. Business units write the specs, hand it off to development; development writes the software, hands it off to QA; QA tests the software, hands it back to management; management tells the server team when and where to deploy it. Such is the way it has always been.
In my current company, though, it's been a little different. The software development group here is much more agile than at my previous jobs. Any time we get a set of requirements, we develop iterations, phases, and stories (terminology varies by group) to cover those requirements, and release many versions as needed to get what is desired out onto production servers. We meet with the business units multiple times during this process to discuss what has been done and what there still is to do. All-in-all, from my point of view, we're doing agile development. Problem is, this point of view was severely limited.
A couple of months ago I was trying to explain this process to another software developer, one who didn't work in the same company. I laid out our system, and he immediately responded with "Well that sounds a lot like the Waterfall model." I attempted to correct him, showing that because our development team would iterate over requirements many times, each time figuring out what was wrong and how we could fix it, and because we were in constant communication with the business units, clearly this wasn't the rigid, creaky, old waterfall method. Obviously we were doing better than that.
Weren't we?
That awkward conversation was on my mind when I had a chat with Jerry just last week. I had originally showed up at his desk to talk about what he meant by "acceptance testing" which we were going to be implementing in the near future. Since I know nothing about testing, Jerry launched into this neat summary of what each kind of testing was: unit testing, integration testing, acceptance testing, and how it all fit together and what our company's goals were as far as implementing all of that. It all makes sense, though we've got a long way to go to actually do all of that.
The offhanded comment, the one that blew my mind, was when Jerry said that this organization, the one that I had insisted wasn't using Waterfall, was one in which each department is more or less separate from the others and information is thrown "over the wall" from one team to another. Turns out that there is a term for this: information silos. Jerry pointed out that each time we got a set of requirements, one silo of people (the business units) would pass the requires to another silo (the management), who would pass it along to the next, and so on until the project was released.
Ralls Texas Grain Silos 2010 by Leaflet, used under license
Gee, what does that sound like? I can hear the rushing river from here. We clearly weren't doing better than Waterfall, and I hadn't even noticed until Jerry mentioned it.
An Iterative Pool
Now that I understood where we're trying to go, and how we're going to get there, I started to wonder exactly what we were trying to achieve with our old system, where the engineering group would iterate many times over but the rest of the process flowed in one direction. I still don't know if we ever chose that architecture intentionally (probably not), but I did find out that what were doing had a name: the Lean Waterfall:
Agile, when executed by just the software development team, looks suspiciously like waterfall if the requirements are still being handed over from the rockstar product manager with the business plan, over to the guru designers, then to the agile ninja development team, and finally to the marketing diva.
That was us, to a T. Development was iterative, but nothing else in the flow was, and as such we were not really an Agile shop. We were just an iterative pool in a series of waterfalls.
Jerry's goal is to move us in the direction of true Agile. We're not the biggest company in the world, but we're not a tiny startup either, and so getting this ship of a business to turn in a new direction will take some time and effort. We know where were going now, (aka getting the hell away from Waterfall), but only time will tell if this new course brings us to promised land, or crashes us on the rocky shore. I'd be willing to bet, though, it will be the former.
Have you ever worked in a Silo or Waterfall shop, and did you realize it at the time? Or, have you now moved to a fully Agile shop, and is it really better? Sound off in the comments!
