Monthly Archives: February 2020

Teaching TDD: Experiences in Pivoting

Culture, Scaling

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.

A Story about Learning, Gaming and Winning

Culture, Digital Transformation, Gaming
“When we’re playing a good game – when we’re tackling unnecessary obstacles – we are actively moving ourselves toward the positive end of the emotional spectrum. We are intensely engaged, and this puts us in precisely the right frame of mind and physical condition to generate all kinds of positive emotions and experiences. All of the neurological and physiological systems that underlie happiness – our attention systems, our reward center, our motivation systems, our emotion and memory centres – are fully activated by gameplay.”
 
― Jane McGonigal, Reality Is Broken: Why Games Make Us Better and How They Can Change the World
 
Growing up playing games, I enthusiastically embrace the idea of learning and games. The fun, intensity and gratification that comes from playing a great game (and winning!) beats the heck out of the drudgery of old school learning. Sitting through long, boring lectures is a demotivating and ineffective way to learn. Gaming, could be introduced as a new and improved learning approach. But, we can’t assume that all games are good and will be effective (and in a similar vein, not all classroom experiences are bad).
 
In an earlier attempt at this post, I started down the path of discussing what makes a good game. In that effort I discussed theory, frameworks and concepts. This included looking at Vygotsky, Piaget, Papert, Playcentric game design and “magic circles.” Gaming theory and frameworks are interesting (and fun!), but there can be a long path from theory to impact. So, I pivoted – and we’ll look at the impact that a great gaming experience can have on learning.
 
I like to highlight that ‘being’ digital requires new ways of working and – new ways of learning. But, new doesn’t mean that we throw away the old. We bring forward what makes sense, adjusting it as needed to improve and have a bigger impact. Yes, we need to increase focus on social and informal learning. But, we don’t have to abandon formal learning. To enhance the impact of informal learning, I like to include games. Sometimes, these experiences are short and focused on a specific concept. For example, the coin game is quick and fun while highlighting the importance of batch size and the theory of constraints. Sometimes, the games are much bigger and take most of a day to play. The key is to have good games that are impactful. Doing so can impact culture and help organizations achieve their digital maturity ambitions.
 
With this background, I’d like to tell a story about impact through gaming. The story focuses on playing the G2G3 DevOps Simulation. Here are some details about the simulation:
  • This is an all-day learning experience, featuring 3 rounds of gameplay. There is a scoreboard, there are rules and it’s competitive. We remind attendees to take breaks and step away from the game.
  • Each round of gameplay includes planning, doing, reviewing and some best practices (Theory).
  • 20 people can play the game.
  • Each player gets a role: Business leader, Product Owner, Scrum Master, Developer, QA, Release Engineer, Operations or Service Desk.
  • To win, each role has to collaborate with the other roles.
  • The scoreboard provides everyone with views on their progress, challenges and performance.
  • Each role has a type of puzzle to complete to do their “work”. And, like the real-world, there’s a need to collaborate to be able to succeed.
  • There are two main types of work: new development that the business requests and incidents that come in via the Service Desk.
  • As work moves through the “pipeline”, one of the facilitators is bridging the digital and physical worlds. Paper cards flow through a “pipeline” and the facilitator confirms the work. The facilitator also gets to play the role of “chaos monkey”, so to speak, and gets to break servers – leading to service incidents.
  • Work from the business arrives via the Business and Product Owner roles.
With this background in place, I’d like to share one of my favorite stories about this valuable experience. My team was facilitating the simulation at a well-known, global technology company in San Jose. We had a group of senior managers and directors participating. They were in the early days of their division’s digital transformation. This company lives and breathes technology every day. But, they still found that they needed to improve and adopt new ways of working (…and learning, thinking and leading…). The agenda for the day included a two-hour overview session followed by the simulation. In total, we had a very full, 8 hour day planned.
 
I led the overview session. This goal for this session was to drive alignment on Agile, DevOps and ‘connect the dots’. The session included lecture, Q&A/discussion prompts, and a video session with their boss. The video session reinforced the importance of these efforts and highlighted the support for our day. It was during this session that I first met “Simon”. Simon sat in the middle of the room and he caught my eye. He was paying attention, rather intently, but he also had his arms crossed and was leaning back – and was radiating doubt. In introduced the benefits of DevOps: improved collaboration, better quality, and enhanced customer alignment. And, that’s when Simon jumped in: “So what – we’ve seen and heard this before! Each new approach that shows up offers the same thing. Bigger. Better. Cheaper. Faster. Why should this time be any different?” At that point, I felt the spotlight turn to me, get more intense and the focus of the room follow along. How to answer? How could I convert Simon? And, how could I avoid losing the group?
 
Pausing for a moment, I realized that I couldn’t convert him with words. I shared some thoughts and stories – but I could see the disbelief radiating from Simon. There was a bit more dialog with others in the group joining in, but we weren’t making much progress. Simon wanted proof he could touch, see and experience.
 
We completed the overview section and moved on to the simulation. We put Simon into the Scrum Master role. The intent of the assignment was to give him direct insight into how work was flowing and engage him with both business and technology roles. He was going to get his proof!
 
Round 1 of the simulation is chaotic as participants only have a little bit of time to prepare for gameplay. Simon worked hard in Round 1 and in the debrief shared his views on the results, challenges and how everyone worked together. After everyone debriefed, we discussed ways to tackle identified challenges. We provided guidance on techniques and ways of working. We empowered the group to be the driver for continuous improvement. The team had to take their experience and the practices we provided to come up with better ways of working. We repeated this pattern at the end of Rounds 2 and 3. However, for Round 3 the goal was to carry forward lessons learned into their day-to-day work. I won’t go into details of the techniques, approaches and thoughts shared (I don’t want spoil the sim for you) – but I will highlight that we made an impact. Throughout the day, Simon changed. His demeanor went from doubtful, frigid and a bit antagonistic to warm, smiling and passionate. Why? He was able to get his proof. He experienced the changes that happen as we take on new and better ways of collaborating. He felt empowered as he and his colleagues made their system work better. Data and debriefs along the way showed them bottlenecks and highlighted issues. And, new ideas on practices fed into experiments that led to solutions. For me, this was a huge win. In traditional training and coaching situations, I don’t see such a transition in one day.
 
The simulation wasn’t the end of their journey. People don’t leave as DevOps experts. But, the sim sets the stage for pulling more learning, for igniting pursuit of improvement and culture change.
 
I’ve had the chance to run the sim at some other companies and would like to share from those experiences. In one sim, my then client and now friend Keith Buehlman was a participant. Keith was the leader of the organization’s transformation. I asked him to reflect on the experience and he shared the following:
“One of the best parts of the DevOps simulation was the opportunity to go through realistic scenarios and, in the process, refine skills and learn best practices that can be used immediately. The DevOps simulation was an important piece of the overall transformation strategy as it comes to understanding the culture that was needed to really operate in an agile fashion. It truly supplemented the hands-on training and day-to-day coaching of the employees.”
I especially like the reference at the end of his thoughts. The simulation is not a one-off, silver bullet that solves all transformation challenges. But it’s a piece of the puzzle that also includes other training and coaching. And – as much as this is about skills and practices, it reinforces the cultural changes needed.
 
Other participants have highlighted that they found it motivating to see the connection between their work and impact. For others, they walked away understanding T-shaped skillsets. One participant shared his surprise that people would cheer for improvements in MTTR. And, as we put participants in roles different from their day-to-day; they come away with a new appreciation for their teammates. Empathy for others can go a long way to making the workplace more hospitable and receptive to change.
 
Through game play we have an exceptional day of learning. The energy is high, passion is evident and the time flies by. And, we create ripples in the organization that support us in driving a bigger change. In wrapping up, here’s a great quote from Ralph Koster that speaks further to the power of gaming and learning:
“Fun from games arises out of mastery. It arises out of comprehension. It is the act of solving puzzles that makes games fun. In other words, with games, learning is the drug.”
I hope this story sparks interest in adding games into your formal learning events. If you’re already using games, which ones are you using? What impact are these games having? Are you creating any new games that are specific to your organization?

Distributed Teams and Learning

Culture, Scaling, Teams

Working in distributed teams with members dispersed in multiple locations is a common reality for many of us. It presents some extra challenges as we try to improve how we work and learn. If we’re going to succeed in scaling learning (number of people and frequency) we’re going to need to succeed in engaging everyone – regardless of location.

Here are a few tips I’d like to share based on experience. First let’s look at how we can leverage technology to help:

  • Use video as much as you can. Seeing a smile, a look of confusion or a twinkle in the eye as someone teases can overcome misunderstandings, keep everyone in the loop and make the team feel closer. And, by seeing everyone, we can also better gauge openings in the conversation – or even create one with raising our hands (or other gestures!).
    • What if some of the team is together and just some team members are remote? I’ve found it helpful to ask the co-located team members to congregate together. In doing so, we use a single audio channel for the co-located team – and – have each person use their laptop/device to capture their video. This keeps the video set up simple – and everyone can see everyone. I’ve been using this approach recently in some of my projects. And it’s been a great way to see everyone and be seen by everyone.
  • Consider using tools such as Sococo as a way to provide some structure to a virtual world that everyone can co-inhabit. The Sococo floorplan metaphor makes it easy to understand spatial mapping between the group members, without getting bogged down with unnecessary details (or dimensions). Here’s a couple of ways to use it:
    • Use a floorplan for day-to-day interaction. Have team rooms, break-out rooms and even some spaces set aside for one-on-ones. Encourage the team to stay connected throughout the day, occupying the space that reflects their work focus. If they need some private or small group time, use a break-out room and close the door (Note: that if someone wants to talk to a person behind a door, they knock to make the request). If you’re wanting to chat, hangout in a social area.
    • Mini-conferences: Set up some time focused on sharing interests, results, problems and failures. And much like a real-world conference, set up your floorplan to have a main hall for major topics and then break-out areas for specialized topics and smaller audiences. Be mindful of the space and consider using techniques to engage the audience as it fits the context.
      • We used this approach with one of my consulting teams. It led to a great afternoon of sharing, interacting and feeling closer than we did in just using traditional web presentation tools. Also, we all enjoyed having a choice of sessions running in parallel and being able to easily navigate our conference hall (virtual as it was!).
    • Record your meetings / presentations. This is a benefit to having a distributed team. Analog meetings are a thing of the past. As you’re all in the digital space, take advantage of the capability to record the session. This makes it easier to come back to the discussion later or include those that couldn’t make it as scheduled.
      • Tools such as Otter.ai look intriguing as an option for taking digital audio and getting notes created. I haven’t had a chance to try it yet – but am looking forward to experimenting and adding it to my selection of tools.
    • They are many other interesting digital tools that can help with sharing, collaborating and researching:
      • Consider how you can leverage chat, video and podcasts as ways to share personal experiences, questions and lessons learned. A short video or podcast is a great way to share knowledge with the team.
        • I’ve used Flipgrid to engage a group via video in traditional learning settings. It might not be the best fit for a single team, but if you’re following a model that includes pods and guilds, this could be a great way to scale and cover distances.
        • And your phone typically has capabilities (or can be augmented with a simple app or two) to create short podcasts or videos.
      • And, seek out tools that support collaborative editing and creation.
        • Google Docs is great for writing together.
        • Tools such as Mural and Miro provide great team workspaces.
        • Tools such as hypothes.is are intriguing ways to collaborate with your team as you access articles, papers or even documentation. Annotating the web can provide a great way to asynchronously learn together.
    • Take care of the basics. Make sure that you have good audio and video capabilities. Using mute to keep out background noise when appropriate.

And that concludes the easy part. The bigger challenge is the people side. We need to be willing to try new tools, connect, collaborate and learn in new ways, be patient, be vulnerable, and be generous. This is a long list of asks and changes. Be mindful of the amount of change being introduced, prioritize and take time to learn and adopt. Here are a few more people-oriented considerations:

  • Don’t forget the Team competencies that I discussed in Teams FTW. A good team is a good team – regardless of distance and dispersion.
  • Have a good facilitator that actively keeps sessions on track and keeps everyone involved. The facilitator should be mindful of participants that like to think out loud and those that like to think and share after they’ve heard others talk. We need to hear all voices.
  • Make sure that you’re setting up clear working agreements. For example, as a distributed team, you’ll need to be mindful of time zones. Set up core working hours that overlap in availability as much as possible.
  • Leverage retrospectives to identify ways to improve, and follow-through on improvement plans. Continuous improvement is a key ingredient of new ways of working.
  • And last, but not least, there will be many opportunities to learn from failure. There will be connection issues, audio issues, timing issues and likely some background noise. Learn from the failures and keep finding ways to leverage the learnings.

These tips all come together to help the team operate, work and learn. And while technology helps, this is still a people challenge. We need a mindset where we embrace the ability to connect, share and learn as a team. Together, we create a space where learning is supported in our activities throughout the day, when we socialize and even with more formal activities.

What are your favorite tips for working and learning in distributed teams? What do you find most challenging when working as part of a remote team?