Team Collaboration Experience Report

Team Collaboration Experience Report

I was recently asked to be a manager for a new team in a different geo. They are going to be working on the same product as another team I work with. I asked the team to provide a tech stack overview (high level) and an experience report on collaboration.

This team is the most collaborative team I have ever worked with. There have been some bumps along the way. They have oscillated between collaborating and splitting apart, but they always come back to collaboration. I wanted them to share their experience as a way to help the new team start their own journey towards collaboration and team cohesion.

I found their experience report to be valuable inputs, so I asked if I could share on social media. They agreed.

So without further comment or editing, here is what they presented to the new team:

Collaboration Experience Report

Pros:

  • Closer connection to the team and team building.
  • Team building of laughing and joking with each other.
  • Quickly learn new techniques and solutions from others.
  • We all have different experiences and skills and can remove roadblocks faster.
  •  Helps us improve our solution and have a better end result.
  • Enables us to move faster on tasks.
  • We learn something new every day.
  • Having someone watching you validates your sanity and keeps you focused on a specific task.
  • Enables us to confidently work in critical production services as a group reducing the fear of breaking something due to an individuals mistake.

Cons:

  • Can be uncomfortable for the person who is driving if they aren't as familiar with the area.
  • Fear of looking dumb in front of your peers.
  • We need to create an environment where we are comfortable working with each other and not afraid to ask questions.
  • Can make it difficult to take short family related breaks or family disruptions.
  • At times its easier to work on things individually:
  • When working in areas that "nobody" knows well.
  • On bigger coding tasks that require more trial / error than direct coding.
  • Can focus better with headphones and in own headspace.

Considerations:

  • Collaborating remotely seems to work better than the in-office collaboration.
  • It enables people to mute and take care of things without disrupting work.
  • Ensure that the driver is rotated and not stuck driving for hours straight.
  • This really only works if the team is all working in the same area.
  • Can be difficult if everyone is working on various tasks unrelated to each other.
  • Collaboration times should be by invitation and not an expectation or requirement.
  • Regular retrospectives to discuss the good and bad on the way we are working.

Examples:

The following has been edited slightly to avoid specifics

  • The last outage was caused by an issue that was in an area that nobody had experience in. Our team attended multiple collaborative sessions which enabled us to all contribute and identify the root cause. Not one person was responsible for the solution. It was a team effort.
  • We had a story to add rpm's to a new repository. One engineer got stuck in an area and we were all able to get on a call and through all of our collaboration we were able to solve the problem in a short period of time.
  • This experience report is a manifestation of our team collaborating to brainstorm ideas.
  • At any point, when we any of us get stuck, we don't try to handle it ourselves, we reach out and all get on a call.
  • https://wheelofnames.com/ is a fun tool for deciding who should drive next or start a conversation.

This is beautiful Don! What a great team to have the courage to go for this type of working together and keep reflecting and learning as they go. You’ve also obviously built a safe environment for them and in fact they’ve now built a safe environment for each other. Wonderful!

This is really cool, Don. It took me a minute to figure out you're mobbing. If you're interested, I'd love to share some stuff with you that might be helpful on "not being afraid of ...".

To view or add a comment, sign in

More articles by Don Eitel

  • 3 Things to Try to Boost Team Productivity

    I'm sure we've all seen it. The team is spinning their wheels.

    9 Comments
  • A Paradigm for Modern Management

    This is by no means exhaustive, but I believe it will guide managers and leaders on the right path towards a focused…

    6 Comments
  • Promising Customers the World (and disappointing every one of them)

    I'm sure many of you are familiar with this scenario. Sales wants to know what the new shiny is going to be.

  • The Dysfunction of Goals

    My organization's HR department recently initiated a top down requirement that 100% of employees create and manage to…

    11 Comments
  • Mob Programming - An Experiment

    What is Mob Programming? Mob Programming is a practice where the whole team works on the same item of work. All heads…

    1 Comment
  • Agile Thought and Influences - A Timeline

    The following was an exercise to get a clear understanding of the history of ideas within agile. This is by no means…

    5 Comments
  • Frameworks and Fixed Mindsets

    "Hmmm..

  • Making Processes Explicit in Scrum

    I work in a scrum context, but I like to include elements of Kanban, lean, and systems thinking into my work. One of…

  • Planning Debt and Sunk Cost Fallacy

    The agile manifesto has a very clear view regarding plans. It's mentioned in one of the four statements: Responding to…

  • Teal, Scaling Agile, and Systems Thinking

    An article from Ash Sheikh and the twitter post below got me thinking about agility, teal, and scaling an organization.…

    10 Comments

Others also viewed

Explore content categories