Tuesday, 24 December 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 themselves and reacting to the content on them rather than speaking. However I took a conscious decision to lighten the slides and talk from within.
  • I worked in small chunks, allowing for iterative improvements. Mainly because I built the content on the train on the way to work. Half an hour at a time for both content creation and to practice delivery. Walking away then re-engaging seems to compliment my style.

Maybe I could have improved by:
  • I went big on ideas, then cut down to a small presentation. Maybe I went too large, I built thirty to forty minutes worth of content. After four years with wrestling with the topic I had a lot of ideas! It led to some hard decisions over what to leave out, and a timing horror a couple of days before!
  • I could have done more practice but in front of other humans. My first opportunity to get feedback was on the night itself, when I had a multitude of opportunities to get some real human input before the big night.
  • A little less humour and more message. I intentionally went for a light tone, as I think a lightning talk should have a couple of laughs, but I left afterwards feeling that I may have overdone it. However I won't beat myself up too much for that one.
Plus I didn't wear a hat. Appeared to be a deal breaker....

Saturday, 21 December 2013

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 what they think they know.


Obvious? 
The software development world does so many things which don't have an obvious reason why they should be done. Not every reason is obvious. Being non-obvious is sign. When the bus is about to run us over it is obvious that we should take evasive action. If your project/product has no obvious reason for existence, ask the question.



Optionality 
In the beginning you will meet those who wish to confirm, finalise and nail down each and every aspect of your project. It is a tempting thought. Until the entropy of time gets involved. Resist these nail-downers and approach your project kick off with a view to increase your options, not narrow them.
Why is this so hard? - If your project kick off is unforgiving, then what you shouldn't do is doggedly push on with your plan to get under way, you should ask the question of why this is so. Perhaps some of the previous parts of this mnemonic are in play, most likely your stakeholder engagement is not what it might be or the critically important project that you are about to embark on is not, well, all that important.



If stuff built > 0 && {insert kick off document name} !signed off 
This test provides an examination of how effective your current process really is. If the kick off document that you have slaved over is still awaiting a rubber stamp 10 weeks into the project, I think you know how keen your stakeholders are on both your project and the way you've handled the kick off phase.

This mnemonic summarises (for me) the key to an effective project inception, setting the tone and direction of the humans involved. Technology and process plays a part but I believe (and experience tells me) that your humans having a similar vision at the same time is crucial for successful delivery.

Sunday, 8 December 2013

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.


Tuesday, 19 November 2013

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? Is it intended to be rendered on a browser? Output into a file and then consumed?

Consumers - Who will be consuming the service? Is the end user a human or a machine? What problem does the service solve for each consumer?

Endpoints – What form does the endpoint take and how is it reached? Is it a single endpoint, multiple endpoints or routed through a load balancer. What level of security is applied?

Operations – What business functions does the service perform? Can they be mapped to current functions performed via a user interface for example? Are the operations descriptively named and readable for both human and machine? Do the operations handle sensitive data?

Volume - Will the service be used at high volume concurrently or sparingly with single high value requests? Are the single transaction sizes an issue? How will API sessions be managed? Is the target architecture clustered?

Error Handling – How will the service handle server side errors? How will the service handle client side errors? Are errors informative and/or verbose? If database connectivity is lost is that handled?

RESTful – does the service have the characteristics of a RESTful service? Is this desirable in context? http://en.wikipedia.org/wiki/Representational_state_transfer

Modularity – How are the components of the service distributed? How do they interact? Can they exist on their own? Can they fail over to one another?

Authentication – how do users authenticate within the service? What permissions are applicable and how does that change the operation of the service? What levels of security are used? Is data sent or received encrypted?

Definitions – What defines the inputs and outputs to the service? Is a WSDL, WADL, XSD, XSLT or Other used? What limits does this impose on the service? Which HTTP methods are used and for what purpose?


While I was creating this, it felt like I could have added a great deal more to the mnemonic but to be effective (and memorable) I have focussed on (what I believe to be) the key areas. So, please feel free to give this a try. Amend, enhance and critique as you see fit.


Friday, 1 November 2013

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. Leave doors open for people, systems, tools and techniques. Who knows when you might need an extra option in a squeeze?
  • My old buddy context. Often neglected, but always waiting to be found. Ask just the right question, dig a little deeper, and ask someone you might not usually ask. When someone on the team asks ‘what is the context of this issue?’ it always brings a little smile to my face, as it usually leads to an epiphany.
  • Timing is crucial. You always hear phrases like ‘just enough, just in time’ and ‘last responsible moment’ in agile discourse. Can you honestly think of a teaching strategy to find the ‘last responsible moment’ to make a decision? It is ethereal, one moment you can taste it, the next it’s gone. And there’s a very good chance you’ll get it wrong. A lot.

I’ve been on agile training courses but I have never proceeded thinking that it would teach me to be ‘more agile.’ To approach without recognising the fallibility of such endeavours is understating the importance of the tacit knowledge required.
 

Of the three principles above how many do you think can be taught and to what extent? I don’t have the right answer. As an industry we chase tacit knowledge tirelessly, trying to encapsulate in training courses and the like, I chose to go back to (my) first principles.

Sunday, 6 October 2013

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 only good practices in context.’
  • The skills I learn will be added to my overall toolkit, for me, the certification is arbitrary but welcome. The expansion of the tools I have is the aim.
  • Quality can be defined as value to ‘some person.’ That ‘some person’ may have a stake in the Product. I’ll bear this in mind when discussing quality on the course.
  • Testing and return on investment are interdependent. Development on a product can be subject to a similar law of diminishing returns as the amount of testing executed is.
  • Acknowledge the bias I bring to the course. I approach the course as a tester, which influences my focus and aims.
My Approach

  • Make my mission available to all participants, accept challenges and critically assess that mission on a continuous basis.
  • Listen (yes, I do need to remind myself to do this)
  • Learn, engage with the new, and contrast that with your current world view.
  • Identify where the knowledge is of use to you in the ‘real world.’ Plan to apply that. 

So, those are my thoughts, I sincerely hope that what I learn will dramatically change these ideas. I will create a review blog and let you know how I got on!



Monday, 9 September 2013

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 change blindness and functional fixedness barriers lessened allowing the appropriate approach and tools for the testing in hand emerge.

Build your toolkit. When the chips are down and you are in fix, they will serve you well. Encyclopedic knowledge of financial services when testing in an e-gaming context, not so much.

"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 availability this will change interaction. Expectations will rise (or fall), so might volume!
So, next time someone says "there's no functional change", as a tester remember that there is more to a system than the functionality it contains, its behaviour has a profound effect on its stakeholders. 

Remember, if you convert your teapot to be made from chocolate, its function is the same but it's behaviour is pretty different!



Thursday, 22 August 2013

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 happy bedfellows.
2. Take the Heat - take one for the team. If the sponsor wants information and you don't have it, volunteer to get it. Then you can pick the timing of any actions required.
3. Role Power Matters - As much as people show a significant amount of bravado, role power hugely matters. Find out from your team whom it matters most to. If there is fear (rational or irrational) from one or more team members then you know who to shield most.
4. Post Storm Repair - Sometimes there is nothing you can do. You will be railroaded. But, these sponsor interventions come in bursts in reaction to a specific issue so they are finite. You may judge this as defeatist but sometimes you need to pick your battles, so have your recovery plan (people first, then project later) ready.

Unless you want one of these in the middle of your team, you'd better act and fast.



Thursday, 20 June 2013

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





Things are getting interesting. 

Your organisation has been transforming itself to an agile way of working for, say, a year or so now. Now comes the critical moment, which I will hereafter refer to as ‘The Wobble.’

‘The Wobble’ is a series of questions and searching of souls. ’Is this transformation really working?’ and ‘Are we working on the right features, at the right pace, with the right value, at the right level of quality?’ are common. Now, here’s the trick and it sound a little woolly but bear with me, if your business sponsors don’t know that its working, then I’m afraid that this confusion is trying to tell you something. That something generally is that something is wrong.

Like most of life’s wobbles, ‘The Wobble’ itself not the key, the reaction to ‘The Wobble’ is critical. So what are common reactions?

Abandon Ship! Liberally distribute yourselves overboard and revert to chaos. By which I mean your previous methodology, which wasn’t even waterfall, just old fashioned chaos.
Measure everything! Try and enforce blanket metrics across teams which mean little to the business and try and ‘standardise’ progress across teams. Think back to why you wanted to transform your organisation. The prison of meaningless metrics probably had something to do with it.
More Resource! Forget you ever read the Mythical Man Month and fully embrace the law of diminishing returns in all its glory.

So, I hear your brains ask, smarty-pants, what would you do?

Don’t panic and add more process – making your teams ‘heavier’ only alienates them, and the business representatives just see more processes and less building of stuff they want. This cycle repeats itself until the team’s produce beautiful reports and documents but no working software. Sound familiar?


Cash Value. In Moolah, Dosh, Wonga, Sterling. In Production - Its time to get honest. It doesn't get more honest than cash. Its honesty tells you where you really are, in your transformation. A lot of features built but still takes two months to put a release together? £0. Building lots of technically interesting features but not what the business wants? £0. I am aware however; very few organisations are willing to be this honest. However, without acknowledging this, you limit your progress and strengthen the power of ‘The Wobble.’

Putting a monetary value on something that is yet to be is hard, but it forces you to ask a great question. If I don’t know what this is worth, then why am I building it. For me the key to agility is honesty, with your team, with your wider project community, with the business. Without it, ‘The Wobble’ becomes more earthquake than minor tremor and may be more than your agile transformation can withstand.

Tuesday, 11 June 2013

What do I want? Everything to change! When do I want it? Yesterday!



 

It has been said have very little patience, which is mostly accurate. I think I can be both extremely patient and massively impatient across different issues of different magnitudes at different times.

That said I like to think I have gained a more considered perspective in the last year or so, particularly in relation to the issue of organisational change. During that process, I have noticed a trend in some of my interactions with others. 

Change, and the demand for it, is being used as a weapon. ‘If things don’t change around here then I’ll be on my way’ and ‘things would never change, so I gave up and left' are statements I’ve heard.

Even in my variably patient/impatient state my recent experiences have taught me that change is an ebb and flow process. The rate of change can be easy and fluid, or hard and unyielding, but never, ever, linear.

This rate of change versus the amount of patience is never more prevalent than when an organisation is in the process of agile transformation. Across various organisational levels, from directors to developers, patience is a rare commodity.


I believe the source of this trend of impatience is the innate human inability to see the bigger picture over longer periods of time. We simply struggle to see beyond our immediate situation, and the pain of change is often underestimated.


For example I have consulted on agile transformations in recent years, where my own and others frustration with progress grew over time. However when I look back I realised that the organisation had come from a state of:

  • Multiple projects in progress for each team, most of which never finished.
  • Uneven team skill sets; some with no test, analysis or deployment focused individuals at all.
  • No test automation or continuous integration/delivery.
  • Long, drawn out projects, which sapped morale and encouraged attrition.

To, in a relatively short space of time:
  • Each team worked on one project until it was done.
  • Each team had a blended skill set.
  • Almost every team had continuous integration and delivery integrated into their processes.
  • Testing individuals had 3 or 4 tools in their locker for testing at DB, Service and UI levels, plus an appreciation of the subtler arts of exploratory and context driven testing.

There were still issues to be resolved, but I know which the more desirable state for a working environment is. 

In short, when it comes to change, I find that many cannot see the wood for the trees. Next time you get frustrated, remember where you began and try look at the bigger picture.