This is a guest posting by Johanna Rothman.
Many people think of leaders as a person with a title, such as “technical leader,” or “dev/QA lead,” or “manager.” In agile approaches, everyone on the team takes a little leadership. Some people lead others in development, some in test. Some people might lead in terms of clarifying how the product works. Agile teams embed some leadership in each person who serves the team.
One tester, Cindy, wanted to know more about how the search performance worked so that she could test it better. She first tried creating a few scenario-based tests to understand how the search acted in each circumstance. She couldn’t tell the difference. She decided to ask Trish, the developer, for help.
Get TestRail FREE for 30 days!
Rethink Leadership
Many people think leaders lead “from the front.” Too often, they think of heroes, as people of action. That’s because the leaders have all the answers.
Leadership looks different in an agile team.
Leadership in an agile team is often about creating experiments, collaborating to create an adaptable culture, and reflecting on the results you and the team see.
Sometimes, it’s more important for the leaders to have good questions. Especially if you see the need for experiments.
Experiment to Learn
Above, Cindy created some personal experiments in the form of scenario-based tests to clarify her understanding of the search function. She used the scientific method:
- Based on her experience, Cindy formed a hypothesis that said her variety of tests would return varying results.
- She created an experiment: several different tests that she expected would return the varying results. She expected to learn from these tests.
- Her results puzzled her: Why did the tests not return different results?
- She learned that she didn’t know enough. She asked for help. Once she received help, she would make a new hypothesis.
Many of us have great ideas. We form hypotheses, the first step. Sometimes, I need to create several alternatives before I’m ready to experiment. I might run short experiments—maybe an hour in duration—to decide which hypothesis to start with. If my total experiment time is short, I might create several experiments, as Cindy did.
Once we measure or assess the results, we learn something. Here, Cindy learned she didn’t know enough. When I’m puzzled by results, I often learn I don’t know enough. I think of this as meta-learning. It’s helpful for me, but not necessarily for the product.
Cindy exhibited a form of leadership by asking for help and asking questions about her results. Cindy and Trish discovered the product didn’t work they way they expected.
They both expected different results than what they saw. Cindy’s perspective was about the whole product because she used system-level tests. Trish’s perspective was based on her detailed knowledge of the code. They both expected different results from what they saw.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Collaborate for an Adaptable Culture
As Trish asked for help from the rest of the developers, Cindy created some other system-level tests to see if she could pinpoint the problems. Trish asked the entire team to mob for about an hour, to see what was wrong.
The entire team gathered around the projector. Cindy was a little nervous because this was only her second time mobbing. She was willing to try.
She stood and explained how she’d run her tests. After a few minutes, she sat down and handed the driver role to the next person. The entire team reviewed the tests, and reviewed the code. They discovered a masking defect (a defect that prevented certain code from running). They fixed that problem and continued to mob.
They discovered two more defects, once they fixed the masking problem. They fixed those. Now, Cindy’s tests ran as expected and the entire team saw different results—results Cindy expected.
When the team mobbed, they collaborated to identify and solve the search problems. Often, agile leadership is a more collaborative approach than more traditional leadership. The team adapted their work as they needed to do so, to understand and fix some deep-seated problems.
Agile approaches create more opportunities for collaboration, in the form of pairing, swarming, and mobbing. Cindy and Trish had informally paired earlier that day, one act of leadership. Trish asked the team to mob, another act of leadership. And, the team agreed to work together, yet another act of leadership.
The team adapted its approach for this particular problem.
Reflect and Learn from Results
After they fixed these problems, Sam, another developer, suggested they conduct a quick kaizen to understand what they had learned. Sam’s suggestion was another act of leadership. Even though the team worked in iterations, Sam thought they had learned too much to wait for a formal retrospective.
The team knew what the problems were (the masked defect plus two others), and how they had solved those problems. Now, it was time to brainstorm some ways to prevent those kinds of problems in the future.
The team generated several ideas. One idea was a fix in the form of continuous review. They’d built this search functionality before they had experienced pairing or mobbing. Now that they had more review techniques available, they made a list of product areas they wanted to make sure to pair or mob on. That would provide continuous review.
They generated several other ideas they would treat as experiments. The product owner was in the kaizen, and he agreed to create small experiments for the next few iterations. That way the team could experiment with these process and product changes.
Embed Leadership into Everyone’s Role
Cindy started demonstrating leadership when she created experiments so that she could learn. Trish and Sam and all the other team members continued leadership actions.
In an agile team, consider how you can embed leadership into everyone’s role. You might have to create experiments to learn.
This article was written by Johanna Rothman. Johanna, known as the “Pragmatic Manager,” provides frank advice for your tough problems. Her most recent book is “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”
Test Automation – Anywhere, Anytime
