Skip to main content

Onboard & Discover

During this phase, the Exchange Lab helps the new team to get oriented to the problem they are solving and resources offered by the Delivery Network.

Pre-conditions

What Success Looks Like in this phase

Applicable Standards in this Phase

Orient the Team

Often referred to as “Sprint Zero,” the first couple weeks of a team onboarding to the Exchange Lab is about orientation to the business context, the specific problem, technology stack options, and the Digital Delivery Network (community) connected to the Lab.

Some helpful resources during this phase:

Note that some private sector teams have worked in the lab and with the digital delivery network before. These teams, or teams with an experienced member, will need less time to get oriented.

Business Context

The Product Owner introduces the team to the government program area responsible for delivering value associated with the product they are building.

Problem Definition

Share the problem statement that resulted from the Alignment session, and any service design or user research that has been done to date.

Data and Technology

Almost every service delivery product uses or collects data. It is likely the program area has improvements to make in this regard.

There may also be multiple existing systems that connect to the product the team is building. Work with government systems and data architects to share diagrams and other relevant documentation that illustrate those systems. Highlight what is known to not work, or where challenges might occur.

Community Connections

The Exchange Lab team’s primary value is knowing where to look for help. There is a growing community - known also as a Digital Delivery Network - that contains the experience, expertise and encouragement that can help a team succeed. This community is supported to convene and share knowledge by the Exchange Lab through a variety of channels and engagement events.

Exchange Lab teams connect and contribute learning within the Rocket.Chat community channels. This is also where teams can get support from Lab Operations and Platform Services as they troubleshoot specific team productivity and product development needs. Teams are expected to ask the community for help here, before seeking an SOS from the Exchange Lab team.

Discover where to Start

After Sprint 0, the team will be VERY enthusiastic about building. Development teams typically do not enjoy meetings or presentations. They are geared towards creativity and problem solving. With enough orientation the team should be able to get started right away.

Start with User needs

It is very easy to make assumptions about what a user might need, particularly if the business area has had this practice in place for a long time. This is a practice we are aiming to shift as peoples’ needs and expectations can ONLY be defined by them.

The Product Owner should work with the team to develop clear user stories, that do not propose solutions: they only communicate needs. This effort forms the basis of the product backlog and roadmap.

The Exchange Lab Offers:

  • Training and coaching for organizations learning to value user research and to build a backlog of user stories.
  • Orientation and connection to experts who can facilitate applying user research practices and standards.

Get Creative and Test ideas

Support the team to build illustrative prototypes to communicate and get feedback on early ideas. This effort will also enable the community to orient the team towards other products and code that may be relevant and reused.

The Exchange Lab Offers:

  • Connection to others who can share examples of effective approaches.
  • Hosting events or promoting content to enable feedback from the community.

Consider Common Components

The Exchange Lab and Digital Delivery Network have several years of experience building modern software. There are dozens of products with functional code or that are approved for licensing that may address the capabilities of the product the team imagines.

Build a roadmap

With just enough discovery and creativity from the team, the Product Owner can start to develop a roadmap to share with the organization. A Roadmap is an evolving plan, that changes as the team continues to build and iterate based on feedback. It typically becomes more firm and detailed as the team wades through the complexity of user needs, policy, and technology.

Develop an Alpha Product

An Alpha product is just enough working software to demonstrate value within the organization. It is also where the team starts learning and forming habits for working together.

It will not contain all of the features that are planned for the final version and testing is often performed only by users within the organization. This builds trust with stakeholders that the team can function and continuously build towards a product that is valuable for people who use the service.

Build a Pipeline to Deploy Code

It takes most teams some time to get oriented to a new technology stack and application hosting environment. During the Alpha build, the team is practicing new skills and learning the policies, protocols, and tools available through Platforms services. They may also refine their internal working practices for managing a backlog and producing documentation.

Apply Government Design standards

Developing the first few features of a product provides an excellent opportunity for a team to set up good practices for design. This includes:

Demonstrate Something that Works

This could be anything. Often teams start with a basic front end that can surface some data or a form that the end user might value. Once a team is able to demo progress, the Executive Sponsors should be engaged to:

LabOps Resources


Back to the Top