5 Process Changes We Adopted to Deliver Quality and with Speed during this Pandemic

Fareed Huda
4 min readMay 3, 2020

As states around the US start to partially reopen while enforcing social distancing, it seems more and more unlikely that we will have people going back to offices the same way we used to.

The organization I work for, currently doesn’t intend to reopen until the end of May, at which point we will only allow handful of people to be in the office at once, so social distancing can be maintained. This is more important for open office setup like ours. For my team and I, it means that we continue to mostly work from home through the summer and perhaps longer.

In order to adapt to this new normal, there are certain steps we have taken. These steps have allowed us to deliver fast and deliver good quality changes to the digital products we manage. Here are five key ones:

1. Local Environment Demos

Before pushing their changes, my development team is now doing demos through screen-share directly from their machine. These demos happen during the development, while an enhancement or feature is only partially complete. This allows us to discuss requirements that may not be clear or need more details, address any unusual behavior and collect testing ideas or elaborate test cases that were not originally covered. Most of all, it has allow me to provide quick feedback early on, rather than waiting till the end of the sprint during my validation (process change no. 3 below).

2. Mid-Sprint Demos

These demos are different from the first one. In mid-sprint demos we are doing a demo of features to our business. In our case our business folks are our customers.

Mid-sprint demos have allowed us to address feedback early on. It has also allowed us to expand on requirements where possible (if we can accommodate within the same sprint), to improve the user experience. This process change has also allowed us to prepare business on what they can expect to see in the product. It allows them to be prepared for the changes and communicate that to the different user groups that will be impacted.

3. Product Manager’s Validation

This is not a new for us, but we do this more religiously and more vigorously than before. As a product manager, I personally validate any changes that are going out. During this validation I run functional test cases related to the feature, enhancement or bug fix. I also run some level of regression testing based on the journeys that the change set impacts.

By doing this we have been able to address many defects prior to handing off a new enhancement, feature or bug fix to QA team. This in turn has allowed us to put more focus on the next sprint while QA team completes testing in parallel.

4. Collaboration with QA Team on Testing

This is relatively new for us and we are still learning and adapting. As part of our regular process we give our developers user stories, detailed requirements and wireframes. These artifacts are used by developers to complete their development tasks.

I use these same artifacts (and discussions in requirement review session, as well as analysis and design sessions) to prepare functional design document which includes some details of the design and solution. Also, in this document we have to include functional test cases as well. In order to add those, I collaborate with QA team. This allows us to cover same test cases — both the positive and negative scenarios — which in turn results in delivering defect-free (or low defect) product to QA team for testing, as most of the defects are identified during my validation (change no. 3 above) much before handing off to QA team.

5. Evening Stand-ups

In addition to our regular morning stand-ups, we included an evening stand-up. Even though we call it ‘evening stand-up’ it is really an afternoon stand-up. We have this from 3:45 pm — 4:00 pm. In this stand-up we don’t expect the developers to provide update on what they worked on and what they plan to work on. The only thing we discuss here is blockers and if there are any updates from the days meetings. Between 4–5 pm, I reach out to developers who are either blocked or want to discuss something or do a quick demo. These discussion allows developers to keep moving for the rest of the evening or the following day.

--

--

Fareed Huda

A product management professional building digital experiences that connect customers with brands.