Don’t Just Ask Questions, Explore Possibilities

Should the Product Owner have all the answers to business and functional questions that arise during a sprint? If she doesn’t, should the business stakeholders have all those answers? If not, what about the end users of the software?

Similar questions apply on the technical side. Should the software developers be able to answer any technical questions that arise? Should the testers know all the testing answers?

‘No’, to all of the above.

No one can be expected to have all the answers around a subject even if that person is the designated subject matter expert. That’s why agile teams emphasize interactions and collaboration. The best answers come from open discussion and exploration.

I see these situations play out in meetings all the time. Someone asks a complex question. Everyone turns toward the subject matter expert (SME) for the answer. The SME doesn’t have the answer and suggests that she’ll get back to the group. Interaction stops. Collaboration never begins.

The answer may be provided at the next meeting or via email to the group. Either way, the group misses out on an opportunity to understand how the answer was derived and to comprehend the meaning behind it.

These scenarios happen because people fall back into their comfort zones. In traditional software organizations, individuals and groups are expected to have expertise in an area. For example, someone may be a database expert, java expert, SQA expert, business process expert, etc. Everyone learns to defer to the designated expert when questions arise.

Want to be more agile? Stop doing that!

Ask more questions. Brainstorm. Explore possible answers. See if the team can find the answer or at least derive options by simply interacting and collaborating for a few minutes. Confirm the derived answer or the possible options with the experts. The team will learn more and retain it for future efforts.

Updated: July 18, 2011 — 10:07 pm