When a team is first getting started with Agile, finding a starting point can be a daunting task. As Agile veterans debate the fine points of perfecting their Agile techniques, novices may lose sight of the fundamental Agile development principles. "If you want to adopt Agile testing, where should you start?" they may ask. "Which Agile techniques would you tackle first?"
These questions came up last year in the calm before Øredev in Malmö Sweden. That's where we held something called "Lean Coffee," a meeting format where participants discuss and vote on topics in five-minute increments.
It was not the kind of question you expect to hear at a small table at a coffeehouse in suburban Sweden -- nor did it seem that we would be able to answer it in just five minutes. With a former chair of the board of Agile Alliance and the lead authors of three text books around the table, it seemed unlikely that we could all agree.
It actually took just about sixty seconds for us to agree on three Agile development principles: retrospectives, whole-team testing, and self-organized, self-directed teams. Let's take a look at each of these three Agile starting points.
When you look back at how things went, with intent to reflect, learn and come up with ideas or plan to try something new, that’s a retrospective. Sometimes called "post-mortem" or "after action review," the retrospective is exceedingly powerful. It is empirical -- grounded in what has actually happened -- and suggests trying things not as a new process, but instead as an experiment. The team can try this and try that and use what works.
More resources for Agile retrospectives
The simplest form of a retrospective is to have every member of the team identify what went right on the project so far, what went wrong, and what to do differently next time. Framed this way, the challenge is to keep the discussion focused on improvement, not mired in blame and the past. When I use this format for retrospectives, I usually build a large list of the team's improvement ideas, then have the team members vote for their top three favorites, sort the list and focus on actually doing a few things at the top of the list.
Another Agile development principle is whole-team testing, which is an organizational design where the entire project team determines a test strategy and shares responsibility for the outcome. It means that instead of testing in a corner, the testers are working with the analysts, the programmers and management to determine what to test, how to test it, what to automate and what tests can be skipped.
When I come into an "Agile" organization and hear about the "test team," that does its own work off in a corner, conducts its own retrospectives and is "responsible" to "assure quality," I get a little uncomfortable. Yes, it is possible to have some success this way, but a team that doesn't share the burden will find itself with strange optimizations, where fast programming does not always mean fast release to production, where some people are working overtime and others are taking off at 4:00 p.m. because they are "done."
Employing whole-team testing means shifting the goals of each part of the team toward shipping the software, not just completing one task. That means programmers are not done when the software is coded, but instead when the software ships. It prevents the blame game, and also allows testers to see into the minds of the other team members, giving them an entirely different picture for the risk profile.
There are a handful of practices associated with whole-team testing. One, the Three Amigos meeting, clarifies requirements, but without a team that functions as a whole, those exercises tend to fizzle as each role looks after its own interest.
Self-organized, self-directed work teams
After the retrospectives comes the hard part -- change. The team might want to re-assign a tester as an analyst or vice versa. A tester might want to start running the build system. The programmers might decide to run the automated checks that demonstrate "done" as soon as they complete a story instead of waiting for QA to come back to it after the fact.
This is how a self-organized, self-directed team works. They implement the change (as an experiment) and judge the change at the next retrospective by the results it created.
Plan-oriented teams need permission. They may have a document that describes the process that needs to change, or perhaps they need sign-off from someone who is on vacation this week. Perhaps the group needs buy-in from an external group. Whatever the reason, plan-oriented teams don't feel that they have the power to decide for themselves to make changes. This lack of decisiveness hampers the effectiveness of an Agile adoption.
Why these Agile development principles matter
Retrospectives, whole-team testing and self-organized teams matter because they allow the team to define its own strategy, one that's grounded in the real issues of the day. "Cookie cutter" strategies fail because they are based on someone else's situation. Command and control fails because it cannot adjust to the changing situation on the ground fast enough.
Retrospectives start with what changes to run -- framed as experiments. Whole-team frees up the team to think of quality as a whole-team issue. Self-organized teams have the freedom to make these changes.
These three Agile development principles may not be all of Agile, but starting from them, software quality teams can derive Agile strategies to fit. Without them, your team can't adapt, or at least, it can't adapt in a way that is decided by the people doing the work.
If you want a decent litmus test for the spirit of Agile testing -- rather than the form -- retrospectives, whole-team testing and being self-organized will get you pretty far.