Agile 101

In this post I’ll discuss some of the basic concepts in Agile. This post is meant as an introductory discussion to detail the high level concepts in agile and how they relate to testing.

So what’s Agile?

Agile is a project methodology, meaning it’s a way we choose to run projects. The basic core to agile is the focus on getting people building / doing things rather than talking about doing them.

All types of projects generally go: I want this > Build that > Check the build is what we wanted. In Agile we try to make the asking for stuff shorter so that we can get to the building, which we do by asking for less and not asking for perfection up front.

Asking for less (or taking less time to ask for stuff) up front means we might deliver the wrong thing… BUT THAT’S OKAY! We’ve released much earlier and can ask our customers for feedback and then change our product quickly too.

Flavours of Agile

Kanban – The business just keeps asking for stuff constantly and the team just picks stuff from the top of the list of stuff to build. This means we constantly trickle out releases.

Scrum – We time-box periods of time to develop in and focus on a few of the asks to deliver in that time. This means we have more structured releases.

Scrummerfall – Like Scrum but have no plans to iterate on the things we deliver. We plan to deliver the whole project all at once.

Okay Cool… How does it work?

In this section I’ll give a high level descriptions for the parts of agile delivery, this will be based on Scrum. The below diagram gives a basic overview of the flow of work (click it to expand it).

“I want this“

The business will ask for things that they want to product to do, these will be captured in a backlog of work to do. This will be added to and refined as the project goes on.

“This is ready”

The backlog of things needs to be understandable for us to be able to work on them. We use meetings such as Triforce to groom these asks into a state of ready to work on (this means they tell us what’s wanted clearly and we can estimate how long it’ll take). Many teams use a document called a Definition of Ready, which is a checklist of criteria that a piece of work has to meet in order to be ready to work on.

“We’ll work on this”

The team (or squad) chooses work from the backlog to work on and deliver within a sprint (a predefined period of time). We use a refinement meeting / sprint kick off to talk through what the work is and agree what to work on. The idea here is that the team gets to choose what we pick up and how much they work on (based on any estimates of work sizing they’ve made).

“Here’s what I’m building”

The team then works on the agreed list of work for that sprint, picking up items from a sprint backlog, implementing them and getting them into a state of done. This state of done means that the work we’ve implemented is good enough to be released / shipped* meaning we should ensure these are tested and understood as part of the implementation. Many teams use a Definition of Done, which is a checklist detailing all the things a piece of work has to meet to be considered finished (e.g. is this tested?).

*Release or shipped quality levels may differ based on “how good” your product needs to be.

During this period of work teams will have a daily stand up. This is a meeting to check in on how work is progressing and identify if team members have something to work on or are blocked by anything / need help).

“Here’s what we did”

Once something is seen as done by the team we can deploy it, but usually we’ll do a review back to the business (or other teams) in a Sprint Review meeting. This allows us to showcase the features we’ve worked on to other teams, get feedback and agree that we’re ready to go live with things. This usually takes the form of a practical demo so we can show (rather than tell) people about all the awesome things we’ve done.

how testing fits in

Testing in an Agile environment is a different beast to other types of testing. Work is progressing much more quickly and in smaller bits, meaning we need to be able to test early, test fast and be involved.

Testing early

We cant wait for things to be built and then test them, this would slow down the team or create bottle necks; we need to be able to test throughout the lifecycle of work.

• When product is saying “I want this” testing the ideas to drive out a full understanding of what “this” means.
• When the team is designing things, identifying risks before we build it so that we can put fixes in up front.
• Testing as we build through pairing, reviewing unit tests and ensuring the team is thinking about risks.
• Testing to ensure things are done (as per our team agreement of what done looks like).
• Reviewing things post-release and feeding back insights to the team.

Testing fast

We’re usually the only tester in an agile team, meaning there’s lots of work to look at and this might be more than we can achieve. We need to be smart and efficient with the testing we do.

• Being pragmatic and doing “enough” testing rather than letting our egos push for exhaustive testing.
• Automating as much testing as possible as this is faster and will free us up to look at other things.
• Championing closer to the code testing, like unit tests, as these are faster to implement and run.
• Testing in the small (features and integrations) over bulky end to end processes.
• Testing locally and not waiting for deployments to big environments.
• Trusting when other people have tested things and not retesting them.

Be involved

As a tester, we have to champion quality in an agile team. That means being an active and vocal member of the team and not fading into the background.

• Champion testing by setting out what testing means and what teams have to do. Run workshops and sessions to explain what testing means and educate your collegues.
• Pair with people to support them in development and question assumptions or ask how we’re baking in quality.
• Show what you’re doing by speaking up in meetings and on slack channels, share risks and outcomes of testing and make them meaningful.
• Get involved in engineering, don’t say “oh that’s too technical” but instead work with people to understand things closer to the code.
• Share information by sharing the outputs of testing or offering to run demos for people. Help people to understand what we’ve built and any pitfalls or risks in that.