The agile waterfall

Sounds like a BS post, doesn’t it? Agile processes are like XP, Scrum, Kanban, etc. Waterfall is not an agile process, period.

Well, actually… The agile manifesto values Individuals and interactions over processes and tools. Then, let’s take a look beyond processes!


I’m working in the payment industry. This industry is regulated by the PCI-DSS standard. Among other things, this standard defines the change management processes. Those processes must have several phases like Design, Development, Testing, Implementation (deployment, as the rest of the world knows). The Design, Development, Testing and Operation teams must not overlap. I.e. we must use Waterfall and we must not have devops.

As DeVill pointed out, we have lots of stupid rules that prevent software development. He is right, these rules make our lives a little more difficult than absolutely necessary. However, I prefer to think we have lots of rules that make sure you can safely pay with your bank card. These rules are like the hospital protocols: they change slowly and incrementally. This is the price we pay for safety. I mean, the safety of your money.

Agility – Practices

So how do we speed up development? First of all, PCI-DSS doesn’t dictate the programming practices. We write unit tests. We write tests firsts if we can. When we’re facing a difficult issue, we are pair-programming. We could use a CI server, but for a team of two it doesn’t make much sense. Anyway, none of these things define agility.

Agility – Incremental Development

Agility comes from other sources. One of them is incremental development. We achieve that with small releases. We prefer to deliver stuff that requires at most two weeks of development. One week is better though. Sometimes we can negotiate with the customer to break down the big project into several smaller projects.

Agility – Communication

When we find the business specification too difficult to handle, then we conduct Feasibility Tests. Feasibility Test is a fancy term for several activities, like studying the code base, developing prototypes and playing with the system configurations. You can consider it as an iteration zero that provides prototypes for the so-called “real development”. The point is that the different teams start to communicate with each other as early as possible.

Unsurprisingly, our upfront design cannot always forsee all the obstacles. In this cases we are negotiating with the customer and update the design documentation accordingly. I believe this is the Customer collaboration section from the agile manifesto.

Wrapping up

Basically, that’s all we do. We deliver stuff in small chunks and we talk to each other.


About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in programming, soft skills and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s