Before starting a project, there are many variables to consider to know whether the efforts we are about to undertake make sense, both for the intended users and us. It is like going into battle without a plan; we have to set a roadmap to guide us, but only after we know what we have, what we need, and whether all those involved are aligned to the same goal. Lesmes López, Agile Delivery Manager (ADM) at Codurance, led a meetup in which he offered keys, valuable tools, and guidelines to discover a project successfully.

What is the discovery of a project?

Activities and deliverables that allow us to understand and align on a problem and the most appropriate solutions with the available means.

- Lesmes López, Agile Delivery Manager

From this definition, he explained the importance of each of the elements of a discovery.

Activities and deliverables

They are the output of discovery, in other words, the representation of the activities obtained from our discovery. Many formats can help us to represent these activities and deliverables; we must choose the one that best suits our project.Understand and align

Suppose each team member does not share a common vision of the problem or needs help understanding the available information in the same way. In that case, it is very likely that the solutions they come up with will be very different from each other or will focus on various aspects. Therefore, the outcome of discovery is that activities and deliverables allow us to understand and align as a team toward the same objectives. As López says: "The important thing is that we come out with a joint and aligned understanding of the needs we need to meet." 

To this end, it is advisable to analyze the problem from different perspectives. The ADM points out three angles to be considered:

• Business (value) - What is the value provided to the user?

• UX (user) - What is the user experience and how can it be improved.

• Technology (feasible) - How possible it is to implement, maintain and enhance the proposed solution over time.

In seeking this alignment, it is important to involve stakeholders, who are ultimately the people who will help understand the problem and the possible solutions available. Among them, he highlighted the domain experts, the sales team, technical leaders, the marketing team, and, above all, the detractors. We should not leave out the people we know can complicate a discovery. "It is key to incorporate the detractors from the beginning because sooner or later you will find them, and they can generate blocks to certain solutions," he said. Ultimately, it's about creating a shared vision from each particular perspective. 

Problems and solutions

So, what do we want to align on? On the problem that blocks us or does not allow us to move forward and the solutions to respond to that problem. This is the key. The nature of the problem to be solved defines the activities and deliverables. For example, suppose the project we will address is more tactical than strategic. In that case, the tools we use will reinforce the tactics since we assume that the strategy already exists. We may strengthen that strategy a bit at the beginning, but we will focus on the tactics in the end.

Likewise, the discovery can be to create a new product, to develop new capabilities of an existing product, which is most common when developing software, or to implement a modernization, for example of a legacy system. Depending on the primary need, the solutions will be aimed at solving the detected problem. The discovery has to do with the amount of information we do not know and have to discover.

According to these categories, López presented some useful tools for each case:

• • • New product
      • • Business Model Canvas. It's a tool that makes it possible to shape a value proposition. Realistic hypotheses must be formulated.
        • Steve Blank, Customer Development. Focus on the customer. We are not going to develop a product but a customer; we have to understand what they want.

• • • Modernization of a legacy system

      • • Value Stream Mapping. It shows the value generation process and identifies where queues or bottlenecks are. It helps to find where time can be saved to optimize the value stream.

        • Architecture Discovery. Shows what the current architecture is like vs. what it could be like.

        • Event Storming. Mapping a product to understand the critical areas that need to be addressed to make the whole system work better.

        • Service Blueprint. Mapping what the service looks like to visualise it and make decisions based on that. 

    • Useful in any case
      • • Gather expectations, realistic or not.
        • Wardley Maps. Strategic analysis tool that makes it possible to visualize where the project should evolve to provide more value.
        • Customer Journeys. Detailing the user journey to establish the pain points that can be resolved in order to improve the experience.
        • Interviews with users.
        • Shadowing Session. Sessions that allow us to observe what users do and evaluate it in order to know which points can be improved.
        • Design Sprints. A series of hypotheses and tests that help to establish the problem and the solution.

Neil Killick explains three areas that help us understand the division between the problem space and the solution space. First is the capability, which is exactly what the user needs to do. Then there is the functional area, which describes the tools we need to implement so the user can achieve what they are looking for. And finally, the technical area is the steps we need to take to implement the functionality the user needs.

Appropriate with the available means

This is the primary point; the discovery must be realistic regarding the means available. To do this, it is necessary to consider the nature of our team (innovation lab vs. product team) and the type of company we are in. Solutions must fit the context and the environment in which we are operating.

To illustrate this section, the ADM introduced the iron adapted triangle from Kent Beck in which, playing with the variables of scope (more), cost (cheaper), time (faster) and quality (better), he describes three different stages within developments: 

• Explore (better/sooner/cheaper) - Limit the scope but speed up the feedback. Do as much testing as possible, the aim is to deliver quickly and collect that feedback.
   
• Expand (better/sooner/more) - Delivering fast and high quality functionalities, but without limiting the cost. 
  
  
• Extract (better/cheaper/more) - Getting the most out of the product. Cost-effective delivery of long-term, large-scale value.

These stages show three moments in which a product can be in, so the project's discovery must be adapted to the scene in which it is: explore, expand or extract. Bearing in mind that quality (better) must be intrinsic in any of the stages.

Inception Deck

To give an example of actions that can be taken when setting up a discovery, López introduced the Inception Deck. This is a set of dynamics that allow the collection of information to establish purposes and objectives, and the whole team must participate equally. It consists of 10 steps:

1. Why are we here? - Compilation of objectives. Find a single, clear, and measurable objective for the whole team. 

2. Elevator pitch -product definition. List qualities of the project so that everyone has a clear definition of what it is. Who it is aimed at, competition, unique characteristics, etc.

3. Product box - List the key points of the project. How would you sell it?

4. Not list - A list of what does not fall within the project to limit a scope. Helps to streamline communications.

5. Meet the neighbors - Identify the map of all the people who influence the project. Consider all those who may be affected by or have an impact on the project.

6. Show solution - A high-level approach to what the solution would be. It does not have to be the final product, but a first approximation. 

7. Up at night - Analyze possible risks affecting the project. Be clear about how likely they occur and how serious they are. 

8. Size it up - Estimate the magnitude of the project and the time it would take to implement it. *Lopez does not emphasise this step because he considers it to be of little value. 

9. What' going to give - Establish which qualities or characteristics are indispensable and set the direction and decisions on the solution in a certain way. Our 'trade offs'.

10. What going to take - Estimate the cost of the project and the decisions involved in this commitment. *Lopez does not emphasise this step because he considers that it doesn't make a major contribution. 

He mentioned that the User Persona and User Story Mapping are other tools of great importance and use within a discovery. These allow us to define the profile of our end users, the path they follow with the product, and in which areas we can offer a better experience.

This meeting was part of the Agile Project Management circuit that aims to effectively offer valuable resources to work with agile projects. Suppose you are interested in reviewing more content on this track. In that case, you can do so on our Insights page, where you will also find videos of past sessions and podcasts. Also, subscribe to our newsletter if you want us to send you relevant content to inspire you.

Bibliography:

• Ceci n'est pas une pipe
• Slicing heuristics  -  Neil Killick
• Assumption vs. Hypothesis – to the Death!
• Journey to Product Teams (Infographic)
• Better/Sooner/Cheaper/More + tweet
• Inception Deck
• User Story Mapping
• Business model Canvas con Value Proposition Canvas
• Value Stream Mapping
• Wardley Maps
• Design Sprints