Team Practices Group/Strategy process FY2016/Decision and lessons

The Team Practices Group (TPG) was dissolved in 2017.

Summary

Over the past several months, the Team Practices Group evaluated possibly adopting one of several new strategies. However, we have decided that continuing with our existing strategy would be superior to the other options. In addition to our normal continual improvement, we will aim to better serve our customers and stakeholders by applying aspects of the potential strategies that we did not choose, and to explore how we could serve potential new stakeholders.

Background

The Team Practices Group undertook a process to consider changing the TPG’s operating strategy. After an initial aborted attempt in June 2015, we restarted in August, using the “Playing to Win” framework. This process involved many team meetings, and later meetings and interviews with stakeholders outside the team.

We identified 8 possible strategic options to address the team’s collaboratively defined strategic problem (“How do we support the organization to be effective and sustainable, while maturing to the next level and maintaining its core values?”). We narrowed those to 5, ran tests for each, and in March 2016, chose one.

Decision

We chose the strategic option titled “Status Quo”. That is, we will continue operating roughly as we have been doing for the last 2 years. That approach is summarized here: Team_Practices_Group#Overview. We will continue to work predominantly with Product and Technology teams, as opposed to actively engaging other parts of the Foundation (or movement).

We will watch for additional work or ways of working that we could take on, and will watch for and discontinue ineffective work. This process of considering other strategies has taught us a lot about ourselves and our customers, and we plan to use that new knowledge to adjust how we work.

Rationale

The Playing to Win framework requires describing strategic options, identifying barriers that might prevent them from being successful, and then running tests to determine if those barriers are surmountable. After running the first batch of tests, we decided we had enough information to choose a strategy. Several factors contributed to this decision:

1. Our existing customers expressed strong satisfaction with the status quo, and strong resistance to many of the alternatives we presented.
2. The foundation is in a rebuilding phase, where stability has value.
3. None of the alternatives seemed worth pursuing after their initial tests had failed.
4. The cost of change is high, so an alternative would have to be a clear improvement to be worth doing.
5. We felt that additional work on this strategy process wouldn’t necessarily lead to corresponding benefits.

It is worth noting that most of our tests involved teams that we already work with, so it is unsurprising that satisfied customers would prefer keeping things as they are. We are aware that there are teams within the Foundation which are not currently served by TPG, but which could benefit from our services. One of the drawbacks of our current model is that our scope is limited by our headcount and that we favor fully embedding team members in other teams rather than focussing on lighter and more engagements. We plan to talk with unserved teams, and to explore ways to scale up to serve more of the product and technology organization.

Each of the strategic possibilities had strengths and weaknesses. We hope to adapt some of the strong points, and add them to our existing model. Here are the options, and some of their drawbacks:

“Agile Advocates”

TPG has traditionally been guided by agile principles, but has remained relatively neutral as far as working with whatever would work best for teams, in their context. This option would have us advocate much more strongly for agile values and practices. Although even many agile skeptics expressed a willingness to experiment with agile, there were concerns that this approach would lead to dogmatism and a “one size fits all” mindset.

“Collaboration Bumblebees”

We would reduce the depth of our engagement with existing teams, and broaden our scope to improve inter-team coordination and communication throughout the organization. The potential loss of TPG services concerned existing teams we work with, and the problems around inter-team coordination were not universally accepted as significant enough to justify this level of focus.

“Process Swarming”

We would no longer be embedded with teams (as Scrum Masters, for example). Instead, we would take a holistic view of the organization, and would “swarm” on one process area after another, developing appropriate best practices, and spreading those throughout the org. The loss of embedded TPGers was not welcomed by our existing teams, and there were concerns about both the difficulty of finding common solutions, and the fairness of ignoring teams who might already have solved the issue being swarmed.

“Verticalization”

TPG would be disbanded, and TPGers would become direct reports within each product vertical or technology group. Existing customers didn’t object strongly, but various members of TPG had reservations about losing neutrality, flexibility, and camaraderie.