Challenge

I work in the Information Technology department of a financial industry and for the past year I  have been focusing on how to make the release process more efficient and faster. The issue we have  been encountering is a developer will spend a week on developing a new feature and then they “throw  it over the wall” to the QA team to test it and then they pass it along to the operations team who would  then deploy the code into production.  The problem here is that each of these teams are working in silos  so it takes much longer for the code to make it to production.

You will see a developer say they are finished and then QA gets ahold of the code and starts  testing it and ends up finding defect after defect and throws it back to development. This process takes  weeks until QA is finally ready to give it the green light. Then the operations team gets ahold of the code  and finds out they can’t build it because it can’t merge into the code base that they have or there is a  different version of a dependency on a server or possibly there is a security vulnerability etc. This then  could take days to figure out and again is simply holding up the feature being deployed and released  into production.

Selection    Obviously, this process was incredibly inefficient and took way too long to get anything new into  production. My team was then tasked with figuring out how to iron out the process and make it better  for the entire organization. So I decided to use the mind mapping tool to map out the current process so  that we could see where the issues were and how we could make it more efficient for the future.

Application    I asked ten teams to create a diagram of their release process from beginning to end. I told them  to start with the developer making the code commits and end with the new feature being deployed to  production. I asked them to map out each single step in the process and write down the process time  (the average time it takes for the tasks to complete), the wait time (the time it tasks before that task can  start) and then from there come up with the lead time for each task (process time plus wait time).

After each team went through that mind mapping on their own then I had one representative  from each team meet and we started comparing the processes and coming up with the similarities and  the outliers. We then grouped the similar steps together and showed each team’s lead time and put the  outliers in a different section on the board.

Insights

From there we could see some common steps in the process that we could tackle that would  improve the release process for every single team. For example, many teams would get into the QA step  before they even ran a security scan on the code. The problem with this is if there was a security risk,  they might have to recode their entire feature making all the time that was originally spent on it go to  waste.

For this example, we decided to automate the task of scanning the code for security  vulnerabilities. Now when a developer committed their code it would automatically kick off a security  scan and give the developer fast feedback on whether there was a vulnerability in their code or not. By  moving this step to the beginning of the release process, developers were more efficient and were able  to fix the security risks before even starting the testing on the code, saving all of the teams time.

By completing the mind mapping first, it gave us a clear starting point of what step in the  process to improve first. Originally we thought we needed to find a way to deploy the code faster but by  mapping out each step we saw that the security scanning step was the correct step to change first  because if you didn’t pass that stage all the steps before it were a waste. Additionally, this was a similar  problem between all ten teams, so this small change greatly improved the process for multiple teams.

Approach    Overall, this mind mapping tool helped us see all the issues with the release process and has  been a huge help in improving it. I think next time we go and look at the release process we will look at  the outliers first and understand why they were outliers. The reason I would like to do this is if only one  team is having an issue with the operations team building their code, we could potentially look at why  the other teams aren’t having that issue. Then we can make those small changes to improve those  outliers while we also investigate the automation for other steps. By doing this we can quickly get all the  teams on the same page and then the automation is much easier. When just one or two teams do  something slightly different it inhibits us from creating automation because there isn’t a standard. So if  we get each team to agree on the same process it makes the whole release process more efficient and  easier for us to automate.


Challenge I work in the Information Technology department of a financial industry and for the past year I have been focusing on how to make the release process more efficient and faster . The issue we have been encountering is a developer will spend a week on developing a new feature and then they “ throw it over the wall ” to the QA team to test it and then they pass it along to the operations team who would then deploy the code into production . The problem here is that each of these teams are working in silos so it takes much longer for the code to make it to production . You will see a developer say they are finished and then QA gets ahold of the code and starts testing it and ends up finding defect after defect and throws it back to development . This process takes weeks until QA is finally ready to give it the green light . Then the operations team gets ahold of the code and finds out they ca n’t build it because it ca n’t merge into the code base that they have or there is a different version of a dependency on a server or possibly there is a security vulnerability etc . This then could take days to figure out and again is simply holding up the feature being deployed and released into production . Selection Obviously , this process was incredibly inefficient and took way too long to get anything new into production . My team was then tasked with figuring out how to iron out the process and make it better for the entire organization . So I decided to use the mind mapping tool to map out the current process so that we could see where the issues were and how we could make it more efficient for the future . Application I asked ten teams to create a diagram of their release process from beginning to end . I told them to start with the developer making the code commits and end with the new feature being deployed to production . I asked them to map out each single step in the process and write down the process time ( the average time it takes for the tasks to complete ) , the wait time ( the time it tasks before that task can start ) and then from there come up with the lead time for each task ( process time plus wait time ) . After each team went through that mind mapping on their own then I had one representative from each team meet and we started comparing the processes and coming up with the similarities and the outliers . We then grouped the similar steps together and showed each team ’s lead time and put the outliers in a different section on the board . Insights From there we could see some common steps in the process that we could tackle that would improve the release process for every single team . For example , many teams would get into the QA step before they even ran a security scan on the code . The problem with this is if there was a security risk , they might have to recode their entire feature making all the time that was originally spent on it go to waste . For this example , we decided to automate the task of scanning the code for security vulnerabilities . Now when a developer committed their code it would automatically kick off a security scan and give the developer fast feedback on whether there was a vulnerability in their code or not . By moving this step to the beginning of the release process , developers were more efficient and were able to fix the security risks before even starting the testing on the code , saving all of the teams time . By completing the mind mapping first , it gave us a clear starting point of what step in the process to improve first . Originally we thought we needed to find a way to deploy the code faster but by mapping out each step we saw that the security scanning step was the correct step to change first because if you did n’t pass that stage all the steps before it were a waste . Additionally , this was a similar problem between all ten teams , so this small change greatly improved the process for multiple teams . Approach Overall , this mind mapping tool helped us see all the issues with the release process and has been a huge help in improving it . I think next time we go and look at the release process we will look at the outliers first and understand why they were outliers . The reason I would like to do this is if only one team is having an issue with the operations team building their code , we could potentially look at why the other teams are n’t having that issue . Then we can make those small changes to improve those outliers while we also investigate the automation for other steps . By doing this we can quickly get all the teams on the same page and then the automation is much easier . When just one or two teams do something slightly different it inhibits us from creating automation because there is n’t a standard . So if we get each team to agree on the same process it makes the whole release process more efficient and easier for us to automate .