As a software test team member, I am always interested in acquiring new problem solving skills. To that end, I...
recently attended a Problem Solving Leadership (PSL) course taught by Jerry Weinberg, Esther Derby and Johanna Rothman. I don't think of myself as a leader in a traditional sense. I do some teaching and coaching, but for the most part, I wanted to learn more ways I can help my own team continually improve in my role as a team member. In this tip, I share advice on how to develop better problem solving skills.
Is winning everything?
A stereotypical view of a leader is someone who's the smartest person in the room and who tells the grateful team members how to best do their jobs. But we know that no leader can come in and fix our problems for us. True leadership involves understanding how to help a team identify its biggest obstacles and come up with experiments to try to chip away at those obstacles.
Much of PSL consists of simulations. The facilitators cannily create an atmosphere of competition by having the class self-organize into teams that often compete for points. I've felt the same type of competitive atmosphere on real-life teams. Even though there is actually nothing to win, we get distracted by a desire to out-do everyone else, instead of simply focusing on solving the problem at hand. Sometimes, the obvious reward is meaningless, and the true reward is missed or forgotten. The lesson I took away is that I should help my team focus on goals that mean something to us.
In more than one simulation, as PSL participants we got so engaged in the competition (which didn't even exist) that we didn't ask for more information. This information was freely available and would have made our tasks much easier. We accepted the rules given at the start and didn't ask good questions that would flush out hidden assumptions. That's never happened on a real project, right?
Tip #1: Challenge assumptions
It was hard to remember to not be so accepting of the rules I knew about, since they were given to us by Weinberg, Derby and Rothman -- three highly respected leaders in the software world. Even when I told myself, "In this next simulation, I'm going to remember to step back and consider the situation and ask good questions," I got sucked into the fake competition and forgot everything else. Our daily work urgency has the same effect.
Any action is better than none, right? A good leader takes the initiative! Well, no.
Much of PSL is built on ideas I've learned before. Set-based development -- an idea that originated in lean software development -- is a terrific strategy for finding a good approach to implementing a new feature. My own teams have often conducted "bake-offs," for example, when selecting a test automation framework. Still, when a team is in a crunch situation, it's easy to forget to "divide and conquer."
In one of our PSL simulations, our team was floundering while under time pressure, arguing over how to solve the problem at hand. Fortunately, in that exercise, we had been allowed to "hire" Rothman as our consultant. She advised us to use affinity voting to choose the top two or three ideas, then divide the team into subgroups to develop each idea for a limited period of time, and present the results to the whole team. Interestingly, after doing so, we found that the top three ideas were all viable solutions.
Tip #2: Delay decisions responsibly
I think that set-based development dovetails nicely with real options. In Agile development, we delay decisions until the last possible moment, keeping alternative approaches going as long as we can, deferring decisions until we have the most information possible. In our last simulation at PSL, we found we could keep our subgroups working on the alternative problem solutions longer and combine aspects of each into one that really rocked. As a result, I understand the practical application of real options much better. It's important to fight our inclination to avoid ambiguity, and get enough information to make a good choice.
Over and over at PSL, I reacted to problems by immediately taking action and trying to "fix" things. Any action is better than none, right? A good leader takes the initiative! Well, no. None of my attempts was really successful. Sometimes taking action prevents you from obtaining easily available information that would lead you to a completely different solution.
Tip #3: Understand it's not about you
Another important takeaway from studying PSL was the realization that your actions don't affect only you. Your moves pull other people along, too. If you go in the wrong direction, your teammates and stakeholders will trail along behind you.
What problem solving skills have you developed? Let us know.
How a QA leads' responsibilities differs from other roles
Dig Deeper on Software Development Fundamentals