Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Improving Teamwork Through Experiments

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

A good way to improve how a team works together is to try to run experiments for collaboration. We’ve listed here a set of experiments you may want to try, depending on where your team is in the journey for better teamwork. Each section has a description, a goal for improvement, and then a set of experiments that may help achieve the goal.

Teamwork Phase: Only-Recently-Moved-From-Waterfall

Description

This team was just formed – after all, in Waterfall projects developers and testers will usually be in separate teams, not to say separate organizations, with a history full of bad blood caused by fierce and desperate battles over defects, whether it is a defect or requirement, who’s to blame for the problem in the environment and more.

At this phase, the organization probably did not change sitting arrangements so they still sit in separate floors and when they meet for planning, each group huddles together in one corner of the room.

The newly proclaimed scrum master was probably the team leader of some of the team members, and she is used to telling everyone what to do. If she came from development,she will tell the developers what to do and assume testers will just “do their stuff”.

The daily meeting is a burden and everyone reports status to the scrum master who is the main bottleneck of the team – everything goes through her.

When you look at their storyboard you see a column for development and a column for testing. Testers keep opening defects as usual in the defect management tool.

Most of the time development will end a couple of days before the end of the iteration in the good case, and one or two days after its end in the worse case. Developers will tell you they were done on time, by the way.

Goal for Improvement

The main challenge for the team is to have a joint goal for all team members working on a specific scope item. We would like the developers to internalize that it is not done until testing is done and for testers to understand that they open defects not to prove something for developers but rather to point out the places that need attention.

Suggested Experiments

Joint Demo Responsibility – In some teams, it is customary that the testers run the demo (after all, they are the ones running the system). In this experiment, we ask a developer to work with the tester on the demo. The immediate response would be the developer asking “but what should I do” and the immediate response should be “not sure, just be there by her side. Maybe you could offer help”. We don’t need to know everything, we want to see what happens.

Breaking Down Stories – To avoid situations where nothing actually works at the end of the sprint, they should try and break stories into smaller pieces. This should be led by the product owner and done through collaborating with the entire team. The team should set a goal for having something working before the last week of the iteration and later even before that.

Teamwork Phase: Task-Oriented

Description

After some time working in the “only-recently-moved-from-Waterfall” mode, some managers feel concerned and the agile coach is also making some noises, and they (together with the team) decide to replace the “development” and “testing” columns of their storyboard with a “doing” column. Everyone agrees to have a common goal of completing the story.

During planning, they define tasks for the story. There are development tasks and there are testing tasks. It doesn’t take them long to find a view in the tool that shows a board of the tasks with swim lane per story.

As people start talking with each other, the scrum master is becoming less dominant and people actually come up with ideas. The stand-up meeting is starting to move away from the status report format, and during planning, people think together.

This transition does not happen in a day. It requires persistence and encouragement but it is well worth it.

Goal for Improvement

The ambition here is a team that works together. This is beyond consulting with each other or reviewing each other’s work – it is actually about doing something together.

Suggested Experiments

Tests Brainstorming – This experiment is about having a brainstorming session for defining tests before development begins. Both developers and testers are suspicious of this at the beginning – they are used to having a test review where developers can show testers they don’t understand anything and testers can show developers they don’t know anything beyond the current class they are developing. The challenge is to have the first session where they think together of what is the scope of tests for the story. The first session will usually not be the last, for this has great value.

Testers not opening defects in the ALM system – The defects repository is a great example of the opposite of “people and interactions over processes and tools”. Testers open a defect and then someone looks at it. In this experiment, we ask testers that instead of documenting a new defect they reach out to the relevant developer (if they don’t know who she is, let them ask) and discuss the defect directly. In case a defect is not resolved on the spot, it may be required to create the defect in the system.

Developers sitting next to testers – A good way to allow people to understand each other is to let them see what the other guy is actually doing. A developer sitting next to a tester for 30 minutes or one hour (or even more) is an eye-opening experience. The developer will start to understand the viewpoint of the tester. I remember when I moved from development to managing a testing team I was astounded by the things I found out. In addition to understanding the tester’s viewpoint, the developer could accelerate testing by providing first-rate support to the tester.

Testers sitting next to developers – Once the code starts to stabilize and the developers beings running their initial tests, having a tester around is a blessing. Since the tester is not concerned with technical stuff (not at this stage), she can help the developer see what’s going on at the system level. This is similar to pair programming.

Testing in parallel to development – This experiment is for trying and having testers test the code before the developers are done. This will evoke a sad, yet understanding, look from developers to whoever proposed this unthinkable utterance. Here, like in the other tests, persistence is key and the word “experiment” is the right approach. Together the team looks for an opportunity to try this endeavor.

Story-Oriented Stand-up Meeting – The purpose here is to start going out of task-oriented work toward story-oriented work. Usually, the basic way that stand-up meetings take place is that every team member tells what she did yesterday and her plans for today. Instead of doing it this way the team will go over stories in the “Doing” phase and talk about them (If the scrum master is leading, she will say “let’s talk about story X” and wait for someone to start. Yes, sometimes there’s an embarrassing silence to cross).

***NEW*** Story-Oriented Planning – The purpose here is to move the team to be oriented to stories, starting already at the planning phase. During planning meetings, after everyone understands the scope of a story ask who is interested in developing it (developing includes testing, so this is also for testers). once people volunteer (a volunteer is a key word here) the scrum master asks if they will think about how they want to tackle it (i.e. which tasks and by whom) and when can they review it with the team. This helps move accountability to the people and gives them a place to grow. The idea is for the scrum master (or manager) to assist them but let them carry it out on their own.

 

Teamwork Phase: Story-Oriented

Description

After doing many experiments and learning to work together, we have one team of people working together toward one common goal.

They don’t remember when it happened exactly, but one day they decided they will not document the tasks in the tool they use. The reason was that with time, they found more and more tasks – micro tasks – that were woven together into a fabric of teamwork. They realized documenting them was unnecessary – they actually talk – who would have believed – so they don’t really need to write it down. Not to mention the fact that these tasks keep changing with the feedback they get from their work.

Stand-up meetings… These happen less as the team is in constant communication and they try to work on fewer things in parallel so most of the time everyone knows what’s going on anyway.

The scrum master, with time, found she needs less time to invest in management as the team knows what to do, so she can invest more time in being a team member and developing or testing. She now contemplates whether she wants to stay on the team or try and go to a management position.

Goals for Improvement

There are two main goals for improvement at this stage.

The first goal is continuing to improve the cycle time: once the team decides they start doing something, they want to complete it as fast as possible – they do it by focusing on less things in parallel, by diversifying each person’s capabilities and by continually improving the way they work together.

The second goal is to try and add more upstream and downstream activities to the responsibility of the team. This will both increase the sense of ownership shared by the team’s members and decrease the lead time for stakeholders’ requests: the time it takes to fulfill a requirement from the time it is raised until the time it is being used.

Suggested Experiments

Add a skill – Find opportunities for people to add new skills to their portfolio. Let a front-end developer do some back-end development: maybe something simple at the beginning. Let a tester learn more about development so they can do better initial debugging when finding a defect. Teach people about UX principles and let them come up with suggestions. Slowly but surely increase the skills of your team.

Go Upstream – start picking items where the team may be involved in earlier stages. Can team members meet customers or other stakeholders? Can team members come up with features and stories? Can team members be directly involved with marketing people?

Go Downstream – define done as when customers have started to use the system and are happy. Try to find aspects of operations that the team can try to do. Learn about DevOps.

Conclusion

We have presented here a partial list of experiments and ideas that can move a team to better teamwork. These experiments can be initially discussed at team retrospectives and planned at team planning sessions. The daily meetings are a great place to continually support these experiments. With time, we would like these experiments to be part of the day to day work of the team.

Can you think of more suggestions for experiments? Tell us and we will add them here with proper acknowledgement.

Subscribe for Email Updates:

Categories:

Tags:

System Team
Scrum Master Role
Continuous Planning
Process Improvement
Scrum and XP
Software Development
Agile India
SPC
Business Agility
Kaizen Workshop
Lean Risk Management
LPM
Nexus and SAFe
Artificial Intelligence
Agile Testing Practices
Professional Scrum with Kanban
Hybrid Work
Nexus Integration Team
ART Success
Scrum
Agile for Embedded Systems
Kanban
Atlaassian
Tools
Jira
lean agile change management
Agile in the Enterprise
Agile Marketing
Introduction to Test Driven Development
LeSS
Risk-aware Product Development
Agile Risk Management
Scrum Master
Program Increment
Agile
Enterprise DevOps
AI
Video
Development Value Streams
Agile Delivery
System Integration Environments
Software Development Estimation
Manage Budget Creation
Lean Agile Leadership
Code
Agile Community
Managing Risk on Agile Projects
Accelerate Value Delivery At Scale
Change Management
An Appreciative Retrospective
Agile Release Management
Story Slicing
ScrumMaster Tales
Operational Value Stream
Elastic Leadership
Introduction to ATDD
WIP
GanttBan
Value Streams
BDD
Jira admin
Lean Agile Organization
Sprint Iteration
Achieve Business Agility
Limiting Work in Progress
Quality Assurance
Perfection Game
Agile Product Development
User stories
Kanban 101
ALM Tools
SAFe
Rapid RTC
Agility
Implementation of Lean and Agile
Scaled Agile Framework
Scrum Guide
Portfolio for Jira
ATDD
NIT
Spotify
Iterative Incremental Development
Professional Scrum Product Owner
Lean Startup
SAFe Release Planning
Lean-Agile Software Development
Scrum.org
RTE
Lean and Agile Principles and Practices
Large Scale Scrum
IT Operations
ROI
Sprint Retrospectives
Agile Product Ownership
Agile Release Planning
Agile Project
Lean Software Development
Continuous Delivery
Tips
Agile Basics
Test Driven Development
Coaching Agile Teams
Professional Scrum Master
Jira Cloud
Planning
chatgpt
Slides
Lean Budgeting
Risk Management on Agile Projects
Managing Projects
POPM
Agile Exercises
Kanban Basics
Built-In Quality
predictability
AI Artificial Intelligence
Agile Games
Pomodoro Technique
DevOps
The Agile Coach
Continuous Deployment
Sprint Planning
Acceptance Test-Driven Development
System Archetypes
Releases Using Lean
Frameworks
The Kanban Method
RTE Role
Agile Techniques
PI Objectives
Lean Agile
Product Management
Webinar
AgileSparks
Games and Exercises
Agile Program
Continuous Improvement
Scrum Values
Continuous Integration
Kaizen
Product Ownership
Principles of Lean-Agile Leadership
Agile Assembly Architecture
TDD
Presentation
Agile Outsourcing
ATDD vs. BDD
speed at scale
Certified SAFe
Lean Agile Basics
Agile Development
Jira Plans
Self-organization
ARTs
Lean-Agile Budgeting
Reading List
Systems Thinking
What Is Kanban
SAFe DevOps
Agile Israel Events
Release Train Engineer
Daily Scrum
Nexus vs SAFe
Agile Contracts Best Practices
Applying Agile Methodology
QA
Amdocs
Nexus and Kanban
RSA
A Kanban System for Software Engineering
Agile Project Management
Lean Agile Management
Legacy Code
Engineering Practices
Kanban Game
Legacy Enterprise
Nexus
PI Planning
Entrepreneurial Operating System®
Lean and Agile Techniques
Agile Mindset
Implementing SAFe
Certification
Effective Agile Retrospectives
Risk Management in Kanban
SA
speed @ scale
Agile Israel
Advanced Roadmaps
Scrum Primer
Atlassian
agileisrael
Agile Games and Exercises
Agile and DevOps Journey
Scrum With Kanban
EOS®
Covid19
Kanban Kickstart Example
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart