Discovery: The importance and relevance in Software Development

Discovery: The TV Channel. The Space Shuttle. 565 million search results in Google.

Which Discovery are we referring to and, more importantly, how does it relate to Software Development?

Let’s go to the textbook definition of the word and start from there. Oxford defines Discover as “Become aware of (a fact or situation)”. Discovery by interpolation would be the act of being discovered.

Plain enough. Let’s break it down.

 1. What are we trying to discover?

 2. Why is it important?

 3. What if we don’t discover?

By trying to answer these questions, we will try to analyze the deep rooted need for Discovery in Software Development and why it matters.

 1. What are we trying to discover

Those familiar with the law of United States would relate to Discovery as a pre trial ritual wherein the prosecution and defense share material evidence and witness list with each other. This is followed by depositions and expert testimony preparations and all this leads into a formal trial overseen by a jury of peers.

Software Development is similar in many ways. It’s a formal activity of developing software application (generic term for all sorts of software development) using various tools and technologies leading to a tangible work product to be used by the requester of that software application. The glaring exception being that most software development activities are not prefaced with a Discovery process i.e. there is no proper sharing of ideas, expectations, understanding of business requirements, existing processes, integration with legacy systems and feature prioritization.

How often do we see generic requirements such as “I need a CMS application”? Pretty often based on cumulative industry experiences.

Without delving into the specifics of what may or may not be required in a given situation, we start shooting answers like – WordPress, Magento, Joomla, a custom CMS etc. It’s not that any of these is a bad solution. The challenge is that we don’t know if any of these is the “right” solution based on the open-ended problem statement.

Discovery in the context of software development is the act of understanding the problem statement, identifying the linkages and charting the path forward while keeping a 360-degree view of the surroundings. Software application development should not happen in a silo. The stakeholders need to be aware of the history, the present situation and try to project the evolutionary requirements so that a sound foundation can be created.

Example: an application for Human Resources team for attendance tracking. It is very important to know how that information is going to be used. If the Payroll team is going to dock defaulters and are using an existing application, then a bridge also needs to be created for inflow-outflow of information from the yet to be built system for the Human Resources team and the one being used by the Payroll team. This fact may not come to light unless all aspects of the problem statement are understood and analyzed.

In essence, Discovery captures:

Deep understanding of problem statement

1. Breaking down the problem into indivisible units
2. Writing good user stories, tasks and epics

Identification of all key stakeholders – users, customers, support agents, daily drivers and departments affected by integration

Factors affecting the development and use of the software application such as artificial budget constraints, unrealistic timelines, linkage with legacy systems, integration with 3rd party applications and compliances (HIPAA, PCI etc.)

Feature prioritization

All software development efforts struggle against the challenge of implementation of a large feature set with only a fraction of budget and time allocated for the effort. Something has to give. One natural response could be to allocate more time and money – that would certainly help but a rebuttal would be: is that the right solution? If we approach the problem from the other end, the solution becomes – let’s trim the feature set.

In majority of cases, a lot of time and budget are gobbled up by nice-to-haves and bells and whistles. An accurate representation of the effort involved in implementation of the feature set gives the stakeholders a good insight into where to invest the critical resources and at what juncture (Phase 1, Phase 2).

A simple x-y plot (as below) can go a long way in helping accomplish this goal.

The x-axis represents the Business Importance of each feature.

The y-axis represents the Technical Ease of Implementation of each feature.

The +ve side of the x-axis represents high business value and -ve side represents low business value.

The +ve side of the y-axis represents easy technical implementation and -ve side represents tedious technical implementation.

All features (marked with a X) would fall in one of the four quadrants. The top right quadrant represents all features which have high business value and are easy to implement getting them the nickname – Low Hanging Fruits. These features must be addressed first.

The bottom right quadrant represents all features that have high business value but difficult to implement, hence called Important with Difficulties. This set should be addressed second.

The top left quadrant has features which are easy to implement but carry low business value, aptly labeled Maybe Later. These features should be addressed if and only if first and second set have been completed within time and budget.

The bottom left quadrant carries features which have low business value and are hard to implement. These need to be dumped.

An exercise like this can bring in a lot of value for the stakeholders and provide valuable insight into making sound business and investment decisions.

 2. Why is it important?

Time. Money. Peace of Mind. Accountability. Getting the gist here?

Quite a few software development efforts fail or end on a bad note between the service provider and the client due to lack of transparency in what to expect. Discovery goes a long way in facilitating that contract between the two and setting up a framework of doables, in-scope items and prioritized features.

1. Time: Time is Money. Even if it isn’t for everyone, it still is a precious resource. There are only 24 hours in a day on Earth and most people try to optimize the utilization of their time. Discovery aids in that. It points to the things that deserve our time by identifying those things.
2. Money: If you don’t care about Time, you certainly care about Money. If you don’t care about either, then you’re reading the wrong content right now. Almost all software development efforts are constrained by budgetary limits, which makes it imperative to make wise and informed choices on where to spend this resource. Discovery identifies the priority items and the efforts required to work on those items. This gives the stakeholders the necessary ammunition to take calls that could influence their financial futures, especially in the case of startups, which are bootstrapped or low on funding.
3. Peace of Mind: Knowing that we have made the right software application investment decision based on facts and data empowers us to tread ahead with conviction. This is even more important for startups which are funded on dreams and ideas.
4. Accountability: Holding the software application developer / agency accountable for their promises is no mean feat. The legal jargon of contracts, oral commitments and the overwhelming human desire to trust others all make us susceptible to errors. A well executed Discovery phase ensures that majority of the operation is black and white and there aren’t any fuzzy areas that could be interpolated differently based on the reader. Clearly worded feature sets, user stories, epics, tasks and flow diagrams set the binding tone of the relationship that is both rewarding and productive.

3. What if we don’t discover?

Really? We’re still on this. The previous chapter about Time and Money should have cleared up why it’s vitally important. There are certain other aspects of Discovery that make it attractive.

1. It typically happens only once, at the beginning of the software development effort.
2. It’s not very expensive. Depending upon the scope, it could be wrapped up in a couple of weeks.
3. The ROI is huge. With minimal upfront cost, it goes a long way in defining what needs to happen, the velocity and order in which it should happen and helping clear up the muddied waters. Most businesses or entrepreneurs have an idea. That idea needs to be defined, groomed and scoped to be ready for ingestion by the technical team. In absence of that, certain assumptions and design choices are made by various stakeholders that may be contrary to the vision and natural progression of that idea.

The question then becomes: why NOT invest in Discovery? It’s required. It’s rewarding. It keeps various stakeholders aligned with each other.

The cost of not doing discovery goes beyond financial impact. It’s emotional as well. We are all vested in our endeavors materially, financially and emotionally. Failures are part and parcel of doing something – a business venture, a risk, an experiment or trying something new. Failure resulting from not doing it the right way is taxing. Discovery prevents that. The business idea may still fail but it won’t be a result of poor planning. That sums it. Discovery is our planning tool, an understated and under-appreciated precursor to software development effort.

Say it aloud: We will Discover our way to successful software development.