“I don’t know”. This short sentence can make all the difference. It might not be the answer you want to hear, but be happy when somebody dares to say it to you. It is not a sign of weakness.
Doubt and skepticism can be seen (must be?) as a skill. Skills can be developed. One can start with the following steps;
- Observe; look and listen with deliberate effort.
- Ask questions; this is crucial. Don’t passively accept what you are told.
- Research; do you own fact-checking.
- Experiment; can you think of an experiment to test a particular claim before accepting it?
- Share your ideas and conclusions with others; this is a great way to get feedback from people who may know more than you about a given claim.
Applying this approach will help to reduce errors. Applying the Specification by Example method (Gojko Advic) can be a powerful aid with step 2 – 5. Specification by example is a collaborative approach to defining requirements and business-oriented functional tests. With specification by example, requirements and tests become one, expressed as concrete, realistic examples. Gojko’s 2 day workshop on this topic is highly recommended.
I don’t want to give away to many spoilers on Zeger’s book, you can download it free: https://testsidestory.com/2016/11/16/the-power-of-doubt-becoming-a-software-skeptic-paper/.
But. I truly like his Skeptic Manifesto:
“A while ago I chose to embrace the skeptic lifestyle. This has taught me to value:”
Suspending belief / Rejecting certainty OVER Being convinced
Finding things out OVER Believing what you’re told
Challenging claims OVER Accepting them
Saying “I don’t know (yet)” OVER Pretending to know
Deciding based on best available evidence OVER Sticking with what you “know” is right
Questions that can’t be answered OVER Answers that can’t be questioned
It’s ok to doubt.
This phrase became well known in the Apollo 13 movie. Gene Kranz (played by Ed Harris) is in charge of bringing back the Apollo 13. He famously said, “We’ve never lost an American in space and we’re sure as hell not gonna lose one on my watch! Failure is not an option!” I can think of other situations where this might be a valuable statement. A mouse, being chased by a hungry cat, would definitely agree. I guess this mantra applies to all life and death situations.
But I don’t think it applies to most real life situations. For instance in the free market, failure is always an option. Startup companies are known for their failure culture. Fail fast, fail cheap, fail towards success by learning the lessons taught by failure. Fail fast is a strategy Agile uses for getting fast feedback. After the feedback the team can adapt and become successful. It’s a smart strategy, as it is fast and relatively cheap.
If failure is not an option, one must believe in the possibility that all risk can be removed. The project will be able to get into a state in which 100% security and 100% of control is possible. This however can’t be done..not by a long shot. Believing you can, is very dangerous for the project. Basically you set up a trap for managers, a trap they easily fall into. Jerry Weinberg reminds us to the Titanic Effect, which says: “The thought that disaster is impossible often leads to an unthinkable disaster“.
So if failure is an option, what do we do now? Let’s start doing some serious risk management. And I don’t mean writing down (and never look or talk about them ever again) only the big risks. Yes a big risk can bring down your project, so can 100 little risks. Start thinking is terms of “what if”. This forces you to have a plan B (or even more, as the alphabet have 26 characters to choose from).
Continuing a project, a project that should be stopped, could get very expensive in the end, and only creates the probability of a spectacular failure. At least build in the option to fail.
People like to hear stories. So do I, stories can give insight to a problem from a different perspective. Recently I saw a parallel between a great story and the world of software. The story is about the Emperor’s New Clothes. Here is the short version of the story.
Many years ago there was an Emperor so exceedingly fond of new clothes that he spent all his money on being well dressed. Two weavers (the swindlers) offer to create a special set of clothes for the emperor. They tell the emperor and his followers that the clothes are invisible to people who are too stupid for their jobs. No one can see the clothing, but no one wants to admit this fact because they do not want to be identified as foolish.
“I’d like to know how those weavers are getting on with the cloth,” the Emperor thought after a while, but he felt slightly uncomfortable when he remembered that those who were unfit for their position would not be able to see the fabric. So he sends in his most trusted men to verify the progress of the weavers. None of them can see the clothes, but none did say so.
Well we all know how the story ends. The little boy said at last, “but he has nothing on at all”.
So how does this work in our software world? First of all, remember that software (and progress) can be invisible like the clothes of the emperor. The development team can use all kinds of excuses. We can’t (will) show you the software right now because;
- We haven’t integrated the latest module yet.
- We haven’t tested the software yet, and don’t want you to run into all kinds of bugs.
- We have no data in the system. This is planned for next week/month/year.
- We are currently understaffed due to <some excuse>.
- The configuration isn’t up to date in the test environment.
- That’s normal in a <huge amount> dollar project.
- We never show the software to our clients until the promised release date.
This can happen. Perhaps in the early stage of a software development project. Time flies. Now you have send your most trusted men to verify progress. Are you sure they return with the truth?
When do you need a little boy to reveal the truth about your project? (Will you even recognize the little boy?)
Holiday, a great time for reflection. This blog shares some ideas, thoughts about the struggle to adopt agile.
I stopped “preaching” about agile some time ago. I thought that if you did something different and important [like running software projects in an agile mindset] – and I did think agile made sense of a lot of phenomena in software development and gave direction that was badly needed – people would hoist me on their shoulders and a carry me in triumph. But that was just incredibly naive.
Sometimes people even looked at me in bafflement: What’s the point of agile development? And what does any of this agile development stuff have to do with “real” [Waterfall] software development? Questions like this left me at a loss. How could they not see it? The [bloody] point is that you have to look at the world as it is, not as some elegant theory [Mr.. Royce’s article] says it ought to be. But people kept being sceptic.
Nothing wrong with skepticism, it can prevent mistakes, even encourage people to come with additional ideas, but….it Can also stop progress. There is still a lot of skepticism in waterfall minded (traditional very command and control) organizations. Perhaps skepticism is because agile development can’t be called a “science”? Perhaps. But how about geology, or astronomy? Can they predict exactly when the earthquake will come or when the next star will be born? Not at all
You might claim that the Waterfall method is still the standard and yes we are locked in to this technique, and that is ok, because…..it must be superior to its rivals. Clocks are like that, locked in, always running “clockwise”. But the Uccello clock in Florence is running backwards. My point? You don’t have to follow the pre defined Waterfall steps to get results. Pair programming and test driven development (tdd) show it can be done in another way.
To answer your unspoken question: Yes it is possible to lock into an inferior technique like the Waterfall method. History shows other examples, like Beta-versus-VHS, the QWERTY keyboard and MICROSOFT software.
It doesn’t have to be that way. Within the (perceived) “Chaos” of Agile, you will find a lot of order. this Order will deliver results.
We are currently fixing a lot of bugs in our system. They have been there for a while, but it was time to do some cleaning. During intermediate testing I found a bug, which “should have been solved”. So I asked my colleague Frank to help me out here. It turned out we had a bug in our bug list. It has been there for some while, hiding, staying unnoticed, until now.
Subject: Re: where did we lose sight of this bug?
I see. It is neither incident#26 nor one the print bugs (incident#36, incident#201, incident#205). It seems that this incident is described in incident#211 and incorrectly was set to duplicate (to incident#200) by Eric last year and therefore is not in the current scope. I will talk to Jack, to clarify whether he can fix it, yet. We will do so, if the solution does not conflict with others.
Best regards, Frank
Subject: where did we lose sight of this bug?
So we had a bug in the bug list 🙂
Best regards, Ronald
To: Ronald (VWM)
Subject: where did we lose sight of this bug?
It seems that we can fix both (the bug in the bug list and the bug itself), without delay in the planning.
Best regards, Frank
Well, I have a next action on my (long) to-do list: checking all incidents with status “closed (due to duplicate)”.
Vrijwilligerswerk is belangrijk. NLdoet is een landelijk evenement waarmee lokaal vrijwilligerswerk wordt gepromoot en waarbij gemakkelijk kan worden aangesloten. Dit jaar hebben een aantal collega’s (waaronder ikzelf) van mijn afdeling mee gedaan.
We hebben geholpen op Zorgboerderij Buitengewoon. Om een lang verhaal kort te maken: een geweldige dag, die ik niet had willen missen!
Meer informatie over de zorgboerderij en NL Doet:
PNOzorg gaat van een oud naar een nieuw administratiesysteem, en dat gaat niet zonder slag of stoot. Ergens gaat er iets mis. En vanzelfsprekend zijn de klanten daarvan de dupe. Fijn project is dit geweest PNOzorg. Ik daag jullie uit om het salaris administratiesysteem te gaan vervangen met dezelfde aanpak als het huidige systeem is gedaan. Kijken hoe dat bevalt!
Houten, 27 februari 2015
Geachte heer Perluka
Aan het einde van 2014 hebben veel mensen gekozen voor de zorgverzekering van PNOzorg. Tegelijk heeft PNOzorg de overgang naar een nieuw administratiesysteem afgerond. Het nieuwe administratiesysteem werkt helaas nog niet zoals we graag hadden gezien.
Door omstandigheden is de kwaliteit van onze dienstverlening niet van het niveau dat u van ons mag verwachten. Zo kan het zijn dat uw declaraties later dan gebruikelijk worden uitbetaald. We worden veel gebeld met vragen hierover, waardoor de wachttijd aan de telefoon langer is dan u van ons gewend bent. Ook kan het zijn dan u langer moet wachten op een reactie op uw e-mail.
We vinden het bijzonder vervelend als u hinder ondervindt. Daarvoor bieden wij onze excuses aan.
Er wordt ok dit moment hard gewerkt om de problemen met het nieuwe systeem op te lossen.
Met vriendelijke groet,