Reconciling “agile” and “traditional”

by , under Uncategorized

This is a question that I get quite often: how do you reconcile the new agile processes like Scrum or Kanban or new approaches to product development (like Lean Startup) both based on empiricism with old, traditional, prediction based project management methods?

It seems hard because the traditional approach is all about planning & execution as planned whereas the whole “New Wave” is focused on adaptation and shuns planning (some gurus of this movement even called planning a “waste”).

But it also seems hard because agile methods are usually “sold” by contrasting them with the traditional “waterfall” and its failures. As part of their pitch agilists do sometimes even portray project managers as “evil”. To be fair, there is a fair amount of FUD-based pushback from the other side. None of this helps. The two approaches seem mutually exclusive, set to battle each other until the better wins.

But I think that in the real world both quite frequently have to coexist. Here are two ways of looking at this problem that I hope will be helpful.

Tools

It is helpful to try and stop looking at processes, methodologies etc. as being “evil” or “good”, “stupid” or “smart”.

Each and every one of them evolved in a certain environment and context with best of intentions. Probably each did work for some problems and some people – otherwise no one would try to reapply it. That – say – the classic waterfall is an utter failure in software development doesn’t tell us it is a stupid approach. It just tells us it doesn’t work well in one industry, with a particular type of work. It still may work pretty well somewhere else, it works pretty well in civil engineering for example.

What is important here is that once we realize this and stop looking at methods emotionally we may discover that they are just a set of tools. Tools that may be useful no matter which “camp” they come from. This is how a pragmatic manager should view them.

An example I like to make is the Gantt Chart. It is seen by many ‘agilists’ as something akin to the ‘mark of the beast’, a sign of the “evil” project manager. But if you take all that emotional baggage away it is just a tool to visualize dependencies over time – and this may be useful should we need to do just that.

Perspective

One of the basic principles of agile is that software development is way too complex an activity to be perfectly predictable. This is the primary reason for predictive methods’ failure. Too many parameters make predicting exactly the amount of work necessary to build a software system close to impossible. And then the requirements almost always change once work is already underway.

However, the key word here is “perfectly”. If we look at a software development or implementation project from a different perspective it may turn out to be predictable enough to be a part of an overall project plan.

Let us suppose for example that you want to open a bank. First you would probably want to asses whether you have enough funds to do it and whether it is a good idea. In order to do that you must have some basis to calculate the costs and estimate the profits. You would probably also want to estimate how long it will take to get your bank up & running and then how long before you will get to the break even point.

From the budgetary perspective you will need to put aside a couple of millions for setting up branches (rent, decoration, staff), another couple for marketing & advertising and so on.

You will also need a computer system to run your bank. You will obviously contact a couple of vendors and maybe a bespoke software development company. You may even consider creating an in-house team and building it on your own. No matter which option you will choose on this level of planning it is quite predictable. Let us say you can safely assume implementing a system like this will cost – for example – 750 kEuros and will last between 10 to 12 months.

For the purpose of creating a rough budgetary plan for a bank this information is sufficient. At the same time it doesn’t really matter on this level what detailed features the system will have or how long the work would take in terms of days let alone hours. It wouldn’t change the overall business plan / picture anyway.

Where it gets unreasonable it is of course when someone expects to have all the features from the 300 page spec document on October 11th for the exact price of 747.881,35 Eur. So, software development is predictable – it is just not predictable in a way that is regrettably the basis of most contracts for this type of work. But this is another story.

Summary

There are no “good” or “wrong” tools – there is inappropriate use of tools to things they were not designed nor intended for. Projects can be predictable even in software, but only on a general level and only to a certain degree of certainty. Plans are just plans – how things will really go no one knows.

Once you keep all of that in mind you can use any tools whenever you think they fit the purpose without worrying whether it is “truly agile” or “proper management” etc.

Leave a Reply