How to Master Discovery for Better Agile Management in Your Technology Projects

Discovery is the entire scope and process identification work undertaken before starting your technology projects to ensure a smoother process in an agile approach. I will briefly explain why we need a discovery phase.

Let’s assume we are starting a new project to develop a product or modernize an existing one. At the initial stage, the content and scope need to be more explicit, and many user stories exist. If these aren’t handled and managed correctly, we may not reap the benefits of an agile approach. Because agile management requires tasks that can be broken down into hourly or daily periods for the team to operate healthily. The goal of the discovery phase is to ease the translation of significant project stories into epic user stories. In addition to this goal, Discovery aims to: identify the processes that might lead to dependencies, provide inputs for planning by defining priorities within the scope, predict the project due date, and the essential workforce.

In short, the project scope, purpose, and targets are identified for correct project planning and creating efficient, feasible, and, most importantly, accurate solutions for emerging needs or opportunities.

Why Do You Need a Discovery Process?

Do not all projects involve a process for defining the scope? Sure, various tasks are undertaken to draw the general outlines of a project. However, we have observed that the work must fully consider the bigger picture. Most of the time, the projects are finalized with way more effort than required due to the oversight in the initial phase.

Let me try to explain this with an analogy. Assume that your project is an entangled ball of yarn in the beginning phase. This ball of string consists of complex processes, intertwined flows, and ambiguous dependencies. Although it looks like a ball from the outside, it is a highly complex structure. You can pull this ball to unwind it, but how fulfilling will the results be? Suppose we do not disentangle this ball properly in the beginning phase of a project. How effectively can we use our time during the project? The first question that comes to mind would be how to get organized. This is precisely the answer we are looking for through the Discovery phase.

A project without a Discovery phase would be like trying to find our way in the darkness without a torch. You need to decide the steps to take after the project starts. As the top half of the image above shows, this would either prevent you from reaching the right solution or cause delays. But in both cases, your team will be demotivated and lose valuable time. With Discovery, we aim to prevent this situation and create a step-by-step plan, just like the general framework shown in the bottom half of the image.

DefineX’s Discovery Methodology

An international bank for which we provide consultancy services started a transformation project to match the changing and developing technologies and to achieve higher quality output with lower costs. The high number and complex processes in the existing structure, intertwined flows, and dependencies prevented the creation of healthy user stories and the desired efficiency from the agile approach. At this point, our Discovery project stepped in to help. Accordingly, as DefineX, we completed 6 Discovery projects in 2022 to facilitate our customer’s main banking transformation project.

So, how did we do that? We tried to change the established perspective that favored “fixing as you go along” since they already used an agile approach. We took a different direction and allocated the time needed for the discovery process. We investigated the customer’s expectations, problems, and needs from various perspectives to minimize the potential issues that might appear during the sprints. We completed the discovery process in 6 steps, as shown below:

In the “Project Purpose Identification” step, we conduct meetings to accurately, clearly, and openly understand the project targets and needs. At the end of these meetings, we summarize the project’s purpose in 1-2 short, clean, open, future-oriented, and memorable sentences.

Here are a couple of examples of project purpose statements:

• To give the best offer to the customers in the most efficient way and with minimum resources.
• To make savings by migrating the central system database and applications that consume too many resources to open-source code systems.

Additionally, we clarify the following topics in our workshops:

• Actions needed to complete the project purpose
• The history of the project and why this transformation is necessary
• The parts included/not included in the scope

After identifying the project purpose, we start with the “Process Flow Planning” stage. We ask the client to explain the existing processes at this stage clearly. We aim to ask the right questions during the briefing and thoroughly cover fundamentals. We draw the process flows after fully understanding the existing and planned operations.

Sample Process Flow Diagram

While creating the process flows, we identify the dependencies in the project. We tackle dependencies from two perspectives:

• Teams dependent on us
• Teams we are dependent on

After we identify the dependencies, we contact the related teams and brief them. We provide details to process flows to show how the architectural transformation will transpire and plan additional meetings with stakeholder architects when needed.

After completing the process flows, the next step is prioritizing according to the project’s needs. The aim of the project and process dependencies should take center stage while prioritizing the actions. For example, the query process should come first since the data reading process will not work without a query. Or if the project’s purpose is to make savings from high CPU usage, we start from the module that consumes the highest CPU. This is how we plan our MVP, which refers to the parts that produce functional outcomes combined in several sprints.

Next comes the “Technical Inventory Identification” stage once the MVP and dependencies are fully identified. We create the technical inventory by considering each element, component, or part in the process flow. Each item in the inventory is an input for the Product List in the project. Then, we calculate the effort based on the inventory and estimated costs.

Sample Technical Inventory

Technical inventory prepared according to MVPs are detailed and highlighted to address the dependencies at the detailed analysis stage.

After identifying the necessary workforce for the project, we continue with the “Draft Schedule,” which is the last stage based on the technical inventory. At this stage, we create a sprint-based schedule that includes the necessary workforce and dependent teams in the project, as shown in the example below. The Discovery is completed by calculating the estimated total cost of the project.

Sample Draft Schedule

We can monitor and track critical meeting notes, pinpoint process flow diagrams, and necessary screen designs on Confluence, a web-based collaboration platform. Thus, we can maximize communication, minimize questions and increase our knowledge and command of the process.

To sum up, through the Discovery Project applied by DefineX:

• We conduct a pre-study by blending our project and team management skills with critical analysis.
• We create a roadmap to guide every stage of the delivery journey and prevent straying from the target.
• We provide a general framework to ensure harmony between the analysis and development teams.
• We create a dependency matrix to ensure more efficient use of time.
• We draft a project schedule that minimizes the possibility of deviation thanks to the prior definition of a realistic technical inventory and MVP.

Discovery Process Brings Substantial Benefits

These are some of the substantial benefits that the discovery process brings, as we observed in many various clients’ projects:

• An inside eye can experience temporary blindness while identifying areas of improvement, and it is not always possible to detect the problems. For example, in one of our projects, our banking client was recalculating the risk amount already calculated by its external supplier. We helped to prevent such duplicate efforts in our new system design.
• We provide solutions to prevent effort and cost loss by adapting systems to new technologies in digital transformation projects. For example, in one project, the client would do KKB queries with the same criteria on CICS and use CPU for each query. We introduced a new approach to decrease CPU usage. We created a structure where queries containing the same standards are saved as a draft, and when a similar query is run, the draft is checked first. Thus, we discovered that the primary system could save more than 200 hours of CPUs per month.
• We divide the draft schedule into MVP sprints and provide a flow that the clients can track. We plan every step of the process, enabling them to get a grip on the project without missing any details. These efforts make it possible to predict the estimated project due date. For example, in another project, we demonstrated that the project could not be completed on the planned due date. We helped the client take corrective actions and create a new roadmap. Since we have a project schedule, we prevent the teams from experiencing negative experiences in ambiguous situations. Teams know which sprints they will work on and which tasks they will do and can focus better.
• At the beginning of a project, we minimize the epic stories and turn them into user stories at the detailed analysis stage. We identify the tasks for each day for the team members to enable proper planning. For example, instead of a team member saying s/he will design a screen for KKB query for the entire week, we help them create a structure. They add the query areas on the first day, complete the required buttons on the second day, and connect them to the query process on other days. This way, applying agile methods is more manageable, even in large-scale projects.
• We ensure on-time precautions against elements at risk for delaying the project, such as external team dependencies. We identify the dependent teams and focus on solving the problems by communicating with them.
• With the Discovery process implemented at the beginning of large-scale projects or projects without a definite scope, we can identify the range, clearly reveal the requirements, and create the project roadmap. We can identify the existing or possible problems that the client might experience from the beginning and provide solutions and support so that agile projects can be managed healthily.