Environment for Better Agile Teams

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).

Physical environment

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.

Co-located teams

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.

Distributed teams

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.

Management support

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:

  1. Motivation – is the applicant driven to succeed in their chosen field?
  2. Personality – will the applicant work well with the culture and the people there i.e. brilliant jerks may not make it in
  3. 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.


Warning: You’re Losing Money by Not Using the right Agile Metrics

The Agile metrics you use to measure Agile teams matters. A lot.

What makes a great Agile team? While there’s the idea of self-organizing, continuous improvement, and ever increasing technological growth, there’s really not a universal way to tell if a Agile team is ‘great’. For example, the business wants to release capabilities A, B, and C by June 30 and the Agile team doesn’t meet this date because the stories blew out, is this a great Agile team? Or how about the team that’s meets every business delivery date but the product doesn’t attract the number of paying customers hoped for, is this a great Agile team?

In truth, there are as many ways to measure an Agile team’s success as there are Agile teams. So if it’s impossible to have a standard measure then what’s a business to do?

The best answer is to tie the success of the Agile team to the success of the business. If the business’s strategy is to grow the number of customers then measure the number of new customers the Agile teams’ latest product features attract. Even if there are 20 teams working on one product, each team can work their new features to attract more customers. Infrastructure teams make the product faster, more robust, and multi-platformed in the back-end. Although customers can’t directly touch these changes, they can sense or ‘feel’ these improvements. The Unique Value Proposition might be, “our product is 3x faster than our nearest competitor!”

A very common occurrence is the scrum master finds initial measures that other scrum teams use, for example, on this site. Although this sounds OK i.e. “we’ll use velocity”, the measure may not fit the business. I was working in a company where teams often received new ‘business critical’ work from outside the current sprint or project. This was work to help secure new customers or address customer requests immediately. The team used velocity to measure performance even when the team, from a project point of view, was having their sprint plans negated through these requests. This should have rendered velocity moot. What would have better suited the team and the business was a measure of how quickly the Agile team could respond to these ‘business critical’ items.

In most scenarios the business needs to grow to be successful. Andrew Chen writes about scaling user growth as an example. This doesn’t automatically mean the development team needs to double their velocity in the coming year. Building the wrong product twice as fast isn’t the answer. What company’s need to do for growth is experiment unceasingly and this means the product development team needs to ramp up to build, deploy, test, and redeploy quickly i.e Growth Hacking.

How well is the Agile team doing? The best measures are related to the business strategy and goals. There are several categories of measures that teams or business could use including: business, innovation, Agile, customer, or environment. The best way to select what metrics to use is to understand what’s best for your customer and your business.

Your key Agile team performance measures will come from the sample list of Business, Customer, and Innovation measures below. The best measures internal to the Agile team will come from Agile and Environment. If the business strategy or goals change, it’s very likely that your measures for Agile team performance will need to change too.

1. Business – return on investment, growth, and customer base & market

  • Net Promoter Score – measure a customer’s likelihood to refer your product.
  • Referrals – this is a raw count of customers who actually referred your product to someone else.
  • Revenue – the amount of revenue generated by your product after new idea or update is released
  • Acquisition – number of new customers to your product after of new idea or update is released
  • Solving Your Problem Index – Customer’s rating on how the MVP is solving their problem
  • Customer lifetime value – Is this changing due to the introduction of a new feature or product line?
  • Rate of Sales Pipeline Growth – Has the new feature or product line accelerated sales growth?
  • Adoption/Use of New Feature or update– Are the customers and users using the new feature or update?
  • Customer/User Feedback from Each MVP – How well received was the MVP?
  • Market Size and Market Share – Is the new feature or update making the projected impacts?
  • Retention – Has the change brought back ‘lost’ customers?

2. Customer – satisfaction with the product and timeliness of deliveries

  • Count of positive customer testimonials – For each update or new idea, are your customers saying good things.
  • Count of negative customer testimonials – For each update or new idea, are your customers saying unhappy things. You can leverage these to get ideas for upcoming releases.
  • How happy is the customer – Have your customers stopped looking for a solution to their problem to wait for your solution.
  • How unhappy would the customer be – If the release was delayed one month, how do your customers react and would they look elsewhere.
  • Percentage of customer base interviewed or involved in usability testing – This is the total count of customers and potential customers involved in your ‘customer discovery’ efforts. The percentage involved will be a statistical significant number to allow accurate predictions.
  • Number of customers who have the problem you plan to solve – The count of customers you know have a specific problem you’re trying to solve. This can come from product feedback, interviews with customers/users, or other survey techniques.
  • Number of customers who want your solution – Count of customers/users who want your solution to their problem. This can come from product feedback, interviews with customers/users, or other survey techniques.

3. Innovation – technology, adaptability, and markets

  • Count of core initiatives – Target up to 70%. Efforts to make incremental changes to existing products and incremental inroads into new markets. Low to very low risk. Enough return to keep the business going for a time but not enough to sustain the business indefinitely.
  • Count of Adjacent initiatives – Target up to 20%. Leveraging something the company does well into a new space. Shares some characteristics with both Core and Transformational initiatives. Medium risk.
  • Count of Transformational initiatives – Target up to 15%. Create new offers (or new businesses) to serve new markets and customer needs. High risk but big returns if successful.

4. Agile – practices, methods, and processes

  • Number of Tasks added/removed during iteration – How well team knows the work and what done means for the story – INVEST criteria being followed and stories are small
  • Number of stories forecast Vs actually completed during iteration – How well the team understands the work of the iteration – INVEST criteria being followed and stories are small
  • Average size of stories in iterations – The ability of the team to make the stories as small as possible and still provide some value to customers/users
  • Average score of “Value” per user story – How well the team understands the customer problem and understands how the customer wants it solved (or what success looks like from the customer/user POV)
  • Percent of user stories in iteration covered by automated System/Solution tests – The team’s journey to automate end-to-end tests at the System/Solution level.
  • How independent is each user story in the iteration – How well the team understands how to remove complexity
  • Test First Vs Test Last testing done in iteration – Measure the team’s journey to be outcome driven at the System /Solution level.
  • Number of hours in iteration waiting for something – Measure of cycle time for same sized stories or epics.
  • Partially done work – By counting stories that are in progress at the end of a iteration we highlight the potential waste of incomplete work. This count is minimized by having small stories and having the development team managing their iteration backlog.

5. Environment – team working conditions and happiness

  • How happy are team members – This measures the general fun factor of work for the team. A happy team will work smarter and deliver a better product.
  • Number of hours in iteration spent helping team members grow and be better – Measure of an aspect of a self-organizing team: caring and improving the team.
  • Are you adequately served by management – Measure of how the team feels management is there to support them.
  • Frequency of team making product decisions – If the team is making most product decisions, they’re more likely to be enthusiastic about the product.