Skip to main content

Posts

Showing posts from 2013

Unaccustomed as I am to public speaking.....

Unaccustomed as I am to public speaking. The ultimate cliché for those who are accustomed to public speaking.
For me though it was true, it was my first time up on stage, in front of the lights, with an audience I (mostly) didn't know. I was surprised. I was nervous, and I'm not a nervous person. But I really enjoyed it, and I think the audience did too. 
When I look back, these positive points come to mind: The subject matter was something I felt strongly about. I have wrestled with the subject for the past four years and had endured some hard lessons and some great successes, giving me real confidence. It was based on experience and not theory. Lots (and lots) of practice. Both in my head and out loud. This allowed me to get my timing right, tweak content and most importantly, the talk felt natural. As soon as I started, my brain knew what was up next and how long to spend on area.I went light on the slide content. My previous attempts at speaking had been focused on the slides…

Project Inception: The Forgettable Mnemonic

This blog is designed to help me to remember the thing that I'd created a mnemonic about, so I didn't forget. I did forget it, immediately after presenting on the topic. So, writing it down should help.
So, when you want to kick off your project in an expedient but sensible manner try my charming mnemonic, IWOOWI (pronounced I-WOO-WI):

Iterate, Man! If your engineering iterations are two weeks then limit your project inception to that period too. There is an excellent chance that more thinking than this will only ever beget more and more thinking at this point.


Who Feels What About Which or Whom and Why?  I know, this is awkward as you'll need to ask about feelings. Let me put it this way, how many rational decisions were made on your last project? Humans are inherently irrational, place no expectations of sensible decisions on your stakeholders. Discovering how they feel about a feature/deadline/other stakeholder is more useful information than what they know. As it will be wh…

I was wrong and we missed out

So, it was the office Christmas Party on Friday. 
A few beers and laughs were had, much discussion on our testing world but on reflection I missed a great opportunity.
I need to be vague but chatting to a person (currently a programmer, who will remain nameless) who said that someone who he knew 'took a step down the ladder and decided to be a tester.'
Now, my response contained more than a little indignation. I put together a polite but scathing comeback, wallowing in my own righteousness.
I was wrong. I had a chance to have a reasoned debate around why this person thought what he thought about testing as a craft. I could have asked:
Why do you think its a step down?Is working with a tester valuable to you?What skills do testers you know have?What skills do you think they should have?
I let that slip away when we could have learned something from each other. And another chance to progress the debate of the value of testers and what we bring to the world.
Shame.

Johnny Mnemonic - ICEOVERMAD

Fairly early in my testing journey, I attended (and interacted with) the Rapid Software Testing course, showing me the power of consciously introducing mnemonics into your testing (and life) toolset.
After this initial experience I noted that even in the most linear of environments where the testing process was seemingly restrictive these techniques could be leveraged. On even further reflection I realised we are all using mnemonics to complete certain testing tasks in a subconscious manner and not acknowledging their fallibility.
So 3 years on, having used a number of the mnemonics created by others I thought I would give it a try. I picked something I have worked on a great deal recently, creating test approaches for and executing testing of Application Programming Interfaces (API’s), henceforth referred to as, ‘the service.’

So, without further ado, I can now reveal:
ICE OVER MAD!
Integration – How will consumers integrate with the service? When will consumers integrate with the service…

Sometimes you know how but you can't say how.....

I was once asked to create a ‘Sprint Diary’ for how to be an ‘agile tester.’ That’s right, on the first day do this, on day two say this, on day three create that. Now, I can understand why they (vagueness to protect the guilty/innocent) wanted this ‘guide.’ I meet many testers who feel discomfort in the agile world who want to know which way to turn. 

They didn’t like my answer. I said:


‘I might be able to show you but I can’t tell you.’
Why ever not they said. I said:


‘The skill and understanding is in the moment, when decisions are made.’
When is this moment they asked. I replied:


‘To be honest I don’t know. And I might not know at the time.’
Honesty does cause a great deal of consternation. Much grumbling ensued.

So after pondering on this exchange, my reflections led me to these (personal) principles:

Strive for optionality. In a world where factors that cannot be finalised or nailed down are constantly hounded for a state they are incapable of, be the person who retains their options. …

Certified Scrum Product Owner - Mission, Principles and Approach

I’ll be embarking on the ‘Certified Scrum Product Owner’ course tomorrow. Ye gods I hear you cry, ‘You’re going to be certified (or certifiable)!’ and ‘It’s methodology specific, what about context, won’t somebody please think of the context?’ 

Before we all get bent (!) out of shape, hear me out. For a great many activities I undertake I define a mission (my statement of intent), principles (thoughts that may guide me) and an approach (how I will behave, act and actions I’ll take).

My Mission ‘In my recent experience, a lack of focus on return on investment has led to a number of unsuccessful product outcomes and identified a gap in my knowledge. Testing is rooted in return on investment (time, effort, thought) and more empathy with a Product Owner and the decisions made can help focus testing on what’s really important.’ My Principles
The course I am about to embark on is theory. Theory is a good grounding but context remains as the focus. I remind myself, ‘there are no best practices …

Skillz pay the, erm, billz

Apologies for the title.

Which are you (as a tester) most proud of? I'm going to make you choose.



Is it your domain knowledge, being the go to guy about this and that piece of functionality? Wow, your changing that are you? That caused problems last time. Oh and this is linked to that so if we change it, we'll need to be careful.

OR


Is it your toolkit? Point me at anything and I can test it as I have the ability to craft a sensible context driven approach with the right tools for the situation.







As I've asked the question its only right I put my neck on the block first.

In my context, I'm most proud of my toolkit as in my line of work, domain knowledge is completely transient. I can be the king of the domain (and modest with it) one day, and pauper the next as I switch between industries.

But this is about much more than a set of tools and techniques, its about questioning fundamentals. Every new domain (to me) is the equivalent of a tour guide for an alien, with cha…

"This project is different as it has no functional changes"

I've heard this statement a few times.
"There are no functional changes to the system, just a bunch of non functional updates to hardware and software."
Huh?
What I really hear is:
"We are changing broad areas of the system, but we're not adding any buttons/fields/pages/widgets so we're going to classify this as a non functional project."
This sort of assumption needs to be challenged. If you are changing the foundation of a system, there cannot not be any functional changes! The reaction and interaction of a systems users dictates function. For clarity a user can be a human or another system in this context.
Do the following count as 'change?' System changes speed: If the system responds slower or faster, those using it will respond to that. Improving your performance can have negative impacts on the consumers of your system, if the user expects a certain speed of response.Systems inherent fragility changes:  If the system has more or less availabilit…

Mr Big Stuff, Who Do You Think You Are?

Ever worked on a project when you thought 'I wish the sponsors were more involved?' That would really help to clarify the vision and focus the team on what is truly valuable.

That is a noble wish, one I have echoed many times. However, experience is now telling me something a little different, that perhaps that desire is entirely dependant on the sponsor you wish to involve. Say hello to our old friend context again.

What happens if your sponsor (as they can be) is a real big hitter in the organisation? And god forbid, they are being judged on the delivery of your project by an even bigger cheese. So, your big cheese starts getting hot and heavy with the team, interrupting stand ups, looming over your shoulder and getting all judgemental.

As a Scrum Master, I've dealt with this a few times, so a little practical advice:

1. Cut the Shit - sponsors will want direct answers. This is the best way to deflect attentions from your team. Patience and seniority are sometimes not h…

Don't worry, it'll hold together. You hear me, agile transformation? Hold together!