What is it that makes a development team successful? Is it their ability to accurately predict the delivery date? Is it their ability to keep bug counts to a minimum? Or is it something else? Could it be how well the team communicates and works together?
Years ago the measure of a great development team wasn’t the team at all but the individual. This person would meet their schedule as shown on a Gantt chart and, maybe more importantly, did so without much intervention or guidance from their manager. They could make quick technical decisions and they knew the product and how it was used. These people were known then, as they still are today, as high performers. So Agile comes along and celebrates the Team, does this mean high performers are no longer wanted? Silly question, of course they’re still wanted. It’s really about definitions and what’s best for the business and for business growth.
The high performer of the past was always about the individual and less about the team. The appraisal systems in use then and for the most part still in place today, focuses on the individual’s performance. If the team results were less than stellar, the high performer was said to be held back by the other members of the team. Clearly it wasn’t the high performer’s fault the team sucked.
Now assume for the moment your business doesn’t wish to go Agile but wants to build teams made up entirely from high performers. This is exactly what Netflix has done (see the Harvard Business Review article, “How Netflix Reinvented HR“, for an eye opening insight on how this works). Now the kind of openness and honesty that Netflix has won’t work in all companies, especially if the company uses performance reviews as a weapon to elicit certain kinds of behaviors. So for those companies unable to go the Netflix route, Agile seems a good choice for company growth and building teams of high performers.
Agile is about teams and teams are made up of individuals. The high performer in the Agile sense is someone who helps make their team a high performing team. High performers in Agile are Servant Leaders, they serve the team first. They do this not by doing the work for those who need help, not by ignoring those who are weaker, not by telling the manager that this person is no good and needs to be trained elsewhere, but by showing the person a better way to work, by devoting time and energy to help those challenged, by working with management to train and build up the competencies of those in need. But how do these high performers learn the techniques and skills of helping, of being selfless, of being a servant leader? Enter the Scrummaster or Agile Project Manager.
The Scrummaster by virtue of training, study, reading, networking, and experience, is ideally suited to help those willing team members become great servant leaders. I say willing as some people will be pre-disposed to resist anything that distracts them from their first love, being developers. These people will need personal coaching to help them help themselves and grow their own servant leadership behaviors. The very first thing needed for any team to be successful is open and trusted communications. Below are 4 ways the Scrummaster can help build stronger communication links within the Agile team.
Most Scrummasters spend a considerable amount of time observing the team, how they behave toward one another, and how they communicate. Listed below are some of the behaviors I’ve observed and some suggestions on how to improve team communications. None of these are a one-off thing to do but will need to be repeated many times to change the team’s behavior. None of these are mandated but can easily be accepted by team member to varying degrees. Given time and patience, team members will build up toward being a high performing team.
- Development team members wearing headphones. This can be a bad situation as people are generally very courteous and often reluctant to disturb someone who’s wearing headphones. There’s no real good answer except to discourage, not necessarily eliminate, the behavior through team and one-on-one conversations. Some teams have set aside a “quiet hour” to solve this but this reaction can have a detrimental affect on open lines of communication and collaboration. Strike a balance where the team’s ability to collaborate and communicate are not stifled by someone wearing headphones. Make efforts to create tasks that easily allows pairing. Watch for the team member who appears to looking for help but doesn’t attempt to interact with headphone wearers.
- Team members who don’t stop working to listen. (This is about conversations within the team, not interruptions from outside the team.) Good face-to-face communications usually requires people to be face-to-face. The ability to make eye contact and observe facial expressions is important to help gauge emotion but it is also a sign of respect. When you stop and devote your full attention to someone while they talk, you are showing respect to them and the thing they’re talking about. I find that people are generally not aware of this behavior so I would suggest filming, with the team’s permission, how the team interacts during the day. When I’ve done filming in the past, people were very quick to see flaws in how they communicated and were able to make immediate and lasting changes.
- Team members who don’t know very much about each other. This may seem unnecessary to some but it’s really an essential ingredient for trust, empathy, and understanding. I was once helping out a Scrum team where there was constant fighting and bickering. This had a lot to do with people having their ideas and opinions ignored by everyone else. It mattered little that the person with the idea might be the subject matter expert because no one else knew that. I asked different team members what they knew of their fellow team members and it was shockingly little. One way to introduce people to one another is to do Journey Lines. I started a new project with several teams and we all did journey lines of our work careers to great success. People walked away saying they never knew or understood the depth of experiences some of their team mates had. I can’t emphasize enough the value of the Journey Line tool. It gets to the heart and soul of everyone on the team and once learned, you can’t go back. Below is an example Journey Line from Lyssa Adkins‘ book, “Coaching Agile Teams”.
- Getting the team out of the office once a week. In my talk, “The Journey to Servant Leadership”, at Scrum Australia 2016, we encouraged people to do a team off-site once a week. Although our Scrum Australia talk was focused on transforming a manager into a servant leader, one important tool for getting the team members talking about decisions instead of the manager making decisions was this once a week meeting in a coffee shop. Part of the journey to servant leadership requires the team take on additional responsibilities and make more and more decisions. During these weeklies, the formality of the office hierarchy and structure disappeared and these team members spoke openly and honestly. The team members not only spoke about issues and problems they had in the office, they also talked openly about their families and weekend plans. But for the Scrummaster (or coach), this is a great opportunity to listen and observe how the team interacts and arrives at decisions. Back to the Servant Leader talk, my observation at the coffee shop was the team was unable to commit to a team decision even when it was overwhelmingly obvious they understood exactly what that decision should be. In talking to the team members later, the primary reason they didn’t make the decision was they feared backlash from the product manager. The decision involved fixing a problem the team had introduced in the previous sprint. The team needed to hear from the product manager that it was ok. This is all well and good in the Command & Control environment but is not the desired behavior in Agile. It wouldn’t fly at Netflix either. The team had to learn that collectively, they know more than the product manager and are better suited to made a quality decisions. The Scrummaster can use these off-site meetings to listen and understand team dynamics to spot areas for improvement. The team was having a conversation in the coffee shop they would normally not have in the office. Also, make sure the right people are there. If the team had the product manager in the coffee shop, the team decision would have been endorsed by the PM.
Building an Agile team of high performers starts with the individuals in the team. The Scrummaster can help build up their communication skills which is an important first step. Scrummasters will do and redo the above steps often as it will take time to get the team anticipating and understanding the wants and needs of everyone else on the team. This can take 3-6 months for most people in the teams to change although it could take longer.
Communications opens up many doors of opportunities not only for Agile teams but also for companies and company growth. A Forbes article, “Why Communication Is Today’s Most Important Skill“, author Greg Satell gives some historical background to great communicators. He also gives us some current examples of how business can flourish using communications.
The sooner people in your team and company are communicating, the sooner they can all be on the same page.