Agile and highly successful teams

If you have ever been fortunate enough to be a part of a high performing team, then the recent findings published by Google (re:Work – Five Keys to a Successful Google Team) on what makes teams successful should resonate.

I have had the pleasure in working in the types of environments described in Google’s article twice in my career, once in the early 2000’s when I led an Agile adoption and currently at Intelliware.  In both instances, I have been working in the field of software development, and in both cases, Agile methodologies were used to deliver software. Coincidence?  I think not; Agile methods embrace and embody the findings of Google’s research.

When you get Agile right, you inherently practice the traits identified as key to successful teams.

Google interviewed 200+ employees and looked at 250 attributes of 180+ active teams.  The findings showed that “Who is on a team matters less than how the team members interact, structure their work, and view their contributions.”

The five characteristics of successful teams as identified by Google are depicted in the graphic on the left.  Let’s examine how these findings align to Agile.

Psychological Safety involves creating an environment that tolerates risk and allows people to be vulnerable in front of each other.  Safety underpins many of the values, principles and practices of Agile. A few examples are:

• Individuals and interactions over processes and tools is the first value stated in the Agile Manifesto, and it recognizes that people, their contributions and actions, and the interactions of the team, are important to the success or failure of product delivery.A safe environment is fundamental to providing an environment that allows individuals to contribute ideas, to take risks and to try things outside of established norms.  Safety allows a person to ask for help or to admit that they may not have the knowledge or capability to complete a task. Safety allows team members to collectively discuss ideas, brainstorm or implement strategies to complete their work. Safety gives individuals and teams air cover to speak out and to interact in productive ways without fear of exposing themselves as weak or lacking.

• Collective Ownership affords each team member the right and responsibility to speak up if they feel that there is an issue that needs to be addressed or to ask questions and/or challenge the team, in an environment that is respectful and allows them to be heard.

• Transparency, Reflection and Adjustment means that information is visible, not for the purposes of blame or shame, but to allow inspection and adaptation in an honest and open forum.

In order to nurture environments that are psychologically safe, Google teams have adopted new norms– like kicking off team meetings by sharing a risk taken in the previous week. An interesting addition to Agile retrospectives might be to discuss risks taken during the previous iteration and the outcomes and lessons learned.  Similarly, in sprint planning, teams could ask themselves what the riskiest part of the upcoming iteration is and what strategies they are going to employ to reduce the risk.  I would challenge all teams to incorporate open and honest discussions about risk in all aspects of project delivery.

Dependability

Asking team members to deliver, to get things done on time and to meet the expectation for quality, is core to Agile.

Agile methods are built on incremental delivery, usually with a defined iteration or sprint at the end of which a potentially shippable product increment is demonstrated and delivered.  This is no accident, but rather the result of careful planning prior to the start of the iteration and commitment by team members to complete the agreed upon work, and ensure that the requirements are met by the end of the iteration.

The Agile principle of satisfying the customer through early and continuous delivery of valuable software combined with Agile engineering practices such as automated testing, continuous integration, and automated deployments help to ensure that the working software that is delivered at the end of the iteration delivers the business value desired by the customer, and that the software actually works. That is the customer representative or Product Owner can depend on the iteration release to the point where they could decide to put it into production.

Structure and Clarity

XP developed the Developer and Customer Bill of Rights to clarify and set expectations of both the customer and the developer and to provide clarity on who is responsible for what. The bill sets out a structure and provides clarity on how Agile teams work together to achieve the project goals.

Agile projects employs a number of strategies and practices that provide structure in clarity, including:

• Release Goals and Themes provide anchor points for the intention of the release.  I have seen release goals and themes effective in keeping teams on track when considering the priority of stories.  For example, consider if your release theme was “Delight the customer”. Resulting themes might look like “Make tasks easier and faster to complete”; “Introduce the ability for the user to…”; and; “Speed up the performance of the Report Generator”.  With this in mind the project team has both a structure for the release (things that delight the customer) and clarity on the specific things that will delight the customer.  Stories that don’t fit the themes have a lower priority for the release.

• Project and Sprint Backlog is an inventory of all of the requirements (as epics and stories) for the project.  The project backlog is used to select particular stories (increments of a requirement) that will be the focus of an iteration.  The sprint backlog is the basis for work in the iteration.  Each iteration, the product owners select the backlog that is the focus of the iteration, based on the team’s capacity.

• Velocity is a measure of how much work the team can complete in a sprint.  This measure is based on work that gets completed and not what was planned or what is partially complete.  It is actively measured, provides clarity on how much a team can actually do, and provides a structured way for planning the amount of work that should be committed to in the next sprint.

• Visible status which provides information on the status of the project, release, or tasks at any point in the project.  Information is available to the team, but also to outside observers.  Visible status keeps information out in the open for all.

• Daily Standups provide clarity by sharing what has been accomplished, what will be undertaken today and what challenges or blockers need to be addressed.

Meaning and Impact

When I think about the really great Agile teams that I have been a part of, or had the pleasure of observing, one of the things that stands out is that they all had a very strong vision and purpose for the work that they were doing.  This was often fostered by a strong Product Owner/Customer Representative who was able to paint a picture of a better future for users, providing the team with goals to rally around and work toward.

Combine this with environments where Agile teams are truly empowered and trusted and what results are team members who understand that what they bring to the team has meaning and importance. In these environments, there is a contract between management and the team – management will step back and trust the team to deliver while providing direction and support, and teams that will implement their craft at a high degree of competency and excellence and who will raise issues and risks to management.  Understanding and achieving this contract results in quality products that delight and provide value to an end user.