Musings from last week about how data infrastructure is a lot less visible, yet carries a lot more decisions, effort, and influence on the software that relies on it (the frontend / API layer).
Code for Canada Fellowship Snapshot – Maddy, Mike, and Andrea May ‘19 – Month 0 Onboarding brings us together in Toronto. We dive into government structure, inclusive design, and start digging into the problem space of federal government business travel through a design sprint. June ‘19 – Mont...
It’s hard to believe, but it’s our last week. It’s week 40.
As I realized how close we were coming to the end of the fellowship, I took a look back over the past ten months.
We’ve done a lot: countless hours of user interviews, talked with 50+ users, synthesized insights that led to key concept prototypes that have influenced the future of business travel within the federal government, and we spun up technical explorations that have opened conversations around how we can improve and build a more robust and flexible software ecosystem.
I’m extremely proud of what we’ve been able to accomplish.
Thank you to my team, Andrea and Mike. They’ve been incredible partners throughout this process.
Thank you to our government partners for bringing us on board, taking flight, and for their support along the way.
Introducing agile practices to a non-development team
Week 34 | February 10–14, 2020
Today, I wanted to share a little bit about my team’s journey of introducing agile rituals and practices to a non-development team. A couple weeks ago, we had a productive and meaningful team retrospective with our government partners. We were really moving in sync as a whole team.
I have spent the last seven, going on eight, years on various development and technical teams from small itty-bitty startups to large hardware corporations. The fellowship has been a new, interesting challenge for me personally. I have a technical background (engineer turned product manager), and for the first time, joined a team that wasn’t majority engineers.
So, it wasn’t without some bumps along the road to finally find a pattern of agile rituals that did work for us.
Background
“Agile” is a word that gets tossed around a lot. Some may say that it earned its place as a buzzword long ago. It can evoke an emotional response without understanding the meaning behind the word.
But, agile isn’t simply a buzzword. It means that you’re able to move quickly and easily. Or, as a team practicing agile software development, you break things up into small chunks of work, and frequently reassess and adapt your plans. And there is structure and methodology behind it.
I’ve come across various practices and tools in my career, but I’ve never had any formal training or education. The concepts of Agile and Scrum are intuitive to me, as I’ve been working in various shades of them over my career, and have learned through experience.
Let’s do a little recap of what they are, and what the difference is between them. This took me a little bit of research... If you know the drill with Agile / Scrum, skip down to “Testing out different agile practices”.
Agile
The Agile Manifesto is the founding document of Agile software development.
“Written in February 2001 by 17 independent-minded software practitioners. While the participants didn’t often agree, they did find consensus around four core values.” [Source]
Image Caption: Agile Manifesto
The authors of the Agile Manifesto also published twelve principles behind the manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile vs. Scrum
Scrum is a framework to deliver software in an agile way. I often hear people use them synonymously; and admittedly, I have stumbled on where the line between the two is drawn.
According to the Agile Alliance, simply put, “Agile” is the “ability to create and respond to change.” It’s an umbrella term that encompasses all the frameworks and practices that empower teams to be responsive to change, and focus on users.
Scrum (and other things like Lean Startup and Extreme Programming) are frameworks that have been generalized to facilitate and support agile practice.
Scrum & other frameworks
Image Caption: Subway Map c/o Agile Alliance
Got it? We’ve got agile, and under that umbrella, we’ve got practices, and frameworks.
If you’re visual like me…
Image Caption: Agile, frameworks, and practices
Testing out different agile practices
What didn’t work
Early on, I suggested that our team try agile practices like daily standups, retrospectives, sprint planning, t-shirt sizing, Kanban, and 1pagers. Our little product team (one developer, two product managers, and two UX designers) jumped in and were willing to try them out.
We quickly found that the kind of work we were doing was highly dependent on other teams and external stakeholders. The practices of regular software development didn’t work for us, especially since we’re not in a delivery phase; we’re operating in the design thinking and exploration phase. Tasks often ended up in the “blocked” column of our Kanban board, which affected morale and made sprint planning much harder and unpredictable.
Image Caption: Gartner Design Thinking, Lean Startup, and Agile
What did work
Weekly standups
Our government partners are doing many things, across many disciplines (program management, communications, research, service design, procurement). The weekly team-wide standup is one practice that has stuck around since September 2019. The ritual of coming together on Mondays at 11am, and hearing about what everyone has going on, has helped create transparency and connection.
Team retrospectives
We recently picked up the practice of retrospectives again. This time around, instead of using stickies, we used FunRetro, so that our remote colleagues could participate fully. I’ve seen a development team use it successfully, and wanted to try it out. The team was a bit skeptical and unsure at first, but it went over waaaay better than expected.
I especially liked the feature that allows you to hide votes until after voting is finished so that people aren’t biased.
Image Caption: FunRetro Kanban board
I was also highly encouraged by the discussion that followed. The online platform provided a level of anonymity, which I believe created a safer space for people to share thoughts more candidly.
Coming out of the retrospective, we identified some concrete action items (like sharing our showcase presentation with the team!) that will help work towards more adaptability and open lines of communication within the team.
Now what?
What worked for me and my team might not work for you. I think all I’m trying to say here is -- get out there and start! Take a look at the practices and frameworks available, and try them!
Figure out what works for your team, and don’t be afraid to face the fact that not every practice will work for you; especially if you’re on a non-development team.
Are you shipping code regularly? Try standups.
Are you in the research / design thinking phase of a project? Try retrospectives.
I’ve mentioned the experimental pilot we’re running a couple of times now.
Our goal is to “make it easier for travellers and travel support to book travel using the booking services of their choice, while still complying with Government of Canada travel directives.”
Our hypothesis is by allowing travellers and travel support to book their own travel, we can reduce errors, save time, and even save money, and hopefully public servants can feel empowered, with more flexibility and autonomy.
Instead of launching the pilot on analysis and hypotheses only, we’re testing this experience with a handful of travellers.
Andrea wrote about prototyping on the Code for Canada blog. Instead of building and testing software, we’re building and testing a new service/process/experience.
So, what does this actually mean for the handful of travellers that are participating in the experiment with us?
Travellers and travel support (team administrators, executive assistants, and other supporting roles) can try booking outside of the centralized tool that is currently available
They can book with the service of their choice (*for example*, through an aggregator like Expedia, Kayak, Google Flights, etc; direct with Air Canada, Porter, WestJet, etc; or even through an in person travel agent)
Travellers still have to comply with the policies, guidelines, and directives
We’re keeping the scope tight to domestic travel, short-term travel only, along with a couple other constraints that keep the experiment focused
I’ll refer to this as “self-service booking”.
Initial Research
We started out by doing a bunch of investigation with our pilot participants and other internal users in their department.
We learned about and mapped out travellers’ and travel support’s current process.
We interviewed their finance department and learned about the policies and directives that constrain and administer travel processes.
We observed how approval forms and expense claims are processed, and reimbursements issued.
We learned about travellers’ concerns if they were told the booking tool they currently use were being shut off.
Then, we kicked off 7 weeks of experimentation. We’re about half way through this experimentation now.
Risks & Opportunities
Some of the biggest risks are:
Increased risk of losing money when prepaid and pre-booked tickets/reservations are changed (i.e. cancelled or modified). Business travel is riskier than personal travel, and changes are more likely in the event that a conference or meeting is cancelled or rescheduled.
Decentralizing the information (since there wouldn’t be a central tool), and the risk of adding more tools to provide the information and support that someone might need at the time they need it, like booking a hotel vs. booking a flight vs. knowing what to do in an emergency
Cognitive overload of pushing the burden down to the traveller and travel support to make more decisions, and chose the platform
Some of the biggest opportunities are:
Users already book hotels directly, so this will not change but perhaps encourage and empower existing behaviour
Empowering public servants to make their own booking decisions based on personal preferences and needs
Creating a direct link between travellers and service providers for better support in unexpected or emergency situations
Potential for overall cost savings
Midpoint Learnings
Last week, Andrea & I reviewed some of the learnings, and Andrea came up with a framework to summarize some of the feedback we’ve received so far. Then we presented these back to key stakeholders.
Caption: Barriers inhibiting adoption of self-service booking, both physical and attitudinal
Alternate Caption: 3x3 table with different categories of barriers (payment, fare classes, changes) and content supporting both physical and attitudinal barriers
These are really concrete challenges that our pilot participants are facing right now, and that must be overcome if we want to roll this out further.
Some of the big, immediate hurdles that have surfaced:
Not everyone has a credit card, which is required for booking flights, trains, or reserving hotels
Not everyone is comfortable running up a personal credit limit, especially if they’re going on multiple trips in a short timeframe, or travelling to remote places where flight prices can be in the thousands of Canadian dollars
The airline industry has become more complicated, and it’s not always clear what fare class is the best value for money, or appropriate for the likelihood that the trip will be cancelled or changed
After discussing these for about half an hour, one of our stakeholders - and a big champion for this experiment - paused. He turned to us and said, “This is a learning process. I’m glad we learned all this now before we included more people in the experiment, or rolled this out to our department.”
It was so exciting to hear that one of our stakeholders saw and truly understood the benefit of keeping the scope small, contained to five people, before we considered roll out to an entire department.
The work doesn’t stop here. We’ve identified hurdles that need to be tackled, and the experiment improved, before any consideration should be made to expand to more participants or departments.
Whew, so, we’re behind on blogging. It’s been a busy few weeks around here.
Instead of sharing details week over week, I thought I’d give a high level recap/share the highlights.
Transition
Our fellowship ends March 27th. It feels too soon to be discussing off-boarding and handoff, but we want to be prepared. We need to ensure our partners are well supported after we depart -- across documentation, skills, and knowledge sharing. We’re figuring out how we can support the team, and properly document and hand off our prototypes, service blueprints, and other work.
A lot of the heavy lifting is making sure the prototypes we have developed are framed correctly, and we identify an owner after we’re gone.
Self-Service Booking Experiments
With a small group of participants, we’re running an experiment where travellers are booking without a centralized tool. The past few weeks have allowed us to create clarity for the participants in what’s expected of them.
We’ve also had check-ins to stay updated, get their feedback, and learn about their experience trying to book without a centralized software tool. We’re digging into issues they might run into, like flight cancellations/changes (What happens if my flight gets cancelled? What if I’m travelling to a business meeting and the meeting gets cancelled?), payment (How will I pay for my flight, train, bus, etc.?), and “unhappy path” situations.
Retreat
We had the opportunity to come together with our fellowship cohort in mid-January. We reconnected, reflected, and discussed stories that we can tell when we look back on our fellowship.
Caption: A team that washes up together... does great work together?
Alt Caption: Man and two women stand beside each other facing a mirror. Man is wiping his hands with a paper towel, the two women are posing, one woman takes a picture into the mirror.
Service Blueprinting
Andrea has been deeply involved in the design of service blueprints, which will be a part of providing recommendations for the future GC travel experience. We’ve done many iterations of blueprints, and are digging deeper into new, specific areas -- like getting approval.
Prototypes
Ongoing development, incorporating feedback from users and feature suggestions from stakeholders.
Caption: Mike on Mike
Alternate Caption: Man stands beside a television screen presenting a slide with a picture of himself with a concerned expression, eyebrows raised.
I’m a little behind on writing this. It’s been a busy few weeks here: lots of productive meetings, Andrea has been head’s down on design and service blueprints, Mike has been at a conference and building prototypes, I’ve been organizing a dedicated test group that we’re experimenting with and supporting Andrea in meeting with folks across finance, managers, travellers, and different organizations to further understand how travel and finance are related.
But… back to week 24!
---
Monday through Wednesday were largely organizational days for me: lots of emails and preparing for a kickoff meeting. Exploring opportunities to experiment with other organizations to put a couple ideas -- for example, what would business travel look like without a centralized booking tool? -- to the test.
We often hear that the regions feel left out since they’re away from the National Capital Region (NCR). We’re also interested in how the process of an organization that is based outside of the NCR might differ from one that is here, so we’re talking with a regional organization to experiment with them and do user research.
On Wednesday, we escaped from rooms with our government partners for a holiday celebration!
On Thursday, Andrea led us through a really interesting activity. Since we’re exploring what decentralized booking for travellers looks like, we started by brainstorming the benefits of a centralized booking tool. Then we ideated around how we could provide those benefits without having a centralized booking tool.
Some of the benefits we brainstormed of a centralized booking tool are:
Reporting -- collect and centralize data for insights and to negotiate with vendors
Simplicity -- e.g. stored preferences and payment cards, aggregated options
Surfacing policy/rules and giving travellers flexibility in cancellation and rebooking
Directly ties into expenses
Based on that foundation, we ideated how we could solve for those in a world where booking is decentralized (i.e. where people can use the services of their choice, e.g. Google Flights, Kayak, Expedia):
*Disclaimer that these are just some of the ideas we had, and are just ideas!*
Offer a non-mandated booking option
Open APIs for profile information
Give travellers a recommended itinerary
A travel guidebook with resources that link out to policy/rules
One travel manager who has all the expertise and can book for the traveller
On Friday, we were back to talking with users! We chatted with a public servant at Transport Canada (TC) for which travel is a big part of their job. They presented some really interesting insights into travelling to remote locations and in and around the northern territories of Canada. For example, unpredictable weather is a huge factor. They can be stuck in a remote location for days until the weather passes.
It’s pretty surreal to think that we’re rounding out week 22 of 40 embedded with our partners. That’s 55%, whew!
We made serious headway this week:
Talked with 6 travellers and travel arrangers. Mostly focused in the NCR, but some in other provinces as well.
IF YOU’RE INTERESTED IN PARTICIPATING, SIGN UP HERE!
If you’re unable to access the GC Intranet at this time, please email me here, or DM me on Twitter here, and we can connect.
Made significant headway on organizing an upcoming pilot with a small test group, where we will be prototyping tools to test whether we can improve their travel experience if they had flexibility in where they booked their travel.
Opened the conversation with our comms team about how we can share our prototypes more widely.
Wrapped up the first version of a fully interactive, functional prototype that helps you put together a travel estimate.
Started getting feedback on the prototype to learn whether it satisfies user needs. (Does it help reduce the time to build an estimate? Does it reduce errors in the estimate?)
Got a local Postgres database set up to consolidate some large Excel files, and allow me to run SQL queries (my data bread and butter) on the historic travel data we have.
Developed a first draft of a current-state service blueprint.
Caption: Mike and Andrea discussing the travel estimate prototype.
Alternative caption: A woman with blonde hair and blue jacket stands holding coffee beside man with red jacket sitting in a chair. They are looking at a laptop computer hooked up to a monitor. They are in an office cubicle.
This week was heavily focused on the building and testing portions of our newly minted team slogan:
Learn &
Build &
Test &
Repeat.
As a product manager, I’m stoked that we’re prototyping, seeking data to define success/failure of the prototypes, and getting feedback from real end users which is leading to… what is shaping up as a product backlog!
Another big turning point this week was changing our working style slightly. We’re shifting back to sprints -- but one week sprints! This will allow us to have really short, tight feedback loops from prototyping to getting feedback on it, and shifting direction based on the feedback very quickly before we invest any more time in a bad idea.
Our partners led us through a one week design sprint modelled after the Google Ventures sprint. Us fellows participated as part of the sprint team: the ones participating in all the activities and doing the work of sketching, deciding, prototyping, testing, and being a part of the conversations.
The goal of this week was to bring key stakeholders together in one room, and share our various backgrounds and expertise to quickly design and test a piece of the what the future GC travel service could be.
This was honestly one of my favourite days because of the sticky-ing! I love sticky notes as an outlet for my thoughts. Through the hours of research findings, we listened, and captured “How Might We” (HMW) opportunities, and then grouped them into general buckets such as “approvals,” “booking,” and “training.” It was great to see HMWs that spanned across the travel solution -- not just the booking software, but the end-to-end experience.
Andrea always reminds me that design sprints are useful for testing the riskiest ideas, since the activity is so low risk. It’s not months of timelines and development. It’s 5 days (sometimes less) of discuss, review, build, test, and learn.
Given that, the sprint goal we came up with as a team was “In two years, the system does not require any training.”
Day one was a very full day. The last step was to lay out the user journey map of the roles of traveller, travel arranger, and financial support. I was surprised at how quickly the user journey map came together with all the stakeholders in the room, from travel to policy and finance.
We selected the top HMWs and put them on the map. By the end of day one we had identified three areas to focus on moving forward: profile, booking, and expenses.
Day 2: Sketch
Day two started off with looking at solutions from the general marketplace, and other domains. I was part of the discussion on expenses, where we looked at three current solutions: Expensify, Shoeboxed, and Concur’s expense tool.
I used Expensify at a previous company, and liked how seamless the email receipt forwarding and mobile app was.
The afternoon was full of sketching, from crazy 8’s to in-depth sketches. Unfortunately, I wasn’t there for the afternoon because I was over at NRCan sitting on a panel about innovation in the public sector.
I spoke about innovating and making change from the ground up. We all have a responsibility to push the public service forward, and there are many tools -- like agile or scrum or kanban or daily standups -- that anyone can borrow and use in their own work or introduce to their teams, to work more efficiently, learn faster, and reduce risk.
Day three was storyboarding. First, we took a look at everyone’s sketches from the day before, and put design dots (small coloured sticker dots) to vote on ideas we liked.
Then, we gathered into three groups, one for each of the focus areas (profile, booking, expenses). Each group created a storyboard of the concept.
One of the most effective tools I found when creating the storyboard was introducing the idea of a “parking lot” -- if the conversation was going down a rabbit hole, we parked the idea or topic in the parking lot, which allowed us to refocus on creating the storyboard.
Day 4: Prototype
Some of the questions that guided our prototyping were:
What if we had a centralized profile?
What if we had a booking tool that highlighted all the incidentals and fees?
What if we had a prepaid credit card with an upper limit of what you were approved, so all your expenses were already in the system and all you had to do was review and submit the invoice when you’re back from your trip?
We broke out into three folks prototyping with Axure and each person addressing one question. At the end of the day, we reconvened and stitched the prototypes together.
As the day went on, I reflected on the fact that, even though the three people prototyping had work that was “theirs,” it was the conversations of the sprint team as a whole that led to that point, and everyone swarming and working together was additive to create a prototype where the whole was greater than the sum of the parts.
Day 5: Test
Test day! We brought in 5 travellers and travel arrangers, and the Jumping Elephants team did guided usability testing. The sprint team was able to see the usability testing in real time.
Culture eats strategy, and process, for breakfast. One thing that became clear during testing with real users was that the way things are happening in practice are not always as they’re designed.
It was valuable to get this feedback in real time. Not everything tested well. Not everything was perfect, or perfectly designed to answer the questions we posed at the beginning of the week. What was important was learning quickly, and now we can continue to iterate on these questions and concepts.
Wow... I wouldn't have to keep track of all my receipts?
Prototype tester + traveller. This is in response to a prototype concept* where all expense items are managed as part of your credit card statement. This testing is part of design sprint week, where we’re looking blue sky, facilitated by the Google Ventures Design Sprint framework.
*DISCLAIMER: This is a concept only!
Last week was full of prototypes, and connecting with folks outside of our team. It’s important that we network outside of our own world because, among other things, (1) there are exciting projects happening all over, with lots of great ideas and parallels that we learn from and draw into our own work, (2) input to our prototypes makes them better and we learn about bad ideas faster, and (3) we capture more, better cross-disciplinary considerations.
Prototypes
I continued to update the content of the “Travel Guidebook” concept based on the latest information from folks across the Government of Canada.
How might we help newer public servants navigate the travel journey from end-to-end?
Andrea and Mike worked on another prototype -- a “Travel Estimator” to assist travelers in putting together a budget estimate.
How might we help public servants be aware of established city rates and limits?
We were delighted to join the TCUX Meetup (Transport Canada User Experience). Thanks to Noah for the invite, and Andee for singing it from the rooftops! We had a great conversation about using prototypes to “show the thing,” have better conversations, and learn quickly.
Week 17: Prototypes, digging into data, and exploring different recruitment methods
Week 17 | October 15-18
Monday
Monday was a federal holiday here in Canada, so we took some time to re-energize and spend time with family and friends. I’m grateful for the four months we’ve spent with our partners so far, all the wonderful, dedicated, and inspiring folks I’ve met, and all the learnings shared by others.
Tuesday
Things are ramping up over the next few weeks! We’ll be at CanUX (Nov 1–3) and FWD50 (Nov 5–7). Our government partners are also running a weeklong design sprint that we’ll be participating in.
We wanted to carve out time to open our doors, and invite others to poke and prod at our ideas. In light of all the upcoming events, we decided to move our Office Hours UP to Tuesday October 22nd, 11am–3pm. Please join us at the NAC if you can!
Mike and I broke ground on Tuesday trying to get MongoDB running locally, so we can be better prepared to handle larger data sets.
If you have successfully worked with large datasets of Protected B data before, please reach out! I’m looking for ways to handle, load, and query data and gather insights, beyond massive Excel spreadsheets.
I’m available on Twitter @madsewins, or email at maddy [at] codefor [dot] ca.
Andrea kicked off a line of investigation into the state of payments for travel.
Wednesday
Mike attended the design community of practice, hosted and held at CDS, and learned about various recruiting techniques.
As a team we discussed how we can test and recruit users through more channels like intercept interviews, one-on-one interviews, by setting up at other events like open houses and conferences, and through asynchronous surveys.
Thursday
Andrea and Mike have been ruminating on the concept of a travel estimator/calculator. We built an early iteration of this during our Code for Canada onboarding, but we didn’t test it with users. They’re going to take what we’ve already built, clean up the interface and content, and test it with users to understand whether this could be a useful tool.
Friday
I reconnected with Dan Tse, former Code for Canada fellow, and current product manager at CDS! He very kindly shared a piece of Starter Stuart, his sourdough starter, so my roommate can make delicious sourdough bread!
This was one of the best weeks I’ve experienced so far in this fellowship. There was something magic in the air. I hate mornings, and I got up early for the gym and morning meetings almost every single day this week. And I felt invigorated and energized, to boot.
As a product manager, it’s incredibly rewarding to see my team taking ownership and pushing forward their initiatives – whether it’s research or design or prototyping or teaching others or connecting with other departments/organizations – and this inspires me daily. We’re really jelling as a team, and moving faster than we have before, enabled by established communication channels and frameworks in place that allow us to share and empower each other’s work while championing our own projects/initiatives.
And of course, bringing user’s voices to the table when we can, and in lieu of that, advocating for the user’s voice, to keep us moving in the right direction -- to build a user-centric travel solution for the Government of Canada.
Maddy Ewins - Code for Canada @maddy-c4c - Tumblr Blog | Tumgag
jbbartram-illu
2087
baratheonpilled
dededos