Agile Collaboration

Collaborate (verb) – to work jointly with others or together especially in an intellectual endeavor

Collaboration (noun) – the action of working with someone to produce something.

(Source: Merriam-Webster)

I was recently giving some training where I asked people if their work environment was open and collaborative. They answered yes. I then asked if they knew what the CEO, CTO, CFO, Marketing, Sales were doing that week. Most didn’t know the answer. I asked how much say and influence the development team had over the type or scope of product work. The answer was little to none.

We often work in environments that are considered ‘open’ and ‘collaborative’ yet we have small groups making all the decisions and passing them around like dinner invitations. We get a meal but little input into the meal itself. For better or worse, the development team is often told what to do through some hierarchy and given requirements with the expectation that these requirements will be implemented as is and on time.

Collaboration and culture

How familiar does this sound: You’re in a meeting trying to solve some problem. The manager asks for suggestions and you boldly give your opinion on how best to solve the problem. The manager is looking at you without expression, perhaps even staring. You finish your comment and the manager continues to look directly at you for a couple beats after you’ve finished. The manager then states the solution which has no relationship to what you just said or for that matter, what anyone else has said. The manager closes the meeting saying something like, “Great ideas and a great collaborative effort. Thank-you all for helping.”

Now some would say the manager took on-board all the ideas and arrived at a solution but more likely, the manager had already made a decision. The manager held a meeting to check if he or she overlooked something and gave the illusion of collaboration. This kind of behavior is not uncommon and in at least one place I’ve been, managers were expected to make all the decisions.

How your culture is set up can determine how collaboration will work. Think about how your office works today. In Steve Coats’ article, “The Conundrum of Collaboration“, he describes it like this:

Think of it this way. You are one of two candidates being considered for a promotion into a higher position. You have always looked for opportunities to collaborate and have been part of many successful achievements. The other contender’s profile doesn’t focus much on collaboration. Instead it highlights a string of great accomplishments that this person has been directly responsible for throughout his or her career. From what you know about how promotions have been determined in your organization, would you feel like you are in the strongest position?

Although the company culture can deter collaboration, Steve Coats goes on to state that people’s own sense of self is a larger barrier to collaboration.

Clearly there are things about an organization itself that impact collaboration efforts, but none of those are the number one reason that collaboration stalls. That reason is much more personal. It is self-interest. People frequently refuse to collaborate because they do not believe it is in their best interests to do so. And those organizational confines just discussed strengthen that argument.

Sure businesses want people to collaborate but the reward goes to the individual who achieved something. At one place I worked, the performance review rated how independent I was. The top score was “works independently”.  Asking for help can be seen as weakness; always working with others can be seen as a crutch. You can’t expect collaboration if there’s no reward for doing so.

The hero and the collaborator

The Agile Manifesto and Principles don’t tell us how to do software, it’s up to the facilitator and implementer to figure out how best to be agile. While agile doesn’t directly say that collaboration is required, the expanded responsibilities needed for a successful agile team means that collaboration is a necessity.

In most organizations there are identifiable heroes; those people the company can “count on” to make projects successful. While this sounds familiar to most it is also an illusion. The hero does it all except grow the team. If the hero is away or leaves then there’s likely a vacuum that takes time to fill because the development team haven’t been trained or encouraged to step up.

In traditional projects, the heroes are in constant motion, making decisions, telling people what they need to do, and genuinely doing their best to make the project a success.  If the project were less than successful, either schedule or budget weren’t met, fingers are often pointed, usually at development. The heroes are Teflon coated and any negative feeling usually won’t stick to them. One reason heroes can flourish is they have knowledge that others do not have. To maintain their status as hero, it’s incumbent for them to withhold certain knowledge. To be clear, they are not withholding knowledge that could be catastrophic if not shared; they are not about to allow the ship to hit an iceberg. However, they might withhold details of why the work is being done. Development teams are expected to write “IF … THEN … ELSE” and not participate in the broader question of ‘why’. But here’s the problem: the development team collectively has a vast amount of knowledge and experience that is left untapped and businesses should tap into this to grow. Agile would sacrifice the hero to get to this untapped resource.

The hero acts like a tourniquet; too tight and the limb withers and dies, too loose and the patient dies. If the hero holds too tightly to knowledge, the development team will feel less engaged. If the hero let’s go without priming the team, the inexperienced team will likely falter. The tourniquet is not the long-term solution but a stop-gap. The danger to the business isn’t the hero themselves but the over reliance on the hero to the detriment of others learning and growing. I’ve been in meetings where one person says they’ll do everything and everyone else steps back to allow them to proceed. A hero can help make the company successful but we’re not here to rest on our current successes, we want to be more successful. Having heroes can limit imagination and growth because you’re stuck with what the hero knows.

Collaboration and success

The need for collaboration can come down to how you measure success. If you’re being agile, success is measured by customer satisfaction and achieving business goals due to that satisfaction. In traditional software development, success is measured by completing the project plan on time and on budget.

To be successful in agile, everyone working on solving the customer problem needs to be aware of how the customer perceives their problem and what they feel is a solution.  This is the fundamental shift from traditional project management. Everyone involved in the solution needs to have a near-identical understanding of the customers’ problem. This necessitates collaboration with the customers, development, product, marketing, sales, support, and management.

Steps to improve collaboration

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win”JFK Rice University 1962

“win just one for the Gipper” – attributed to Knute Rockne

“I have a dream!”Martin Luther King 1963

If you’re looking to improve collaboration, one could say simply change the company’s culture to reward collaboration but this is insanely hard. Besides, when was the last time something big happened because you ‘said so’?

Improving collaboration within a business and between teams requires finding the answers to these two questions:

  1. how does collaboration benefit the individual
  2. how do I collaborate more

Neither question has an easy answer and the details of the answer are wholly dependent on the environment. However we can look at some general strategies to answer both.

Benefit the individual

One thing that most people will agree on is an engaged employee is a happy employee. The first step toward engagement will be to trust the them and their team to collectively find solutions. This begins with the business establishing boundaries where the team can operate and make decisions freely. For a development team this probably starts with the product backlog and grooming the requirements/user stories. To be clear, it becomes the team’s responsibility to work side-by-side with the customers, users, and product people to appropriately understand and refine the work. The reward is the team gets more input to the product. As the team becomes more involved with the business of solving customer problems, the more skin they have in the game. The teams will spot pitfalls and opportunities much sooner, increasing the likelihood of success. Taken together, this empowerment to make decisions and the added responsibilities will:

  • create strong team bonding
  • increase the team’s sense of ownership of customer and business problems

This will also allow a team to fail earlier and make corrections much sooner.

Collaborate more

It’s very easy to tell people to collaborate, very hard to have valuable collaboration. When I worked with teams that were located in different cities, I arranged for two scrum-of-scrum meetings each week. I also set down an agenda that balanced high-level knowledge sharing (e.g. business/customer problems being worked & architecturally where the last and next changes would occur) with low-level implementation work so developers weren’t stepping on each other. These collaboration sessions were facilitated by scrum masters and one team in each city documented decisions and actions. We did the double documenting to make sure we all heard and understood correctly. As we progressed we adjusted these sessions to maximize the value and reduce the duration. We generally did them in less than 20 minutes.

To get the executives, senior managers, customers/users, and agile teams on a first name basis so to speak, we did inception workshops. A key activity for internal collaboration was a ‘who/do‘ table. This is based on the book “Gamestorming” by Dave Gray, Sunni Brown, and James Macanufo.

Through this table of actions, all stakeholders team up and commit themselves to achieving a successful result. While there are several activities that can be done throughout a project to strengthen collaboration, retrospectives for example, having this at the start sets strong expectations for all stakeholders. The ‘who’ on the list are actual names of people when needed or roles otherwise.

If the team has trouble identifying who they need to collaborate with, they can do a variation of the circle & soup game during retrospectives. This is a game usually used to identify improvements and problems that either slows down or blocks something the team feels is important.

  • Inner circle: “Team Controls” – what your team can directly manage
  • Middle circle: “Team Influences” –persuasive actions that your team can take to move ahead
  • Outer circle: “Soup” – Can’t control or influence: elements that cannot be changed. This refers to the environment we work in and must adapt to. Ideas from the other 2 circles can identify ways to respond to the barriers floating in our “soup.”

As well as identifying problems and how to approach finding a solution, the circle & soup game makes clear the avenues of collaboration. For those improvement items they ‘control’, these are the areas that collaboration is needed within the team and between teams. The items in the ‘influence’ and in the ‘can’t control or influence’ circles means collaboration with those people who own the area of interest. The different circles suggest that different tactics and collaboration skills will be needed.

Mutiny

What happens with the developer who only wants to write code and doesn’t see talking to users or writing user stories as enjoyable or desirable? Moving these people is hard and could be likened to moving the sofa across a floor. At first you’ll need to exert lots of force to overcome static friction but once moving, you only need enough force to overcome kinetic friction. However, there is a point when it’s cheaper to hire right thinking people for the team rather than attempting to change behavior. This may sound harsh but it needs to be done on occasion. When I’ve seen this it often benefits both the company and the individual. I’ve also seen where someone once removed from an agile team returns sometime later.

Summary

Collaboration isn’t natural behavior for people and is therefore something that must be practiced and learned. There are tools that can help, ‘who/do’ lists and ‘circle & soup’ games, but in the end management and teams must recognize collaboration adds a dimension of efficiency and speed to any endeavor. The business needs to setup the conditions where collaborating becomes natural. Managers and management have long been collecting information, filtering it, and making key decisions. Pushing decision making down to the people who have the knowledge will be a challenge for some managers. However, only management can begin the process of removing hierarchies from peoples’ minds and teach teams how to collaborate and how to behave to maximize collaborative results.

 

When will my agile team self-organize?

Great! Your business has decided to move from a Waterfall paradigm to Agile Scrum and now you’re waiting patiently for the benefits to kick in. You’re hoping your Scrum teams start self-organizing soon and are inventively solving customer problems faster with better efficiently. You’re also waiting for the team to become major contributors to the business decision process based on their intimate knowledge of customers and their pains. And you’re waiting … Still waiting …

You ask yourself what’s holding the team back. The Scrum Master has trained the development team on the agile manifesto including the principle:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

The Scrum Master has also trained the development team on self-organizing as described in the Scrum Guide:

  • defining the Scrum Team: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. … The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”
  • defining the Development Team role: “Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”
  • defining the Scrum Master role: “The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality.”
  • defining the Sprint Planning Meeting: “The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint…By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”
  • defining the Daily Scrum: “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.”

It’s clear the Scrum Guide expects the Scrum team, and more specifically, the development team, be a self-organizing body. It’s also clear that training people that they should be self-organizing isn’t always enough. The organization must want and the businesses actively support the team becoming self-organizing.

Setting Expectations

Getting a Scrum team to self-organizing is hard primarily due to the fuzzy nature of what ‘self-organizing’ actually means. If you were to ask 5 people to define what a ‘self-organizing’ software team is you’ll probably get 5 different answers. But even in that result some truths are seen, it’s not how I define self-organization, it’s how the team defines it.

In Nitin Mittal’s Scrum Alliance article, “Self-Organizing Teams: What and How“, he describes 5 essentials of self-organizing teams:

  • Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above.
  • Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged.
  • Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
  • Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues.
  • Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn’t help. Continuity is essential for the team.

I was once Scrum Master to a team during which I did training on the advantages of setting priorities, of sharing work, and of getting stuff done. The team was very good at their jobs and helped each other out whenever asked. However, I didn’t realize helping out had a limit until one day at the daily standup when the person working the most important story, the highest priority story, was out. I asked who could pick up the work to move it forward? No one raised their hand. One of the quietest people then said it was massively inefficient to have someone else pick up the work. For me personally this was a sad, sad day. After talking priorities, talking of sharing work, talking of getting stuff done, and talking how the team best works together, the team couldn’t let go of their own personal task responsibilities. The team couldn’t find it in themselves to embrace a team responsibility of getting the most important work done first. A self-organizing team would have kicked into a self-managing mode and re-allocated work so the highest valued work could continue. At the end of the standup, team members felt a stronger bond to their own work in areas they were most comfortable with than to the whole. It wasn’t competency but rather motivation that was holding the team back.

What makes it so hard to motivate a team to feel responsible for the whole? When a business pushes individual roles & responsibilities over team commitments or when survival and blame permeates an environment, it’s very unlikely that the team will move beyond the ‘forming’ stage (team members sticking to what they know best individually and doing what they feel most comfortable with).

In some business environments, the dip in productivity while transitioning from ‘Forming’ to ‘Storming’ is unacceptable. This would be especially true in a strong hierarchical or Command & Control environment where those in the hierarchy are held responsible (accountable) for team performance.  If the business is clinging too tightly to a hierarchical and Command & Control environment, the likelihood of birthing self-organizing teams is diminished. At one company I was at, one of the most senior software engineers was a team lead. The team was always seeking his approval for any decisions and if the manager thought otherwise, the team changed their ideas to conform. This wasn’t the worse thing to happen but it was heavily reliant on the team lead always being right. A consequence of this was lower scores on the company’s engagement evaluations especially around empowerment and feelings of trust.

It’s worth the attempt

Adopting Agile and Scrum will not automatically cause people or businesses to change. For Agile and Scrum to make a positive impact, people will need to see that they need to change their own behavior. It’s possible to see that in an environment where individual knowledge or individual skills are the most sought after commodity, Agile may not be the right tool. In a business where rigid hierarchies and Command & Control are dominate, it may be a long journey to establishing self-organizing teams but certainly worth the effort.

David Ticoll in his Harvard Business Review article, “Get Self-Organized”, states that, “It would be difficult and risky—even foolhardy—to try to wholly transform a hierarchical business model into a self-organizing one. But the potential of self-organizing systems to enhance competitiveness is becoming clear to managers of some conventionally structured businesses.”

David Tricoll further states, “Today, the ability to stream complex, real-time information to the front line gives hierarchical companies greater power than ever to exploit self-organization.”

One approach might be getting the team to participate in business events such as creating business plans, working with customers and users, and respecting them as contributors to business success. Teams with greater insights to business and customer problems are more likely to be engaged with solving these. To be quick and competitive, businesses must relinquish control to the teams in the front lines and the teams must be willing to accept the responsibility. When the business leaders and development teams shared these insights, I’ve seen the development teams rise beyond their own specialties to rally around both the customer and the business.

For a team to become self-organizing, it will take more than a business to want and support it, it requires the team itself to see advantages in self-organization. If you’ve ever seen how an assembly line worked in days gone by, you’ll see an environment where self-organization would have been detrimental. Your job was to put nut ‘A’ onto bolt ‘B’ period. Repeat this for 8 hours a day, 5 days a week and you got paid pretty well for what to some people would be the most boring job on earth. The business wasn’t holding out hope that the workers would self-organize and the workers had no motivation to do so. In the factories, piecework was common. Workers were told what to do, how to do it, and when to do it. Software development is not piecework, if it were, robots would be doing it today. It is knowledge work where thinking both inside and outside the box are assets to the business.

In the situation above when a team member is absent, the moment the remaining team members decided that doing and completing individual tasks is more important, all advantages of self-organization were lost. Instead of adding value for the customer and business, the team had elected to follow a plan. The decision essentially comes down to: I have my own work to do and don’t have time to do yours.

To some, this kind of dedication is how you advance in the company. However, if the company were to emphasize customer and business value of work being done, it would cause a fundamental shift in team thinking, from doing tasks to getting the highest value work done quickly. When the business puts emphasis on value, the team is more likely to devote their combined efforts to achieving value. It would come to pass that even when one of their numbers is absent, progress won’t stop, although it may slow down. If the team is accepted as a fully participating business team member, not just a partner, the team will genuinely feel the success of the business is also their own success and act accordingly.

To me, one of the principle tenets of Agile is the team. The great power of Agile comes from a group of intelligent people working as one. Collectively they are more knowledgeable than any one individual although the shared experience may be less. To ignite the team requires the business to openly give the team responsibility and accountability for the outcomes of each iteration. For the business to move forward and empowering the team, they would need to establish safe boundaries from which the team can safely operate in.

When business leaders, product owners, and scrum masters attend the daily standup, what’s more important than hearing team members say,

I completed task <x> yesterday”,

is hearing them say,

we added <some> value to the product yesterday”.

The role of managers and customers on the self-organizing team

In an InfoQ interview, Rashina Hoda cites two environmental factors needed to be in place to enable self-organization to emerge. These are:

  1. Senior management at the teams’ organization must be able to provide freedom to the teams so that they can self-organize themselves.
  2. Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required.

“Self-organizing Agile teams … require organization structures that are informal in practice, where the boundaries of hierarchy do not prohibit free flow of information and feedback. In an informal organizational structure, the senior management is directly accessible by all employees (maintaining an ‘opendoors’ policy), and accepts feedback—both positive and negative.”

– from “Supporting Self-Organizing Agile Teams What’s Senior Management Got To Do With It?” by Rashina Hoda, James Noble, and Stuart Marshall

Summary

For the business leaders, giving development teams insights to both business and customers plus giving development teams space to operate, will motivate teams to accomplish amazing things. When the business states these are our goals and asks the team to solve it in the best manner possible, you’re likely to see a team self-organize to meet the goals. No one goes to work hoping they fail.

When the business has a strong hierarchical and Command & Control environment, moving a team toward self-organizing is made more difficult but not impossible. Building a bridge of trust and respect is essential. By establishing a strong partnership between the business and development team, followed by full membership, the team can exercise their collective knowledge and capabilities to contribute to business successes.

In the end, it’s a mutual effort on the part of both management and the development team to become self-organized. It will probably be a bumpy ride along the way but with a clear goal as a guide, both should arrive at the destination together.

 

 

 

Agile Team High Performance Communications

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.

Team Communications

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.

  1. 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.
  2. 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.
  3. 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”.

    Source: “Coaching Agile Teams” by Lyssa Adkins
  4. 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.

Summary

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.