Thoughts for improving your business

What is agile? Get in touch

The Antibiotics of Software Engineering – Agile Testing

Surgery is not a recent invention, it dates back millennia. 

Notable Milestones in Surgical History (

6,500 B.C.E. – Skulls found in France show signs of a rudimentary surgery called trepanation, which involves drilling a hole in the skull.
1540 C.E. – English barbers and surgeons unite to form The United Barber-Surgeons Company. These barber-surgeons performed tooth extractions and blood letting. Physicians were considered an entirely different profession, treating illness with medications.
1818 – First transfusion of human blood.
1843 – First hysterectomy performed, in England.
1843 – First use of ether.
1867 – British surgeon Joseph Lister publishes Antiseptic Principle in the Practice of Surgery, extolling the virtues of cleanliness in surgery. The mortality rate for surgical patients immediately falls.
1885 – First successful appendectomy performed, in Iowa.
1890s – Widespread use of chemical agents to minimize germs. Carbolic acid was put on incisions to minimize germs and decrease infection rates.
1896 – First successful heart surgery performed, in Germany. Surgeons repaired a stab wound in the muscle of the right ventricle.
1905 – First successful cornea transplant.
1917 – First documented plastic surgery performed, on a burned English sailor.
1928 – Antibiotics discovered.

Even if the procedure was successful, often the patient suffered and usually died of subsequent infections. 
Also, not to ignore is the discovery of Ingnaz Semmelweis, a physician at a Vienna hospital. While working at a Vienna hospital in 1847 he discovered that far more women died after childbirth by the so called childbed fever in the medical ward then in the midwifes ward. Semmelweis postulated the presence and spreading of germs causing the illness by doctors. Even though, after applying a chlorine and lemon based hand-wash solution the death rate could be reduced from ~35% to 1%, he was being labeled a heretic by the doctors. Ignaz Semmelweis was ignored until Louis Pasteur confirmed the germ theory.

Now, after it was accepted that germs caused infections and that hygiene was mandatory for good outcomes it became also obvious that there was a need to have a treatment once an infection set in. As listed above, on September 3rd  in 1928 Alexendar Flemming discovered the antibiotic effect of Penecillin and transformed medicine as we know it. Nowadays, antibiotics are used to treat all kinds of infections and antibiotics are prescribed in a preventive manner for many medical procedures. 

In software development we are able to develop rather fast and make significant changes to existing systems quickly. However, after these procedures the system often falls sick, suffering from bugs, side-effects and other ailments. I like to consider these as infections. Those infections even arise after well planned and executed engineering efforts.
The fundamental question is, how can we cope with them or even better avoid them – what is the the antibiotic equivalent in programming?
For me, the answer is: Agile Testing

Agile Testing is the process to validate that new functionality performs correctly and more importantly to verify that the existing behavior has not changed – that no infection has set in.

1. We have proof that the current system is healthy before the procedure starts
2. We are able to monitor the systems health during the procedure
3. We can intervene the moment side effects set in
4. We have proof that the procedure was successful 

A well done Agile Testing strategy is the equivalent to clean medical equipment and antibiotics. 

Business Analysts are Important

I’ve always been convinced that User Stories are the way to describe feature requests. It just felt natural. IEEE 830 specification are just too ambiguous. Use Cases, even far more verbose, are often too large by covering all possible flows and exceptional cases. User Stories just fit the bill.

Writing good User Stories can be a daunting exercise. A proven way is to use the
AS A persona/role
I WANT goal
SO THAT business value

template with which the User Stories become much more tangible and more important of value to the customer. Watch out for ‘and‘ or ‘or‘ in the I WANT section, those often indicate a second User Story.
So far so good, but this still leaves the acceptance criteria out of the picture. Acceptance Criteria are a good guideline for developers to make sure they do the right thing right. It gives them a change to cover themselves with proper unit tests. QA also uses them as a testing foundation. Most important though, they are the definition of development done. (see ‘Measuring Progress‘) Sure, the customer still has to like and accept them!

So that brought me to use:

GIVEN context

WHEN event

THEN expected outcome

With those kind of user stories you would think you are in pretty good shape. Well, you probably are in the remote case should you develop a programming tool. What does this mean? The more the development team knows about the problem domain the better they are off. Now, consider the case that you develop software for the financial, medical, nuclear or any other foreign field. Looking at the image below you are ok for as long as you stay in the green band where the requirements are clearly understood. In case of the mentioned programming tool your programmers will.

Once you enter the red band, the team enters an unknown and not well understood territory. The User Stories might read like this.

AS A wombut

I WANT to blabalam amplituded chromioms in a shamaluk

SO THAT I can implotude the defused mobolobs

Makes any sense? If you are post-doctoral wombut it will. So, how can this knowledge be transfered to the mortal world of developers?
One option would be to have the wombuts and developers spent long hours together so that they get some understanding about the domain. The more knowledge is missing the longer it will take. Most often, however, wombuts are so busy that they can only spare an hour here and there. There might be some short hallway chats; but often those rise more questions then they answer.
Over the long run, this will lead to an information deficit and the resulting vacuum will be filled with assumptions. Don’t assume — if you assume you make an ASS of yoU and ME ­čśë

In the world of TOC (Theorie of Constraints) you can mitigate a constraint like this with introducing a buffer. The buffer enables you to be productive even though a upstream step is blocked. What could this buffer be? As the title already reveals, it would be a Business Analyst (BA).
Having a Business Analyst will give you two things. First, knowledge you can access all the time; usually the knowledge of the BA is a subset of the experts but in general good enough. If the BA does not know an answer or isn’t sure, she will follow up with the domain expert and report back and grow her knowledge by doing this. Second, the BA can help to bridge the communication barrier between the developers and domain experts. She is used to work with developers and understands how they think. Still, the lingua franca between both sides would be the User Stories with their acceptance criteria. If both the developers and domain expert are happy with the resulting User Stories then we have an agreement about how the customer value will be delivered.

What about the blue vertical band on the requirement image from above? The green/blue area is a well understood domain but is technically challenging. Think about the really fancy programming tool mentioned before — for that strong programmers will be able to do the job. The red/blue area is when you need both; a BA and real good programmers.

Considering I lead a project in the plain red area (not red/blue) and I had to choose between a real good programmer or a BA, I would opt for the BA without hesitation.