Jazz…Nice

One of the books that has made a big difference to how I’ve been thinking about teams, people and the dynamics that go on as people create software is a book called The Jazz Process

The book is written by Adrian Cho who both works in an agile team and plays Jazz, so he’s in a good place to talk about the parallels between the two. The book has slow points and low points, but on the whole it’s pretty good at explaining how teams can work better to produce good software.

In a bid to clear my house of books I’ve decided to give my copy of the book away to the person who gives me the most interesting answer to this question:

If you were to form a jazz quartet (that’s a group made up of four people) who from the Testing world would you choose and why?

Answers here please:

The Jazz Process

Agile South Coast Meetup

I attended the Agile South Coast Meetup last night in Southampton, the first one I’ve been to in about 3 years. It was good to meet up with the guys again and despite a small crowd it was an interesting evening. The first part of the talk was about change models and then the second part talked about how we could change the group and move it forward. I for one didn’t realise it was a group committee planning session but never-the-less some interesting discussions were had.

The group can be found on LinkedIn here and Twitter here.

Mike Williams kicked off the introduction followed by Plamen Balkanski who talked about making a difference using the change management 3.0 model by Jurgen Appelo.

Plamen talked about why we should make change happen?
He cited a prosci study 2009 which showed that teams that can change were successful.

Plamen also mentioned a number of excellent books about motivation, change and inspiration including Drive (By Dan Pink), and Creating Passion-Driven Teams (By Dan Bobinski)

How did we get here?
Plamen mentioned the three major changes in management

Management 1.0 – i.e Taylorism
Management 2.0 –  same frameworks plus add on like, TQM and Six Sigma
Management 3.0 by jurgen appelo – which talked about Complexity.

Plamen introduced the following ideas from Management 3.0

1. Energise people
2. Empowering teams
3. Align constraints
4. Develop competence
5. Grow structure
6. Improve everything

He then moved on to talk about change management 3.0.

He talked about dancing with the system if you cannot control it. And then moved on to talk about the Deming Plan. Do. Check. Act framework.

Talked about the adkar model
– awareness
– desire
– knowledge
– ability
– reinforcement

He then talked about stimulating the network and the innovation adoption curve (initiators, innovators, early adopters, early majority, late majority, laggards)

He also then moved on to talk about the 5 i’s (Information, identity, incentives, infrastructure, institutions)

As you can see we talked about a lot of useful models and frameworks which were then put in to practice in the second half of the sessions as we worked through each model with reference to Agile South Coast user group. There were some good ideas generated for the future and how the group can move forward.

If you’re in the South region of the UK (Hampshire, Dorset etc) and interested in scrum, agile, lean etc then it’s worth joining the group and getting involved.

Anchoring

Anchor

Imagine you are being asked to give an estimate for the completion of a piece of work. Imagine that this group includes Testers, Product Owners, Programmers and representatives from different departments. Imagine that you are going to have to haggle, negotiate and barter to get the time you think you need to do a good job.

Now imagine that I could give you a little trick that *could* help you get the number of days you actually want.

The above scenario is a common occurrence for many teams. We are often asked to give estimates for work.

Some teams use techniques like the Delphi method, rubbing the goat (don’t worry, it’s safe for work), like for like (same estimate as programmers) and a variety of other techniques. These are all valid and I’ve seen each one work; including the goat.

Now imagine this. As you are in the process of estimating you have the direct ability to dramatically influence what others agree on simply by shouting out a number (or holding up a number in Planning Poker (first round)). This number could be anything, but the more extreme the better (at least for this imaginary situation).

Simply by offering a number you have the ability to create an “anchor”.

I’ve been studying a lot about “anchoring” and how this relates to price and numbers. Anchoring is a bias (cognitive one) that occurs when people place too much emphasis on a piece of information. Michele Smith wrote a good blog post on anchoring and testing here.

So let’s look at this from a generic example point of view.

You are looking to sell something to someone. In this instance the price is not listed. You think this “something” is worth about £2000; that’s what you want to get for it.

So you throw in a crazy high price of £5000. The buyer laughs and nearly chokes. So you smile and say comforting words, then come back with a price of £3000.

According to much of the research in anchoring the above scenario would likely end in you selling this “something” for a higher price than if you had opened the pricing at £2500.

According to studies on pricing you have thrown in the anchor of £5000. It is now acting as a reference point in the buyers mind. Your offer to sell for £3000 now seems like a real bargain compared to the £5000. The same applies when buying. Go in low and then move up from there. This offer that no-one is ever likely to accept is curiously known as a “dead dog”.

When I read more around price anchoring I see this in everyday life.

You’ve surely seen the adverts:
“Was £100 – now only £25”
or “Reduced for a short time only from £100 to £25”.
In these instances the £100 is an anchor. The fact that the product might only be worth £25 anyway is why anchoring is used in the first place.

Another technique is to offer your products (with slight variants in deals) for different prices. One incredibly high price which no-one would likely buy and a lower price which is really what you want to sell your services/product for. In this example the research suggests that you will sell more of your “lower price” service because people are using the high price as an anchor. High end designer shops go mad with this technique.

Every day you are exposed to anchors in pricing.

So what has this got to do with Testing?

A lot really.

Going back to the example earlier, let’s say you want to get an estimate of 10 days to be accepted. So you throw in an estimate of 25 days and give a list of reasons why this might be a good estimate.

Lots of smirking, muttering and breathing in air through teeth. You sense the discomfort.

So you now go for an estimate of 14 days and give some reasons why you could achieve this and why this might still work for you. According to the anchoring theory it seems likely that this estimate could very well be accepted. In comparison to 25 it’s a good deal.

In a sense this is the interesting side of Planning Poker. The first round is intended to be called at the same time, for the very reason that anchoring plays a large influencing effect in estimation. Yet the first round can often throw in curve balls. Three people give 5 points, one person gives 1 point and another person gives 10 points. The second round often has people gravitating from their original number to either the higher or lower; a lot of this gravitation depends on the negotiating skills of the outliers.

A counter to anchoring is something called an Adjustment Heuristic which is essentially a mechanism we use to adjust to the anchor to get closer to our estimates/outcomes.

Anchoring is complex, complicated and very intriguing. I haven’t done it justice here, but it’s an area that I believe warrants a lot more reading about (and experiments). Over the next few months I’ll hopefully share some of what I am learning with you and no doubt fine tune my own thoughts on how anchoring plays a part in Testing.

If you’re interested then here are some resources on anchoring:
http://en.wikipedia.org/wiki/Anchoring

Priceless by William Poundstone

Short but interesting links from Behavioural Finance

Anchoring and Adjustment at Less Wrong

 

Photo by David Feltkamp on Flickr.

 

 

Testing over time

I’ve been using Google Books nGram a lot recently whilst I research some topics for blog posts, books, articles and other writing. It’s a great way of searching on a term and then finding related books. In fact, it’s so good that my impossibly large reading list has grown from 1498 books to 2200+. I know…I will never read them all, but I’ll have a good go.

So I thought I would share with you some of the graphs nGram created relating to Software Testing terms.

If you’ve never used nGram then head over to Google Books nGram page and have a play around. The year data it returns in the table at the bottom are clickable and will lead you to the books that mention your search term…let your expanding reading list begin 🙂

nGram basically works by scanning millions of books for your search term and then providing you with a line graph of that terms use over time.

When you enter phrases into the Google Books Ngram Viewer, it displays a graph showing how those phrases have occurred in a corpus of books (e.g., “British English”, “English Fiction”, “French”) over the selected years. – from the nGram page

Here’s one for the term “software testing”:
Ngram_softwaretesting

(clicking on each image will show a larger one)

As you can see around the 1960’s and 1970’s the term really took off and has grown in it’s use through the last few decades.

Here’s another one, this is “test automation”

Ngram_testautomation

Again, the term really comes in to use in the 1960’s and grows dramatically, but interestingly it drops off in 2000. Did we see a drop in books about automation around then? Or did we start calling it something else? Or some other reason?

Here’s “quality assurance”. Same sort of trend as Software Testing and Test Automation
Ngram_qualityassurance

 

Here’s “exploratory testing”
Ngram_exploratorytesting

Interestingly the term has been around for a while but when clicking through to search for the books you get some very interesting suggestions. Try the search and click through to the books from the 1800 – 1949 – some fascinating looking books.

 

“Test Management” sees a similar trend to “software testing”:
Ngram_testmanagement

 

What about “boundary value analysis”

Ngram_boundaryvalue

 

“performance testing” shows a similar growth:
Ngram_performancetesting

 

“Usability” sees a later rise but the numbers show it was a growing topic of interest between the time ranges. It’s a popular topic now, but nGram only appears to go up to 2008.
Ngram_usability

 

You didn’t think I’d do all of these search terms without searching for “certified tester” did you?
Ngram_certifiedtester

 

Interestingly the term has been around for a while and in the early books it referred to various different roles and responsibilities, mostly associated with science, schooling and adjudication. It grew hugely in the 1980s, again mostly from schools and education before dropping greatly in the 1990’s – possible as school systems went through reform and as electronic marking and computers came to education. It took off again in the 1990’s and 2000’s with a load of books about ISEB and ISTQB certification.

This is pretty vague data but the beauty of nGram is the book search off the back of the term. Clicking through the dates you can grow a large reading list over time of how a term (i.e. idea or process) changes. It’s also a nice way to see what the historical trend in books is for a term. It doesn’t show me (at the moment) anything of significant value; we know the software development industry kicked off over the 1950’s, 60’s, 70’s and 80’s so it’s to be expected that there are growing numbers of books over this period.

But even though I can’t draw anything direct from the data doesn’t mean it’s pointless. I find it interesting, I like to stumble across new books, I like to play with tech and I like to find try things that might later down the line inspire new ideas for me.

Why not have a play around and see whether you can find anything interesting about Testing by using nGram.