Consider discovery and definition

We’re now at a crossroads. The workshop may have yielded sufficient definition of a potential product, and the stakeholders are aligned. The workshop may have also resulted in five opportunities with conflicting priorities, a muddled technical landscape, and legacy systems that need to be refactored as part of the program. We can estimate and propose the solution, or we could recommend a paid discovery and definition phase prior to starting delivery. We want to get started as fast as we can, but we also know the value of product research, prototyping, and technical feasibility analysis. How do you determine which path to choose? How much risk are we willing to tolerate and how accurate can our estimate be?

Discovery and definition is deployed when we need to build a more detailed level of shared understanding between Devbridge and our client before delivering an estimate or beginning a new phase of work. As a result we may reduce ambiguity before estimating and delivering on an engagement or find that the effort is not worth the outcome and to rethink or eliminate the proposed feature set.

D&D follows a workshop, however not every workshop should result in a discovery and definition phase. The primary objectives are to a) create understanding and b) derisk the product, and c) improve estimate accuracy.

There are three types of D&Ds that we run:

Product viability, research, prototyping. Deployed for greenfield engagements, new initiatives within the client team, and when pivoting existing products within a portfolio. When products need to generate additional buy-in, funding, or to prove out value. These are useful when selling new ideas to the business, or when selling Devbridge’s approach.
Change management and systems design. For products that are replacing existing solutions, or when the product may significantly shift the way the business operates.
Technical feasibility. Used when there’s a need to determine technical architecture, data models, or operational readiness within a client environment and organization. Typically valuable in legacy environments, high technical complexity projects, engagements with multiple dependencies. Also deployed when new technologies and frameworks are to be used on an existing engagement.

Product viability, research, prototyping

We engage in product research and prototyping efforts to validate products and build internal consensus. The goal is to validate that the product will fit the market or business need, to identify the best place to start development, and to potentially generate approval internally for the product to move forward. The focus of prototyping is validation. Prototypes should be thought of as temporary artifacts and stakeholders should be educated that the final product will deviate significantly.

Products with a bold vision that challenge the status quo or represent a marked departure from business as usual require a strong upfront discovery and definition effort. When engaging in a product viability effort, the team will be putting the product and business' operations through the paces to confirm that the proposed approach is possible and will have the desired outcomes.

Viability discovery is effective at sorting through one of multiple directions for the product, for gaining additional context for estimation, and for building alignment and consensus within a client organization. There’s often a pirate or bold visionary at the helm, often sparking significant resistance within the enterprise due to the disruptive methods used. For this reason efforts should leverage a more experienced product team that can ride the waves and navigate uncertain and political waters.

Generally, these engagements answer the following questions:

Is it possible to build what is asked?
Is the client operationally prepared?
Do we have access to the right systems and stakeholders?
What shape could a potential solution take?
Is there alignment and momentum on product direction?

Change management

Certain new products cause a significant shift in the way a business operates. A change management effort is necessary to anticipate these shifts prior to delivery and that is the role of this D&D flavor. The client staff who are leveraged as subject matter experts, who are interviewed about the product, and who are impacted by the change all set the internal tone for how the change will be received. The development of the solution and the business system design must go hand-in-hand throughout the delivery process.

Disruptive products will have unforeseen upstream and downstream consequences. Service design activities, such as a service blueprint, should be regular components of delivery to track how these changes manifest. Similarly, these efforts are often paired with technical feasibility studies. These engagements may be slightly longer if prototyping is also necessary to validate the product direction. The prototype should be built from the research done in this phase, and not attempted concurrently.

Generally, these engagements answer the following questions:

Who will own this new operational standard?
Which departments and workflows will be impacted?
Will we have access to the right roles and users?
What are the unique hallmarks of this improved future state?
What are key areas of measurement?

Technical feasibility sprints

Technical feasibility sprints help the team identify risks, estimate complexity, and move closer to delivery. Rather than turning ambiguous engagement down, we instead find a way to say yes to the opportunity, de-risk it, build a predictable plan, and deliver value to the client. There are three types of engagements where technical feasibility work may be useful:

Greenfield product builds

Feasibility may be related to a technical capability, emerging technology, integration, etc. A Greenfield product or application benefits from a build, measure, learn loop - the sooner incremental working software can be pushed to production, the higher business value (or lower risk) can be extracted. Bottom-up estimates are used for incremental releases, top-down estimates are used for roadmap planning and overarching investment. Even in scenarios where overarching roadmap prevents the MVP release from going directly to production customers (e.g. too few features to be market competitive), the team can facilitate user research, allow stakeholders to use the software, leave enough room for changes of direction, etc.

Fixes, legacy modernization

Feasibility may be needed to break up domain, identify dependencies, components. Fixing and evolving an existing, stable application introduces fewer risks than an application that is not deployable. Depending on the health of the application (e.g. maturity of testing, DevOps, etc.) and complexity of scope a discovery phase may be needed to onboard the team and give them the confidence to commit to estimates. Additionally, once discovery is complete the scope should be finite, clearly identified, limited to a 3-4 month phase, and owned by a Devbridge Product Manager. The objective is to align work product to business outcomes and use Scrum to ship. If scope is ambiguous and not owned by Devbridge (e.g. backlog is provided by client), Time and Materials are used in a Dual-Track Scrum process.

In-flight efforts, rescue missions, and taking over existing products

Feasibility may be needed to evaluate risk, attempt build process, evaluate maturity, chart path forward, stability. The largest risk in a takeover of an in-flight project are incorrect assumptions (by all parties) about infrastructure, components used, licenses for commercial libraries, testing maturity, DevOps maturity, dependencies on external services, and so on. To reduce risk, the immediate need is to create a deployable product. If a deployable product can not be created (nothing to deploy, missing dependencies), then a pure T&M approach should be taken to build technical feasibility tests, validate infrastructure, and build proof of concept. If building a pipeline is an option, the project can be estimated more accurately after this effort is finished. Implementation and migration reveals the majority of underwater risks for future phases. The prototype is migrated, business joins a workshop, future estimates and delivery follow predefined delivery models.

Outcomes of technical feasibility

The desired outcomes of technical feasibility are:

de-risk engagement by breaking down work to three month deliverables
identify and actively manage risks
establish or refine backlog, estimate work
increase estimate accuracy after deep dive
build up “know-how” of existing technical landscape
suggest strategic changes to architecture (e.g. avoid red flags, adopt best practices)
establish engineering maturity guidelines (e.g. development, deployment, maintenance)
produce POC code, perform technical spikes

Each technical feasibility engagement will be slightly different and they will not have the same set of goals and outcomes. Use the above as a guideline.

Getting to an estimate

Discovery and definition provide additional information to improve the estimation process and reduce ambiguity. Ideally, D&D will narrow the scope of what a first release should be and creates a series of micro-funded efforts that progressively limit both risk and investment, giving the product a chance to show a return before making the next push.

The only way to disambiguate a large and complex product is to break it into small manageable segments. Estimates are a living, breathing part of the product delivery process and should be revisited every other sprint and compared against burn rate projections. If we are too fine-grained with our estimates we risk greatly overestimating, where if we are too general we risk the opposite. Use D&D to build a clear line of sight, estimate against that line of sight, and then set out on the next push.

Determine research needs