Leveling Up Together - Synchronizing Mixed Experience Teams
As engineering leaders, we constantly face the challenge of exciting our teams to share their experiences with each other in a way that encourages mutual growth. It requires dedication, discipline, and, most important of all, communication. Fostering and encouraging constant communication and dialogue among team members is not always easy, and finding ways to do so can make this process a lot more difficult than most people would suspect.
“小打も積もれば大木を倒す” Little strokes fell great oaks. - Japanese proverb.
Enter the Dojo
Teams often come to Target’s immersive learning environment, the Dojo, seeking help for a variety of reasons. Some teams are looking to prototype a product, learn Agile, or implement DevOps best practices. Others are brand-new teams, brought together to solve a business need. One recent team is an excellent example of the latter. A group of skilled individuals coming from the area of stores hosting, brought together to solve a problem: managing control room inventory quickly and accurately via a web application powered by an API. This application would be built from the ground up and deployed via Target’s CI/CD pipeline. While the team had experience in scripting and database queries, both RESTful concepts and CI/CD were new to many of the team members, so a significant time investment would be required to get everyone on board.
This engagement in the Dojo would mark the first time these individuals would be working together as a team, which made it important to build trust as a first step. In the Dojo, we have discovered that in software development teams, trust and attitude can often trump pure aptitude in predicting success.
The first step was to establish a core foundation of technical knowledge. In the mornings, the team would participate in lectures and experience concept introductions through a classroom style approach, followed in the afternoons by workshops and hands-on activities that were designed to reinforce the concepts taught earlier in the day. This approach helped nudge the team forward and created an environment that encouraged collaboration. The activities themselves took several forms – including case studies on topics like source control, basic Python scripting, and consuming RESTful services – and all were designed to be completed as a team. Only after a few days of collaboration via hands-on activities could the true productivity of the team be unleashed through “mob programming”.
Mobbing Mind Meld
Mob programming is a software development approach in which a team works on a deliverable simultaneously via one monitor, one computer, and one keyboard. Each team member will take a turn at the keyboard as the “driver” for several minutes and then switch, with the cadence determined via timer. Those not at the keyboard are also active participants in development, helping the driver solve technical hurdles, look up solutions, explain concepts, and more. Mobbing is a full team activity – it is not a group of people sitting in silence watching each other write code on-screen.
The importance of adherence to the timer is paramount, as unregulated mobbing can often turn into teams “fighting over the keyboard”, or those not actively typing at the keyboard “tuning out” or switching context. We mitigate these issues in the Dojo through repeated encouragement of participation among all team members, and utilizing Mobster . Mobster is an open-source tool that enforces turn order for all participants and will display a message when it’s time to switch, helping to enforce the rotation and allowing everyone to keep their focus where it belongs: on creating software as a team.
The benefits of mob programming for this team were immense. Mobbing enabled each team member to share their knowledge with the group. Also, its introduction increased the cadence at which team members generated ideas while writing, refactoring, and testing code. Productive conversations often occurred organically throughout each mobbing session.
In today’s business environment, the demand for a team to have business agility and the dexterity to deploy software rapidly is crucial in order to stay relevant. With such high demand for software changes & updates, test automation as part of a CI/CD pipeline is essential. The stores hosting team solved this problem through spec-driven development when crafting their API. In other words, the specification for the API, defined via Swagger, was completed before any code was written. This approach was extremely useful for the team, as it allowed them the breathing room to understand each endpoint’s design in detail. Combined with open source Python testing library pytest - which solved some compatibility issues introduced by Swagger – the team was able to build a robust library of unit and integration tests in parallel to developing API endpoints.
Pytest allowed this team to build a robust library of tests and integrate them into their CI/CD pipeline in Drone. Any new code that was checked into master branch would trigger a job in Drone that would build the application, deploy it to a Docker container, and run the test suite without manual intervention. Introducing testing and CI/CD practices to this team provided them the confidence to experiment at will, with confidence that the test infrastructure would be there to catch common errors introduced throughout the development process.
The stores hosting team took to mobbing quickly and the rapport developed during exercises became paramount. The team began to operate with a “hive mind” of sorts, with each member switching off in rotation without missing a beat. Thoughts and intentions were communicated effectively and persisted across each hand-off of keyboard control. Mobbing allowed the team to fail together, learn together, and correct mistakes together. Over the course of a few weeks, the team tackled API development via Flask, CI/CD, Python, TDD via Pytest, automation, and secret management.
The minimum viable product delivered by stores hosting exceeded expectations, and the new team gained plenty of confidence in software engineering concepts and – more importantly – in each other.