Determine the type of workshop

In preparation for the pending workshop, plan activities, and map out the agenda based on the type of workshop the team is facilitating. There are three types of workshop:

1. the “help us ideate” workshop;
2. the “problem identified” workshop; and
3. the “solution prescribed” workshop.

“Help us ideate” workshop

Perhaps one of the more challenging types, these require an unscripted approach and a senior facilitator. These workshops happen at high-growth companies that have decided to make a significant investment in advancing their digital capabilities—such as a logistics company with technical and operational debt.

Opportunities outnumber available funds, so the objective is to understand the lay of the land, capture primary business value generators, and select one or two specific ones to take to the next stage of the workshop.

This type of workshop is driven by a senior facilitator. The majority of the talking is done by the client with the Devbridge team augmenting discovery with its own ideas. Use this list for facilitating and set clear objectives.

• Describe the current state of the organization. Have the client discuss the overall business model to onboard the Devbridge team into the domain.
• Outline the challenges and opportunities. Have the client present areas that could benefit from bespoke software.
• Identify targeted goals. Explore the value that would result if the team were to build the selected product. Quantify the value in terms of operational efficiency (lower costs, improve throughput), new revenue generation (sales enablement, new channels), and competitive advantage (market share increase, winning business from competitors).
• Define major risks. Create a list of risk factors from pursuing and not pursuing the opportunities identified.

Capture notes from the session on sticky notes to define priorities, technical readiness, and operational feasibility of each product.

• Priority. Identify which products would drive the largest return, being reasonably aware of the feasibility and technical readiness to successfully deliver them.
• Technical readiness. Examine whether the company has the needed data available and ready for consumption, whether environments and end points exist, and if there are dependencies on in-flight initiatives.
• Feasibility. Not all opportunities are feasible from an operational perspective. Ensure that the organization is in a position to adopt this change of process without drastic changes in the organizational structure.

To help, map the above products on a chart comparing business value with the risk of implementation:

At this point, the team should have clear direction in terms of which products are feasible and important enough to warrant the next step.

Problem-identified workshop vs. Prescribed solution workshop

The most frequent workshop we facilitate is “problem identified.” In this scenario the client is well aware of both the risks and the needed outcomes from a desired product. Such workshops are not prescriptive in how the product should be built, but outcomes are well defined.

One of our recent clients detected stagnating revenues on a licensable software product that was used both by internal consultants and their customers. The product was built over the course of the last fifteen years and has reached the point of no return with both technical debt as well as product debt. Competitors had launched new products with customer-centric UI and demonstrated the ability to rapidly release new features driven by the community. Our client selected Devbridge to reimagine the electronic filing product from the ground up using product development best practices. This is a good example of a problem-identified workshop—the client knew the needs and did not prescribe the path of how to get to the outcomes.

At times, clients are directive. They have identified the problem to address and know (or think they know) exactly how the product should work. They know the solution to tackle the issue and what the features should be. And they ask for us to help execute.

While there are exceptions, this is not an ideal scenario because the solution is likely based on preconceived biases of the sponsor. There may be detailed requirements—captured in a Word or Excel document—that delineate a very specific path for our team to take. How do we navigate such an arrangement?

While this isn’t a preferred way of working, demonstrating results earns us trust and flexibility. A rigid client may become malleable once they learn about our process, see the results of a few sprints worth of work, and recognizes the value of having their customers’ input on the output. This is my recommendation: play along in the beginning; you can start flexing your influence once trust is established.

As it pertains to the workshops process, drive the story-mapping process through the key facilitator—capturing requirements from the group and curating the content as we go. This is a summative process. Most stakeholders have the same requirements because alignment already exists (they have “designed” the solution already). If the exercise is run in the standard fashion—when all stakeholders write on their own sticky notes and present ideas—they end up repeating the same sagas and the same user stories. This creates more noise than value, and so driving the discussion through the facilitator (who also handles documenting stories) is a better approach. As stories are collected and posted by the facilitator, the room can fill in the gaps.

Specifying workshop duration

Depending on the complexity of the product, you may capture the necessary requirements during a single daylong workshop. Focus the effort on the minimal amount that is needed to get started—not in defining the business acceptance criteria for the whole platform. Work toward developing awareness of the size of the product so that the team creates reasonable estimates and allocates the appropriate amount of resource needs for delivery (not to mention overall product architecture).

For more complex projects, two or three days may be necessary . . . with caveats. I have watched Lean Requirements workshops mutate into waterfall requirements definition—the opposite of what the workshops are meant to achieve. As a guideline, even a longer workshop should aim to

• build alignment around outcomes;
• define high-level platform outcomes (and roadmap beyond initial release);
• define just enough detailed requirements for the team to get started and define the initial release (but not beyond it); and
• educate the client about the process—allowing the product team to learn and pivot when the initial release happens.

Often, the client will want complete and utter definition of the whole product up front and it will be up to the senior members of the team to explain the value of Agile product development and the failings of waterfall.

As a baseline, a single-day workshop is effective to kick off initiatives that require six months or less to ship the initial release (ideally three or four months). These numbers are somewhat arbitrary, but I urge you not to plan an initial release that is priced above and beyond $1 million—there’s plenty of ambiguity at that scale to fail.

Alternatively, you can think of a six-month and a twelve-month roadmap. Six months is a manageable risk, and we tend to deliver on time and budget. If you’re stretching your roadmap beyond twelve months and trying to be accurate with features and estimates, then you’re really just daydreaming. The reality is that a product is going to change, so planning beyond a single year is simply not feasible. Use theme-based funding, establish anticipated burn numbers for allocated product teams, and get to building software.