Pym-teams for business agility

How much toilet paper is too much?

What would you do when the demand for toilet paper goes through the roof? If you were a manufacturer, you would love to have the ability to increase your production and logistics capacity overnight to stock those empty supermarket shelves!

Also, what do you do when the demand for flying is too low? Once you have stood down your staff, how easy would it be to start restoring services and quality once people start flying again?

Introducing Pym-teams

In a recent article on business agility, I wrote

If the key benefit of agility is to respond to changing business needs, the ability to scale or ramp-down rapidly to balance demand and supply is a key enabler for business agility.

Size changing is a super ability from the realm of science fiction and comics. Ant-Man has it! He can change his size at will. You don’t need to be the Ant to peep through a key hole, but you definitely need to be one to pass through. You need to go sub-atomic to sneak through molecular gaps, but you might also need to be a Giant-Man once a while.

What if teams have that ability to change size in order to deal with everything thrown at them? Because it the capability of the jacket and not the man, I want to honour the fictional creator Hank Pym and call teams that possess this ability to size-shift as Pym-teams. After all, we in the agile world tend to borrow abundantly from sci-fi.

Sorry Hulk, you may not be workplace friendly with all the anger and stress issues! The word elastic seemed to be too over-used too! And I liked the metaphor of the jacket as an ability that could be acquired compared to being endowed with from birth or by accident!

The case for Pym-teams

Pym-teams are based on cross-functional teams, an agile/capability best practice where teams are resourced with all the domain skills required to deliver the task or feature at hand. Cross-functional teams are able to independently deliver with minimal external dependencies. This improves speed and quality because collaboration and feedback happens mostly within the team.

Stable teams with minimum or zero changes to team composition is another agile methodology best practice. Stability allows a team to settle in. Stability fosters better levels of collaboration – no doubt about that. The stable team pattern, in its purest sense, keeps the capability constant with the goal of maximising productivity. Value optimisation is achieved through prioritisation, where features with the best value are prioritised for delivery.

As much as it makes sense from a team point of view, organisations often find themselves in situations where changes in strategy or market conditions require capability over and above what is currently available. In such a scenario, the ability to scale delivery capability on demand dictates the ability to successfully execute organisational strategy or even capitalise on opportunities. The converse also happens when teams needed to be ramped down to meet drop in demand. If not, there would be waste and inefficiencies from idle capacity.

A definition for Pym-teams

Pym-teams are cross-functional teams that have embraced systems thinking to prioritise business agility over team stability.

They acknowledge that it is more important for the organisation to be able to vary delivery capability as required. They value business performance over team stability.

Pym-teams are an opportunity to bring what the cloud has brought into computing – scale capacity on demand. The concept is not totally new either – organisations at the provider end of the outsourcing boom definitely had their own strategies to ramp up demand as the market grew. The challenge is to sustain the efficiency and high-performance even when you scale. The challenge is to ramp down when not required and elastically stretch again for the next opportunity.

Traditionally the responsibility for the growth and ramp-down has been with program/project or portfolio management. However Pym-teams would seek to own this at the team level rather than push this to the management level.

My experience with a Pym-team

Personally this learning come out of my experience through the early days of Suncorp app delivery when I was scaling the team to deliver crucial digital APIs and mobile notification infrastructure. We had to drastically grow and even split into two teams. We also needed to be prepared to ramp down to a single team after the initial couple of releases.

I realised that my challenge was to create a team that could change size on a short notice to ensure that we always had the optimum capacity. And thanks to a great group of people, we were able to do that! We added people and skills just-in-time to be able to deliver features and components outside our usual remit and make the mobile app a reality! We also ramped down after a while and started growing soon again to meet the demand for the next business strategy cycle.

Building a Pym-team

Building a Pym-team is akin to building a few practices at the same time. This is because you may need to scale every capability or skill within your team. So, understanding the various skills required for delivery within your organisation is usually the first step to building Pym-teams.

The usual best practices in practice development including onboarding, community leadership for coaching and mentoring, competence management, knowledge management and process consistency are all valid for building Pym-teams. That’s probably a topic for another article!

——

This article was originally published at bobtheagilist.com.

Bejoy is an expert in product engineering and agile ways of working. He publishes his insights at bobtheagilist.com and is a conference speaker.