One secret to a great Agile/Scrum team is the environment where they work and will spend a large portion of their daily life. This environment is made up of many things but arguably, the most important are communications, physical environment, and management support.
Communications is critical for the success of any team: waterfall, agile, military, or sports. Scott Amber has a great article, Communication on Agile Software Teams, which includes the graph below showing the effectiveness of various communication channels.
Face-to-face communication is essential to:
- communicate bad news e.g. Honey, I don’t have any money
- communicate sensitive information e.g. I lost all our money at the dog track. I know I said I’d stop gambling.
- communicate anything that would benefit from eye contact, a reassuring nod, and other body language e.g. do you forgive me?
Phone or video communication is appropriate to:
- come to a quick, clear understanding e.g. Honey, tell me again why you kicked me out
- removing small bits of confusion e.g. I can come home when what freezes over?
- make a personal introduction or ask a favour e.g. Mom, could you lend me some cash for food?
Email communication is appropriate to:
- to share complex Information that does not require discussion e.g. From: Dewey, Cheatem & Howe, Attorneys at Law. Dear Sir, What follows is exactly why you lose the house, the BMW, and the dog…
- to confirm the details of a face-to-face or phone conversation e.g. Mom, as I said earlier, I don’t have any money for food
- to pass on information without interrupting someone e.g. Dear Sir or Madam, I need a job. Will you hire me?
Communications and the scrum team
Communication behaviors to and within the Scrum team is probably the single most important team asset a Scrum Master can cultivate. Communications lays the groundwork for trust, team engagement, and team empowerment. It is no surprise that communications is one of the 12 Agile principles.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Let’s break this down this principle into its components:
“most efficient and effective method of conveying information”. One big advantage for face-to-face communications is observing facial expressions and body language. This means that one can read the other’s body language to see if there’s understanding, discomfort, boredom, or something else. For example a product owner is discussing a user story, are the team members understanding the concepts or do they look confused or bored? Face-to-face communications gives a product owner an opportunity to show they care by asking probing questions of the team and actively listening to understand the team’s perspective.
“to and within a development team”. This means that outsiders as well as team members use face-to-face communications. The product owner uses face-to-face communications to demonstrate respect for the development team. This is accomplished through direct interactions and active listening to the team’s feedback. Face-to-face communications establishes shared experience that can enhance all future communications.
Management uses face-to-face communications to build trust, share their strategy, explain it clearly, and answer questions honestly. Face-to-face communications helps create camaraderie that is the basis of cooperation and success across the organization. This can make the development team feel valued and gives them a chance to contribute to organizational strategies.
Face-to-face communications gives both the product owner and managers a chance to confirm the team’s understanding of key issues, identify gaps and encourages ongoing feedback and engagement.
“is face-to-face conversation.” This means that you should not explore alternative methods of communications unless absolutely required. Bug tracking tools, paper documents, and email are not an acceptable alternatives to face-to-face communications. However, video or Skype call, or old fashion phone calls may be the best if face-to-face isn’t possible.
Encourage your team to speak to each other even when working. This allows others to overhear and can provide them an opportunity to contribute. I’ve observed most companies use IM tools, Slack being the predominate tool. The down side of these tools is dominate personalities can prevail and quieter people often times do not give their voice. Quieter people will often need prompting to get their thoughts, ideas, and opinions out and IM tools can fail in this regard. The team includes everyone and everyone should be encouraged to participate in important decisions the development team is making as they solve the customer’s and product owner’s problems.
And the very best way to conduct a face-to-face conversation is in front of a white-board (see physical environment below).
The physical environment and management support go hand in hand as the environment is usually provided by management. In the best environments I’ve seen, the Scrum team (development team, scrum master, and product owner) sit together to foster better communications, building a sense of team, and limiting outside distractions.
The value of a team space is the sense the team gets with ownership, which is not too far removed from a family’s first home ownership: it ours! This is a comfortable place for the Scrum team to live and work 8 hours a day. A place where daily scrutiny is (hopefully) absent. The first Scrum teams I helped form were given a cubical that could easily seat 6 with lots of room to spread out. There were partitions that gave a strong sense of privacy and a double-sided whiteboard on wheels was just at the entrance. I also ‘found’ some small round tables that fit nicely inside so the team had a place to huddle. I don’t remember anyone saying it was heaven but it was quite good. Management really wanted these teams to be Agile and even offered to redesign the team area if the team wanted.
InfoQ has additional reading on developing an ideal Agile work space in the article, “Designing Collaborative Spaces for Productivity“. It’s a little dated but you’ll get the intent for team space with a lot of ideas.
The prime ingredient for the co-located team, other than a place to put their computers, is a big wall or whiteboard for the team the ‘think’ with. When I was setting up multiple Scrum teams I had purchased double sided whiteboards on wheels for each team (there wasn’t much wall space available for all teams). After a while some teams acquired two of these whiteboards. These boards were used as the Sprint Board, software designs, component designs, and system architecture designs. They also held the team’s metrics, customer names, business contact names, and most anything the team needed documented.
Another item that helped was a conference room for the team’s exclusive use. This made impromptu meetings possible when needed. This quiet space was very beneficial during customer interviews and user testing. It had a whiteboard, table & chairs, a computer and a phone. Nice private spot for the individual or teams use.
Another item was a dedicated test environment, configured as customers would. When I was at a product company, the Quality team set this up to mimic customer environments as close as possible. The Quality team created simulators and the development team made use of off the shelf simulation tools. All this allowed the team to better build in quality. For a digital product team, this would be a fully functional A/B testing site or staging area.
And finally, what development team is happy with their computers or workstations? Here the company went to great lengths to keep the development team up to date with the latest technology and software packages. However, as Scrum Master, I bought SSD drives and software for the team when they needed it and the company couldn’t act fast enough. I was usually reimbursed but not always.
When you have team members or whole teams off site, the effort you put into communications will determine how well it goes. Here are some tips I gathered from Vodafone on their communications with off site teams.
- Spend a minimum of 3 weeks with the full team, either at their site or have the team on your site – Vodafone does 3-6 weeks leaning toward the longer time
- Communications order of precedence: Face to Face -> video (Skype, Google hangouts) -> voice -> text – Vodafone uses a 24/7 video feed to communicate with their off site teams
- Set up a camera and microphone in each distributed team area so people can casually communicate anytime
- Bring in an outsider to observe your communications so they can objectively rate it – listen for silences or no questions, these can indicate a communication problem
- Take special note of when the off site team works, their time zone, their start time, end time, lunch time, break time(s) – have a big clock set to their time
- Provide context, give the big picture of the business and the details of where a story/task fits – Macro & micro details are important
- Understand the culture of the team – how they work and what they expect are very important – are they waiting for direction and decisions by you?
- Stylize your communications to cater to the off site team’s culture – say thank you for small things and smile
- Finally and most importantly, the off site team is not a partner, they are an extension of the local team – don’t get into the habit of us and them
When working with distributed teams in other countries, check out www.worldbusinessculture.com to gain some insights to their culture. For example in the Philippines, it’s extremely important to be aware of the sense of ‘face’ of every member of a group because an insult to one could be construed as an insult to all.
From the Agile principles:
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The Scrum Guide doesn’t list any roles for managers but this doesn’t mean there isn’t a strong management presence and influence. The Scrum team and product owner are the link between the product and customers/users. Product managers and line managers are the link between the Scrum team and the company. Without the company there is no product and without a product, there is no company.
Hire the right team members
Management starts by hiring people who will eventually become members of the Scrum teams. A while ago I asked Gary Swart, then CEO of oDesk, how he hired team members. His answer was attitude mattered more than their skills. Heresy you say, how will the work get without all the heroes? Managers like their heroes, those super productive people with whom they can count on in a pinch. Of course the heroes don’t go away but, as Ilan Goldstein, managing Director of AxisAgile, has written about Scrum team members:
We prefer Attitude over Aptitude
That is, while there is value in aptitude, we value the right attitude more.
Gary Swart used three attributes when hiring a new team member, in order of importance, are:
- Motivation – is the applicant driven to succeed in their chosen field?
- Personality – will the applicant work well with the culture and the people there i.e. brilliant jerks may not make it in
- Skills – do they possess the basic skills necessary to do the job and are they eager and willing to learn more, even outside their specialty?
Getting the right people is important and this responsibility usually falls on management.
Support the team
My early experiences in software development was in the defense industry. We had a matrix organization where, as project manager, I would need to speak to several managers each day on progress and other statuses. These managers were well within their rights to tell me or the team what to do or which tasks to work next. This was a waterfall environment and all dates, capabilities, and deliveries were agreed to when the contracts were signed. The managers’ responsibility and accountability was to get the project in on time, within cost, and with the contracted scope. It all worked but did take its toll on people. This relationship has changed with the introduction of Agile but maybe not as much as you might think.
Managers in an Agile environment are thought to possess qualities of a Servant Leader. Today’s manager serves the team, helps the team manager their project and project tasks. Today’s manager supports the team by helping the team find their own successes. And in the process, the manager becomes more successful. The goals of management in an Agile environment is to deliver high value software to the customers as quick as possible. They do this by empowering one or more Scrum team to determine which features are of the greatest value to customers and allowing the teams to implement & deliver these features in their own way.
Setting up and maintaining the optimal team environment is hard and requires effort by both the teams and management. If you do nothing else, strive to perfect communications between the business and teams and within the teams. This open communications will pay off with not only having people knowing what they need to know to be successful but allows for the possibilities of new ideas and innovative solutions.
When setting up team spaces, if possible, involve the teams in the layout decisions. Most companies will probably run with an existing office layout but a whiteboard wall to divide up team homes is relatively cheap and is remarkably useful in achieving greater productivity. By any and every means possible, give each Scrum team ample wall or whiteboard space to help productivity.
And none of the above can happen without management support. Management comes to recognize that the Scrum teams pull together to satisfy the customers with the highest valued products first. Management’s role is to support the Scrum teams in ways that help these teams be successful. They accomplish this by hiring the right people with the team’s involvement and by ensuring the Scrum team has every scrap of information needed to increase their chances of success.