James Bob Lawless

There are number of reason why DOE is not commonly used in the coroporate world or service settings. The most fundamental challenges in applying Design of Experiment in a service set-up are the following: Lack of Awareness, Knowledge and Misunderstanding which tends to discourage experimentation in most service organizations Performance of a corporate or service industry is very difficult to measure accurately Corporate or Service Organization's Process Performance has a great dependency on human behaviour involved in the process Impalpable parts with the delivery of service, outcome may not be as stable as manufacturing. Is often simultaneously contructed and consumed and unapparent dimensions are important indicators of service quality context. This means experimental control of the inputs and measurement of the results needs careful validation and consideration In any service process, it is very common that a clear description and distinction of process is needed for quality improvement and control. Understanding of front/back-end processes and customer requirements are essential for these improvements. Practical Solutions to Overcome These Reasons 1. Start with the basics by defining all processes and operational definitions 2. Standardize and Set Clear Quality Guidelines and Process Documents available to everyone 3. Build Robust Awareness Drive across the organization 4. Influence other Leaders and Empower People to do small DoE in their processes to practice the tool and see potential improvements

Technical Debt - Is also called as "Tech Debt" or "Code Debt". This describes the output after a development team, taken action to accelerate the delivery of a piece of funtionality in which later needs to be refactored. In simple terms, it’s the result of stressing on faster delivery over perfect coding. Guidelines for Technical Debt It is the Agile Leader and/or Scrum Master's judgement wheter to decide of taking the longer TAT vs. having Technical Debt. However, to help them choose the better decision they may consider the following: 1. Factor Tech Debt into "release-level" stages 2. Alignment between organization and technical issues 3. Working Agreement 4. Shot-Term Investments for Long-Term Improvements 5. Iterations 6. Experimentations 7. Iteration-Level Activities Code Coverage Cost Overhead Velocity Reduction Developer's Satisfaction Refactoring Slack Mentoring Flow Static Code Analysis Retrospectives The Amount of Acceptable Technical Debt (If Any) The only evaluation of this is “snowball programming” methodology, that this accomplishment leads to more effectiveness in the least crucial parts of the project. Get an estimate of the percentage for the bulk of what can be allowed into critical functions and less important functions. Show and explain this benchmark to your developers from the startof the project, so they will have a quantifiable number to work with. As nearing to the project end, they will inherently include this productivity benchmark together with their other KPIs instead of trying to include efficiency as a last minute addition to the process.

3 Types of Time Series Analysis 1. Trend - It shows the general tendency of the data are increased, decreased or stagnate in a reasonably predictable pattern and / or long period of time. An application of this is when we analyze the KPI Performance of a team over a week, month, quarter or year. As these type of data in a report generally show trends or show patterns over a period of time. 2. Cyclical - The values of the data exhibit ups and downs repeating after a period from time to time due to economic or business cycle. An application of this is when we analyze business growth or recessions, depressions and recovery. 3. Seasonal - It has an indicative in which the data arrangement or experiences regular, foreseeable and repeated every calendar year. An application of this is when we analyze variations due seasons, weather, traditions etc. Overall the most difficult to handle type of Time Series is Seasonal as when you need to improve a process with this type of data, you have limited data points and sometimes does not show trends or patterns.

Kotter's 8 Step Change Model can be related and integrated to LSS DMAIC projects by: 1. CREATE URGENCY (Brainstorming) Look for potential threats and create scenarios depicting what may happen in the future Identify and study opportunities that could potentially be expoloited Secure support from customers, external stakeholders and industry expert 2. FORM A POWERFUL COALITION (DEFINE PHASE) Identify key leaders and stakeholders to support your project. Similarly to Stakeholder Analysis in LSS Define Phase Create a SWOT analysis of your project team members to make sure you have a good mix of members to help in your project 3. CREATE A VISION FOR CHANGE (MEASURE PHASE) Identify the important values that are critical to the project. As to LSS, this is similar to identifying the critical Xs. Have a short-summary that depicts what you see. As to LSS, this is similar to Current & Future VSM 4. COMMUNICATE THE VISION (ANALYZE PHASE) Use the visions and make decisions and solve the problems. Likewise to LSS, these are your RCA sessions and tools Address the concerns and anxieties of the people. As to LSS, this step are similar to your Solution Brainstorming sessions and again the tools involve 5. REMOVE THE OBSTACLES (IMPROVE PHASE) Identify or hire change leaders whose main role is to deliver the changes. As to LSS, this is similar to building solutions and/or process re-engineering to come up with concrete solutions to address the root causes. 6. CREATE SHORT TERM WINS (IMPROVE PHASE) Find quick wins to be implemented. Similarly your Kaizen Burst or Quick Solutions to address the low hanging fruits or challenges. Examine and analyze potential solutions to address the challenges. Using Control-Impact and Effort-Impact Matrixes to prioritize solutions with the least amount of effort invesments and highest ROIs. 7. BUILD ON THE CHANGE (CONTROL PHASE) After each improvements, analyze what went well and look for further improvements. Similarly in LSS projects, you may relate this step as to the Future State Value Stream Map, whereas - you keep on improving the recently improved state of the process. 8. ANCHOR THE CHANGES IN CORPORATE CULTURE (CONTROL PHASE) Reward the project team members and recognize the key members that significantly delivered the positive changes. Create plans to replace key leaders of change and standardize the process. As to relating this to a LSS project, a well planned and managed process documentation is equially important to keep all improvements and avoid or eliminate future defects in the process. At the same time, project knowledge alignment across.

Code Refactoring is method of improving or updating the codes without changing the output and/or functionality of the solution. A team must consider doing code refactoring is before making or adding any updates or new features to exisiting codes. Looking back and cleaning the exisiting code before adding in new will not only enhance te quality of the solution, but it will also make it easier for other developers to build on to the original codes. Code Refactoring may not be avoidable in projects. However, these are the Main Techniques: 1. Red-Green Refactor - widely used in Agile Test-Driven Development. It breaks into 3 distinct steps 1.1 Stop and Consider what's required (RED) 1.2 Pass Basic Testing (GREEN) 1.3 Impose Improvements (REFACTOR) 2. Refactoring by Abstraction - used for large scale refactoring to be done. It involves inheritance of class, order/hierarchy and extraction. The main purpose of abstraction is to minimize unnecessary duplication of codes (e.g. Pull-Up / Push-Down). 3. Composing Method - It involves streamlining of codes resulting to reduction of duplicates. Done through numerous processes, including "Extraction" and "Inline Methods". 4. Simplifying Method - It involves tweaking the interaction and relationship between classes. Adding, Removing and Introducing new parameters together with changing parameters with explicit methods and calls are all aspect of simplification. 5. Moving Between Objects - It involves making new classes and moving functionality between old & new classes. 6. Preparatory Refactoring - This is done when a software developer notices the need for refactoring, while adding new feature(s). By doing-so, the developer is minimizing future debugging or technical debt. Conclusion: Code Refactoring is keeping a clean, orderly and streamlined codes. Do regular cleaning on your codes and you will hve better solution and productive work environment.

Visual Control is a method used for displaying the KPI (Key Process Indicators) of a process or processes to its end-users/participants. These visuals aids and gives early warning indicators to the team members and learership for any deviation in the standardized process and/or impact of the errors. There are various types of visual controls and here are some of them and their effectiveness in use: 1. Color Coding - it is the easiest form of visual control to apply to any and all visuals (e.g. Dashboards, Reports, Boards, etc.). It is highly effective as it gives you the overall impact and by error impact at a glance. 2. Andon - it is a system that provides real time notification to leadership and its team about any challenges or problem in the process. It is regarded effective as it provides real-time alert and also serves as early warning indicator to prevent an error from happening. 3. Floor Line Marking & Signage - this type of visual control shows pathways, lanes, working cells and/or intersection. This helps the workers to easily and quickly identify different marking & signages across their workplace. It shows where the required materials and flow of process are, which reinforces process standards and of course safety. 4. Kamishbai Board - it is used mostly on manufacturing set-up wherein it is a simple way for workers to be able to verify if a particular task or tasks has been finished. Overall, the benefits of a Visual Control will: Help detect the problems in real-time and act on them faster Avoid problems that may potentially arise during the process Reduce cost due to rework or quality defects Reduce or Elimate other types of wastes Increase productivity and quality of the process Increase Customer Satisfaction Increase Employee Satisfaction Increase Profit

The acronym INVEST is a guideline to come up with a well-written user story. A good user story should have: Independent (story should be independent of all others) Negotiable (story is not a contract, rather it is a trigger for conversation or brainstorming) Valuable / Vertical (story must show value or prioritization otherwise it should not be done) Estimable (to a good approximation) Small (so as it will fit in multiple iterations) Testable (story must be validated before we say it's done) Out of these 6 guidelines, the most challenging part to follow is Independent. Simply because people always tend to relate or connect details of their story to one another, making it challenging to break apart in order for the story/stories to be worked on in any order. This somehow coincide with Valuable as we loose track what is really the priority of the user in their story.

Human Centered Design is an approach in problem solving that focuses, begins and ends with the actual people or end users of the product or solution while specifically built to suit their needs. I personally once used this principle to solve a particular process problem in my previous organization wherein I had to cultivate deep empathy with the end users of the team I am supporting at that time. The product design was solely focused on their wants and needs to both address the challenges and be user friendly at the same time. A couple of prototypes were built and the project took a bit longer than the estimated target closure date. But finally agreed on the final design before putting it in production or use.

McClelland's Theory is about a person's explicit needs picked and formed over their life experience may it be professional or personal. These experiences are categorized as Achievements, Power and Affiliation. A person's performance quality is exactly determined by any of the categories mentioned. A Project Leader can use these 3 needs as motivation for his/her project team members. As it plays a vital role in an individual and/or organization's productivity and the overall employee's satifactions towards work.

The concept of Bodystorming is another form of "Brainstorming". Whereas, bodystorming involves the participant's own body to have first hand experience of the solution and or potential solutions. It helps the developers and project team members observe the triggers and issues end-users may experience. This method is widely used in Design Thinking for definition, purpose and product sampling. One sample I can think of is the Virtual Reality devices using our mobile phones to watch videos online or play games. Another sample is when we were still children, we used to "pretend play". We imagine and visualize our favorite superhero character. Sometimes we also wear homemade costumes to fully embody the experience.