How can teams work with different functional mindsets, yet operate as a unified team?

How can teams work with different functional mindsets, yet operate as a unified team?

on Sep 29, 15 • by Christine Bottagaro • with No Comments

A unified team is critical in helping navigate the sometimes rocky waters to deliver great products. Read on to learn how to set your team up for success...

Home » Agile Development » How can teams work with different functional mindsets, yet operate as a unified team?

(Read part one and part two of this Agile series.)

We know the best teams, the ones with the highest velocity and that produce the fewest errors, are persistent teams.

Harvard Business Review studied the impact of persistent teams with these results:

“A 50 percent increase in team familiarity was followed by a 19 percent decrease in defects and
a 30 percent decrease in deviations from budget.”

These teams don’t change from week to week, or from project to project. They work together everyday, navigating the sometimes rocky waters of team dynamics to deliver great products.

So, if we have persistent teams, balancing the individual viewpoints to act as a unified team becomes the focus. Optimal Agile teams are 7 +/- 2, and comprised of a ScrumMaster, product owner, and developers and testers. Each, while carrying his/her own perspective, contributes uniquely to the team.

Quick definitions help to define these roles:

• Product owner owns and prioritizes the backlog

• ScrumMaster orchestrates team efforts and removes impediments

• Developers and testers make up the majority of the team, writing and testing the code

Agile works best when all voices are considered throughout the process: From ideation to completed stories. Throughout each sprint, the team defines and grooms the backlog items, carrying input from the various team member roles and perspectives. Each team member contributes to the user stories, tasks and acceptance criteria. While they act as a unified team, members absolutely have their say in what and how the feature or functionality is designed and built.

So when secure coding becomes part of the team’s purview, possibly brought to light by a dedicated team member, the elements become part of the user story and definition of done. No second-class citizenship as it is part of the development process, including testing. This also allows for the critical separation of duties principle outlined in our Agile + security webinar.

This is really where Agile shines, as every task, user story, and epic reflect each person’s insights and contributions. Building a common understanding of the expectation for each role, a thorough knowledge of Agile practices, and a dedication to the process itself will yield results that highlight each person’s contribution and lead to the ultimate (secure) success of the release.

Code confidence

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top