Being Data Driven - Analysis the Lost Discipline

I always had mixed feelings with Agile. Mostly like it but I think some disciplines were always left behind like Architecture and Design. There is another discipline which often times I think we need to do more which is analysis. There is a huge relationship between Analysis and Being Data-Driven. Amazon is a Data-Driven company. There is no sense to just collect data and do nothing with it. So analysis is an old and yet important discipline. But what being data-driven means? Well, it means a bunch of things it could be from a Deep Dive analysis or simply rely on industry data or evidence of someting rather than just opinion.  So you might be wondering why we dont do more of that? That's a good question and I believe there are a couple of reasons. 

The issue with Standard Process

Before agile, the world was all about the process. In some sense, I would say the world still is about that. Back to the RUP Framework, there was an analysis discipline, and software/systems analysis was a prominent role in the industry. Little by little that role of the analyst becomes obsolete as the developer or engineer ends up doing more roles like (Design, Analysis, Testing). I believe agile had a huge influence on that plus the fact that most of the time there were huge word documents with +300 pages where you had code in written form and the complexity was not that big and definitely there was too much up to front thinking. So agile, historically always was against BDUF(Big Design Up to front) and I believe generally is a good idea. However, some problems are complex and they are very hard to do on-demand and they require more design up to the front in order to get them right. Engineering Organizations and Product Organizations have completely different realities. 

Even in engineering Organizations, Analysis is something that is done very little or nothing. It's true that not all kinds of problems require such discipline or you could do it in an agile fashion more on-demand. The main point is there is value in analysis, especially if is data-driven because the data always tells the truth.  So when agile was created there was lots of waste in analysis and I would say Engineering Organizations were not a thing. 

Throwing the Baby with the bathwater 

There is this English expression that says "You don't want to throw the baby with the bathwater". However, I believe thats exactly what happened. We should not do big BDUF for simple problems and things that do not have an impact, complexity, or technical challenges. However, if you want to be Data-Driven you need to do analysis. Data-Driven Analysis has several benefits such as:

 * Reduce Cost 

 * Avoid Re-Work

 * Better Customer Experience

 * Get it right from the GetGo 

Better Customer Experience happens because as you are on an engineering or product org you tend to deliver things that work better on the first shot and require less re-worst and migrations. If you take a long time to get something right you will affect your user experience. 

Reducing cost and avoid re-work is super appealing, so why not apply that for all kinds of work? Because not all problems are worth doing Deep Dive Analysis up to the front and you could be just inflicting WASTE. 

When to do Deep-Dives Vs On-Demand work

Figure it out when to do it or when not to doing is an often hard task. I believe there are some factors that will give you better criteria were to run some Deep Dive analysis vs being more on-demand such as:

  * How much you are exposed to your consumers?

  * How many consumers do you have?

  * What is the blast radius of refactoring if you get it wrong?

  * How complex the problem is and how much coupled with the product it is?

  * How much you will cost you to do it again if you get it wrong? 

Based on that I believe you can have a better sense when run this Deep Dive Dat-Driven analysis vs being more agile on-demand with analysis/design. 

Data-Driven Analysis

So in order to demystify Data-Driven, we need to look into some samples on what means being data drive such as:

 * Look Industry Data(Surveys, Research, Polls)

 * Look for References (books, articles, posts)

 * Analyse your own data (Code, Database, Tests) - Github can help a lot

 * Have Theories and use the data to validate your theories 

 * Structure data in ways that are simple to understand

So as you can see being data-driven is not an alien thing, it quite simple actually. This is great because by doing that we have so many benefits such as:

 * Drive Fear Out (Data tells the truth)

 * Avoid Bad Decisions

 * Avoid Waste

 * Favor Science == Create a culture around Data and Logic

Even being data-driven you can make mistakes and learn things along the way which is totally fine however I would argue is much harder. If you combine POCs + Data-Driven analysis I would say you can build strong and solid foundations for Designs. 

Tools & Practice

IMHO the killer app is the Excel or googles sheets. While collecting data, IMHO is the place where you can structure your finds easily and also easy to share and others can make comments. However, after conducting your analysis I would say a slide deck could be a good place to splash the results/findings.  I know lots of people hate slide decks but If you get it right and make it as zen as possible and educative, I believe it could be a great tool to convey information. After all, you want to use the data to tell a story and drive people into one direction. 

Data-Driven Analysis is a strong practice that is mandatory in some kinds of problems(not all of them, not CRUDs for sure :-) ). You can also rely on grayscale for this discipline, like a dial, you dont need to do it for 1 year in a massive waterfall or dont do it at all, you can find balance and different intensities in different sets of problems. Like anything in life, continuous practice will improve your results. 

Cheers,

Diego Pacheco