Software systems to innovate and grow

How to Run a Remote Discovery Sprint

By Ecil Teodoro October 10, 2018 10 mins read

Back in the early 1990’s I had the opportunity to participate in one of the most ambitious software projects of its time. One of the largest Brazilian bank corporations decided to re-engineer their business processes and revamp their entire software infrastructure. This was during a time when object-orientation was only discussed in academia, a couple of conferences or specialized media (say printed magazines or books). And there I was, in the middle of a multimillion-dollar project, all because I was one of the few developers with some experience in object-oriented programming.

Two years after the project kicked off, we found that a big chunk of the budget had been wasted. We were stuck gathering requirements, discussing architecture, and still had yet to release a single line of useful code.

Where we went wrong was trying to tackle too many changes at once: business process reengineering, replacing legacy systems, replacing mainframes with a client-server architecture. What we knew and used at that time was the Waterfall process model, Gantt charts, and Shlaer-Mellor object diagrams.

How to Run a Remote Discovery Sprint

Before things got too out of hand, I decided to abandon the ship. My intuition was right, and the ship sank two weeks later. The project I was working on was cancelled, and the dream of implementing a big object-oriented project had to be postponed for a few years.

Fortunately, this chaotic scenario in software development is part of a remote past. Since then, the emergence of lean agile disciplines and creative problem solving methods, the requirements discovery process has improved by leaps and bounds.

I have to confess, I’m a bit indifferent to novelties with catchy names; it’s hard to get my attention. Until I was introduced to the Design Sprint book.

How to Run a Remote Discovery Sprint

I’m the grumpy process nerd at the company, so I’m always looking for a way to create a method for everything. My goal at the time was to try to design a requirements discovery method that was simple, effective, and kind of fun (yeah, it can be can be fun sometimes).

Before we began working on our process, we had been holding an informal project kick-off and requirements discovery meeting with our clients. The sponsor or SME from their company would explain their overall vision and we would take notes, asking follow-up questions to clarify the areas that were not clear to us. In doing so, we made assumptions about the problem and the solution. We did our best to validate those assumptions.

Now, our team has always had strong engineering DNA. At the time, we were in the habit of rushing to get to the fun part and doing what we love most: coding and delivering software. We were successful too; clients were always happy with the outcome. We were good at communicating, understanding the problem area and satisfying customers needs. But I had this gut feeling that this success was dicey. We lasted as long as we did because we were a small team of very talented people. My main concern was that if we were ever going to grow, this was not a sustainable strategy. And grow we did.

Suddenly, I saw an urgent need to have a mature and defined process to conduct our discovery sessions. There was no more getting by on guesswork or irrelevant questions building up throughout our sessions. Guidelines needed to be set that could be repeated, followed and produce outcomes. We could no longer depend solely on the talent of our developers.

Design Sprints inspired the organization for our work. It offered a simple and straightforward method. With the implementation of just a few simple steps used to compartmentalize the main requirements and frame the problem, we were able to produce a quick turnaround of just a few days on all of our projects.

Inspired by the ideas of Design Sprints, I devised our Discovery Sprint to be in front of our agile, scrum-based, rapid development method.

What is a Discovery Sprint?

The purpose of the Discovery Sprint is to help the team understand the problem we are trying to address. In the shortest possible amount of time, we aim to align the business strategy, identify the users needs and pain points, propose values, and validate proposed solutions.

In this relatively short Discovery Sprint, we must be able to identify the main functionalities being developed so we can come up with a development plan, make high-level estimates, and have enough information to start fleshing out details.

After a few runs of our shiny new Discovery Sprint, we saw outstanding benefits:

  • Clear requirements
  • Sponsor buy-in
  • Solid estimates for implementation
  • A product that meets business goals, satisfies users needs, and makes user’s lives easier
  • Increased likelihood of user acceptance
  • A tangible view of the product (prototype)

How to Run a Remote Discovery Sprint

The Case for a Remote Discovery Sprint

We are a full stack software development firm based out of Miami, Florida with clients spread all over the country. Even our internal team lives in different timezones, as we have a remote workplace culture. Though we schedule regular on-site meetings, discoveries, and get-togethers, sometimes we simply cannot be on our clients’ sites for every new project kick-off.

Clients are rarely able to dispose of or give up a whole week to participate in Discovery Sessions. As the aim is to have everyone on the same page, it is usually hard to combine the agendas of executives, analysts, users and technical staff. In addition to time, it’s hard to commit all the necessary physical resources for five full days— like rooms, snacks, trips, accommodations and whatnot.

Design Sprints and Discovery Sprints have some similarities but they serve different purposes. We made adaptations in terms of time, audience, structure, outcomes, tools, and techniques. We took into account the limited time and remote nature of our Discovery sessions. As we run more Discovery Sprints, we continue to improve them.

Running a Remote Discovery Sprint

Though there are some challenges in running Discovery Sprints remotely, by using the right tools and techniques we are able to accomplish the same goals as running a face-to-face session accomplishes. Another benefit is the time-constrained nature of the remote Discovery Sprint. People focus on the core problem at hand and waste less time on irrelevant details.

Find the Right Tools

We are constantly reevaluating tools and finding better ways for project teams to communicate and collaborate. These are the current tools we use to conduct our online Discovery sessions.

  • Zoom is a video conferencing tool that allows us to screen share our entire desktop, share single applications, switch between monitors, share connected mobile device screens and make sketches on a collaborative whiteboard.

    In addition to being able to access on a computer, it allows you to call in via a toll-free phone number, record calls locally or in the cloud and integrates with your calendar meeting invites. Other acceptable tools include Skype, Google Hangouts or Cisco WebEx.
  • Slack is our messaging app of choice for internal and client communications. There are plenty of other options out there like Flowdock, Skype, and Google Hangouts. For every new project we usually create two Slack channels, one internal and another one for communicating with the client’s team.

    Depending on the project size, you may want to create more specific channels for frontend, backend or devops for example. It’s a better way to involve less people in each channel and create less noise. Though we use Slack more frequently when development starts, a great deal of information and clarification is exchanged offline during the Discovery Sprint.
  • Basecamp is our central repository of project deliverables: project stakeholders lists, RACI Matrix, Business Alignment Board, User Stories, Prototypes, Status Reports, email threads, etc. Some deliverables are stored in Google Drive, some of them are in a PDF, other deliverables are just links. Basecamp helps us organize this myriad of project documentation into a single space.
  • Google Drive is where we store templates for most of our deliverables for our Discovery and Software Development Method. We make heavy use of Google Docs, Google Slides and Google Sheets for their collaboration and easy sharing capabilities.
  • Balsamiq Mockups is one of my favorite tools to use while I’m running remote discovery sessions. It is great for sketching almost anything. We use it to express ideas and concepts, to sketch scenarios, storyboards, user interfaces and validate navigation flows. What is great about it is that it’s very easy and quick to sketch something on-the-fly, while sharing the screen. Mural is another great tool under our radar and we’ll be trying it soon.
  • Sketch is a user-friendly design tool, used by UX and UI designers to build prototypes. Our designers use it during our Discovery Sprint, after we have explored several ideas and decide on a specific solution. Then it’s time to create high-fidelity mockups and interactive prototypes. Users will have a taste of what the final solution will look and feel like and validate those concepts before we proceed to engineering.

    There’s a long list of alternatives to Sketch and sometimes we even make use of different tools on different projects. In recent times we have seen the emergence of several design and prototyping tools like Adobe XD, Framer, Figma, Pop, Flinto, Principle and Invision Studio.
  • Invision is our tool of choice for prototyping and handoff. We started using Invision when Sketch didn’t have prototyping, preview and cloud capabilities. Invision is how we communicate our high-fidelity prototypes to customers and our engineering team. Using the Craft plugin for Sketch, we synchronize our designs with Invision in a breeze.

Set the Stage

If you are reading this, there’s a good chance you are the one who conducts the Discovery Sprints. If so, you are the facilitator, a product manager, some sort of technical lead or a business analyst. If you are in one of these leadership roles and in need of a place to start leading a Discovery Sprint, here’s where to begin:

  1. Start by finding yourself a comfortable and quiet room. Choose one with a neutral background if you are turning on your camera. When it’s your turn to listen, mute your microphone. It’s common to overhear dog barks, emergency vehicles and domestic noises. As a general rule, it’s best to avoid noisy spaces like cafes or open co-working environments.
  2. Make sure you and your team are set up with a fast, low latency internet connection to avoid voice breaks and freezing screens.
  3. Ask participants to join via computer instead of phone calls. Discovery Sprints are pretty visual activities with lots of screen sharing. Phone calls may have poor connection, especially if the caller is moving or using a cell phone.
  4. If possible, ask participants to turn on their cameras. It’s hard to distinguish people’s voices during discussions, especially if it’s a new customer or new stakeholders.
  5. Ask participants to join individually from their computers, or if joining collectively from a conference room then use a wide angle camera so each individual contribution can be recognized.
  6. Record each and every session.

Build the Team

Team building is a key success factor in every Discovery Sprint. We recommend keeping your team as small as possible. Our experience has shown us that the ideal team size is around six people. In the past, I have seen calendar events involving a dozen or more people. Unless the vast majority of attendants are merely listeners, this won’t work. Too many diverging opinions or too many irrelevant details are brought up in discussion. To help with this, arrange to have one person represent an interested party or group.

In order for a session to run smoothly, we recommend appointing the following team members for continuing sessions, on both the client side and internal side:

  1. Client Side
    1. Sponsor/Influencer: this is usually the person on the client side who proposed the project. The sponsor has a broad understanding of the business strategy, why we are doing the project, and how the project fits in the scope of the overall business goals. They financially sponsor the project and refer to the right people to answer questions and remove blockers.
    2. SME: a subject matter expert is the person with skills in the particular problem area we are trying to resolve. Ask the sponsor to choose an SME who is available through the entire project, not just the Discovery Sprint. When development starts and we need to add flesh to the bones, the SME participates in sprint plannings to detail user stories, provide clarification and validate delivered features.
    3. IT staff: DevOps is necessary when the software is hosted inside a client’s infrastructure. DevOps are responsible for granting end users access, installing software in different environments (like staging and production) and setting up whatever access your team needs to perform the job. IT staff doesn’t need to participate in every session.
    4. Other staff: marketing teams may contribute with brand and visual guidelines, especially if we are developing a public facing website or app, for example.
  2. Internal side
    1. Technical expert: if you are not a software engineer like me, you will need a technical expert to propose the technical architecture and design the solution. It’s even more important if the Discovery Sprint involves building a proof of concept.
    2. Design expert: our aim is to design user-centric applications and great experiences. We always involve a UX/UI designer in the process.

Start Playing

It’s time to start the show. At this point, calendar invites were sent to previously identified stakeholders, including a meeting description, web conference link and call-in phone numbers.

  1. Session 1
    1. As an icebreaker activity, ask team members to introduce themselves.
    2. Define roles and responsibilities of each team member.
    3. Review the agenda for the Discovery Sprint.
    4. Ask the sponsor to walk the team through the business vision and offering, market analysis, and business goals.
    5. Identify the value proposition, users, and success metrics.
    6. Define application goals.
    7. Define the positioning statement. A positioning statement is an expression of how a given product, service or brand fits a particular consumer need in a way its competitors don’t.

      Example: For (target customer) who (statement of the need or opportunity), the (product name) is a (product category) that (statement of key benefit – that is, compelling reason to buy). Unlike (primary competitive alternative), our product (statement of primary differentiation).
  2. Session 2
    1. Given all information collected from previous sessions and by using the positioning statement as a north star, brainstorm whichever techniques come to mind that your team finds suitable for the problem at hand. This way you are able to generate as many ideas and solution opportunities as possible.
  3. Session 3
    1. Decide which solutions will become a prototype and start sketching the prototype to validate on the fly.
    2. Identify non-technical requirements.
    3. Set up an offline session with your technical expert to start designing the technical architecture.
    4. Set up an offline session with your design expert to design hi-fi mockups.
  4. Session 4
    1. Present your hi-fi mockups.
    2. Design user interactions (prototype).
    3. Present to the team and validate.
  5. Session 5
    1. Test prototype with end users.
    2. Setup offline sessions with your internal engineering team to identify user stories, break them down into tasks and create a project plan with high-level estimates.
  6. Session 6
    1. Present project plan and estimates.
    2. Define priorities with stakeholders.

    General comments

    • Session duration and number of sessions may vary from project to project.
    • Two-hour sessions are enough in most cases but allow them to be longer if needed.
    • Encourage everyone’s engagement. All opinions matter.
    • Don’t let people speak without visuals. For any given moment someone’s screen or a collaborative whiteboard must be displayed. People tend to get lost without visual clues.
    • Arrange for a discovery assistant to take notes while the facilitator is guiding the project team and discussing ideas and concepts. Have these notes be shared with the entire team to track what was discussed and agreed upon during each sprint.

    Takeaways

    The remote Discovery Sprint comes packed with challenges, but also comes with benefits.

    Main benefits:

    • More efficient use of time, cost and resources.
    • Agendas are not blocked for a full week.
    • Discovery Sprint is performed in small iterations during the week.
    • Easier to coordinate.

    Challenges we have faced include:

    • Including client side team members during all discovery sessions.
    • Keeping up the engagement level of all interested stakeholders.
    • Convincing customers of the importance of following a method and documenting requirements, especially those related to the business strategy.
    • Taking notes while facilitating is somewhat challenging for me. Additionally so because English is my second language. Fast typing and misspelling may lead to incomplete information and some funny situations. Google Docs is useful in these situations as it allows an assistant to collaborate on the document when taking notes while the facilitator guides discussions or tries to understand complex concepts.

    We are constantly improving our processes, particularly our Remote Discovery Sprint method, as it is at the foundation of creating a great product and a great user experience. It acts as the primary source of validation for backlog items that feed our Scrum development sprints.

    We spare no effort in evaluating new ways and tools to facilitate the Remote Discovery Sprint activity as smoothly and as lean as possible, without losing relevant information. We believe remote sessions can be as efficient and effective as being in the same room.

    Software project planning has come a long way since the early projects I tried tackling in the 1990’s. I’ve become much more confident as a manager, growing from running aimless meetings to running a well thought out remote discovery sprint. My team no longer relies on our talent alone to get us through projects, and has proven that implementing a process has been a crucial step in successfully managing our growth. By using Discovery Sprints we eliminate huge deterrents in communication, saving time and costs in the overall project. I hope you are able to finish this reading feeling excited about implementing some of these tips into your own planning.