How to define purpose for an Agile team? A practical guide to defining purpose and aligning with your organization’s goals

As a Scrum Master, we are often worried about what goes on with the teams we work with.

We care about the people. We help the team communicate, collaborate so that they can achieve the team’s goals.

However, we often don’t work on a larger goal: the goal of the organization that needs that team. Organizations exist to fulfill certain goals or aspirations. The teams we work with are part of that organization and have a role to play in helping the organization achieve its goals.

When was the last time you had a retrospective or a conversation with your team members about the goals of the organization, and how the team goals help (or not) with the organization’s goals?

Questions to help the team align with the organization

Here’s a set of questions you can ask the team members in that retrospective:

  • What is the most important goal for my organization? Brainstorm with the team, and then use dot-voting to select the goal that the team thinks is most important
  • Who should we review the goal we just prioritized to get feedback? Agree on 2 to 3 stakeholders you will present the outcome of the previous question so that you can gather feedback, and potentially change the goal the team should align with.

In the next retrospective, review the result of the feedback you collected. Help the team craft a clear goal that is aligned with the goal of the organization. I recommend you follow these steps every 6 months at least, with the aim of having a team/organization goal review every 3 months later on.

How often do you review the team goals and compare those with the goals of the organization?

One thought on “How to define purpose for an Agile team? A practical guide to defining purpose and aligning with your organization’s goals

  1. Please consider what the Scrum Guide says about scrum teams.
    I’m willing to bet that most orgs will not recognize these statements to be true of their “scrum teams” — and some may confuse the “official rules of scrum” with sedition. But there is an official definition, and here it is:

    * The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
    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.
    Development Teams have the following characteristics:
    * They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
    * Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
    * Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
    * Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
    * Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

    A bit more exploration here:
    http://agileotter.blogspot.com/2017/07/there-is-no-such-thing-as-scrum-team.html

Leave a Reply

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