building a lean analytics culturedays+2019... · • currently working in an environment using...

Building a Lean Analytics

CultureJustin Ball

Lead Data Analytics Engineer

Nature’s Sunshine Products

My Background and Current State

• Transitioned from Server Administration roles to Web Development to BI/DW

• Experience with variety of web and DB languages/technologies/vendors

• Currently working in an environment using Oracle BI Applications (provides large out-of-the-

box DW, ETL via ODI, OBIEE semantic layer); Pull data from Oracle EBS and several home

grown systems; customized BI Applications

• Analytics stack consists of Oracle DW, OBIEE, Azure Analysis Services

• Presented in the past at UTOUG a few times

• Always had interest in using Lean methods and principles to improve business consumption

of technology as well as improve development cycles

• I attended a party for the last aired episode of Seinfeld

What is Lean?

• Systematic way of eliminating waste in a variety of ways

• Waste is determined as anything not providing value to the end user

What is Lean Analytics?

• Systematic way of eliminating waste in a variety of ways with the

development process of analytics solutions as well as the

implementation of analytics solutions from a business viewpoint

• Waste is determined as anything not providing value to the end user

• Apply Continuous Improvement & Respect for People pillars to the full

Analytics lifecycle (from development to data consumption)

What is Agile?

• Implementation of some lean principles specialized for software

development

• Agile isolates focus, same as Lean

• Agile improves quality, same as Lean

• Agile follows just-in-time concept, same as Lean

• Agile has quick feedback loops, same as Lean

• Several styles: Kanban, Scrum, XP, Scrumban

• Dev cycles map to roadmap

Then, is this presentation on Agile?

• Mostly not, but some yes

Scrum

• User stories sized by story points

• Sprint planning meetings

• Backlog grooming meetings

• Retrospective meetings

• Daily stand-up (best if including product owner)

• Scrum master facilitate scrum process/team (may replace traditional project manager)

• Pull and Push system

• Backlog can be partially managed by product owners

Kanban

• Focus on Lead and Cycle time

• Use Lead and Cycle time as gauge for time to complete story

• Integrate story prioritization into natural development flow and story gather

processes as they occur

• Pull system

• Progress review meetings

• Focus on removing WIP (active dev queue limits exist)

• Periodic reviews to identify how to limit cycle time

Scrumban

• Integration of Scrum and Kanban where features of each are picked based on

what works best in the specific environment

When to use Scrum

• Scrum when:

• Improvement needed with individuals working together (business & dev)

• Project has strict time constraints with additional resources available

• User stories fit into smaller dev pieces well

• Product owners exist and are defined

• Best if trained scrum master exists to help with story points, velocity and

burn down mgmt./planning; helps identify/facilitate resources when burn

down not being met

• Dev work seems to take to long (from another dev perspective)

When to use Kanban

• Kanban when:

• Dev resources are very limited and small but time is more flexible

• If you don’t like meetings

• No scrum master type of resource exists

• WIP needs focus

• Workers naturally work through issues together throughout the day (location

helps) and are incorporating business users

When to use Scrumban?

• Scrumban when:

• You like saying Scrumban

Respect for People

Respect for People

• Respect business units to know what’s best for their unit. Limit their constraints on IT.

• Waste introduced as business units continuously require IT when they can do it themselves

• Respect where users are technical and where they are not and have stronger business

acumen

• Identify analytics solution that works for the user to maximize their strengths

• Database Access for SQL users/analysts

• BI Tool access (which BI solution works for your type of users?)

• Search to Report functionality

• OLAP

• Create their own business data layer

• Analytics autonomy

Constraints

Degree of Self-ServiceC

on

stra

ints

IT Analyst Manager Director

IT CreatesParameterized

Dashboards

Business Creates

ParameterizedDashboards Many Org Levels

Using BI Tool

IT CreatesMany

Reports

Business using machine

learning tools

Waste

Unnecessary Feedback Loop

• Self-service eliminates unnecessary

feedback between end user and

developer creating report/dashboard

• Maintain Feedback for information

needed to support self-service

architecture

• Make it a priority to teach people

who will help themselves

How to Get There

• Identify how your users are using data, maybe you already know

• Work more closely with users, think of what type of user you are working with (from a

technical and business perspective); over time as you work with a variety of users, consider

collectively the functionality necessary in a technology to match users

• Are there users experienced in Excel?

• Are there users who learn well but don’t have tools to work with?

• Are there traditional analysts?

• Consider budget and resource constraints for technology

• Ongoing development cycles should consist of practices that involve frequently collaboration

with users

• Establish BI Tool training program, Center of Excellence (blog or something similar with BI

application tips, analysis tips)

How to Get There continued

• Stay current on vendor solutions (Machine Learning will become more accessible and

delivered in more self-serviceable formats)

• Think of business relationship as a venture partnership; end users are part of the solution

developing process

• Have business user own process of BI tool field names, folders, etc. (anything they can own

will help; use judgement and be engaged in processes with them where needed)

• Bring users together and some demo uses of BI tool or analytics in general (User Days, User

Bakeoff; really looking to establish a user community within the organization)

• Document of BI system and provide definition of fields

• … Start with an A3

A3 Report

• Identify the issue, analysis, target outcome and results on a 11x17 sheet of paper

• Single paper forces attention to focus on an isolated issue (prevents scope creep)

• May not be necessary for smaller bugs, dev tasks, user stories

• Very useful for larger implementations, project planning, architecture changes, larger user

stories or features

• Emphasizes PDCA (Plan Do Check Act)

• Consider audience when creating; helps communicate focus and purpose of project

• Utilizes scientific method for problem solving

• Work on as team; Is a living document until solution is implemented

• Avoid ‘solution’ oriented thinking while creating

Background

Current Conditions

Target Conditions

Analysis

Proposed Countermeasures / Implementation Plan

Results

Follow-up

A3 Components

• Background (Why is this being talked about; What’s the business reason for bringing this up)

• Current Condition (What is the business feeling right now as a result of this issue; Where

things stand today; current symptoms of issue; Use visualizations)

• Target Condition (Contains realistic measurable goals of where you want to be)

• Analysis (Can utilize Lean analysis tools or can be anything you want that communicates

what’s happening that’s preventing the target condition; find root cause; Use visualizations)

• Countermeasures/Proposal (List of things to try to resolve the issue with why and who will do

them; proposal to reach the target condition)

• Action Plan (Could be combined with Countermeasures; could be a Gantt Chart or links to

user stories, etc.; include results, make sure you know how target condition was met)

• Follow-up (Any specific things to watch out for; ensues PDCA is followed)

• Fishbone Diagram

• 5 Whys

• 5S

• Value Stream Mapping

• Any type of chart/report to help

communicate and identify the root issue

A3 Analysis Tools

Fishbone Diagram

Problem

Environment People Policies

Tools/Machines Process

cause

Development/Code

• Categories can be any number and custom to what makes sense

(or follow 4ME: Man, Method, Machine, Materials, Equipment)

• Group potential problem causes into categories, indicate why for causes

• Helps facilitate brainstorming of all potential causes

• Useful for getting to root cause

• Can find a common ‘why’ that impacts multiple categories

1013

23

2730

47

51

58

62

79

40

5SSort

• Only have necessary tools open for a given task

Set in Order

• Arranging and labeling items adequately to easily find

• Follow good naming conventions and have good organization of codebase

• You want yourself and others to find things easily

Shine

• Keep environments clean

• For example: keep content out of production that doesn’t need to be there

• Clean environments limit defects and make it easier to find root causes when there is a defect

• QA and proper testing to keep Production clean

• Implement routine procedures to keep environments clean

Standardize

• Review first 3 S’s and identify where policies are helpful

Sustain

• Follow policies and look for improvements

10

13

23 27 30

47

40

5 Whys

• Provides method to identify root cause

• First why is associated with the process that made the defect

• Then begin asking ‘Why’ was that defect not identified and continue

why’s

• Don’t need to hit 5, and might be more than 5

• Really just need to keep asking why until you realistically cannot

get more information from additional why’s

• Sometimes this is happening naturally while debugging, but

sometimes a fix of a symptom is implemented rather than the root

cause

• Dev processes

• Data quality

• Delivery of self-service

• Types of users reached

• Number of users

• Business units reached

Continuous Improvement

Constraints

Reusable Enterprise Objects

• Data Warehouse

• Semantic Layer, Virtual Database

• Data and Object Security

• Report Sharing System

• Codebase

• Pre-calculate common metrics

Eliminate waste in areas where reuse can exist so focus

on PDCA where necessary

Constraints

• Document Data Flow

• Data is your product, treat

the same as manufacturing

treats production line

Constraints

Use proven software development practices:

• Everyone has needed components of

application stack for them to work in

isolation

• Ability to do branching from master

codebase

• Frequent checkouts, merging

• Checkout only the piece of code you

need to work on, test in your own

environment

Constraints

Use proven software dev practices

• Shorter Dev Cycles

• Automate QA

• Automate deploys

• Removes risk

• Enables fast deploys

and fixes

Transportation

Waste

Over Processing

Inventory

Skills

Defects

Motion

Over Producing

Waiting

Waste

Movement of Code

• Review anywhere code is moved

• How does it get there, what manual

work is done

• How is code merged, how are

conflicts resolved

• What type of movement is involved

for QA

Transportation

Waste

BI Code Flow Diagram

Master Codebase

Dev Branch

(2)

(4b) Test Stage(5) Prod(6)

Dev Branch

Dev Branch(2

)

(4a)

Smoke Tests

Waste

Inventory

Code Repository

• Structure and Organization

• How is versioning done, any

automation?

Codebase Organization

• Use self-documenting tools where

applicable

• Name packages, procs, functions,

objects appropriately

• Use comments, descriptions, etc

Waste

Motion

Guiding Dev Activities

• Auto Complete in Dev Tools

• Organizing workflow (user stories,

iterations, etc)

Code Motion

• Manual work that can be

automated?

• Any steps that can eliminated?

Waste

Waiting

Developers Waiting

• Shorten dev wait time on code

running (are there simple areas

where performance can be

improved)

• Waiting on personnel

• Database connections

• Network changes (firewall)

• Dependent dev work

Waste

Waiting

End Users Waiting

• Performance

• Bug fixes

• New features

• Uptime

Waste

Over Producing

To many products

• Dashboards that can be

consolidated

• Move many reports to one

dashboard

• Consolidate reporting platforms

• Many of the same reports

• Is more likely to happen at an

organization level rather than within

one group

Waste

Over ProcessingTo many features

• Occurs when going through details

of user story to early

• Reduced by self-service (not

creating content in report that’s not

going to be used)

• Wait for users to request something

or get their approval while

collaborating before implementing

Waste

QA

QAQA

• Identify waste in data flow

• Example: Doing QA on the same

data multiple times

Waste

• .

Defects

Handling Bug Fixes

• Be capable of quick fixes

• Cut out unnecessary code and

features to reduce risk

• Remove unnecessary environments

• Prioritize bugs

• Fix at the root

Waste

Skills

Skillsets of Others

• Identify highly analytical end users –

these will be your champions

• Get to know skills of co-workers

Skillsets of Team

• Help organization understand

capabilities of Analytics group

• Be involved with cross-functional

projects

• Self-service training acts as form of

evangelizing

Waste

Real Time Reports

Put in Transactional, BI?

In Transactional:

• Waste with transactional system resources

• End-users constrained when changes needed

In BI:

• Use BI resources, offload transactional system and gain BI performance

• End-users can modify report content w/out IT

Ownership

Ownership

Self-service gives ownership of

analytics to business

Ownership

Give ownership of backlog to

business

Need an IT Champion

… and a Business Champion

End user champions

organically scale self-service

LinkedIn: https://www.linkedin.com/in/justin-ball-3427191b/

Questions?