High Performance Commitment Culture, Start with Team Norms!

What do the following have in common?

They are manifestations of team norms throughout time, driving organizational culture towards better performing teams.

Team norms are important for establishing a shared belief that the team is safe from interpersonal risk taking. Teams norms express intentions of individual team members as a collective whole. They represent an opportunity for individuals to express what is important to them and to learn what’s important to their teammates. Team norms pre-empt unforeseen situations by providing a context to proactively discuss grievances about team behavior and prevent frustrations from festering. They ultimately help establish trust among team members and optimize team performance.

At Streamline Health, when we form a scrum team, their first sprint is a “Sprint 0” during which they define their team norms. The practice may be applied more broadly to other teams to discuss and agree to norms at the beginning of an engagement. Team norms may be used as a tool to reset anti-patterns in a non-confrontational way. If people sometimes forget the norms or unintentionally violate them, having agreed to be governed by them enables team members to remind each other of the ideal behavior.

5188116378_57e6c4be1d_qUsing an analogy found in nature, team norms are the visible surface of an iceberg.  They should be documented and posted somewhere for all to see and refer to in times of conflict. There is also a large portion that lurks beneath the surface, the surface does not move without the hidden mass below.

At a macro level, according to various sources on Scrum Alliance, good team norms empower the team to deliver value at the end of the iteration. They do not define a role for individuals as the team is more important than the individual. They empower the team to take ownership for the work and each other. Good team norms also save the team valuable time, forgoing discussing the things that are regulated by them, and focusing on the work instead.

8745184787_90842c59e4_q

Norms can be at any scale, ranging from agreement about how decisions get made to basic principles about how the team communicates on a daily basis. Maybe the earliest recognized manifestation of team norms for software development, the Agile Manifesto (c. 2001), emphasizes that while there is still value in the items on the right, the items on the left are valued more. At Streamline Health the Agile Manifesto is the genesis of many team norms.

At a recent lunch and learn associates across the organization came together to discuss team norms and how they contribute to a high performance commitment  culture. We discussed specific examples of team norms that can address any aspect of the team’s functioning, such as safety, expected work hours, communication response times, or meeting attendance. Norms that address a team’s operating rhythm, communication, decision-making informed by a definition of done, and accountability can have a big impact on team cohesiveness and performance. We also discussed examples of good team norms that address individual team member’s egos, such as avoiding hidden agendas, being open minded, and admitting it when you don’t know the right answer. These are some of my own personal favorites. Team norms should not be set in stone and may evolve over time as team culture changes. Streamline teams are encouraged  to review their norms early and often and to use the sprint retrospective as an organic cadence to review and refine them.

Back to our nature analogy. If team norms are the visible surface of the iceberg, what  is  the portion that lurks below the surface? Culture. Culture is the critical mass that is strong enough to puncture holes in titanic ships. It often lies beneath the surface. Culture is what team norms require to be sustained over time and space.

In 2013, Google made this discovery: Who is on a team matters less than how the team members interact, structure their work, and view their contributions. Instead of stocking the team with individual stars, it’s more important to have empathetic team members who listen to others and can make the team greater than the sum of its parts. High-performing teams, they found, displayed five characteristics.

  1. Psychological safety

Members feel they can be vulnerable. They know their ideas and opinions will be respected and considered, even when they conflict with those of the rest of the team.

  1. Dependability

Members are confident their coworkers will deliver what they are supposed to when they are supposed to.

  1. Structure and clarity

Members understand their roles and the roles of others, and the goals of the team overall.

  1. Meaning

Members feel that what they are working on is important to them personally.

  1. Impact

Members believe what they are doing will have a positive effect on the organization and the world.

Google sales teams with the highest level of psychological safety outperformed their revenue targets, on average, by 17%. Those with the lowest psychological safety underperformed, on average, by 19%.

Another takeaway: the effectiveness of teams that were very high in dependability was actually impeded by a lot of structure in terms of role definitions and goals. By contrast, the teams with low dependability benefitted greatly from structure and clarity. That’s a useful insight for new teams, where members don’t yet know whom they can depend on.

According to their research, by far the most important team dynamic is psychological safety — the ability to be bold and take risks without worrying that your team members will judge you.

The High Performance Commitment Model posits that if we apply the elements of cross-functional, focus, purpose, psychological safety, trust, and transparency over time we may achieve a high performance commitment culture. Therefore, for a high performance commitment culture, start with team norms that enable these elements.

 

-Luis Lira, Manager of Business Analysis

Advertisements

You’ve got to have SOME standards

Well-defined, agreed upon standards are key to successful development using scrum. When you convert from waterfall to an iterative process, standards replace a lot of the requirements that you historically included in your specifications. They also govern team processes and at a more micro-level than the scrum broad rules do.

At Streamline Health, when we form a scrum team, their first sprint is a “Sprint 0” during which they form their standards. As a group they determine what their definition of done should be, including what specific standards each item they produce must adhere to.

It’s not a wide open field. We have some best practices and some required processes in place that apply to all of our scrum teams, and some even apply to our dev ops teams. For example, manual testing must use our testing tools and maintain traceability between defects and requirements. Teams must show test metrics during the sprint demo. Our management tool, Microsoft Team Foundation Server, is configured with standard queries for all teams and products so that anyone can understand what’s in the backlogs for all of our products. Teams do not have the leeway to change these.

More technical standards do vary from team to team and product to product depending on the age of the code, the predominant language, and even whether it’s web based or thick client, SaaS or premise installed. Unit test code coverage, test automation, coding standards for architecture and design, code commenting, source code structure, and database structure can all vary among our teams.

Quality of Service standards, what you may think of as non-functional requirements, are a mix of enterprise-wide and product-specific (e.g., branding is enterprise wide, but other GUI requirements are specific to the product).

In a recent lunch and learn, members of all of our scrum teams came together to discuss the state of their teams’ standards:

  • When did they last review them?
  • Do new members have to read them before getting to work?
  • Does everyone know where to find them?

The result of this frank, honest discussion was an agreement for teams to review their standards early and often, use the sprint retrospective cadence as an organic milestone to refine standards and reinstate a neglected process of “retrospective of retrospectives” wherein the scrum masters come together to share global improvement opportunities – including scheduling review of standards in the next HIP sprint.

— Luis Lira, Manager of Business Analysis