Agile over waterfall

Agile is the hype these days and there’s probably no single startup which isn’t using this approach right now. In big corporations the adoption is slower, but they are also moving toward it as it simply works. Develop in small steps, measure how well product works so far, move forward or take a step back and fix. Data is really crucial here. Measure how well new improvement helped you with your problem, or measure how it’s made some things harder, as it can go both ways. Correlate the data with how it was before and make a judgment if it’s the right way.

Recently I’ve written very basic tool to solve simple problem. It’s stripping leading whitespace characters and empty lines from given text file. It helps to save some time and money on printing emails. It’s not a perfect tool, but it’s brought measurable improvement. And yes, sometimes it’s not sufficient and manual editing is still required. However it’s still better than manually editing the whole file. It simply saves X minutes per each file, so it quickly adds up.

Waterfall is opposite approach. Do everything in one go, no feedback during development, no measurements. Simply put, “make it perfect on first try”. Problem is, it’s never perfect. But some people like this approach better.

Some time ago I’ve created a solution to some problem, more complicated than the one mentioned above. It wasn’t perfect and it wasn’t most convenient, but it’s done its job. But it was scraped because “the feeling” was that it’s more work this way. It’s just a feeling because there’s no data supporting it. And I seriously doubt that additional task at the beginning is more work than occasionally copy/pasting quite substantial parts of text scattered through different parts of file(s). And then doing it again on output. My solution required no manual effort on output. But again, there’s no data, so I can’t be certain. Maybe it was more time consuming.

Question is, should decisions be made on gut feeling or real data? I’ll vote for the latter. And believe me, I wasn’t a supporter of agile way from the start. Quite contrary, on first approach I’ve refused to use it as I’ve found it unsuitable to my needs. But it was just my lack of understanding of the concept. I’m not saying it is perfect, but it’s definitely better than waterfall. However the improvement won’t start until people won’t change their mindsets, and I have little hope for that.

I’ve read an interesting article on how they’ve applied agile methodologies in one of the Polish banks. It was full of examples how small, iterative improvements helped the team gain substantial savings in both time and cost. Not a single solution was full automation, at least at the beginning, but helped people to reduce their effort. And this is how automation should be approached. Not as binary, either fully replaces human or is considered not working. But as something which is supporting human effort, saving him few minutes, or even seconds, here and there which adds up to hours or maybe even days of savings in the long run. If we won’t approach it using small steps, we won’t get there, ever. Especially in environments with complex processes where only after few tries you grasp the full concept.

One of the reasons why companies are now using short iterations instead of long waterfall style development cycles is that customer rarely knows what he wants. And it’s OK. We’re all humans, processes are complicated and it’s often hard to grasp the whole picture. That’s why it’s better to develop small, even partial solution to single problem in the process. Than to try improving whole process in a single run. If customer will provide feedback after first iteration then in the second one product can be improved. And maybe after 3 or 4 (in reality more like 30-40) it’ll be almost perfect. Almost is good enough, I’m too old to believe in perfect things anymore.

I’ve worked at startup once and I’ve hated it. But one thing they were doing was simply brilliant. Periodically they’ve gathered members of entire team, confronted them with outsiders, and asked to map all of their processes in usual production cycle. Complete with how much time is used during each step. Once bottlenecks were identified the focus was put on removing them. Such approach should be used everywhere, because throwing more people at the project won’t really provide efficiency if you don’t fully understand what’s slowing you down. And sometimes problems with your process are hidden from your eyes, as you’re too used to doing it this way, hence opinion of people outside of your project helps. Don’t take pride from doing a lot of manual work! Try to automate it, even partially! If your idea of job security is to not evolve, but to simply work harder, which is often just appearance, you’ve already lost anyway.