Shifting from planning to learning

Ashley Evans
Good Trouble
4 min readAug 24, 2022

--

About how building an agile organization is ultimately about shifting towards a culture of continuous learning.

This post is written by Sarah Ingle, Jane Lu, and Ashley Evans.

Background: We are a small team within ESDC trying to create enabling conditions for service teams and work in the open in the spirit of sharing our ongoing learnings. Views are our own.

“Field Notes” notebook and a pencil on a boardroom table during a meeting.
Photo credit: https://unsplash.com/photos/EPppwcVTZEo

Barriers to service design and delivery

We’re about 2+ years into building our team and its products — digital services for people accessing social benefits in Canada. Along the way, we’ve discovered some barriers to doing this kind of digital transformation work.

The biggest barrier is the go-live process. Service design teams, agile product managers, and leadership alike agree that the current process is unclear, overly complex, and controlling.

Paul Craig has written about his experience with these protocols. Essentially, service teams are often unsure of which privacy, security, or other governance requirements they need to meet, when or how they need to be met, and who is responsible for determining whether they adequately met them.

As a result, services are often delayed and diminished during development, or blocked from launching altogether. This also results in long or fragmented feedback loops which make it harder to maintain or continuously improve services and to respond to urgent needs with updates.

This is not only disappointing, but disempowering for service teams. Especially, because the team understands the problem space and needs of people affected in detail, and is often the most well-equipped to make decisions about the product or service’s future.

Elevated, winding steps at sunset.
Photo credit: https://www.pexels.com/photo/black-and-white-roller-coaster-106155/

Through conversations with service teams, agile product managers, compliance areas, and leadership, here’s what we’ve identified.

The key problem is that protocols are not contextual, they are:

  • Disproportionate to risk level — e.g. a single go-live process for all products, whether they are built for the authenticated or non-authenticated space and regardless of service features
  • Disconnected from service design phase/maturity of research, design, or development — e.g. requiring details around data collection and use during the Discovery or Alpha phase
  • Repetitive — e.g. requiring teams to fill out the same information each time they interact with a new form
  • Duplicative — e.g. collecting the same or very similar information across different forms or compliance processes
  • Unclear processes — e.g. what it means to complete a protocol is not defined
  • Lacking user participation and public accountability — e.g. public participation in deciding what products/services to prioritize, visibility into feedback being implemented, proactively releasing compliance documentation, etc.

This results in:

  • Teams spending more days watching rather than doing
  • Taking time and energy away from research, design, and development
  • Disempowering practitioners, who signed up to apply their knowledge and skills, not complete one form after another accounting for the work
  • Restricting creativity and problem-solving
  • Creating urgency to deliver underdeveloped products and services

The root problem is a desire to avoid failure by overplanning and creating a sense of false certainty.

From a structural perspective, this barrier shows up as excessive forms to fill out, briefings to give, or checklists to complete.

From a cultural or behavioural perspective, it shows up as top-down decision-making, discouragement of change, or critique without support to find an alternative.

We need to redesign go-live protocols and digital governance processes so that they are contextual, and encourage creativity, responsible design, and learning over compliance, oversight, and risk-avoidance.

Working toward more agile governance

Our team’s theory of change is that if we could redesign digital governance and go-live protocols, service teams can design and deliver better services.

Orienting governance involves a holistic approach. It includes:

  • Looking at and changing our own team structure and org chart so service teams have wraparound supports
  • Making service decisions at the right time, at the right level
  • Changing how we do reporting, so it focuses on learning outcomes and value delivery rather than outputs
  • Having experienced service practitioners assess quality against the Digital Standards, and have those practitioners provide a coaching rather than gatekeeping function
  • Documenting and amplifying what we’re learning through all of the preceding steps, through this blog and through partnerships

We can’t do this alone

Our ambitions for services are big, but we are one tiny team trying to work differently. We are grateful to have some early partners already helping us bring this to life, specifically –

  • OCIO — contributing to and supporting our thinking about how we want to change how we report
  • Canadian Digital Service — helping us design and iterate on our service review process
  • Ontario Digital Service, GDS and other orgs who generously shared their experience reorienting governance

If you are in a team trying to do this, we’d love to hear from you. Get in touch with Sarah Ingle, Jane Lu, Ashley Evans, and Daphnée Nostrome.

--

--

Ashley Evans
Good Trouble

Immersed in policy and service design at Service Canada. Let’s chat @OneTeamGovCan, @DigiAcademyCAN, and Age of Mythology. :)