building a lean analytics culturedays+2019... · • currently working in an environment using...
TRANSCRIPT
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?