niedziela, 23 listopada 2014

Business Process Re-engineering in Rome or Terravision, a horror story!

Business Process Re-engineering

This is not a lecture, but it is a good example, of how life could be better. An example more convincing than any lecture!

After teaching for three days my BPR course, available at, (“BPR” means “Business Process Re-engineering” – a fashionable name for process improvement to achieve business advantage) to some people in Rome, I was to go back to the airport and fly back home. What happened then, was the best example available, why BPR is necessary, why it is not the same as introducing IT / Web support, and why it is so very interdisciplinary.

Already on arrival some days earlier, I was rather taken aback when my shuttle bus stopped somewhere in the middle of the rather crowded and badly-lit street, at a place not easily recognizable as any bus stop, except for a long queue of nervous-looking people with suitcases, and heard a laconic info from the bus driver “Termini”, the name of the main and biggest railway station in Rome. No railway station was there anywhere to be seen, but – thanks heaven for Google Maps and its Street View! – I managed to recognise a rather morose and ugly wall of a huge building as the station building.

[this article will appear in "Quale" soon]

It has already, I was told, but since it is impollible to load, I give the rest of it here, too, for your benefit.

Two sister acronyms: QA and BPR

What we have in common

Business process re-engineering (BPR) is an interesting discipline for QA engineers. For example, it has many crucial activities in common with business analysis. Actually, business process change, is what should often take place after business analysis, instead of system development. If, due to customer’s misconception, they take place in parallel, this leads to many interesting phenomena, including the notorious scope creep.
Poor business process may destroy the best efforts of software engineers, when a potentially good software cannot be used properly in hostile business environment. For example, the stock-market internet bubble crash at the beginning of this century, was not caused by using XP end other not-so-concerned-about-the-requirements development methods, but because the need for these methods had been created by bad, cowboy, irresponsible business approaches.
Last but not least, testing a business process, and then “debugging” it, that is looking for the reasons why it fails, has much in common with software testing.
The story I describe here, happened to me almost symbolically the day after I had taught a three-days training course in BPR in Rome. It is a wonderful example of how business processes fail, as well as of how social, cultural and economic environment create conditions in which bad business practices can thrive.  
So, after teaching this course, I was to go back to the airport and fly back home. What happened then, was a brilliant show why BPR is necessary, why it is not the same as introducing IT / Web support, and why it is so very interdisciplinary.

Bad UX, or user experience

 Already on arrival some days earlier, I was rather taken aback when my shuttle bus stopped somewhere in the middle of the rather crowded and badly-lit street, at a place not easily recognizable as any bus stop, except for a long queue of nervous-looking people with suitcases, and I heard a laconic info from the bus driver “Termini”, the name of the main and biggest railway station in Rome. No railway station was there anywhere to be seen, but – thanks heaven for Google Maps and its Street View! – I managed to recognise a rather morose and ugly wall of a huge building as the station building. Naturally, this experience made me somewhat apprehensive before my return journey.
This is the first interesting lesson of the story: the effect of an even slightly bad first experience has very devastating and lasting effect of how a product or a service is later seen. So, spiral development and prototyping in all respect, beware of creating such a lasting impression by demonstrating a very bad first system version to customers too early.


Reassuring second experience

To feel safer, I searched the web for ideas and found a professional-looking web site of a shuttle bus company “Terravision” ( Wow, I could really buy now my bus ticket on-line, thus avoiding the scary prospect of perhaps having to buy my ticket from the bus driver or his assistant. Why was it scary to me? As the bus company’s personnel did not wear any uniforms, which I had learned already on arrival, I was afraid I would not be able to recognize the right person easily (now I know I could – the assistant by shouting, the driver by smiling sarcastically at the stupid people attempting to board his bus).
So, until then I had already experienced a number of seriously “broken windows” (see Michael Levine,, seriously damaging my user experience. Lack of recognizable uniforms. Unprofessional behaviour – the assistant smoke a cigarette while talking to passengers. Badly lit location / venue / bus stop. No markings on where I was, lack of helpful information, the sight of obviously stressed people, queuing. Too bad!
Product quality, whether a product is a service or a physical entity, does not hang in empty space, it is tightly connected to everything around it. Therefore, QA in general and testing in particular, may easily pay too much attention to technical details, instead of the complete user experience, or UX. The conclusion is not that technical, functional and extra-functional (yes, I hate the misleading and stupid term “non-functional”) quality is not important. Yes, it is a necessary, but insufficient precondition of high UX. 
Radek Hofman conducted a number of very revealing experiments in this area. They show clearly, and in a statistically significant manner, which is a rare occurrence in anecdote-prone software quality engineering, two important phenomena:
“Software quality perception” ( tells you how simple rumours (oh so easy in the age of Facebook, Instagram, twitter and other rumour-spreading and brain-killing social media) can dramatically influence the judgement passed on quality by professional testers.
“Behavioral economics in software quality engineering” ( tells you how “history effect” – the influence of your first bad experience of a product, will stubbornly bias your perception of it.
Finally, if you’d rather have a model to see similar effects on a diagram, welcome to Kano model:
 (courtesy of
Back to Rome. I was then still ready to revise my first negative impression, and I was well on my way to do it, when I found Terravision’s sensible and well-organized web site, and could buy their ticket in advance without any unnecessary hassle, which I had by then learned to expect from shuttle buses’ notorious customer interface. A warning sign, though: the necessity to exchange my ticket for a separate boarding card before being allowed to take the bus looked like a rather crazy and unnecessary complication, as the ticket I bought was valid for a specific hour, but what the hell, I thought, you must not expect perfection when you buy a 4-euro service, not a Rolls-Royce.
When I arrived next morning, on 20 November 2014 – well before the assigned time, to be sure – at the well-advertised Terravision Café at Termini, I was rather shocked again, when I saw a long communist-style line of nervous-looking people queuing to buy their tickets, thoroughly mixed up with people wishing to exchange their tickets for boarding cards. Obviously, the whole system of tickets and boarding cards was extremely clumsy, totally unnecessary, and awkward for everybody, both customers and for the rather angry-looking (tut-tut! Too sure about their jobs, perhaps?) girls inside the ticket booth. Yes, there was an A4-format paper telling those with tickets to “jump the queue” before those wanting to buy tickets. An obvious failure of localization: an attempt to impose a rather peculiar Italian habit on pre-dominantly international customers.
The whole queue thoroughly blocked the only entrance to Terravision Café inside. I started expecting the worst, but the exchange process ticket-for-boarding-card went surprisingly painless for me. I could not help overhearing, however, an elderly Swedish couple enquiring about the possibility of ensuring tickets for the next day, only to be told – in a rather brusque and unfriendly manner (tut-tut!) – by one of the girls behind the counter – that it was not possible longer than 30 minutes before bus departure. She did not mention the possibility to use their web site; why bother.
Clutching my precious boarding card in my somewhat sweaty palm, I endured without further ado being told that my bus was 20 minutes late, thanking business process analysis gods for deciding to go before due time, so I still had a lot of time.
-          Where’s the bus stop? – I enquired.
-          Just outside! – was the answer. Not a sign of a bus-stop sign there, but a tell-tale, suitcase-armed queue made any doubts obsolete.
I joined the queue, wondering how to tell the end of the queue from its head, and how we’d be able to sort those willing to travel to Fumicino airport from those Ciampino-heading (no signs, no information boards, of course).
Finally, a bus to Fiumicino arrived. As I had already noticed a few days before, the fact that people exited the bus at exactly the same place as those wishing to enter queued, beautifully added to general chaos and irritation. I was happy for being observant, too, since the only indication on which way the bus was to go, was on its front, while its sides were decorated by a beautiful, but rather confusing sign “Rome <-> Fiumicino, Rome <-> Ciampino”. Good idea, this! You really can, with some effort, design a customer process in the worst possible way! A gentle touch of very stupid and confusing user interface makes a mildly bad user process into real horror!
And horror did start immediately, as rather restive and desperate passengers attempted to enter the bus. Some had no tickets, believing they could buy them at the bus. Some had not exchanged their tickets for the required boarding cards, some were not sure to which airport the bus went, and some were unsure what to do with their luggage. The bus assistant immediately resorted to shouting, not so much to be heard, as to show his authority and passengers’ stupidity. A good thing was, he was too busy shouting to be able to smoke, or perhaps he was a non-smoker, I couldn’t possibly know.
Still shouting, he made, however, a very sensible move of telling the people who wanted to go to Ciampino, to form a separate queue. This could, possibly, give a thinking person a nice BPR-idea to actually mark two separate queues on the bus stop, and avoid some of the hassle in the future, but I do not think there was any thinking Terravision representative around. If there was, they might had discovered this genius solution many years before… Or simply, as is so often the case at IT companies, too, especially as software testers are concerned, the employees were expected to perform the duties assigned to them in an obedient manner, instead of arrogantly stepping on management prerogatives and proposing improvements. Good bye, Kaizen! Good bye, TQM! Good bye, Toyota system! Good bye, Juran, good bye, Deming! Terravision has still much to do before they catch up with the ideas that were known and widespread as early as forty years ago!
The bus to Fiumicino left, we Caimpino enthusiasts waited for our twenty-minute late bus to arrive. I decided I’d take a taxi when it was 09:40 (the bus would be 50 minutes late by then). As minutes went by, I could enjoy watching the growing restlessness of those waiting, and the total absence of any attempts to inform us about the situation from the nearby Terravision personnel. While I departed in the direction of the taxi stand, I could hear a Terravision lady shouting (they are good at shouting at this company!) that the bus would arrive later still because of traffic. You may be interested to know, that on my way to the airport by taxi, I was told by the driver, that traffic from Ciampino to Rome was unusually light this morning… A blatant lie, too!
So this is the end of my Terravision story, but it’d be incomplete about adding some views on the feasibility of trying to achieve real BPR in any not market-driven situation. Socialism, as some of us can remember, was extremely adept at business process degeneration, rather than any improvement.
As I arrived at the nearby taxi stand, I was utterly surprised to find passengers waiting for taxis, not the other way round! Years and years of my age flew off my back and I felt thirty five years younger, in the middle of some communist era Eastern Europe city, where taxis, as any services, were scarce, and those in the power to bestow them on eager customers were arrogant, reckless and unfriendly. I gathered immediately that in Rome, taxi drivers’ corporation alias trade union alias mafia must have won the privilege to limit the possibility to join this trade, thus ensuring for themselves endless monopoly benefits. In spite of my ex-communist training, it took me a while of patient and fruitless waiting first at the end of the line (the taxis then stopped at its head), then at its head (the taxis had by then switched their stopping habits), before I got back my uncanny ex-communist instincts and ran directly to grab a taxi before it had even come to the curb. 
Here my BPR-Rome story ends. Ciao, Roma! I’ll surely come back, yours is a beautiful city. Some BPR may make it a better place to live, and to visit, though! Terravision (what a f…ing arrogant name!), I hope you will pay my back four euro you stole form me, but anyway, I and probably all other passengers, too, would rather pay one or two euro more, and get serious and better service in exchange. So that you can have an extra bus in reserve, in case of one breaking down again, or some real, not imaginary, traffic jams in the future.

środa, 12 listopada 2014

From here to Eternity: The Evolution of Software Engineering

(Complete article:

The Evolution

There is an evolution in everything, including software quality engineering. Even though you may be forgiven for believing software engineering is purely rational, scientific and engineering-wise, in reality its development has over years followed a bumpy, turbulent road, like any other social phenomenon.

During early, pre-transistor, pre-integrated circuit days4 of computing, so beautifully described by Richard Feynman in his reminiscences from Manhattan Project, software projects were very few and – by today’s standards – very small. So, there were enough geniuses and Nobel prise laureates to people them and to conduct them competently without special processes, organisation, or tools.

This changed; computers grew more powerful and numerous, projects grew larger and more complex. There were not enough geniuses to people them all, so more ordinary programmers had to take over. When confronted with daunting tasks, people have an ability – almost unique among world species - to tackle them not only with the power of their individual minds, but with organization and cooperation, processes and procedures. This was the course taken by programming – although the name “software engineering” did not even exist then - in the late fifties and in the sixties.

As software continued to grow in complexity, but pre-manufacturing project methods remained, the situation deteriorated. Words about “software crises” were spoken, and, finally, talking about software engineering, instead of just programming, became standard. Companies, who refused to mend their ways, are mostly extinct now.

And this trend continued, creating growing bastions of techniques, procedures, documentation, rules and standards as defences against the powers of chaos and entropy.

The Revolution
But there is such a thing as overdosing, and all methods, if used without reflection and due consideration, can easily create effects opposite to their initial intentions. Sensible documentation and order more and more often degenerated into stifling bureaucracy. Good formal techniques were sometimes used without regard to real business needs. When the cost of quality exceeds the cost of the lack of quality, overall cost increases instead of decreasing, and quality is no longer free.

(Complete article: