Teams on Noetic Nought

Glue Highlight Reels

Wed, 06 Feb 2019 14:33:00 +0530

As a leader on my Ultimate team, I spend a lot of time talking to my team mates. I get to hear out their complaints, their joys and everything in between. All these conversations got me thinking about what makes someone feel like an integral part of the team, where they are making a meaningful contribution.

Metrics to measure contribution

How do we measure our contributions to the team. What do we look at, to tell ourselves and others, whether we have made a contribution or not? I’m still trying to make sense of this, but here are a few metrics I found.

Highlight or Debacle reels

A lot of us tend to remember things as highlight or debacle reels - we make stories out of these events. If you got that layout grab or D, you tend to remember it and that leaves you with a feeling of satisfaction. If you’ve more highlights to remember than the number of debacles, you feel like you made a positive contribution.

But, I think games are not as “eventful” as we think [citation needed!] – especially when a team is playing good Ultimate. When everyone is making good decisions and executing them well, the game is quite uneventful. The credit for the success is distributed over the team, rather than one or two individuals. Are we capable of identifying this, acknowledging it as a meaningful personal contribution?

Tiredness

When we are done with a day’s play, we only have a few moments stuck in our memory. What remains as a physical manifestation is how tired we are, physically and mentally. A lot of us tend to use this metric, probably even subconsciously.

But, with a big enough squad that is being rotated well, I’m not sure this is a good metric.

MVP awards

At the end of every game, teams have a spirit circle where they discuss each others’ play, and pick a player in the opposition who made a difference to the game - Most Valuable Player. Being identified the MVP is definitely one of the easiest things that is used as a metric for contribution. Only one person gets it in a game, and often, the same person gets it in a few matches over the course of a tournament.

Sure, the MVP played well, but what about the dozen others? If you weren’t the best player, doesn’t mean you didn’t make a difference. Would not being identified by the opposition make you forget those contributions? Is there something the team can do to help recognize and identify them?

Being Challenged

When a game was very challenging, win or loss, people tend to feel happy and satisfied about it.

Just being challenged to their limits seems to make people feel like they have contributed. Or may be just makes them forget about asking this question.

Contributing in other ways

If I’m not having a good day, or I’m injured, I don’t mind filling water bottles and taking it easy. If I’ve been able to alert someone from the sideline and they make a difference, that’s a contribution I’m making.

Better metrics

Stats

Stats might help in a small way. For instance, just using a rotating scheme for calling lines, a lot of the not-enough game time problems seemed to go away. Just being able to assure people that there’s a system in place to ensure they get enough game time, took their minds away from it.

The usual kinds of stats - scores, assists, drops, etc. - might actually only end-up reinforcing the outlook of highlight and debacle reels. But, it may help with triggering some faded memories, which might alter the story we make up from the events recorded.

I wonder, though, if there can be other kinds of metrics that might help bring out some of the “grind” aspects of the game, rather than events. These stats will be harder to collect, but would there be a way to reward someone on how well they made space for the next cutter, or how they shutdown the person they were defending and took them out of the game?

Culture

I am beginning to think the problem is primarily cultural. In a world where we care so much about the number of likes and retweets, I think it’s just hard to remember the “grind”.

Sarah Griffith shared an interesting idea that she calls Glue players - players who just do the basics right, and aren’t necessarily involved in spectacles like a layout D or a super difficult throw.

Matty’s shout outs are for glue plays - reliable fill cuts for big yards, or somebody who committed to fronting their matchup because that was the game plan even though it’s scary as heck to give that cutter the chance to go deep on you.

And anyone who has ever played for Matty knows that these shout outs are a coveted thing, because you know that what you’ve done was selfless and helped the team succeed, and that’s an honor.

Matty Tsang is a great coach who has some revolutionary ideas on how to play and coach Ultimate. I’m not surprised the idea of glue plays goes back to him.

But, as a team without a non-playing coach, I wonder how to bring about this culture of identifying and encouraging glue players. May be having a handful of players who make it their job to do this for a few weeks or months, will set the ball rolling.

Sarah has some advice on how to go about doing this in her article.

When you’re holding tryouts for your team, look for who is facilitating scores even if they’re not always catching them. Look for who’s eliminating their person from the offense with great positioning rather than bidding all over the place on D. Look for who shows up, and who you can count on. And then let other people know. Celebrate it. Glue playing is contagious - make people aware of when it’s happening by calling it out and focusing on it, instead of the glory plays.

The idea of “Glue highlights” replacing the (figurative) highlight reels seems like a very promising idea. I’d like to give this a shot, as a team!

Thanks to Tariq, Tejaa and Shantanu for being excited reading drafts of this post, and encouraging me to publish it.

Software development practices for sports teams

Sun, 23 Sep 2018 11:31:00 +0530

Motivation

A few weeks ago, I came across a talk on Mob programming — a technique for working on a software project as a team, that was accidentally discovered by a team trying to figure out how to work well together. The speaker lets us in on how they stumbled on it, and how they fine-tuned it to make it more effective while being relaxed and enjoyable.

A few days before that, I shared a post on “getting feedback (as a software developer)” with my Ultimate Frisbee team-mates and it seemed to resonate with them. I’m often looking at things happening in my sports team from a software guy’s perspective, since I spend a lot of time being the software guy. But, I rarely, if ever, directly share these thoughts and ideas with my team-mates.

But, the mob programming talk inspired me to make a conscious effort to look for software development patterns that could be adopted by our (sports) team.

Most players on our team have been playing Ultimate for a while now (2-5 years). So, we have more problems due to miscommunication and everyone not being on the same page, than we have due to lack of skills or knowledge. When someone on the team does not understand the plan, the whole plan goes for a toss.

How do we make sure that everyone understands what the team is trying to do and is able to contribute their bit to the team’s plans and success? How do we make playing with each other as enjoyable as it can be?

“The object isn’t to make art, it’s to be in that wonderful state which makes art inevitable.” — Robert Henri

Some ideas for adoption

Here are some ideas that, I think, could be adopted by our team. Some of these are things that teams, including ours, do in some shape or form. But, identifying and naming would make it easier for people to talk about them and develop a common understanding of why and how to do them.

Ubiquitous Language

Eric Evans, in his book Domain Driven Design, talks about building a Ubiquitous language in the team. It grows as the team’s understanding of the problem grows, and helps the team communicate clearly throughout the development cycle.

Our team plays a lot of zone defense, and it usually works well for us But, it wasn’t working particularly well, during one of the tournaments last year. Luckily, we had Moby playing with us, and he asked us some probing questions around the objective of the play and the roles of each of the players. With just a short chat and a few small adjustments, the zone became way more effective. Essentially, we built a common understanding of the objective of the defense and brought everyone onto the same page.

Ultimate teams use a lot of lingo – a lot. New players just pick it up by osmosis, at practice, from the senior folks. This works most of the time, except when it doesn’t. Each person on the team has a slightly different understanding of what a term means, and the difference is sometimes big enough to cause a plan to fail due to miscommunication. Spending time building a common understanding would make the team communicate and operate more effectively. Practicing game scenarios is essentially a way of doing this, but it would be worth thinking about and discussing the terms and the language being used.

Off-field lingo should also be clarified using a similar process – for instance, what does “good sideline support” mean? What does giving or not giving “feedback on the field” mean?

Sprints

Agile development recommends continuous development of software. Often software teams use 2-4 week development cycles, called sprints. For each sprint, the team sets itself a goal, and the whole team prioritizes tasks and makes decisions in-line with this goal.

Sports teams would also benefit from sprints – short and focused practice cycles, where everyone on the team is aware of the team’s goal. This would make it much easier for players to help each other out. Also, players can align their individual goals with the team goal, making practices much more effective.

Retrospectives

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. — The Agile Manifesto

Most Ultimate teams do some kind of post-practice retrospectives, though, they don’t call it that. These retrospectives are a discussion of the good, bad and the ugly. Usually, no conscious decisions are made about what practices are working well for the team, and what should be taken forward to upcoming ones.

Slightly longer term retrospectives would be quite useful too. If a team adopts the idea of sprints, each new sprint should start with a retrospective of the last one and planning for the next.

A retrospective’s participants are expected to follow the prime directive.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. — Norm Kerth, Project Retrospectives: A Handbook for Team Review

Internalising this would be really helpful especially during post-tournament retrospectives, where emotions can run high – it would keep the discussion positive and focused on identifying problems and finding solutions, rather than spiraling into blame games, defensive arguments, etc.

Daily Stand-ups

Agile teams gather each day at the start of the work-day, to let each know about the progress of the work-items. The team tries to help each other get rid of the impediments to progress.

Ultimate teams could also benefit operating in this style – everyone shares with each other what they are working on, and the problems in their learning. This would make it easier for others to look out for things to help with. Team-mates would limit themselves to giving feedback to the thing that a player is working on.

Players setting themselves a small number of clear focus points would also force them to consciously think about and work on their game more effectively.

Face-to-face communication

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. — The Agile Manifesto

As our team has grown larger over the years, more and more communication has moved to the WhatsApp group. Keeping everyone informed via face-to-face communication, at this team size needs a lot of co-ordination and planning, and the time at practice is considered to be too precious to be spent talking and not practicing.

But, clearly WhatsApp doesn’t seem like the best medium to have discussions. Discussions rarely, if ever, happen on our groups. It often just seems to be information dissemination. Using a better communication tool could mitigate a few of these problems, but face-to-face discussions have other benefits. They bring about a greater sense of belonging to the team and increase buy-in into the team’s plans.

Unit tests vs. Integration tests

Practice games are helpful to gauge if a team is playing well together and if its plans are working. This seems analogous to integration tests — checking that we have functional software, end-to-end.

But, in the early stages of development, it’s common to write unit-tests – tests to ensure that each of the individual components works well in isolation. An analogous thing would be to have individual evaluations to help players identify weak areas, and to measure progress in those areas. It would also prevent players from slipping on important “indicators”.

Other ideas to think about

Some ideas that I find interesting, but don’t yet know if and how they can be adopted by sports teams are below.

Mob programming

In a mob programming session, everyone on the team is working on the same computer, in the same room, at the same time. This seems tremendously ineffective at the face of it, but turns out to be a good way to produce high quality software, quickly.

Hammock driven development

Bugs are incredibly expensive to be found and fixed in production software. They are cheaper to fix in the development phase. But, the design phase is the best place to fix them.

Rich Hickey recommends feeding a lot of information about the problem you are trying to solve to your waking mind, so that your background mind can feed off of it while you are asleep, and make useful connections.

Conclusion

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. — The Agile manifesto

This sounds exactly like what players in our team need too. The captains and the mentors in the team should work towards providing the environment and the support everyone on the team needs, and trust them to do the job.

Thanks Meghana Iyer, Ravitheja Tetali, Shantanu Choudhary, Vandith PSR, Varun Rangarajan and Vivek Krishnaswamy for reading drafts of this post and giving helpful suggestions.