Misheard Lyrics 2

A few posts back, I talked about misheard lyrics and how they can apply to assuming our customers’ needs. After a conversation with a friend, I realised I had missed another aspect. What if we had a non-English speaker mishearing English lyrics? This could change the meaning of the song in a whole different way.

I think this works much like people with different skill sets in a team. So, we have the developer who mishears the lyrics and a tester, whose first language is not English, hearing something else. Possibly, we get test cases assuming one thing and software that does something completely different. Sometimes we even get people hearing something they like and ignoring anything else. Paul Simon summed this up nicely in his song, The Boxer, “A man hears what he wants to hear and disregards the rest”


So how do we fix this?
The answer is Behaviour Driven Development (BDD). So what is BDD?

BDD was created as an evolution of test driven development. It was developed by Dan North as a place to start writing tests. It relates to how the software should work or behave. When a user clicks a button, what exactly will happen, or what does the user expect to happen?

How do we find out these answers? Well, through conversations with business stakeholders and end-users. What BDD allows for is these conversations. It allows developers, testers and business stakeholders to talk before any code is written. This would stop the misunderstanding in the lyrics. It would even allow for all different meanings of the lyrics to be addressed. Everyone gets their view point heard, and all it costs is the price of a conversation.

I’ve seen it save hours of waste in misunderstood requirements. Once the conversation has been had, then acceptance test driven development can start, and everyone is on the same page. Don’t believe me? Try it for yourself! Start small, then tell me all about the results.


Why Ask Why?


My dad used to work in the main Lab in Guinness. He told me a funny story, which I will share.
When he started in 1977, the guys he worked with did, what was called, a KBOS test. KBOS stood for something, he thinks maybe it was “potassium” related. The reason he can’t remember is that writing on the test had faded and all that was left was the initials “KBOS”.

But every day, without fail, someone in the lab would do this test. They would check the potassium levels on some samples. It was such a big deal that other labs would send over samples. All the results would then get recorded in a book and also sent over to another lab. The lab they used to work in was horrible. It was an old run down building full of rats and cockroaches. So eventually in 1988 they got to move labs.
In the move, they were trying to streamline the lab. Making sure only the important tests and equipment was moved. Eventually someone remembered the super important KBOS test. At this point someone asked, “What does KBOS mean anyway?”. Nobody could answer.

My dad had been doing the test since he started as had, it turned out, a number of people for years. Nobody knew why. So, they asked the other lab who they sent the results to. They checked their books. Yes, they had other results different tests to make sure Guinness was not polluting Dublin. Right there beside the results was indeed the KBOS results. But they realised that they NEVER USED the results for anything. It seems somebody, years before, needed to check it for a few weeks, and the test was then passed on to everyone else who started. So for 11 years this test was just done. Years of time wasted on a test that nobody ever even looked at the results for. The guys in the lab had a good laugh about it and moved on.

I think it shows the importance of asking “Why?”. Years ago, had someone questioned the KBOS test then they could have saved hundreds of man hours in doing it and recording the results. So, when you get asked to do something – to develop a new feature, or even define and break it down. Do you ask “Why?”. Do you question the business value? Sometimes you will find that the work is being done just because someone said “Lets do it.” There could be no real reason for it, no value to your customers. You could be wasting time doing something that will not meet the needs of your customers.

After all in the words of Paul Simon, aren’t we all “Just trying to keep my customers satisfied”.

Just Do It


I love hosting retros. Of course, there are hundreds of different ways to run one. But what I want to talk about is how to capture those actions that get missed. What do I mean by “missed actions”?

Well, have you ever been in a retro where you put up something you want to get resolved and nobody votes on it? It has happened to me a lot. What’s worse is that maybe you put up the same thing next retro, and nobody votes on it again. I find it tends to happen with easily resolved problems. Stop breaking WIP, or run acceptance tests locally to stop the build breaking so much. These tasks don’t get voted on as they seem fairly simple, so there is nothing to discuss. So how do we capture this area of waste and get it done?

What I like to do is add a “Just Do It” section to the retro. This can work with just about any retro game, but I will keep it simple.

For me the easiest retro technique is “stop, start, continue, puzzles”. Get loads of post-its and pens/markers. Put up post-its on one of the walls in the room: “stop, start, continue, puzzles”. And one last one “Just Do It”.

We can explain what each term means, “Stop” is anything the team wants to stop. “Start” is something cool they have seen do before, or read somewhere, and want the team to try. “Continue” is a nice way to show past actions that have been working. “Puzzles” is anything the team do not understand. Then you mention “Just Do It” is there to capture lost actions, it will become clear later on.

Give everyone some time to generate ideas, help them by putting them up on the wall, under the correct section.

Then spend five minutes reading out the ideas so everyone understands them, and group them. This is where “Just Do It” comes in. During the idea grouping, you may find some tasks that don’t need voting or discussion, they are already actionable. At this point, say you are placing them under “Just Do It” and assign someone the task of getting it done. Simple, you now don’t lose those actions.

At this point you get the group to vote on what topic they would like to talk about. Everyone then gets three votes each.

Once everyone has voted, you then sort the topics in order of highest voted first. Then you ask the room how to solve the problem in the topic. Give people five minutes to come up with possible actions to fix the problem. After five minutes ask if they want to keep talking about this topic. If yes, give another five. If no, move on to the next topic.

Make sure you capture the actions they suggest on a post it and leave it beside the problem.
Example: STOP breaking the build – ACTION the build breaker buys the team coffee. (You now have an action to fix the problem).

Repeat this until you either run out of topics or the hour is up. Make sure you assign someone to be in charge of looking after each action. Put the actions up on your board or where you do the stand up. I suggest reviewing them every Friday, so people don’t forget to get them done.

I would love to hear how the “Just Do It” lane helps your team’s retros. Also, let me know if you try it with different retro games.

Using retros, we can start to learn from our teams mistakes. As in the wise words of Sum 41, “What’s the point of never making mistakes?”.


Misheard Lyrics

Have you ever sang along to a song out loud and then been corrected over the lyrics?
Happens to me all the time! You hear one thing, and it sticks with you. In fact, it’s so common and so funny that there are websites dedicated to misheard lyrics. There is a Pearl Jam song called Yellow Ledbetter, nobody knows the official words to it. Don’t trust me? Try and find them! If you do, please share them with me.


I find this becomes a lot like Chinese Whispers. The singer sings, and we pick up random words. Some people will hear something new, or even different, to what you might hear. So, what’s the point?

Well, this got me thinking (dangerous, I know). But, if people mishear lyrics and happily sing them wrong (sometimes for years), then how easy would it be to mishear business requirements?

If we just half listen, we end up assuming what the customers wants. Or sometime between what they are saying and what we are writing, the misheard lyrics creep in. This means we won’t know that we have been singing the wrong lyrics until it’s too late to change them.

How do we fix this? How about, we help the customer write the lyrics and agree on them together. Let’s get a tester and a developer involved as well. This way, we don’t just get the words but the music as well. Collaboration is the answer! If we keep the customer in the loop at every step, we will always deliver what they want. It’s that simple, have a meeting with a tester, developer, and a BA for each block of work. This makes sure the work is what the customer wants, testable and actually doable.
Sure, you will still mishear lyrics in your favourite songs, but from now on you won’t mishear your customers.

I’ll leave you with a quote from one of my favourite songs:
“??????”- Yellow Ledbetter – Pearl Jam

Lean Cheating

I used to cheat on school exams.

In fact, a friend and I had a system: He would learn question one and two, I would learn question three and four.

During the exam, he would answer his questions I’d answer mine. Then we would leave the papers on the table so we could both see the other’s answers. We both scraped a pass, the system worked.

Having a chat about this recently, I realised we were using lean principles. We limited our work, had a pull system, and collaborated. Most importantly, though, we trusted each other. If either of us did not put some work in, we would both fail.

This made me think, without trust – everything else goes out the window.

You can set up boards and talk about breaking down work and setting up work in progress limits but, without the full trust from management and the customers, it won’t matter much.

The team needs to trust each other. Maybe people are only used to working in silos, dev teams, test teams etc. They may not fully trust the other teams, they may only have interacted with these teams through emails or a bug tracking tool.

The management also needs to trust that the team can manage its own work. The customer may only be used to a massive document and a two year wait, so trust will need to be built to change that.

Personally, what helped me build trust with others was pairing. Once someone has a clearer understanding of another’s role, it helps break down walls. Testers stop seeing developers as “that faceless person who gets assigned a bug”. Developers stop hating these “faceless testers who keep finding problems with their work”. Analysts stop worrying about whether the software will work, as they have seen it and can happily show the customer.

Everyone gets to sit together and see what each other does. When a team gets good at it, you won’t even need a bug tracking tool anymore.

So much like the band Madness “All I learnt at school was how to bend, not break, the rules”. I also learned the importance of trust, which you can build anything on – including great software!


Defining Agile

A good friend of mine once said to me, “Before meeting you, I always thought Agile just meant not doing documentation”. This made me think that the word “agile” gets said a lot, but what does it actually mean?

There are many different definitions, and different ways of working. So, I can only really say what it means to me.

I started out working on a QA team, writing automated tests from a regression test backlog made up by a manual tester on my team. This was fine and worked nicely until the test suite broke, and then the fun began. The developer would blame me for writing “crap tests”, I would blame the developer for changing something and not telling anyone, and the manual tester would blame us both! I HATED this, every day there was an argument with somebody over something very small. But nobody wanted to take ownership of the problem, for fear of the managers “giving out”.

Eventually I got sent on a Scrum training course with a few other devs and testers. I loved it! I saw the opportunity to remove the stupid daily fights. It made me realise the big take away was communicating and removing the handovers. The handovers were causing the fights. The developer would write some code, forget about it, and throw it to a manual tester who would then write a few test cases and throw it to me to automate. Usually, by the time I had been given the automation task, the code was live anyway. So, who suffered from this? Well other than me, the customers were getting untested, and often buggy, software. But that’s OK, because we had an iron-clad paper trail to pin the blame on somebody else.

The test team used to sit in a different room to the dev team, after the training we tried a team where the tester sat with the developers. Immediately there was a noticeable difference! Instead of a daily fight, there were questions from both sides. There was no longer a “throw the code over the wall” mentality. I got to write tests as the developers were writing the code, and was also able to see the software locally. This meant that my tests were more robust, because if any changes were made then I was told right away and didn’t find out through a broken build in the morning. All that changed was sitting us together and giving us the space for a chat, instead of a fight two or three days after the code went live.

Since then, I have moved on to work in more Lean teams and have seen Scrum evolve into Kanban. This came about from teams wanting to improve the way they work and remove waste. None of this would have been possible if we stayed in our silos and did not communicate.

So what does Agile mean to me? In the wise words of Pink Floyd, “All we need to do is make sure we keep talking”. Let me know what Agile means to you.


Not In This Lifetime


Any fans of Guns N’ Roses will have heard the expression “not in this lifetime”.
For those who don’t know, it was what lead singer Axl Rose said when asked if the original members would ever get back together. In the last year, most of the original band have reformed, mended fences, etc – the tour is also called “not in this lifetime”.
You may be thinking, what has this got to do with software?
Well, after the initial excitement of one of the best rock bands ever getting back together- it made me think. People change. That may seem very obvious, but if it’s so obvious, then why do we still develop software with the idea that people stay the same?

We make these massive plans for software, big promises, big specs. Sure, it will take two years to develop- nothing can possibly change, right? If everything works out two years later, the customer gets a completed functional product. But what if at this point the software is out of date or they have already changed their minds? They are human after all.

Would it not make more sense to embrace the idea of change? Cut out the middle man, remove the spec and replace it with a conversation.

Agree on the smallest possible solution and let the customer play with it as soon as possible; doing this you will learn exactly what they want, and also build trust with them.

This means that if a feature is going to take a little longer, they will see it evolve as it’s built and be aware of where their money is going. With this trust and positive experience, they are also more likely to come back to you next time they need something built and recommend you to other potential customers.

Start with something small and give it a go, you will be surprised what you learn! Maybe next time you are asked to write up a large scale spec you can respond with;

“Not in this lifetime”.