How to form an idea using
Discovery in the process of Software Development?
- What is Discovery and why is it used for?
- Is it Discovery teamwork?
- How is it created?
- How is it structured?
A great idea for diving has occurred! A new adventure, or quest for something new and interesting.
But we didn’t explore that area of the ocean. We didn’t hire a diving instructor; we didn’t look at weather conditions for that day...How deep will we be diving?
The idea for that day will be gone with the wind because in many ways it could get complicated.
Uncovering a new project will be like diving into fresh ocean water. With all goosebumps, expectations, and shivering over a new dive.
Thankfully, reasonable people know the path for calm and risk-free diving.
In the software development industry, those feelings are well-known and those pre-steps are constantly used, so these factors could be a clamp for the following explanation.
What is Discovery and
why is it used for?
“Discovery” is a document of an initial process where project’s information, its intended market, and audience are analyzed. It allows the team - people who are gathered over the same goals and scope - to go into the depth of the project and its possible limitations.
This document isn't focused on delivery, it is discovery-centered, meaning building the right project.
Ignoring the Discovery part leads us to the assumption that we are building something right. The definition of assume is to accept something to be true without question or proof.
Well, in Software development there is no place for this type of speculation.
Discovery is often called pre-work, like that isn’t real work (before hard code programming work). Deciding what and how to build is required work, and this is what Agile Discovery is all about. Once it is decided what to build, Discovery helps the team with the project. With this document, it is more likely that it is going to be built properly, with high-quality standards and efficiency.
The Discovery phase implies eliciting requirements, assigning priorities, and importantly, creating a roadmap that describes how the system will evolve from idea to launch.
(This is how does that process looks. First is an idea that is going to be built, then launch, and then learn about an initial idea.)
Learning about the new product is a proper way of access but is an expensive and long process. The most expensive way to test the product is to launch it.
Once again, Agile shows its ability to adapt. Here comes Discovery with its power to shorten that road from the conception of an idea to learning about it. That is how our idea is validated as soon as possible.
It is seen that there exist a few points of view about this type of documentation. Most of it says that Discovery is a phase, and on the other hand idea of phase is not very Agile.
Is it Discovery
The Discovery phase of a project provides an opportunity for everyone involved in the process to come together and develop their shared understanding of what this particular endeavor will entail.
Working towards that collaborative vision not only ensures that there is always end goal clarity but also helps avoid any potential pitfalls along the way by ensuring no stakeholder feels left out or overlooked early on during planning phases.
It has been shown that Discovery causes a lot of positive outcomes, one being that it builds bridges between members of the team. These relationships are what bind everyone together in this complicated industry and create trust among customers or business partners who might not otherwise understand how things work behind the scenes.
The power comes from within when you know your project inside out. Creators are next:
- Product Owner
- Project Manager
- Business Analyst
- Solution Architect
- UX Designer
- QA Testers
- Representative and-users
Not every Project requires these roles in the team. This would be the optimum for various projects and, for example, this is the team from Phoenix’s latest discovery document.
How is it
Engaging so many people before even starting development shows us that Discovery isn’t a linear approach. It is a continued loop between discovery and delivery by feeding each other. It first had to be discovered in order to be delivered and vice versa.
Nevertheless, some of the steps are unavoidable. Steps from collecting information to presenting in The Discovery process are types of activity that are used for gathering in one place. Those are: interviewing, observing, and field research. Thereby communication with stakeholders has to be clear during this period of exploration of the product.
The aim is to narrow the information down and to make the structure. That is why starting from non-specific is the right lead. Approaching should go from the highest level of problem-general product areas followed by specific activities to remove excess and then find answers around problem space.
How is it structured?
Diving deeper into this powerful and meaningful document opens us its structure. Through collaboration, all those factors which affect our future project will be put in these next items.
- The Discovery team - clarified who is taking roles in creating this document.
- Project Overview (Summary, target audience, Goals) - all discovery parts have to be aligned with this central part. The summary section is the place where the background is explained with the introduction of companies' generals.
- UX design Discovery - reveals references and inspirations to us.
- User Journey is a path of a single user throughout its needs and wants.
- Design principles aligned with user experience goals.
- Product Backlog – Scope - is included in the discovery process so as next documents: Roadmap, Time estimation, Cost estimation.
- Methodology (Agile) - is a part where workflow is explained.
- Product Backlog - is related to the project and it is attached.) Features are broken down into smaller, actionable working units organized around epics and user stories.
- Design & Technical approach - brand & style alignment, prototyping, user testing, development support.
- Site map - visual representation of the pages that will be created within the app and their hierarchy. Shown through breakdown.
- Wireframes - an outline of each step that will be in the product, low fidelity.
- Technical stack - tech architecture presents proposed architecture for the solution’s technical and non-technical requirements built in a scalable but cost-effective model on cloud.
It implements resilience, monitoring, logging and alarming features to support production usage of the platform (solution). They are based on the experience of implementing similar use cases and in accordance with client’s expectations and/or preferences.
- Service tools and subscriptions - additional cost, out of project budget.
- Assumptions and Risks elements that are necessary for the project to happen and elements that can jeopardize the project.
- Next steps on-site - explanation of how it is going to proceed if client decides whether to move forward with the suggested course (Go/no Go).
If we are going to follow up on the statement: “Testing ideas are the purpose of Discovery”, we would be able to say that there lies the WHY of Discovery.
The answer for WHY is also revealed if we dig into practice and take SCRUM for this point of view and watch developing an idea from Discovery to Backlog throughout sprints to the product.
The relationship between Discovery and Backlog is a moment where Backlog is similar to a filter. Good ideas become requirements, and the poor ones are replaced or forgotten.
However, a more suitable description would be that Discovery is the conceptualization of an idea. Inspecting different aspects is just what the product needs to be properly produced. Another reason why Discovery needs to be done or documented adequately is that Discovery is one of the few benefits that can produce a look beyond the idea.
Did you know that one in three software development projects substantially exceeds its budget, misses deadlines, or completely fails?
Experience suggests that the Discovery process is the way to save a ton of time and money and avoid painful mistakes.
So, if Discovery isn’t used, we risk it.
If a Software Project Manager or a customer asks itself why starting software development with the Discovery project- it can rely on several benefits.
They are transparent and they are offered to us as a help to get a comprehensive view, bring tech competence, optimize the cost of development and create a clear product vision.
Therefore, challenge every assumption. Start asking why and do your homework before getting started on any given task — especially ones involving technology.
- Discovery is a document where project’s information is analyzed, its intended market, and audience. It allows you to get into the depth of the goals, scope, and limitations.
- This document isn't focused on the delivery, it is discovery-centered.
- It has been shown that the Discovery document causes a lot of positive outcomes: it builds bridges between members of the team and creates trust among customers or business partners who might not otherwise understand how things work behind the scenes.
- Steps from collecting information to presenting in The Discovery process are types of activity that are used for gathering in one place. Those are: interviewing, observing, and field research. Thereby communication with stakeholders has to be clear during this period of the product exploration.
- Approaching should go from the highest level of problem-general product areas followed by specific activities to remove excess and then find answers around problem space.
- Discovery is the conceptualization of an idea. Inspecting different aspects is just what the product needs to be properly produced.
- Fresh Work studio, “Understanding the Discovery Process in Software Development”,
- “Agile: Discovery is not a phase!” YouTubeAgile Discovery is NOT a phase!