Teaching TDD: Experiences in Pivoting
Going beyond the classroom to drive TDD impact. While constraints may restrict us to traditional learning approaches (in the beginning), a focus on impact supports pivots that lead to better approaches and outcomes.
I was excited to be taking on a new client challenge, introducing Test Driven Development (TDD) within a large financial institution. The effort focused on a group that drove their digital and innovation efforts (web and mobile). If you’re not familiar with TDD, the idea is that we write a test before writing the code for the solution. We take small steps and grow our tests and the solution code, bit-by-bit. In doing so, we get insights on quality and validation, improved design, and code that is easier to test (and in turn understand, change and maintain). TDD guides practitioners to think about what is being built, why and how. This exploration leads to group discussions driving insights and alignment across the group. And, as a bonus, TDD leads to executable documentation (which stays in synch with the code and helps us understand the ‘why’ behind the code).
My collaborator and lead from the client-side, Sunil, was focused on driving impact in his group. The group was early in a journey to improve how they work. They were primarily waterfall-oriented and finding that they couldn’t move at the pace needed by the business. So, while the journey to Agile and DevOps ways of working would take some time, we could introduce TDD to nudge the group forward. And while the group had about 1000 developers, we would focus on working with 300 developers and 50 managers. Within this group of 350 people, we had cohorts focused on Java, .Net, iOS, Android and relational databases. The foundation built in this effort would support the remaining folks in the group.
As we embarked on this journey, we were well aware of our challenge and constraints (funding and time). We focused on being a team that would collaboratively design a program, execute together and pivot when and where needed. We connected often, planned together and reviewed progress (and outcomes) along the way.
We took a small and simple step as we started. We introduced key senior leaders to TDD — covering details on what it was and why it was important. At a minimum, we knew we’d need support for the initial investment. And, we knew we’d need further support as we introduced a change in how people would work and think.
We focused our first efforts on a classroom-based approach. We introduced two classes: a two-day Java developer class and a half-day manager class. The developer class had solid learning objectives, good discussions, and we spent over half the class time in hands-on labs. We delivered a couple of sessions and took a pause. While feedback from the students was good, they went back to their day-to-day and fell back to old habits. This wasn’t shocking — a couple of days in a classroom cannot overcome a system oriented to legacy thinking and approaches. Old habits are hard to break!
One memorable moment was a debrief that we held at the end of one of the classes. Sunil joined us for a debrief, and we were asking the students questions about what they had learned and what they would take back to work. One student shared her thoughts explaining: “…once we get perfect requirements, we’ll then…” and my heart sank. After a couple of days of great discussions, interactions and practicing — we were still seeing a mindset that was stuck. We had been optimistic that we could light a fuse and get change started. We needed to adapt. As an experiment, the client asked another vendor to deliver a session (using that vendor’s materials) to see if it was the class itself. The result? A different class with different materials didn’t make a difference. So, we re-engaged and continued to discuss ways to further our impact. We wanted to see evidence day-to-day of TDD adoption and application. There should have been more unit tests created, better written code, and more discussions.
Constraints are an amazing ingredient driving innovation. We had a challenge (more impact!) and many constraints (funding, timing, number of people, variety of platforms) and needed to come up with better approaches. We had more Java-focused classes to run as they were the biggest cohort. And, the smaller cohorts of iOS, Android, .Net and DB developers still needed support. As a team, myself, Sue, Lance and Sunil worked through ways in which we could adapt to lessons learned and our constraints. We recognized that this was more than just picking up a new skill. We were running right into culture, mindset and “that’s not how we do things!” We needed to take a more innovative and broader approach (and figure out how to scale). Our solution focused on tactics across: Classroom training, Coaching, Collaboration, Community, Time & patience, and Culture.
Classroom training: We still needed to use some classroom time. We didn’t need to drop it; we needed to augment that experience and think bigger. One small step was creating a video of a training delivery. This video then became available to the rest of the organization — and — an asset that the team could revisit as needed. For the other cohorts, we would need to make further adjustments. We’ll get to those in a little bit.
Coaching Developers: We needed to have a coach onsite to support students as they went back to work. Students needed more support to transition from the classroom back to their day-to-day. The coach supported the team on technical topics and “softer” topics such as dealing with change and uncertainty.
Coaching Coaches: We had constraints. We had one coach, lots of people and a small budget. So, we identified developers within the teams that “got it” and had the potential to be good coaches. And, we coached the apprentice coaches. We built internal support for TDD to drive long term success and self-sufficiency.
Collaboration: This is where things get interesting (and impactful). We injected more collaboration into the approach. We focused on collaboration between coaches, students and managers. We needed to learn together, and we needed to learn by doing. We needed a model for the smaller cohorts that used non-Java skills. Supporting other languages, toolkits and platforms was a big challenge. And, it is difficult to find one coach that can support TDD across all these technologies. We decided that we would adopt this model:
- Have our coach and the apprentice coach co-create a half-day training session for each technology.
- Incorporate Katas (self-paced exercises) to drive further practice. We emailed a problem description to students and asked them to take a TDD approach to create a solution. The exercise was set up to take between 30 and 60 minutes. Once completed, the student would email their solution to the coaches. The coaches would review each solution, provide feedback and highlight the best solution. We gave a coffee shop gift card to the creator of the best solution. It wasn’t a big prize, but it was nice to have some fun and a bit of competition.
- Host a Dojo that followed a round-robin, paired programming model with a small group. The session started with the coach and a student working on creating a solution using TDD. After a bit of time the coach would rotate out and then it would always be two students working together using TDD. We projected the main coding screen to make it possible for everyone to follow along. As they developers were pairing, they talked through the code and thinking as they went.
- Include one-on-ones to provide team members with a chance to ask questions, share challenges and get further support.
Community: We provided guidance and support as a TDD community was established. The community had a website for sharing training materials, videos, and the problems that supported katas and dojos. And, live sessions were set up for sharing experiences (successes, challenges, and approaches).
Time & patience: A two-day class is inadequate for such a challenging change. There needs to be time to reflect, practice, discuss and revisit. And, there needs to be patience from all involved to support the team as they embark on this journey.
Culture: Everything I’ve shared above started us down the path of impacting culture. Further, this was all supported and embraced by the organization. This reflected the importance of new ways of working, thinking and learning. We continued to support leadership in understanding the changes and how they could support the change effort. And, we maintained a focus on metrics and impact.
This was a great experience of learning, adapting and continuing to learn. The partnership we had as a team, our apprentice coaches and our students allowed us to continuously improve and make a difference. And, I like to think that the approach illustrated provided a model to support future changes.
Originally published at https://blogs.ubc.ca on February 17, 2020.
