At work have you ever been challenged to learn a new programming language, cloud platform or whole new skillset? It’s not uncommon in the tech industry to be “asked” to do this and if you are lucky enough you may be given the time to get it done right. Unfortunately it is also not uncommon for us to be tasked with learning a whole new skillset… yesterday! Here at Industrial Logic we are familiar with both faces of these challenges. As much as we’d like to say we always have plenty of time, most of the time we really don’t.

Recently we had an opportunity to take a group of experienced player-coaches who had never worked together before and tackle learning iOS development in Swift. We discovered many things along our brief three-week journey.

How we formed as a team

“You can’t have a high performing team until you have a team.” - Ashley Johnson

Our first challenge was to decide how we would work together. Industrial Logic is known for its Extreme Programming (XP) technical player-coaches that strongly believe in code as craft. These crafters share some common values and beliefs. We all have strong technical abilities but are also unique individuals with different strengths and specializations. It’s much like taking four professional race car drivers that specialize in different types of racing (F1, NASCAR, Dirt Track, Monster Truck, and Motocross) and having them drive the Paris-to-Dakar Rally.

Working Agreements

One of the key aspects of teaming is how the team collaborates. In order to collaborate effectively teams often form Working Agreements, which we never explicitly did. In retrospect, many of our working agreements formed organically based on common shared beliefs and values as crafters. We never asked the question “How are we going to work?”, it just happened.

Some of the key aspects of how we worked.

Items we didn’t have to discuss given our shared background and values:

• Ensemble Programming
• Source Control
• Test Driven Development
• Regular reflection points / retrospectives
• Micro commits
• Frequent Breaks
• Using cameras
• No apologies
• Whomever is present is who needs to be present
• Flexibility to change the process

Items that required discussion:

• Working Hours or Work Rhythm - Eastern Time Zone vs. Pacific Time Zone, when to start and do lunch, meetings, etc.
• iOS development challenges (some had macs, some didn’t…)

Items we knew were core to our success but had to play with to discover what worked well for us:

• Some way to “share the keyboard” - Code With Me vs. mob.sh,
• tracking who’s talking/driving/next - List of names in Mural vs. verbal “role call”

Shared Purpose

Another aspect of forming effective teams is to have a shared goal or purpose. Our goal was to “skill up” and prepare for a future engagement in a space where we had little prior experience.

Safety and Trust

The final aspect of our forming that turned us into a high performing team was trust. As fellow crafters, everyone at Industrial Logic takes the default position of assuming good intent and egoless development. With that viewpoint we were safe to experiment and self-organize. We were autonomous in our ability to try new tools and techniques. Being unburdened from needing to ask permission, our daily work had the freedom to adapt and learn more effectively. We had the safety to take risks and do what we needed to do.

We were able to form as a team very quickly because of our common beliefs, values and being crafters. There were times where we would storm and re-form. That’s very common on all teams, especially new teams. We were enlightened enough to observe struggles, safe enough to talk about them, and empowered to experiment and overcome those obstacles. Shared beliefs/values among code crafters allows for an incredibly fast ramp-up of self-organizing teams. Given a common goal and a team of crafters, acceleration from no code to deployed walking skeleton is unbelievably fast.

How we learned as a team

“All the brilliant minds working [learning] together, on the same thing, at the same time, at the same computer” - Woody Zuill

If we were tasked to do this as an individual there are some common approaches that we could take such as reading a book, watching videos, or diving in and creating a hands-on tech spike. However, how do we know, as an individual, that we are learning the right thing? When in doubt, we may ask the team for feedback. Later, once we’ve finished our research, we would report back to the team what we learned. This report back may trigger new questions or new areas to research. As you can see, this is adding multiple levels of asynchronicity to our system. The asynchronous nature of this work inherently creates queues. By gathering people to collaborate and work together we can eliminate those queues and thus reduce delays in the system. One such approach that enables the team to do this is ensemble programming.

An ensemble creates continuing forward momentum in the unknown. It allows a group of people to easily experiment, practice and learn in a fun environment.

There are many other alternatives to learning as a group that we’ve seen in the wild:

• Attending external workshops as a team
• KT Sessions (lunch and learns)
• Going through the same online course separately
• Book/Article Clubs

For the reasons above, we decided to learn iOS app development as an ensemble. We experienced three main benefits learning this way:

• Shared Knowledge
• Rapid Feedback
• Diversity of Experience

Shared Knowledge

When working as an ensemble, an individual’s knowledge becomes common knowledge. Learning iOS development in an ensemble accelerated our learning, enabling us to move together as a group building on our collective prior knowledge one concept at a time.

In addition to accelerated learning, working as an ensemble created a shared experience. This common experience had a few significant impacts:

• A deeper understanding of the subject through conversations. When any of us questioned our understanding we were able to dig in immediately to teach and learn from each other, improving the group’s understanding.
• An ability to refer back to this experience as we were continuing down the path. If one member of the group had forgotten something it was easy to trigger their memory by saying “remember when X happened”

Our experience has been supported by academic research. In a study published by Rowan University in 2004, researchers found that test scores improved by 15% when classrooms learned as a group rather than as individuals.¹

Rapid Feedback

An ensemble receives and provides rapid feedback in both the direction and value of their efforts at any given time. There is a natural bi-directional feedback loop with any ensemble for all members at all times. When two members have different ideas for how to solve a problem, the ensemble can try both solutions and then can have a brief conversation about which solution they prefer and commit to one.

During one session, our ensemble was banging their heads trying to refactor to a convenience constructor on our ViewController. One member noticed that the group was spinning their wheels and said “Are we still learning?”. Hearing that question sparked insight for the whole team. The group looked up and refocused. The team got back on track to explore the iOS development concept they wanted to learn that day.

Diversity of Experience

Llewellyn Falco described a great insight he had about pair programming. He describes the true value of pair programming not in the common experience but in the different experiences that the members bring to the table. As with most benefits of pair programming, this benefit is also greatly amplified by working in an ensemble. Each member of the ensemble brings different backgrounds, experiences and understandings.

As we applied the ensemble approach to learning we found that there was rarely a topic that at least one of us didn’t have some familiarity with. We had either worked with a pattern in the past, had experience with a similar tool or had read about an idea somewhere. This gave us each an opportunity to share back our individual experience and accelerate the rest of the team’s learning, while also deepening our own understanding of the topic.

As we were Test-Driving our solution, one member had a realization and a growing concern over tight coupling. Our business logic was being tested through our View components. They suggested that our tests should only be validating that our state is bound to the View. Having had experience with using the Model View ViewModel (MVVM) pattern, that member immediately began teaching the ensemble about this topic and we started to navigate our way to refactoring out of this code smell.

While we were using practices and techniques that we had all used in the past, we began to realize that the context we were applying them to was new. We came to call this approach Ensemble Learning.

What is Ensemble Learning?

Ensemble Learning is applying the techniques of Ensemble Programming with the ultimate goal of exploring and gaining proficiency in a new domain as a team.

Ensemble Learning brings the benefits of shared knowledge, rapid feedback and diversity of experience.

Requirements for Ensemble Learning:

• A clear learning goal.
  • In our case, we wanted to gain enough proficiency in iOS development to be able to coach an iOS team around XP practices.
• Effective regular feedback
  • We held short (10-15 minute) retrospectives daily, reviewing our learnings for the day and establishing a rough plan for the following day.
• Safety to operate as an ensemble.
  • This requires mutual trust, understanding, and openness in order to create a sufficient level of safety to be effective.

Additionally, it can be very beneficial to have access to an expert in the domain. In our case we met daily with Jon Reid, a fellow IL’er who is an expert in iOS app development (you should read his book). This was very useful in helping to direct our learning and build our confidence that our learning was continuing to move in the right direction.

Using the Ensemble Learning approach we achieved incredible results in only three weeks. We were able to take 5 crafters who had never before worked together and form a truly high performing team. We gained enough proficiency in a set of technologies which we had little to no experience with that we felt comfortable diving into a legacy iOS app to refactor and get it under test. Finally, and perhaps most importantly, we had a lot of fun while we were doing it.

If you try Ensemble Learning in the future or have stumbled upon this method of learning previously, please let us know. We would love to hear your story!

Notes

1. Grimm, Devonn, “Individual learning versus group learning in a suburban second-grade classroom” (2004). Theses and Dissertations. 1156. ↩