Lean 5S applied to Agile Software Product Development for Oil and Gas Integrated Process Safety Management

5S principle in Lean Manufacturing, was developed by Hiroyuki Hirano and Osada in Japan (with Just in Time manufacturing). Later Safety was added to become 6S.

During 2010-2014 while working with Lifewood Data Technology, a Business Process Outsourcing organization specializing in Digitization using manual and automated workflow, I had the opportunity to implement 6S. When I suggested to include ‘C’ with 6S, Ronald and the team welcome that. With my motto being WeCanWeCare, the ‘C’ denotes the Care – Care of Customers, Care for Employees and Care for other Stakeholders.

Source: Hirano's view of the 5S concept (Hirano, 1995, p. 34)

Fast forward in 2018, when I started with IRESC as a product manager, I had no idea on what was Risk Consulting and what are the challenges of Consultants. Initial few months I spent interviewing management team and consultants on how they went about when a project was initiated. Management team’s expectation was to develop many systems.

Over period of time this scope was narrowed down to integrated process safety management system to help Facility Owners, Operators, Design Engineering companies, Safety consultants and others involved in managing or designing hazardous installations such as offshore platforms, floaters, LNG facilities, refineries, petrochemical complexes, and storage and transport operations covering Risk Management studies through-out Plant Life Cycle including HAZID, ENVID, HAZOP, SIL Classification, Safety Requirements Specification, Alarm Management and Bow-Tie Analysis, SIL Verification and Safety Critical Elements/Performance Standards with an underlying Safety Asset Database of all instruments, alarms, mechanical safeguards, and safety critical elements which can be taken forward to the maintenance program and feedback by Owners/ Operators to better manage their process safety program. One can imagine the challenges of developing such solution from the scratch without any experience, knowledge and with limited resources.

With COVID-19 situation, Haz360  (https://www.irescglobal.com/softwares.html) is being used by multiple teams working concurrently from home and office from different locations across regions covering multiple units of facilities. This has been feasible with the support of both Consultant Users (with execution experience of over 200+ projects, Management team and Development teams collaborating continuously and delivering the solution using Scrum (Agile methodology). With my prior experience on Lean, I also applied some of the 6S principles to this framework.

We started off with a very big list of product backlogs and we delivered functions/features iteratively with many sprints. Our approach had been based on immediate project requirement taking one function at a time. With 25+ projects we gained many variations of the requirements and delivered using continuous delivery model. My focus in this publish is on Lean 6S principle applied to Agile.

Many of you may be aware of the 6S - Seiri, Seiton, Seiso, Seiketsu, Shitsuke, Safety and Care 

Seiri (整理) – Organize (Sort)

Seiton (整頓) – Orderliness (Sequence/prioritization)

Seiso (清掃) – Cleanliness (Eliminate waste)

Seiketsu (清潔) – Standardize (Systematize)

Shitsuke (躾) – Discipline (Sustain)

Safety – Keep Work Environment Safe

Care – Human Factors Engineering

We have had many challenges over the course of the development. First and foremost being the Technology framework. It took 3-4 months to finalize on the core framework and all the components needed. With very specific requirement for web based excel like grid user interface, unstructured data known only few days before project start, hierarchical data with multiple siblings, ability to have underlying database for future analysis, and many more others, we created a backlog of functions and features – with functions being like different types of excel sheets and features being common elements like insert row, copy and paste (rows of data with all the parent and children or multiple cells in columns etc.)

This is where 1st step of 6S – Seiri (Organize) was useful to first organize the requirements backlog as well as all the technology components.

It is always a challenge to decide on the depth and breadth of the solution as well as the functions and features. We had to have a delicate balance. Instead of typical water fall method where we will document all requirements and start designing, we took Agile to deliver what was required to use for first project. With over 25+ live project experience, we continually improved the functions and features. Release 1.0 being matured and self running and self deployable, now we have embarked on Release 2.0 where our objective is to make it more flexible , secure and user friendly externally. Also internally make it more clean code, maintainable and readable. Agile is about improving continually.

Here is where the 2nd step of 6S – Seiton (Prioritization) was helpful. As a product owner, I took decisions on the prioritization in consultation with the Management team. Our first few sprints were planned to help us complete those backlogs which will enable us to use the software for our first project.

I also wore the hat as a Scribe for the project to help the Chairman to get firsthand experience on how the software will be used in real life situation. There were over 35+ members attending from owners, contractors, vendors, the one week session of HAZOP. The software was projected on to a large screen for everyone to see. Any issue with software was being watched by 35+ pairs of eyes. This was a huge pressure. We used Microsoft Teams to communicate with the development team during short tea breaks and lunch breaks to resolve few minor issues and some of the major issues were also planned to be delivered next day. With just 2 programmers who were new to technologies and the components we managed to complete the session successfully. Off course it was our first real life exposure of how the software will be used and what were the challenges faced by scribes. Based on this our backlog got bigger - some were bugs, some enhancements and some were totally new requirements. Without Agile thinking it would had been impossible to deliver the code at such short time-frame.

Originally we started using JIRA to document all the scope and track. However when the project deadline was closer we found it difficult to keep up with the pace of the changes and delivery expectations, and we had to apply the 3rd of the 6S – Seiso (Eliminate waste) by dropping all documentation using JIRA. We started using a simple system of Excel to keep track of the backlogs as there were loads of feedback from users once the initial version was released.

I remember during 2000, when I merged my small software product company COSMIC with then NYSE listed NASDAQ company, I was provided with a 60 member team. My task was to convert my Products Jewelry software with integrated accounting and Supply Chain software from Magic Software (Rapid Application Development (RAD) tool) to Java and ASP.NET technologies. Being a CMM Level 5 company there were huge documentation process with few project managers tasked only with such work. Unfortunately in those times there were no Agile concept (though I had been practicing and delivering entire Trade Finance application including 25+ accounting reports to be approved by HKMA within 6 months with a team of 20 offshore with minimal documentation – I must thank Magic Software for that efficiency and productivity – it was a wonderful tool I used from 1991 to 2000 – very structured language with ability to monitor any programmer’s code. It did not allow any programmer to write the code differently compared to Java or ASP.NET codes which I found to be very spaghetti like with no inherent standards being enforced. Please don’t take me wrong – I am not against documentation but the process need to be thin and efficient not to drown development resources with unnecessary work.

Documentation is needed but in a simplified manner easier to trace and not take too much of developer time. Especially for Testing, documentation is key for keeping track of various scenarios and ensuring that Quality Assurance team automates the tests every time changes are made to releases.

Eliminate Waste - Task switching: many times Agile practioners advise NOT to allow Task Switching. But in practice especially for Agile in continuous delivery mode, developers must be open to in and out of tasks on need basis - yes this should not be a daily affair and try to avoid such task switching on a regular basis but at the end of the day Customer Users get the first priority. Also one should keep in mind if the team size is too small like just 1 or 2 then the Task Switching will be inevitable especially before the system matures during iterative delivery mode.

Eliminate Waste – too many long meetings: one of the beauty of Agile Scrum is its stand-up meeting (this is a very good practice even otherwise and important that teams are kept small in size). Avoid very long meeting but instead have very short 5 to 10 minute meetings everyday just to ensure everyone is on the same page. It is not about micro managing, but ensuring every team member is clear about their tasks, get help from colleagues on any technical challenge they face and also a way of pull system to manage the task allocation between themselves.

Eliminate Waste – Lack clarity on which task to do: “Begin with End in Mind” is another of my favorite - this is similar to OKR (Objective Key Results originated by Andy Grove of Intel). When the team is able to have clarity on what needs to be done broken down to smaller tasks, it is easier for them to complete. It is also a good way to build confidence within the team seeing successes.

Eliminate Waste – Not testing like a user: Stepping in to Users’ shoes and thinking like an user only comes with exposure and experience. Many time developers’ lack the empathy. Historically having only faced with bugs or problems during development phase, developers feel uncomfortable to interact with users and learn how the users use the software. Also some users do not have empathy for developers’ challenges – lack of resources, lack of training, lack of clear scope etc. It is mutual. It is important that Management team set the expectations right and have a balanced view to encourage open constructive discussions.

Eliminate Waste – Not completing last mile (End to End): This is useful to anyone in life too - many time developers have the attitude that ‘I finished my task’ - coded, tested on my environment, compiled and shipped. But in practice this is not the end - this is also where the “ C’ comes into play - Care for Customer User - meaning it is important that the changes requested by end user is tried along with the end user after patch is updated and ensuring this is what they wanted. I have seen many times there may be bugs which only happen the way user operate or in their environment which possibly could not be simulated at developer environment. This important step will eliminate user frustrations and improve Customer Satisfaction rating to highest. This is also the opportunity to learn and interact with users. Typically developers are shy to speak up and face customers. This is an opportunity for them to improve their communication skills and also see the success first hand.

Eliminate Waste – lack of communication on limitations and constraints: Due to available resources and technology constraints, it may not be feasible to meet all the expectations of the users. This is where the weekly project status update plays an important role to communicate with the Management and end users on the progress of the development work and clear user manual or release notes on what is available and what are still Work In Progress (WIP).

This bring us to the 4th step of Seiketsu (Standardize or Systematize) – it is important that all programmers follow certain standard way of coding, naming conventions.

For C# for example coding guidelines might look like

·        Avoid writing of long functions or long class files

·        Create separate file for each class. Don’t have number of classes in single file.

·        The method or function should have only single responsibility. Don’t combine multiple functionality into single method

·        Controller Actions in MVC should have meaningful names and each action have single responsibility only.

·        You can also put some constants like database connection, logger file name, SMTP information variables etc. in form of key and value pair in config file.

·        Use resource files instead of hardcoding strings.

·        While comparing string, convert string variables into Upper or Lowers case

5th step of 6S is Shitsuke (Discipline or Sustain) – maintaining this way of working with every new programmer and having a coding standard with continuous improvement mind set is important for the organization. I learnt this very hard way by losing touch on my coding skills after 2000 focusing on Sales and Product architecting. This hit me hard when in 2008, I had to let go all my programmers and the huge eJewel, eHR, eTrade application became worthless with no other new comer able to understand or maintain. This again emphasizes the need for Standardization and some amount of documentation (in the code by programmers on their logical framework and why they wrote the code this way and what were the constraints).

This brings us to the final S – Safe Working Environment: I am a big fan of remote work@home from the beginning. I also believe in giving opportunity to women coders who might have given up their career after marriage and child birth. With remote work@home it is easier for them to be flexible on their work schedule as well as eliminate the need for travel (typically average worker spends 2 hrs a day in commuting and the added stress of transportation. Though I also would like to employ physically challenged, there is lack of such trained resources currently. Hope this changes in the future.

To conclude, we have to recap the 1st Principle of Agile - “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. This agile principle refers specifically to customer satisfaction. By delivering product features and functionality that offer value to the customer, we keep the customer happy and satisfied by delivering their requested features not only early in the project, but also continuously during the project.

This lean principle also can be applied to Strategic Execution , Sales Process, Customer Service and others. More on this in the future until then StaySafe StayHealthy StayHappy