Retrospective on the EnerGuide API: a lot of “firsts” and lessons learned
As our partnership with NRCan on the EnerGuide API winds down, the CDS product team held a retrospective to reflect on our experience, accomplishments and lessons learned.
What is a retrospective?
A retrospective or “retro” is a technique often used in agile development at the completion of a sprint. Sprints are used to accomplish something in a defined period of time (at CDS we do two week sprints). Each sprint contains:
- a goal of what is to be built
- a design
- a flexible plan that guides the build
- the work of building, and
- the result of the build (at a minimum, some increment of usable functionality)
At CDS, we hold a retro at the end of each sprint to review what worked, what didn’t work, and what we could have done differently. Each team does this a little differently, but in this case, team members were given a few minutes to independently answer the following:
- What went well during this sprint?
- What didn’t go well during this sprint?
- General comments and/or questions
Responses are written on post-it notes or shared virtually by remote team members. When finished, each member takes a minute to explain their responses to the group.
As members share their responses to these three questions, themes start to emerge. The retro facilitator groups responses by theme for later voting by team members.
Once everyone has contributed, each member is allowed to vote on up to three themes for team discussion.The themes with the greatest number of votes are discussed in greater detail, which generates lessons learned for the product team.
Here’s what we took away from our final retro for the EnerGuide API product.
Team communication must extend beyond daily stand-up meetings. Daily team stand-ups are a great way to keep everyone on the same page, raise issues and bring new team members up to speed quickly. But, to ensure everyone works together as a team and not teams within a team (i.e. research, design, development, etc.), members need to ensure communication with one another throughout the day.
Incorporate weekly partner stand-ups starting at the discovery phase. Our partnership with NRCan included weekly partner standups, which helped ensure our partner was on the same page as us in terms of what we’d accomplished, what we needed to accomplish and any blockers we needed to remove. Starting this practice at the discovery (rather than at the build phase) would have been a great learning experience for our partner and could have helped in better understanding user needs.
Conduct user research with real users. It became apparent early on in our user research that some of the users we spoke with were one or more people removed from the users we needed to speak with. Probing to find out who the ultimate end user was led us to the specific information we needed.
No design decision is too small for usability testing. To demonstrate the capability of the API to non-technical users, we built a Proof of Concept (PoC) web page. Usability testing was conducted to determine whether a predictive query tool would work for users. While this was a very small task to ask users to do, the insights garnered proved invaluable in determining the design direction to take.
A dedicated product manager with a single vision for the product is critical to challenging assumptions and ensuring product team alignment. As this was one of our early partnerships, we had to get to work in the absence of a dedicated product manager. While a few team members did a pretty good job sharing this role, a dedicated product manager would have saved us some time and hiccups along the way.
Co-locate whenever possible. Co-locating at NRCan helped us tailor our capacity building to meet the needs of the NRCan developers we were working with and, in turn, having NRCan developers co-locate at CDS gave them insight into how we work.
As we concluded the final NRCan EnerGuide API product sprint, one of the themes that emerged was “firsts” for NRCan’s Office of Energy Efficiency. From automated testing and using GraphQL to build the API itself, we broke new ground. Most importantly, we were able to help NRCan realize the value of putting users at the forefront of product design, and get their feet wet with adopting modern development practices.