Ford Credit DevX Team
The PDO teams were floundering in cognitive overload and change management issues.
Ford Motor and Ford Credit are in the middle of a massive technological change regarding their software delivery model. For years Ford had focused on Pivotal Cloud Foundry (PCF) in their own data centers as the main framework for developing and delivering their Java Spring applications. They recently did an about face and are partnering with Google Cloud to migrate and utilize the Google Cloud Infrastructure.
They are also attempting to build a microservices based architecture using containers (Docker - PodMan) and Kubernetes ( GKE- OpenShift) to deploy those applications. They are also migrating off of Jenkins and on to Tekton for CI/CD pipelines. They have always used FOSSA for license validation and SonarQube and other tools and testing platforms. All these changing technologies while trying to incorporate Software Engineering best practices of TDD, Clean Code, SOLID, extreme programming principles puts a strain on the Product Development Organization (PDO) team members.
They are also attempting to build a microservices based architecture using containers (Docker - PodMan) and Kubernetes ( GKE- OpenShift) to deploy those applications. They are also migrating off of Jenkins and on to Tekton for CI/CD pipelines. They have always used FOSSA for license validation and SonarQube and other tools and testing platforms. All these changing technologies while trying to incorporate Software Engineering best practices of TDD, Clean Code, SOLID, extreme programming principles puts a strain on the Product Development Organization (PDO) team members.
Formed Developer Experience Team to help the 100+ PDO software dev teams
Change >> Cognitive load >> delay, stagnation, frustration
I was asked to survey a number of the PDO teams and see what DevOps services and tools were needed. In my meetings with the teams, I meet with 25 of the > 100 software teams (4-20 software engineers per team) and discovered that they were just floundering and overwhelmed with the cognitive load caused by the change and the lack of support.
Each team was rediscovering answers to the same issues and questions. There was no central resource to go to for guidance. Example: to migrate my Jenkins CI/CD pipelines to Tekton and change from internal servers running my JAVA/Spring/React application on PCF to containers on a Kubernetes cluster and migrating the SQL Server database to PostgreSQL each team was figuring it out on their own.
There was an internal corporate Agile migration change model that were referred to as Basecamps [ Basecamp 1 to 5 ] and these basecamps had different levels. Basecamp-5 was a fully agile team that used all the agile ceremonies (standups, retros, Story pointing etc) and had many deployments per day and a continuous tested, 12-factor application that was cloud ready.
Each team was rediscovering answers to the same issues and questions. There was no central resource to go to for guidance. Example: to migrate my Jenkins CI/CD pipelines to Tekton and change from internal servers running my JAVA/Spring/React application on PCF to containers on a Kubernetes cluster and migrating the SQL Server database to PostgreSQL each team was figuring it out on their own.
There was an internal corporate Agile migration change model that were referred to as Basecamps [ Basecamp 1 to 5 ] and these basecamps had different levels. Basecamp-5 was a fully agile team that used all the agile ceremonies (standups, retros, Story pointing etc) and had many deployments per day and a continuous tested, 12-factor application that was cloud ready.
Sherpa's or Developer Experience Team (DevX)
I came up with the concept of the Sherpa - they would not climb your mountain but we would help you get up safely and as fast as you could move.
We helped the teams by:
We helped the teams by:
- Piloting & Documenting new technologies
- Scripting or making standard template or libraries in Github repos
- Jenkins shared library - just include it in your pipeline and it works.
- Piloted virtual development environments - containers maintained with the code base to allow a software engineer to deploy a working development environment in minutes - vs. building the environment on their Mac or Windows or Linux machine. This allowed the organization to move resources around and throw experts at a problem quickly plus every member of a team was using the SAME TOOLS reducing the environmental differences causing errrors.
- Pairing with teams to help with migrations or introducing new tech - i.e. IAC or containers
- Metrics reporting for DORA
- Rally and Jira and Jira Align migration and best practices - integration of GitHub