Thursday, August 9, 2012

An Agile Murder Mystery

It's been a busy few months, and I really want to put something on the blog, but have been incredibly busy.  So I've stolen the following article from my book the Software Minefield.

This was a Cluedo-based activity I was hoping to do at the Wellington Agile 2012 conference.  Sadly it didn't make it, so it ended up getting written as an article instead (I'm never going to waste a good idea).

Around Wellington and Twitter I've seen and heard through friends about a lot of Agile projects which haven't quite worked.  As I gathered stories, I noticed a few familiar characters coming out time and again.  Heck, in the early days it turns out I was one of the usual suspects!  Enjoy ...



It was supposed to be a weekend company retreat to discuss our recent Agile implementation, hold a retrospective and look to the future. However early Sunday morning we were woken up by Scotland Yard's finest to be informed that Dr Black, our Agile coach had been found dead, murdered beneath their Kanban board.

So there I found myself in the drawing room, here together with a group of the usual suspects, and found myself wondering, "which one of you killed the Agile process?".



Mrs Peacock, the suspicious Product Owner?
It's easy to succeed if you don't aim high enough?

Although originally each Agile sprint had delivered as promised, she was beginning to suspect the success was coming too easily, and maybe this was because people weren't working hard enough.

She was pushing hard to double what was delivered in each sprint because she wanted more business value, and was annoyed when they failed to deliver.



Colonel Mustard, the resistant Project Manager?
All this Agile is mumbo jumbo, stick to what works ...?

Resistant to the Agile move, Colonel Mustard looked upon Agile practices such as stand-up meetings as if they were a form of voodoo. Thus to make sure the team did not miss anything he had them follow old Waterfall processes together with Agile ones to reduce the risks?.



Reverend Green, the evangelistic Architect?
As my good book says, the problem with this project ... it's just not Agile enough?

Reverend Green had been away on some Agile learning courses, and carried around several books on Agile. He was enthusiastic to learn that the team was being turned into an Agile project. However he argued constantly with the Agile Coach complaining the transformation process was too slow and that it just wasn't Agile enough according to his theory books.



Miss Scarlett, the cynical Business Analyst?
This is just another company fad ... it'll be abandoned soon

Although not hostile to Agile, Miss Scarlett saw Agile as another company attempt to jump on a bandwagon. Although she followed process, she never got involved fully and never saw the value.



Professor Plum, the anti-social Developer?
The great thing about Agile - no more documentation. I can just get on with developing all day.

Professor Plum was originally keen on the idea of Agile feeling it would involve no more documentation, and full days of coding. However he was less than happy to find that he would still have to interact with the rest of the team during stand-ups, which he saw as another drain on his time. He just wanted to be left alone to code.



Mrs White, the fearful Tester?
We had a process before Agile where we got products out the door eventually. So why change it?

Mrs White had a number of years on the project, and was used to the rigid software development processes that had been around as long as her, and which she had mastered. She was fearful that a change in the organization to Agile would render her skills and job obsolete.



Although people are increasingly getting exposure to Agile projects, not all of it is good news. A lot of Agile projects don't stay Agile, and revert to either V-model or Waterfall. Taking part in local Agile Wellington events I've networked with a good deal of people from the IT industry and heard their war stories of Agile transformation gone bad.

There are a number of obstacles for an Agile team, - without an Agile coach, there may just not be enough experience in the team to make the transition - there may be issues with co-location and delivery of software which means Agile is just not feasible

And sometimes Agile just won't work, because whether consciously or not, it's sabotaged from inside.
From our list of suspects, do you have a favourite for the murderer? Most people will have someone there they'd like to accuse. The list of suspects is drawn from commonly encountered personality types on Agile projects.

Who is the murderer? They all are!
  • Mrs Peacock rather than being pleased that she was getting working software overloaded the sprints, but then turned it into an issue when everything was not delivered.
  • Colonel Mustard by keeping both Agile and Waterfall practices to "play safe" overloaded his staff with tasks to reduce their efficiency.
  • Reverend Green wanted the kind of Agile process he'd read in theory books, and so failed to see that the project had real needs not directly covered in theory. And so was needed to be pragmatic in it's application.
  • Miss Scarlett never got into the spirit of Agile. She didn't want to talk much in stand ups, so people never got much information from her of any use.
  • Professor Plum looked at only the things in Agile he liked, and was upset he couldn't pick-and-choose what bits of Agile he played along with for his own convenience.
  • Mrs White used every opportunity to say how the old system was better, and like Colonel Mustard continued to use the old ways of doing things.
Of course maybe some of this is slightly unfair. And Scotland Yard have another theory. Dr Black committed suicide.

Why? Because Dr Black was in a position to address all the team's divergent needs, but didn't.
  • Mrs Peacock should have been encouraged to increase what they were aiming to achieve during each sprint. It becomes an issue though when it becomes dramatic when everything from the forecast was not delivered. To me, this is a key litmus test for a team who think they're Agile, ask them "tell me about a time you failed to deliver everything in a sprint". If they give a tale of woe, it's worth exploring. The thing is no-one knows the capacity for an Agile team, and the measures we use to size up stories is imperfect. This need to be appreciated, as well as the fact that if something is not delivered this sprint, it should be next sprint. At least we know now about problems around it.
  • Colonel Mustard should have been persuaded to drop his Waterfall use of project measures, and educated on how the Agile ways of measuring the project worked. Although Dr Black should have attempted to mentor the Colonel, in the end they might have had to force "just do it my way" for a few sprints. This would have pushed the Colonel out of his comfort zone, but after a few sprints he would hopefully have learned that the sky didn't fall in, and get comfortable with the Agile way of doing things.
  • Reverend Green should have been mentored on the reason some Agile processes were incorporated, but some processes stayed the same.
  • Miss Scarlett, Professor Plum, Mrs White each needed training and mentoring on the Agile process. They needed to be encouraged to participate, to understand the values and avoid choosing out only the bits they liked. Sometimes like the Colonel they might have to be forced to "just do it" Dr Black's way. However Dr Black should never have stopped trying to get the message of the value of the Agile way, so that people would become educated and accept the values in the Agile methods.
Maybe then, a lot of needless bloodshed would have been prevented.
CASE CLOSED

Sunday, July 15, 2012

Remembering Violet


This weekend has been an emotional one for me. It marks the two year anniversary of the death of my close friend Violet, which felt as painful as last year. I spoke briefly about Violet and my reaction to her death earlier in the year in TheProblems We Can't Fix.

However despite talking about the passing of world luminaries like Steve Jobs or Dennis Ritchie, I've never really spoken about Violet despite her huge personal influence on me (partly as her death came 6 months before I started this blog).

So to mark her extraordinary life, I'd like to share with you who she was and how she continues to challenge and influence me …


Violet was many things – when she died at 35 she had in some ways lived out more than many of us.  She was primarily an artist, this was her passion. But she was a knowledgeable genius in many fields – psychology, photography, politics, ethics, obscure science fiction and engineering. Like my own family, she'd grown up in an engineering family, and she was passionate at tinkering and understanding technology – despite having worked in computers for over 10 years I was always asking her “how to” do things.

But her true legacy is the relationships she nurtured. She was a big believer and champion of people above all.

She was an easy person for others to dismiss – she was transexual, she had a number of mental problems suffering from crippling levels of manic depression (bipolar) and well as suffering from acute levels of anxiety. She'd even been committed over her mental health issues for periods of time.

And yet she used her own demons to battle the demons of others. She understood the mental health system, symptoms of certain conditions and medication as only an experienced end-user. There are countless stories of the people who she helped get diagnosed and find real help to deal with their issues. When she died in 2010, the phrase most on peoples lips was “you understood me when no-one else did, you championed me when others judged, you saved my life”. I too consider myself within that number of people who faced my inner demons with her, and came out stronger. This is why I consider her a friend and a mentor.

That ethos of “we're stronger together” ran through her whole life. She was a big believer in co-operation and trying to get to a better place as a community.

She loved OpenSource, and was always experimenting with Linux, especially Ubuntu. She believed the internet had great potential to aiding all to access information fairly, and be able to be informed and a global community. She feared technology and the internet becoming a divisive line in the world, where only the “haves” who could afford Microsoft or Apple devices would benefit. As such she often helped people to build their own Linux machines often from spare/junk parts.

She was a committed vegetarian and passionate peace and political activitist. She wanted a fairer world where the line between the privileged and the non-privileged would not become the line between life and death or opportunity and enslavement.

Meanwhile, I was someone who I worked previously for nuclear energy (at University) and on countless military applications. I never thought we'd be able to be friends. But she only ever saw the good and the potential in me – encouraging me in my work, and in my writing. We actually became the best of friends, and it's the reason my book The Software Minefield is dedicated to her.

At work I'm always striving to build a team around me who are committed to each other on a work level and a personal level, and seek wherever possible to work for companies with a strong ethics and behaviour, who will seek to say no when a situation is wrong. All these things are the legacy of her mentorship and example. I know in my heart she would have excelled in an Agile environment.

And yet amongst all the serious stuff, she had a wicked sense of humour. One of the things which makes her memory so bittersweet is it's hard to think about her too much without wanting to laugh remembering some quip of hers. She had a true talent for saying the right (humorous) thing to turn around my most monstrous of problems. She kept me sane like that.

I must be honest. My first reaction to this strange transsexual with so mental challenges was of being unnerved. Not an easy thing for me to say, but I say it because if I had chosen to judge and follow that prejudice, I would have missed out on one of the most positive and influential friendships of my life.



Friday, June 29, 2012

An equestrian project ...

Fellow tester Lisa Crispin gave me the idea for this ...

What the customer imagined ...



The early prototype ...



How it felt bringing the business owner on the journey ...



The speed with which the project progressed ...



Phase one testing ...




What was finally delivered ...


Wednesday, June 27, 2012

"Beam me up Scotty" requirements ...




Everyone's heard of the phrase “Beam me up Scotty” from Star Trek...

There's just one problem - that the phrase was never spoken in any TV series or film in the Star Trek franchise. We can trawl through them all and we'll find something very similar in a few occasions, "Scotty, beam us up" or "Beam them out of there, Scotty”.  But never properly, word-for-word “Beam me up Scotty”.

Never-the-less, the phrase has entered culture so much that we know it's associated with the series. We just have the inconvenience of not being able to be backed up by the facts!

I've recently learned that something similar with requirements. On my Waterfall project, we've been living and breathing the same set of requirements since Christmas. We've had meetings about them, we've had a dozen updated copies of the. We've discussed them informally.

Imagine our surprise then when we had software delivered this week, and it didn't quite meet expectations. We turned to our source of truth, the requirements, and found … erm that they weren't there. Not quite as we'd imagined them.

We'd kind of asked for a certain behaviour, and we'd definitely discussed them. But rereading them from a different angle now, maybe not.

This no doubt is the weakness of Waterfall projects. When you talk about the requirements so much, it's very easy to read them “in the same manner as how you've discussed them”.

The difference sadly is one between “what you think the requirements say” and “what they actually say”. Oops.

This in my mind is definitely the power of Agile, where it's the group discussion and consensus which is the living and breathing source of truth for the project, instead of the derived set of documentation (often delivered weeks after all those conversations).

Thursday, June 14, 2012

The electric chair problem ...


This week I’ve been having a bit of fun talking with testers about implicit (unspoken) requirements we might have for products.  [Don't take the next bit too seriously]

One that seems quite obvious is,

“It’s a bad product if it ends up killing someone”

Of course testers know better, “but our product is an electric chair … so isn’t it the purpose of it?”.

How could we check this?  In a real project we’d ask a Business Analyst for their opinion.

I have a great relationship with Patrick, one of my Business Analysts.  We share a bay, and there’s a lot of good natured banter.  Like me he used to be a programmer, and he turned BA, whilst I turned Tester – so we’re kind of equal but opposite. 

So I put it to him,


To: Patrick, chief BA
From: Mike, chief Tester
Subject:  Electric chair requirements

We’re working on an electric chair, and we need your business analysis of it.  For our product, is the guy strapped into the chair the end-user, the customer or just an interested party?

When it comes to the reliability of the product, who would you consult most with, they guy throwing the switch or the guy sitting in the chair?

Where is the customer experience in this scenario?

Mike

---------------

His response was so good, I’ve just had to build a blog around it …


To: Mike, chief Tester
From: Patrick, chief BA
Subject:  RE: Electric chair requirements


The end-product is a chair that is capable of sending a high enough current discharged through the body of the person in the chair to end their life in (insert parameters here eg. 5 seconds). 

The Customer is the person who is paying for the product, together with all the people who work with them/support them to ensure that the product fulfils it’s set objective (“a chair that kills with electricity”).

The business rules for this product can be that,

  • the power is not to ignite the body
  • that it won’t prolong death
  • that the current won’t blow the fuses

Consult with

  • the Business owner,
  • the chair manufacturer,
  • the electrician looking after power supply,
  • procurement,
  • property,
  • medical professionals
to determine best death time within the parameters.

So the deliverable is a chair that kills people, the business owner owns the relationship with the person in the chair, not the BA or the Project!

Patrick

---------------

Wednesday, June 6, 2012

Testing in pictures


How we testers see ourselves ...




How we view business owners ..




How we feel requirements are written ...




How we view developers ...




How we really need to behave with our teams ...




How what we deliver is viewed ...



How our jobs can feel like some days ...




What it feels like to encounter a high level defect ...




What it feels like when we miss a defect ...




How the project manager behaves when a deadline looms ...




How it feels when it goes into production ...



[Take with a pinch of salt - just a bit of fun]

Sunday, May 13, 2012

To ISTBQ or not to ISTBQ, that is the question …




It is without doubt one of the most contentious points in software testing at the moment. “Do we need an official certification to be software testers”.

There are arguments all over the place, and I've found myself inspired by an article by my fellow Twitter collaborator Jari Laakso to write up my own opinion.  You can read his article here.

In favour of certification of course is the fact that “anyone can call themselves a software tester”. Any industry where you can just call yourself a role without needing some form of registration, means that the “cowboys” bring down the reputation of the industry. I might be able to call myself a plumber, but the almighty mess I'd leave your house in, coupled with a crippling bill for call-out would lead you to curse plumber-dom if I was allowed to behave in such a way.

However against certification, there is the fact that it very much becomes a whole “industry” in itself to sell you the course, the exam and the shining certificate. And how do you measure someone's ability? Frankly the way it's examined in a multiple choice exam is laughable – give any good tester options A, B, or C and they will always come up with a brand new answer D.

I myself qualifying for the ISEB exam back in 2005 – it was a compulsary course for my company, and I took it with someone who was new to testing. I found myself wrestling with the syllabus, because in many ways the material hooks into such an idealised form of software delivery that I've never seen it in the real world. I kept finding myself asking “but what if ...” and “but surely ...”.

That said, I really enjoyed the course, and I managed to learn from some formal ways and background theory of doing things which I'd previously just done intuitively (without really being able to say way). And despite being the slight heckler in the class, I formed a good relationship with Rob my tutor, and we kept in touch for a few years afterwards.

As a test manager myself I do find myself looking for someone with the foundation qualification, as I know we'll have a relatively similar framework of testing vocabulary to work from.

However I also agree with a lot of the criticism. The exam based on this certification is based on multiple choice and a rigid syllabus. It's the idea that there's a “right way” and a “wrong way” to test, like everything is black-and-white.

Sure there are many “wrong ways” to test. But there is also no single “right way” to do it either. Testing is taking the pure theory of software delivery model, and then using imagination to find a best model for the project in front of you, the way it demands updates, the way software is developed, the methods used to update your test environment. You don't put together a test plan using multi-choice …

I had a great boss (Stephen Pedrick) in 2005 when I took my course. Not only did he book me on the ISEB course, but he booked me on a following course “Testing – Putting Theory Into Practice”. This dealt with really looking at the theory and making practical test plans, evaluating sample projects. This was almost an antidote to the ISEB course, taking the theory we'd learned (which I did enjoy) and really thrashing it in real work scenarios.

The ISEB course was good, the Putting Theory Into Practice was invaluable. Sadly though, where 30 people took the ISEB certification, only 4 took the one follow on (for which you didn't get a shiny certificate). And this indeed is one of the many potential traps of certification, believing that certification is “all you need” to train as a tester.

It's not, as Obi Wan said to Luke Skywalker, “You've just taken your first step into a larger world” ...