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 1 year ago

Public Feedback

comment Suggest improvements to the Speaker
  • Prasad
    By Prasad  ~  1 year ago
    reply Reply

    Hi Maaret, 

    Thanks for your proposal, can you please complete the structure and learning outcome of your proposal. Also it will be helpful if you can point to a slide pack or one of your previous talk in this theme.

    Cheers

    P

    • Jutta Eckstein
      By Jutta Eckstein  ~  1 year ago
      reply Reply

      Hi Prasad,not sure if you've seen that Maaret is an invited speaker, so Maaret is well known for delivering great talks!
      Thank you,

      Jutta

       

       

  • Deepti Tomar
    By Deepti Tomar  ~  1 year ago
    reply Reply

    Dear Maaret,

    Thank you for submitting the proposal on "Next Level Teamwork: Pairing and Mobbing". Thanks for your time and efforts on the detailed abstract. The Program Committee would require some more information from you to be able to review your proposal for all its aspects. 

    In order to confirm completeness of the proposal, I'd suggest you to go through the following link to Overview of Review Process - https://confengine.com/review-process#selection-criteria

    We'll certainly keep you updated in case we need more information once you have updated your proposal for the required information through the relevant fields and as per the points mentioned in Overview of Review Process.

    Please let us know in case of doubts/queries,

    Thanks,

    Deepti


  • Tobias Anderberg
    Tobias Anderberg
    Developer/Coach
    Agical AB
    schedule 1 year 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!

  • Liked 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.

  • Liked Alex Sloley
    keyboard_arrow_down

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

    Alex Sloley
    Alex Sloley
    Alex Sloley
    schedule 1 year 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.

  • Liked 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.



  • Liked 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.