If you’re reading this looking for a simple formula for implementing an Agile methodology you won’t find it. Agile by the numbers is a pipe dream because agility isn’t a task you accomplish, it’s a trait you develop. And developing traits takes time and follows no formula.
Here is a list of key steps on the path of becoming agile.
- Stop accomplishing tasks. Agile people can’t focus on the task, they need to focus on the goal. When we’re surprised (as we almost always are) we need to be able to re-think the task in a way that lets us achieve the goal.
- Stop being patient. I remember asking a tester if the developer was aware of a major blocking bug he’d found. He said he’d sent an email. When I pressed him it turned out he’d sent the email four hours earlier. He’d been unable to work on the Story for four hours and he didn’t even know if anyone had read his email. When one developer wasn’t getting what he needed from another he said, “I know she’s busy and I don’t want to nag.” If someone’s counting on you to get something done you can’t take these delays.
- Stop being clever. There’s an old story about a digital toaster where a software developer overly engineered a design for a digital toaster that eventually required a high-powered (for the time) computer to run. The original intent of the story was to remind software developers that, in the real world, you only want enough software to get the job done.
- Stop rushing. People who are rushing make foolish, sometimes harmful mistakes. We’ve all experienced this, usually realizing that we could have afforded just a little more time to think carefully. In writing software you will introduce a silly defect that’s hard to track down, or forget to log the data that could have helped you find it. In testing you will skip a key step and miss a key defect. When documenting the defect you may leave out key information that makes it harder to debug. Take the time to think and work in the most effective way possible.
- Stop playing it safe. All of software development involves risk. Things will go wrong. Eventually something you do will go wrong. These risks are inherent in what we do. What we want to do is identify the risks early, especially if they will actually kill the project. We don’t want anyone to be foolish but we want people who aren’t afraid to experiment to find out what is possible and what isn’t. Often it’s faster and easier to do an experiment than to do an analysis.
So, to recap (not in a particular order, but at least there are numbers):
- Stop accomplishing tasks, start achieving goals.
- Stop being patient, start getting things done.
- Stop being clever, start being productive.
- Stop rushing, start working quickly.
- Stop playing it safe, start playing it smart.
If you’re interested in learning about Agile QA (not by the numbers) check out the 2-Day Agile QA Course to be held at the beginning of October.