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.

communication

Advertisements

Not In This Lifetime

gnr

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