Next Level Teamwork: Pairing and Mobbing

I know something you don’t know. You know something I don’t know. And I don’t know what you know that I would need to know. This is where individual contributor approach to software development and testing breaks down. Why aren’t we working together, contributing together and learning together? Why do we, often at best, collaborate on the requirements and understanding of what to build, and then step away for implementation, only to come back to test it after?

This talk looks into my experiences in pairing (two people one computer) and mobbing (more than two people one computer), and the wonders of being a non-programming tester whose ideas get translated into code as equal. The journey to get to pairing and mobbing has been a rocky road, with loads of practical tips to offer on how to approach it.

In software development, those who learn the fastest do best. Could pairing and mobbing take us teamwork to the next level by enabling learning between everyone? Lessons specific to skillsets rub in both ways, leaving everyone better off after the experience.



 
 

Outline/Structure of the Case Study

-

Learning Outcome

-

Target Audience

all roles

schedule Submitted 2 years ago

Public Feedback


    • Tobias Anderberg
      Tobias Anderberg
      Developer/Coach
      Agical AB
      schedule 2 years ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      Ever wondered why some people prefer to work alone? Or why some people cringe when pair programming is mentioned? It might be that that person, like me, is an introvert. But is is really that simple? Can we really put every person in a box labeled "introvert" or "extrovert" or are we all just ambiverts?

      During this session I will talk about introverts, extroverts and everything in between.
      Drawing from almost 15 years of personal experience being an introvert on agile teams I will talk about the differences of being an extrovert
      or an introvert, how to foster an inclusive team environment, and the importance of psychological safety.
      You will hopefully leave this session better fit to help EVERYONE on your team to reach their full potential!

    • Jutta Eckstein
      keyboard_arrow_down

      Jutta Eckstein - CD – Continuous Delivery and Cultural Difference

      20 Mins
      Talk
      Intermediate

      DevOps and continuous delivery is typically elaborated technically - what kind of tools, technologies, or skills are necessary for being able to deliver continuously. Often it is forgotten that continuous delivery requires also a culture change - in development, operations, marketing, sales, and not least for the customer.

      This can be recognized for example, that although it is technically possible for a team to deliver continuously, but it seems that this delivery isn't welcomed. This means the actual system will not be directly used.

      Therefore, in this session by taking into account the necessary cultural change, I want to answer the question how to implement continuous delivery successfully and what kind of pitfalls you need to be aware of when doing so.

    • Alex Sloley
      keyboard_arrow_down

      Alex Sloley - The End is Nigh! Signs of Transformation Apocalypse

      Alex Sloley
      Alex Sloley
      Alex Sloley
      schedule 2 years ago
      Sold Out!
      45 Mins
      Talk
      Advanced

      How can an Agile Coach figure out when an Agile “Transformation” is going wrong? Are there signs that they might see, heed, and take action upon? Of course, there are!

      Hindsight is 20/20, but in the moment, these warning signs can be hard to see. Let’s explore some of the more common, and frightening, warning signs that your Agile “Transformation” might be exhibiting. We will discuss transformation provider types, frameworks, keywords, and other anti-patterns that might be signs that THE END IS NIGH.

      This session will review common themes and help familiarize you with the warning signs. Armed with this new knowledge, you will be able to plan as appropriate, to help navigate your organization through potential impending doom.

    • Maaret Pyhajarvi
      keyboard_arrow_down

      Maaret Pyhajarvi - Working without a Product Owner

      45 Mins
      Case Study
      Intermediate

      For a decade of software product agile, we had worked in a structure where business responsibility of what to build was allocated to a product owner and the responsibility of how to build it was allocated to a development team. Product owner would maintain a backlog, act as voice of the customers. Until one day we realized that the choice of what to build or fix is hard, and critical to everyone’s success. If we wanted to do it poorly, we delegated it to a single product owner.

      We started a no product owner experiment. For three months, we experienced the development team delivering multitudes of value to what we had grown to expect, and innovate customer-oriented solutions in direct collaboration with customers. Team satisfaction and happiness bloomed. The experiment turned into a continuous way of working.

      Customer-focused team directly in touch with their customers performs better without a proxy. Join me to learn how the decision power shared for everyone in the team transformed the ability to deliver, and how collaboration is organized with product experts and business representatives.



    • Maaret Pyhajarvi
      keyboard_arrow_down

      Maaret Pyhajarvi - Practices Change - Moving to Delivering Continuously

      45 Mins
      Case Study
      Intermediate

      Delivering continuously - easier said than done. As I joined my team delivering Windows Desktop products two years ago with the aspiration of implementing continuous delivery, I was told it cannot be done. It started from the fact that making a single release was five-day effort, and continued with “no user would allow us to deliver frequently”.

      Two years later, making a release takes us two hours and the way we work together looks very different. With the principle of fixing maintenance issues in the latest release has resulted in improved flow forward and savings of effort in supporting small number of releases.

      This talk goes through our lessons learned on the journey of shortening release cycles to a continuous daily flow.

      We’ve experienced three essentially different sets of practices, with the core difference coming from release frequency. The good place is when we deliver continuously. The soulsucking place is when we deliver on two week cadence. And the insane asylum is when we deliver just once at the end of the project.

      Think of it like this: a pool is not just a bigger bathtub. The things you can do in a pool are different to those you can do in a bathtub. While both are containers of water, they serve different purposes. It is the same with release frequency. While it is all still releases, the continuous ones enable different practices.