What? — Why? — How? A pocket guide for your next project.
As a QA Engineer with more than a decade of experience, you start to see some patterns emerging for solutions that don’t fit the problems.
I wrote this article not just for QAs, but for all professionals that are somehow connected to a software development process.
In the ‘agile’ era of software development, it’s easy to say that your team or company does agile and delivers software in small iterations, all that good propaganda that we like to hear. Still, some of those things might not translate into our daily lives.
I know there is no perfect project, but I’m here to help you understand some patterns and behaviors that will clear your vision, so you can engage with your peers and stakeholders to improve the overall development process for everyone.
And since I know your time is valuable, I will be as direct as possible on this article/pocket guide.
First of all — never underestimate your peers or stakeholders. Everybody has different backgrounds, different strengths, and weaknesses. Don’t be that person that points fingers. In the end, everybody has the same objective: functional software that serves a purpose.
That being said, I will break this pocket guide into 3 sessions with a specific focus that will inspire you to take action.
- What is the current problem that stakeholders are facing?
- Why are they asking for this solution?
- How the stakeholders and the developers envision a solution for that problem.
What?
What is the current problem that stakeholders are facing?
As you can imagine, this is the question that developers, project owners/managers usually have on the back of their heads when a user/stakeholder approaches the team with a problem, right?
Unfortunately, this question is usually overseen. The solution mode kicks in, OKRs are defined, stories + epics are created, and developments start with a half-backed vision of the actual problem.
“We can always pivot and change direction because we are working with agile”.
I cannot tell you how many times I have heard this.
Don’t get me wrong. Sometimes you need to start somewhere if things are not clear for the team and for the user/stakeholders. Prototyping and Proof of concept are fantastic tools to use when in doubt, but sometimes they are not enough.
Understanding a given problem will not show you the whole picture. You need to understand the Whys. The symptoms(problems) make sense only by going to the very core of the issue.
You need to connect to the stakeholder on a human level. Tear down defenses, loosen up a bit and be informal. You don’t need to ask what they had for lunch or if their kids are OK, but do ask about their day, the context of their role, and the painful process they face. Ask them What would be the perfect solution for them.
Why?
Why are they asking for this solution?
This step can be tricky, as people might feel threatened when someone contests their request. Even harder for QAs when organizations don’t encourage processes such as “shift left” (to be honest, this guide is pretty much using the concepts of shift left).
The whole purpose of this step is to introduce a bit of uncertainty and encourage users to review their request and use you as a corporate “rubber duck”.
Asking Why should lead to a deep “What is the actual problem”, and if you have some difficulties asking questions, this is the part where you can be generic. Remember that this process is not about code or software architecture but business solutions.
You can try a few of these:
- When did this problem start?
- Why do you feel that we can solve this with software?
- Why are you requesting this specific solution?
- Are there other users with the same problem?
- What is your ultimate goal?
After understanding the problem, where it came from, and how it affects the users/stakeholders, you can use their expertise for the solution.
How?
How do the stakeholders and the developers envision a solution for that problem?
Usually, developers take for granted the expertise of some users/stakeholders. I did this a lot in my early years as a QA engineer, but time did tell me that every person can impact the development process, and your job is to make sure it’s a positive impact. :)
In this step, I suggest you invite stakeholders to a “pré” solution meeting that will take their input for the final solution.
Only the stakeholders know what is important to them and usually know what they want. Your previous questions were the most important to expand their mindset for this “final” step.
This is where you ask:
- How do you envision the solution?
- How do you see yourself working daily with the software?
- How does this could solution interact with other areas?
- How would you solve this problem if there were no development team to provide a solution through tailored software?
This is also where you can challenge their vision of the end goal, which might also surface root problems that didn’t appear in the initial interactions.
Human interactions are complex, and people have different ways of communicating. Giving them space to think, reflect and take ownership is essential for a healthy development process.
Solution mode might be easy, fast, and sometimes satisfactory, but the success rate could only increase when the “human” factor is considered before tailoring a solution.
I hope these insights help you on your journey as QAs, developers, and anybody that finds joy in helping people through software.
Have a great day :)
