Agile Development — Are we building the right thing?

DavidTzemach - Sep 27 '22 - - Dev Community

I think that I can say for a fact that most Agile teams (and especially their testers) feel there is never enough time to test. But for me, testing the software is only one part of the equation. I often saw how organizations waste time developing software that doesn’t meet their customers’ highest-priority needs or products whose cost of investment exceeds their value to the company.

I worked with some great development teams who have mastered the most advanced technologies and practices, allowing them to deliver robust products throughout the years. Most of the customer issues found and reported in this project turned out to be missed or missing requirements caused by a lack of communication/set of expectations.

Also, now you can perform browser test automation on the most powerful cloud infrastructure then leverage LambdaTest.

Always ask “Why”

In my experience, one of the most critical ways that Agile teams and their testers can contribute to their customer is by making sure they focus on the business purpose of each new feature they need to deliver. When we can ask why customers request the feature and the problem they are trying to resolve, we’re more likely to build the right thing. During feature review, the team (Engineering with Product) will discuss different aspects such as feature requirements, goals, acceptance tests, and how to measure success. With this discussion, the team can create a roadmap and set business and technical milestones.

A constructive discussion about “why” we are building this product or why our customers need it, involving both product and engineering team members, frequently leads to the realization that the customer isn’t asking for a product they actually need or that what they are asking for won’t solve the problem. This is an essential conclusion as, in the end, if the customer doesn’t get the right solution, the business may suffer.

This is because the ROI and delivered functionality are vital components of the product’s business value. This is why it is so important to focus on the “Why” before diving into creating the functionality. So, when working on a new business requirement asked by the field, keep thinking about building the “right” thing and any other questions that will help you keep product quality high.

Practices for Customer Engagement

Understanding the “Why” can be difficult in most cases as the customer is not always available for the team. So, how can we overcome this barrier and answer the “Why”? There are many effective practices to help the business and delivery teams figure out the right things to build.

I proposed some tools for examples and requirements in my book “Agile Quality: A Practical Approach,” including mind maps, checklists, flow diagrams, and more. Here, I want to focus on Impact mapping as an additional practice that I found valuable for understanding customer needs and using them to increase the value we deliver and create tests that guarantee the quality of the product.

Leverage LambdaTest automated testing for a faster, reliable, and scalable experience on cloud.

Impact mapping

Impact Mapping is a strategic planning technique (introduced by Gojko Adzic in 2012.) I use it in many organizations during product development to visualize the impacts that various people (in the method they will be addressed as ‘Actors’) will have in contributing and helping us achieve a common business goal.

A goal might be something simple such as implementing a specific tool that will promote discussions, something you want to achieve as a team (for example, better RCA and retrospective processes ) you want to promote, or it might be something big you want to achieve such as implementing a new development framework that will take weeks and even months.

Impact Mapping has been adapted from other planning and brainstorming tools such as Flow-Diagrams, Mind mapping, etc. (all covered in my Book “Agile Quality: A Practical Approach”). Impact Mapping is a light, simple, and structured way to make sure the team maintains their focus on the purpose of what to build, and it helps identify the most valuable features to build first.

The focus shifts from “What are we going to do?” (as I usually see in organizations at the beginning of a new project) to “Why are we building this, what is the problem it will resolve, what is our goal, who can help us promoting the project and what risks can getting in our way” For, me the most significant thing about it is that it increases and encourages every participant in the room to focus on the goal and not waste time on bureaucracy and other political issues that may influence the decisions made at the end.

At the end of the impact map process, you should have a diagram that visualizes the process outcome, including:

  • The goal the team wants to achieve or problem statement.

  • High-level prioritization of project scope that could be delivered.

  • What impacts (if any) the development process and how.

  • List of people in the business who help or hinder our ability to achieve our goal.

  • List of potential impacts and risks that may affect the project.

User Story that translates deliverables into specific features to be implemented.
An impact map is a visual mind-map structure used for answering four fundamental questions:

Q1: Why? — The central node that starts the whole process is used to answer “Why are we doing this” and “What is our Goal?” Your goals should define the problem or requirement to be solved and are usually presented by someone who represents the business (Product Owner, project manager, etc.).

For Example:

  • Increase gross margin.

  • Reduce field tickets.

  • Increase the number of monthly Active Users by x until the end of the year

Q2: Who? — This node is used to describe the people (Individuals, Roles, and Key stakeholders) who can make an impact (who can help us, and who is getting in our way?”) on the outcome. And if we simplify, we need to map the people who can bring the team closer to achieving the goal or prevent us from reaching it.

For Example:

  • Support team

  • Existing customers

  • New customers

  • Customer success agents

  • Marketing department

  • Finance department

Do you know which are the most wanted automated testing tools that have climbed the top of the ladder so far? Let’s take a look.

Q3: How? — During this stage, the team will identify what they want out of each actor to help promote the team from achieving their goals. So, a good practice to generate this list is to ask questions like “How could our actors’ behavior change to help us achieve our goal?” or “Which behavior is most likely to get us to our goal?” Or “Which behavior is most likely to add a negative impact on our ability to reach our goal?

Let’s say that you want to increase awareness around your company website. An ideal impact would be getting users (Identified in the previous node) to spread the word about the site to their friends using a subscription program.

Q4: What? The fourth and last step of the impact mapping process identifies the deliverables (Tools, Features, Processes, and Business activities) that actors will use to achieve the desired outcome. More importantly, they represent what the team can do to help them.

For example, let’s say that you’re managing a technical blog that helps users increase their knowledge. Your goal is to boost traffic from new users. The impact you want is to get users to access your app more frequently.

So, one of the ‘Features’ that can help you achieve this goal could include an E-mail campaign or push notifications to potential readers. It will allow them to remain updated with new content uploaded to the blog and give them a reason to return to the blog.

Who should attend this session?

I have a rule for my teams that each meeting should include all stakeholders to promote the meeting goal. So, as long as you keep it in mind, for this session, I would usually expect to see the “Product Owner,” “Project Technical Owner,” facilitator, and project sponsors (Business and Technical).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .