Rhythm Is Gonna Get You
Every team has a unique personality, replete with quirks and idiosyncrasies. Even scrum teams in the same company who ostensibly follow the same processes and schedules end up with slight variations in how they work.
For example, a company with multiple teams may follow a retrospective format that calls for 15 minutes of gathering happy, sad, and puzzling items. However, one team may invite team members to write items on a whiteboard for 15 minutes before the retro starts, while another team asks team members to voice their items aloud while a member transcribes items to a spreadsheet as they’re called out.
Each team also develops a cadence, or rhythm, around their work, from inception to production delivery. Unless you’re working on my ideal team (next blog post?), teams can easily default to working in a series of mini-handoffs, which means work can get blocked when there is no one to receive a handoff.
…teams can easily default to working in a series of mini-handoffs
Mini-handoffs happen when a designer gives a mockup to developers, when a tester finds a bug and adds it to the backlog, when a product owner finds a previously undiscovered requirement and sends a story back for rework, or when developers change system configuration as part of implementation. While testers cannot single-handedly eliminate handoffs, they can influence when and how these handoffs occur so that work flows smoothly through the team.
Here are a few ways that testers can help a team hum along.
When you see something, say something. As in - ask a question. Don’t wait and see if something becomes important enough to mention, or for the right time, or for your turn - bring it up when you see it. Asking questions, no matter how small, can uncover potential issues and more importantly, build a common understanding for the team. This is one of the biggest lessons I’m learning from my teammate, Lisa Crispin (@lisacrispin). Fearless questioning! She’s a rock star.
Oh, those cosmetic bugs are so obvious and tempting to write up. Look away! There’s plenty of time to polish those later, and as I’ve mentioned in previous posts, your designers are all over those.
So HOW to find the big bugs fast? Take the time to explore - don’t start by checking off met and unmet requirements. Perhaps a conundrum, but working with time pressure to accept stories quickly means you might miss the big bug staring you in the face. Explore with some basic paradigms first - you’ll be surprised how many features fail the 0, 1, many paradigm.
Have an on-going conversation with developers. With tools, sometimes it’s easier to communicate through the tool than face-to-face. Co-locate with your developer or developer pair so that you can eavesdrop during development and ask questions (see #1) and also they can eavesdrop on you while you talk loudly to yourself during your exploring.
If you’re finding big bugs fast, then keep minor items that aren’t central to the story purpose as separate bugs or stories. Don’t dangle the latest shiny object in front of your developers - let them stay focused on completing the essential parts of the current story - THEN ask them for help in grouping and prioritizing minor items. Much as we like our tools, the reality is that detail gets lost in long descriptions, task lists, and comments. If your dev team or pair has moved on to another story, it may be easier for them to circle back around and fix multiple small bugs, rather than include them in the current story and have them get lost. By now, you know your team and what works for them. Keep in mind that continuous delivery is the goal, NOT delivering everything perfectly at once.
Don’t dangle the latest shiny object in front of your developers.
One of the gifts of agile is that development work gets broken down into manageable chunks. Over time, the chunks naturally become pretty much the same size. The size ends up being the size that a developer or pair can pick up and deliver in a single stream of work, without having tangents to implement dependencies or peripheral items. Testers can blow the whistle when stories contain too many moving parts, are taking too long, or seem to need a lot of rework. Are product owners the only people on your team who can put stories in the backlog? Change that, too. Developers and testers can break large or complicated stories into right-size stories that will fit into the team’s rhythm.
Yeah, I’m not fond of that song either, but it’s a great intro for the analogy I’m about to make - which I think is brilliant, by the way. In music, “basslines work along with the drum part and the other rhythm instruments to create a clear rhythmic pulse.” The baseline also is important in “supporting and defining harmonic motion.” Testers are the bassline of a team - supporting the rhythm of the team and also contributing to the depth of the final work. Pretty awesome, eh?