Over the years I’ve seen my share of product backlogs and while they are telling in themselves the product backlog naturally is not the only source of insight. The vibe amongst the team is yet another important one. Growth time is another. For this post I’ll paint the picture of 2 teams for you to illustrate the premise.

Let’s say team Nautilus have done everything right in the team chartering stage and are off to a great start. Everyone knows the team’s purpose and is bought into it. Things are running like clockwork. Nautilus are pushing themselves. Most of the time they hit their iteration targets. A few times they fall short. Retros have become honest, open, constructive, and real. The team is firmly in the performing stage of team development. After a brief period however the team members start to complain about being overworked. There is an impressive amount of productivity, which is coupled with an increasingly bad vibe.
Team Condor is in a similar position. The main difference is that the vibe remains positive and full of excitement; the team keeps getting better. Overall they deliver almost as much as team Nautilus, say 90%.

Over time the quality and creativity of the features created by team Nautilus are declining, while in team Condor they are growing. Team members in Nautilus are getting sick more often, and team members in Condor are staying healthy, save for the seasonality of the common cold.

As a Product Owner, which team would you prefer to work with? Is the extra 10% worth the decline in quality, creativity, happiness, and health? I’d ask which one a team member or Agile Team Coach would prefer to be with; that’s too obvious of an answer though.

What’s the difference then between Condor and Nautilus?

Let’s take a look at the product backlog first. While they both in the beginning may have favoured new features, things balanced out over time with changing ratios of investment into the 4 backlog quadrants. This is from a tool that I like to suggest to Product Owners and Agile Team Coaches/Scrum Masters. It was created by Barry Overeem and you can find it here. So there is little discernible difference between the two backlogs.

Then we would take a look at the iteration backlogs that the teams  take on. At first glance they also look the same. It’s hard to make out. Condor does seem to take on just one or two features less per iteration. Observing what goes on during the Sprint there is always activity in Condor and they seem just as “busy” as Nautilus, so what are they doing in their “spare” time?

The answer is: They Develop. Not the product, they develop themselves and/or they develop as a team.

What happens in team Condor?

Team members have time (a.k.a. Slack) to learn, share learning, connect with other people outside the team, experiment, and sometimes just take a walk in the park to unwind and sort their thoughts. They also use the time to continue to have team chartering activities beyond the team chartering stage and outside of team restarts (yes, it’s good to do that, especially activities that help to strengthen relationships and address the Who). I like to think of this time as time to grow, or growth time.

Soaring like team Condor. Why is that a good thing?

There is much rationale for how this makes Condor a team whose happiness, creativity, quality, and teamwork increases.

Firstly, happy knowledge workers are 23% more productive than unhappy ones. This was shown in an academic study in 2004. What team condor is doing also plays firmly along with Maslow’s hierarchy of needs, helping people to achieve self-actualisation. Working hard without learning and reduced social connection hinders them from furthering their pursuit of self-actualisation.

There are also a lot of benefits realised through growth time in the area of emotional needs. Strengthening relationships inside the team helps to fulfil a team member’s emotional need for sense of status and acceptance. Fostering relationships outside the team helps to fulfil team members’ emotional need for feeling part of a wider community. Occasional time spent learning by oneself also helps to fulfill a team member’s emotional need for privacy. There is much resonance with typical activities done during growth time (others call this “slack” time) and fulfilling emotional needs. You can find more information about these on the Human Givens institute’s website.

What’s in it for you then?

We often referred to a pace at which team Condor creates, encompassing product development time as well as growth time, as sustainable pace. On its own this is just a set of two words with little meaning. Hopefully the above demonstrated the value of practicing sustainable pace.

For a product you might end up with a few features less. A team that continues to develop its people and itself as as team as above, those features that are being created will be higher value though. So overall this team will generate higher business value than one that churns out 10% more features or so, is stressed and doesn’t learn much.

An organisation with teams that go about their work with continued people and team development like team Condor  will be overall more successful with higher staff retention and staff satisfaction.

Reality check

From my own experience I have now seen a low, medium, and high level of challenge to practising work the Condor way.

At Ministry of Justice Digital & Technology the teams are continuously delivering business value (meaning they fulfil user needs, and thus realising value for the business). There are communities of practice in many disciplines at various stages of the community development lifecycle. There is a weekly show & tell for sharing interesting and sometimes just fun stories. There is an pervasive, active attitude of improving, learning and sharing. Overall this is a highly fertile bed of digital product development. Here I rate the level of challenge as low. What I’m seeing is a lot of the Condor way.

Previously in the private sector I have seen the medium and high levels of challenge with enabling growth time. Actively generalising this to make the point; think about a client and a client service provider. A company in the private sector is driven by profits and having a value-based conversation along the above lines is key to overcoming a medium level of challenge. Product Owners who “think Condor” will be rewarded.

Client services organisations (e.g. creative/digital agencies) are constantly under pressure to deliver more for less and in this scenario I would rate the challenge level as high. The biggest challenge is to help the client understand during contracting that a fixed scope is in the client’s worst interest. A fixed scope upfront commitment is the biggest risk to growth time, so tackling this head on is key. We suffer from the illusion of knowledge and can be tempted to underestimate the complexity of what we sign up for. So working against this temptation and illusion in order to work out at least a gradually sequenced top-level outcome-based scope arrangement is much better than a fixed and detailed upfront scope commitment, for the user, the client, the client service provider, and the team/s. I know that this type of contracting is hard to do. One client services provider that I’d like to call out here as being as close to  working this out as I’ve seen (having worked with a dozen or so client services providers myself) is a digital product studio. Their name is ustwo. They place a high value on their people and however much the teams have on, there is always a Condor in sight.

Offer of growth time encouragement

In closing I’d like to offer 3 strands of encouragement. The three strands can combine to a strong band.

Growth time pipe-cleaner strand team bracelet
Photo by Kamala HB from an outing with the team

Product Owners, I’d like to offer encouragement to you to consider the above points and relate them to the generation of higher and better business value over a long period of time. If you are already in Condor’s jet-stream, I thank you and encourage you to share how the inclusion of growth time increased value for you with the community at large.

Agile Team Coaches/Scrum Masters, I’d like to offer encouragement to you to entertain a conversation with the Product Owner and team you work with about how the Condor way could increase different types of value for you all. I’d also like to encourage you to help the dynamic between Product Owner and team (especially in planning sessions) to ensure growth time is considered.

Team Members, I’d like to offer encouragement to you to consider the above points and to leverage them in iteration planning sessions when you’re tempted to take on more work than your gut tells you to. I know you’re ambitious and want to deliver the most with your team. Embrace the Condor way to be happier and have time to keep getting better at the great work that you do.

Go Condor.

What do you think? Go on, leave a comment please.

Thanks for reading this article!

Who in your networks might find it useful? 

Please kindly share it with them ...

About the author 

Georg Fasching

A leadership team development specialist, International Coach Federation - Professional Certified Coach, with global product management experience since 2000, employing Agile & Lean since 2010, Georg Fasching guides leadership teams to delighting their clients, fulfil their people, and improve their prosperity.

Leave a Reply

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

  1. Great post. This captures what I’ve been thinking for a long time. When we’re working in a product development team we’re developing two things:
    The product AND the team that understands and possibly even loves it. Time and dedication is needed for both sides.

    To me – working as a ScrumMaster – it’s intuitively obvious. But the people need to feel relaxed and invited to take this time and that takes a lot of signaling in the organization from senior & middle managers. The question is always lurking: Can we pay for this fluffy stuff?

    Looking at it from a POs perspective – as you do in the post – is a great link to business value. I would add looking at it from an organizational context. I think here is were it _really_ reveals some value. Just consider: How much money are we spending on legacy – i.e. software developed in some previously abandoned team-context that nobody owns or loves?

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hone your Product, Team, and Leadership Craft with 

free videos & Live Streams.