Don't be a Mad Hatter Agile Shop!

Delivery of software is not madness.

Becoming a scrum master is not hard. Professional certification takes two days of classroom training and a simple test makes sure you understood the information.  The real work happens when you are beginning your servant leadership of a software development project.  You wear multiple hats.  Somedays, a scrum master is a therapist.  On other days, they act as a cheerleader and on others they are a technical consultant.  It is a challenging career.  One of the things which get lost is the purpose of agile and scrum; is the team is responsible for delivering software.  Today, I want to discuss software delivery.

The Agile Manifesto is very clear about delivering software.  An agilest prefers working software over comprehensive documentation.  When the manifesto says “working software,” it means software in production used by customers.  Anything which does not meet this goal is not working software.

Over my career, I have had numerous conversations about when work is done.  Many of these conversations sound like sections of Lewis Caroll’s “Alice in Wonderland.”  I had a developer tell me with a straight face the code was finished, but the code did not compile.  I had another developer tell me they did not need to write unit tests before checking in code to source control.  The worst moment in software development is when a developer says, “It works on my machine, so it is done.”

None of these situations qualify as working software.  As a scrum master, you need to ensure that everyone understands what working software is.  In the agile community, we call what constitutes working software as a "definition of done."  In the medical community, successful treatment of illness is called the "standard of care."  I prefer to use the medical term standard of care when talking about working software.  It is a set of necessary and sufficient conditions.  Here is my formulation of what a good standard of care for web development is:

1. Does the software compile?
2. Does the software have a unit test to prove it is doing what it is supposed to do?
3. Does the software exist in a source control environment so that others can inspect and edit it?
4. Does the software work on a staging or test environment?
5. Does the business approve of the software delivered?
6. Does the software work in a production environment?
7. Are customers using the software?

We do not have working software if these conditions are missing.

I understand the standard of care seems extreme to some but think of all the steps you have to go through when you have surgery.  The nurses are required to count every piece of gauze, and surgical instrument used. The last thing a patient needs is a piece of gauze left in their body to be an environment for infection.  Likewise, in the software world, you do not want to deploy code which is not unit tested because it will be harder to debug and troubleshoot when something goes wrong.

Software not being used by the customer in production is not working software, and any good scrum master and product owner must make sure that happens.  If not, you are just pretending to be agile.

Until next time.