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”.