I confess – I’m for it. And I’ll go even further – I think “making it up as you go along” is one of the greatest, and most important processes of any age.

No great explorer set out with a detailed set of explorer guidelines. They adjusted and discovered.

No great inventor set out with a detailed set of inventor guidelines. They experimented and adapted.

No great leader set out with a detailed set of leadership guidelines. Leaders point the way and rally followers when their faith fails.

“Making it up as you go along” means that you recognize a good foothold on your way up a mountain and know how to take advantage of it (in other words, you understand your craft). But you don’t need (literally) a step-by-step instruction book (because you understand your craft). In software development terms, the “step-by-step” equivalent is a requirements specification. Kind of like paint-by-numbers for would-be Rembrandts who don’t yet know that method is incapable of producing genuine art.

As good as your tools?

One of the things I hate most about our industry (the web industry, the UX industry, the IxD industry, whatever), is the penchant for folks with too little imagination and too much process training, to force “development models” on us. We have “mental models” galore. We have “process blueprints” en masse. Sadly, we have a myriad of tools, but not always the proper skills.

There’s a Danish expression common to craftsman: “A worker is only as good as his tools.” Granted, good tools are critical, as is a good process. But tools represent the lowest common denominator. Even with the best tools, an idiot will make a mess of things.

Agile or ingenuity?

We’re still at the beginning of an era. The web is not yet 20 years old. We are very much making things up as we go along despite excellent pattern libraries and established best practices. Anyone who says we aren’t is either a liar or a fool. Unfortunately, in the interest of professionalism, many folks are trying to legitimise their existance by formalising their work processes.

The smart tool of choice these days for software development is agile. ‘Agile’ is basically a fancy term for making it up as we go along. Mind you, there’s nothing wrong with this. It’s a good technique used by the pioneers for whom oceans are named.

In the old, pre-computer era, we call this ‘flexibility’ and ‘having an open mind.’ ‘Talent’, ‘intuition’, and ‘ingenuity’ were also once keywords. When did we stop appreciating these abilities? We have, you know…

Now, agile development is being groomed for polite society (e.g. the clueless business executives who would have insisted that Columbus produce a map showing the exact passage to India before he had actually done his discovery work). But gosh, Mr or Ms Business Leader, agile isn’t Russian Roulette. It’s not going to cost a fortune – in fact, it will probably cost less than the idiotic “requirements specification” some overpriced consultant is going to talk you into.

Which leads us to scrum

‘Scrum’ is a term stolen from rugby (which follows a wonderfully make it up as you go along kind of gameplan). In the world of software development, scrum formalizes the informal iterative agile development process. The Scrum Master is a project coordinator who presides over meetings and shepherds the team based on a set of strictly defined rules. A formalised certification course during which potential Scrum Masters learn the basic rules and mechanisms takes several days. Why is scrum popular? Well, first, it’s not a bad process. Unfortunately, scrum can be a nasty weapon in the hands of the wrong people; business execs are often comforted by processes that are governed by strict rules. Particularly those pesky, unpredictable creative processes.

How to win the game? Stay loose!

It’s not that I have anything in particular against scrum, but I have a lot against creating gameplans that don’t allow for deviation or the unexpected voicing of a sudden brilliant idea that turns the whole project on its head. Good Scrum Masters know the value of exploring new directions. My problem is with the tyrants who blindly stick to this (or any other established process); who hide their own lack of talent and creative insight behind a veil of pedanticism and false authority.

Sorry Columbus, ignore this new world of yours. Remember, your job is to find a passage to India. What will you do between now and the next daily scrum meeting regarding this project?

How many of us slavishly follow our car’s navigation when we know it’s giving us bad advice? Very few – that would be silly. And how many times have we uncovered a blatant fault during the very first usability test? Does it make sense to test with several more respondents before fixing an obvious problem? Of course not – no matter what the test protocol may dictate.

Although I’ve singled out scrum, there are lots of other processes that can go equally awry. Many companies these days are busy trying to implement Toyota’s LEAN production system, often with disappointing results. Kaizen quality management (another Toyota development) can also go very wrong – and for the same reasons Total Quality Management, House of Quality, and Philip Crosby’s Zero Defects went wrong back in the 80s; too many managers let the process get in the way of the ultimate objective. Remember, the goal is the goal.

For every rule, there are myriad exceptions. For every battle plan, there are unexpected circumstances. For every process, there are fifty other ways to do things. So, my advice is to do what needs to be done, when you need to do it. And as to the gameplan? Don’t be afraid to make it up as you go along.