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
teamwork?
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
- Developers
- 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
created?
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).
Why
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.
Conclusion
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.
Takeaways:
- 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.
References
- Fresh Work studio, “Understanding the Discovery Process in Software Development”,
https://freshworks.io/understanding-the-discovery-process-in-software-development/
- “Agile: Discovery is not a phase!” YouTubeAgile Discovery is NOT a phase!
