Sep 23, 2021
Agile Team Thrown into the Fire
It’s 9am on a Monday morning in July and our Agile team of user experience and software development pros return from a long weekend, rested up and prepared to dive back into our regularly scheduled programming (developing weather and fire behaviour tools for the BC Wildfire Service (BCWS)), when our Product Owner joins our morning standup to say, “Stop everything, we’re going to pivot.”
Don’t worry — Agile pivots are way more fun than Ross, Rachel, and Joey getting sofas stuck in stairwells, for all the 90s kids reading this.
If you’re curious about Agile, it’s a method of delivering software incrementally, allowing us to identify user needs, test small pieces of work frequently, and continually improve — ensuring we’re solving the right problems, and delivering value quickly.
And that’s exactly what prompted this pivot. In what we now understand to be one of the worst wildfire seasons on record, unique challenges were emerging for the hardworking folks of the BCWS, and we were well-positioned to help.
THE OPPORTUNITY
Every single day, starting very early in the morning, Fire Behaviour Specialists analyze the relationship between weather conditions, vegetation, and the diverse topography across BC to provide expert advice to firefighting crews and planning and operations teams.
With persistent hot, dry conditions and most of the province on high alert throughout July and August, fire behaviour professionals were spread incredibly thin this year.
Analyzing and predicting fire behaviour across the province is an art and a science where expertise, experience, and data inform a complete picture of likely scenarios and associated risk. Data was where our Predictive Services Agile team was positioned to help, allowing the experts to focus on analysis and crafting actionable advice — quickly.
Enter the Fire Behaviour Advisory Tool, more commonly known as FireBAT.
HOW WE DID IT
Self-organizing teams and a great deal of trust are two of the key principles underpinning the Agile method. Our Product Owner, the BCWS legend Dana Hicks, assessed the problem, set us up with a few core requirements, and empowered us to figure it out.
Our team follows a two-week sprint cadence that allows us to learn, deliver, test, adjust, and repeat — ensuring we’re constantly adding value and remaining user-centered.
In sprint 1 (weeks 1–2) we went from a problem briefing to delivering a working prototype to a closed group of stakeholders and users inside of four business days. This ensured we could test and learn, while managing risk.
While our User Experience (UX) Practitioner Tess Good interviewed and shadowed fire behaviour folks to understand how they work, our development team of Conor Brady, Sybrand Strauss, and Andrea Williams dove into the APIs and equations that would automate predictive fire behaviour calculations.
Valid, trustworthy data was our primary focus and the biggest risk to our success and impact, which prioritized our efforts in this first sprint.
Being a distributed team, on day 1 we kept a virtual meeting running all day for rapid ideation, brainstorming, alignment, and delegation. It was a stressful but energizing day!
We made a few trade-offs to add value quickly — the pace of Agile development is meant to be sustainable, and design and technical excellence should always underpin our work. But, because the window to make an impact on the fire season was so short, we consciously took on UX and technical debt in the short-term.
In sprint 2 (weeks 3–4) we began to focus on adding critical functionality and improving usability and performance of the tool. By testing early and often with users we could prioritize the most pressing opportunities and pain points that impacted the goals of the product (time on task and access to data).
Building a minimum viable product (MVP) in a short amount of time can be challenging. With FireBAT, users and stakeholders immediately saw the potential for diverse applications of this tool and had big ideas. We captured this in a roadmap document, but we were relentless about keeping the tool as simple as possible in order to deliver value quickly and remain focused on the primary problem.
Lessons were learned along the way — we tried to avoid the Not Invented Here Syndrome, a belief some hold that in-house development is always superior to existing implementations, e.g. component libraries or front-end frameworks. That said, after some trial and error we found that in some cases developing bespoke features made us faster, and supported the customization necessary for our unique context and user needs.
By sprint 3 (weeks 5–6) our users were indicating their core data analysis task was now supported and working well-enough, so we began to address the critical technical and UX debt we had been tracking in our backlog, and started returning to incremental work on the other products we develop and support for the BCWS.
THE OUTCOME
Within four to five weeks a minimum viable product (MVP) was available to all fire behaviour experts in the BCWS, with analytics demonstrating significant daily use.
Qualitative feedback validated that our MVP reached a complete state when we learned the following:
The fire behaviour experts trusted our product — if we didn’t get this right, nothing else mattered. The risk of getting it wrong was twofold; bad data produces bad advice — in a severe season the margin for error is low to nonexistent, and it would mean lost credibility for our team as we build more wildfire products.
Time on task to generate advice each morning was reduced by 50%. Automating fire behaviour calculations allows the experts to be experts — instead of crunching numbers and juggling multiple apps, they can focus on analysis and crafting advice, and spend more time in the field directly observing conditions.
Access to good data supports decision making — in addition to crafting quality daily advice, FireBAT allowed folks to run scenarios that informed bigger-picture decision making such as the State of Emergency declared on July 20.
Recording historical data supports continual improvement — with export functionality in this new data product, historical analysis and the retrospective conversations that will be taking place this fall/winter are much better supported.
This is a big win, as accessible, reliable data to inform decision-making is a cornerstone of the Government of BC’s Digital Framework for a modern, digital government.
Finally, working remotely was an advantage — given that we support the BC Wildfire Service, with operations centres in Castlegar, Kamloops, Parksville, Prince George, Smithers, and Williams Lake, involving stakeholders, users, and collaborating as a team was seamless with the help of a few digital tools.
Our team believes that if one person on the team is remote, everyone should be considered remote (even if a few people are in the same location). This is an inclusive strategy practiced by many distributed organizations that puts everyone on a level playing field, with all knowledge sharing and team-building moments experienced equally by all.
Also notable — working incredibly quickly on a dynamic challenge arguably accelerated us through Tuckman’s team development framework of forming, storming, norming, and performing, given that we had a few new members of the agile team join this summer. So, don’t be afraid to take on a challenge here and there — great things can happen!
With the urgency of the fire season now behind us, we’re looking forward to growing FireBAT and other fire behaviour tools this winter, following a similar approach but with a more sustainable pace.
It’s an honour to support the brave and hardworking folks of the BC Wildfire Service and we’re highly motivated to continue to deliver value as we investigate how data and predictive technology can support in 2022, and beyond.
Author: Tess Good is the UX Practitioner on the Predictive Services Agile Team.
The Predictive Services Agile Team was formed in 2020 and incubated in the Exchange Lab. We develop technology for the BC Wildfire Service as part of the Information, Innovation, and Technology (IIT) Division.
The IIT Division within the Ministry of Environment and Climate Change Strategy is leading the modernization and transformation of business practices for British Columbia’s Natural Resource Ministries through continuous improvement projects, new technology options and operational information management/information technology.
