6 learnings from working in two very different product teams
Experiencing the good, the bad and the ugly during product design and development
I work for a consultancy and one of the best parts of my job is the range of projects I get to work on and the range of people I get to work with. I commonly work in teams made up of colleagues of mine from the consultancy and also employees from the clients side.
I’ve worked in two teams this year, for the same period of time, working with people who have similar job roles and responsibilities and both trying to achieve the same — product design and development.
I had two different experiences, and wanted to share my observations and learnings.
I’ll be referring to the successful team as Team A, and the not so successful team as Team B.
With Team A all team members were based together in the same room throughout the project.
Team members were only ever two desks away, instantly accessible and ready to chat. Whereas with Team B, certain members of the team were based around the country so face to face meetings or calls would have to be arranged, normally with at least two days notice.
Working in the same location means communication is instantaneous and shared with everyone, something that is hard to achieve via phone, Slack, email etc.
Also having consistency in the location the team are working in really helps. Team B moved location 3 times in 3 months, each time having to pack up work, whiteboards and iMac’s. A lot of time was wasted packing things away and then setting them up in the new location. Building passes and wifi codes had to be sorted for every new location, a tedious and time consuming process.
2. Team bond
It’s hard to create but it is important when creating a product.
With Team B there was little team bond, there was no effort made by the Product Manager to create a good team spirit and team bond amongst team members. Therefore it was just a group of individuals all working in their own little silos on their own individual part of the product.
Whereas the Product Manager of Team A made a real effort to create a strong team bond.
At the very start of the project we got to know one another on a personal level. We got to know what we were all interested in, the things we had in common with one another and throughout the project we socialised together, getting drinks and having team lunches regularly.
- Great trust between team members
- A team that wanted to help one another grow and improve
- A team that felt safe and comfortable to share ideas with one another
- Quickly understood strengths and weaknesses
- Different specialities in the team wanted to collaborate with each other
Having a clearly defined sprint goal and end product goal that the team came up with and all agreed upon also helped create a strong team bond. Team members were all aiming for one shared goal and would work hard to achieve that because they didn’t want to let one another down.
Team members need to feel empowered to produce their best work.
With Team B decisions would be made that would affect the team, but the decision makers wouldn’t consult the team for their opinion first.
On top of that, when people in the team had an opportunity to give an opinion and suggest something, commonly people with higher seniority or somebody that had a more important job role on paper wouldn’t listen to the opinions put forward by the team.
In the end it created such low morale among team members because it felt like the team didn’t have a voice.
Whereas with Team A the whole team felt extremely empowered. There was no hierarchy everybody was on the same level, the team would listen to one another and greatly encourage everybody to give their opinion on a matter before deciding as a team how to move on.
Command and control is the opposite of Agile. Give power to the team, trust them.
This point isn’t a specific trait that Team A had (like the rest) but Team A did do this, and without completing it teams are more likely to exceed budget and time expectations.
With Team A a thorough discovery phase was conducted by a Business Analyst, Designer and the Product Owner. This detailed analysis into what the project wanted to achieve and what successful outcomes would look like led to a clear definition of the project and scope of work.
That definition then led to an end product vision that the team came up with and all agreed upon. Doing the bulk of the discovery work early on led to stakeholders and the team buying in and committing to an approach.
The strong discovery phase also stopped the team starting things that weren’t achievable, something that Team B regularly did. Team B members would start working on a new part of the product only to be told a few days later that the part was now no longer in scope or that it couldn’t be achieved technically in this phase. Not only was it a huge waste of time but it also meant productivity and morale went down as no progression was being made and hard work being wasted.
5. What’s in it for me?
The two teams were doing work that would not directly benefit them. Everybody wants to do good work and enjoy doing it, but humans always crave more.
Something the Scrum Master of Team A did early on was to ask the team what they wanted to get out of the project as an individual and as a team. The responses were:
- Pay rise
- Contract extension
- Be proud of what we put out there
- Show other teams how it’s done
- Have other teams look up to us
This exercise that none of the team had experienced before brought with it a range of benefits. It helped with team spirit as we identified shared outcomes that we all wanted to achieve, it helped the team buy in to the project and encouraged team members to really strive for success.
6. Constantly improving
Both Team A and Team B were newly formed teams, nobody knew how well they would work together and where there would be inefficiencies.
Team A held a sprint retrospective meeting after every sprint (every 2 weeks). The team sat with one another and discussed what went well, what needs to stop and what needs to start to ensure the team was constantly moving forward. The team bond enabled honest and open feedback which team members and different specialisms within the team were grateful to receive.
The retrospective meetings took no longer than one hour, and all that was needed was a good moderator to keep the conversation flowing.
Whereas Team B never discussed how they were performing, and this was something that came from the top down. The Product Manager did everything in their power to stop having other teams in the business review the product and process, and not once brought the team together to discuss how the team could improve their ways of working.
Reflecting on how successful the two teams were motivated me to summarise my feelings about them to inform anyone that finds themselves in a similar situation, hopefully with a chance to influence the key team facilitators to make necessary changes.
Bad teams are characterised by:
Fear of raising problems, team members treating each other as strangers, and poor communication amongst team members.
Good teams are characterised by:
Open, transparent behaviour, of people working comfortably and communicating straight forwardly with each other, preferably face-to-face.
In terms of the characteristics I describe here, good/successful teams are:
- Located together
- Feel a common bond
- Feel empowered
- Have a strong project discovery phase
- Understood what’s in it for them
- Are constantly improving