Tag: team

New Leaders Series – Part 1: Shift in Stance

~ Caroline Sauve ~ Leave a comment

After years of hard work as a software developer and high performing team member, you’ve found yourself facing a whole new set of challenges. You are a leader (architect, team lead, scrum master, mentor, manager) on your team.

Looking back, everything that you’ve done along the way has supported you to get to this point. You’ve never backed down from challenge and have embraced the uncertainty of solving problems in code. You love the focus that comes with being able to tackle these problems with confidence. You’ve enjoyed the satisfaction that comes each and every time you’ve transformed an idea into a solution.

However, all the skills you worked hard to hone in yourself reflect your stance as “expert practitioner” and while expert practitioner skills are foundational to your role, these are not the skills that you will need to grow in order to succeed as a leader.

And no one told you this. When you got the promotion, no doubt your manager told you of the confidence he had in your abilities; however, your leadership up to this point has been fundamentally built on your ability to hone your craft expertly.

Your new role requires a shift in stance. You are now responsible for supporting others to do what you did so well. There is a hidden assumption there; indeed, a fundamental change in how you perceive your value on the team.

Your work is less “about you” and more “about them”.

This shift from “me” to “we” isn’t a small change in thinking and being. It’s one that I’ve seen many new leaders struggle with as they are drawn instinctually back to the joy derived in expressing their craft…. the satisfaction and joy they experienced in being “the guy who solves the problems” rather than “the guy who enables others to solve problems”.

In this series, I plan to explore some of the new skills that young leaders might consider as part of their new practice – assisting them to make this shift from “me” to “we”. It is my sincere hope that my own lessons (sometimes learned the hard way) can be of service to others beginning on this journey.

Great Teams

~ Caroline Sauve ~ Leave a comment

Having recently gone through a round of recruitment at my work… I am surprised by how many people out there have yet to fully appreciate or experience the benefits of working on a great team.

To begin, let’s be clear… a team (by definition) is a group of individuals who work towards a common goal. From this point of view, most people have experienced this particular circumstance at some point in their life.

However, a great team fully appreciates the fact that they depend on each other in order to achieve this goal. They understand that they cannot achieve the goal alone and nurture the connections required to support the inherent dependency that comes with working on a team.

They understand their role and responsibilities. They understand the role and responsibilities of their team mates. This means that they don’t “throw problems over the wall” at their team mates. Rather they are proactive about sharing what they are up to, especially if this will impact their team mates. In return, they are empathetic and interested in what’s going on with their team mates. Respecting each other’s craft, they trust each other in a healthy and balanced fashion. Being open to constructive conflict in order to ensure that the team is indeed driving towards their common goal.

While this may sound like an idealized situation, I can tell you first hand that I have been privileged and lucky to work on great teams. The Agile coaching community is my extended team (my tribe!) who has helped me stay steady over the years in the belief that not only are great team members possible… they are worthwhile seeking out.

So if you are looking for work and we happen to meet in an interview… don’t be surprised when I ask about your most recent experience with a great team.

Why We Play…

~ Caroline Sauve ~ Leave a comment

It’s not uncommon for Agile coaches to engage their teams in games in order to experiment with new ideas. If you have ever participated in such activities, it’s likely that you have encountered individuals who dislike the idea of anything work related being transformed into a “game”.

So… why do we play?

We play to prototype and experiment with new ways of thinking and behaving. We play to open our minds to possibilities. Indeed, engaging in an activity “as play” actually helps us to explore many new ideas quickly and effectively as a team.

In short, playing brings us to a “personal edge” in a friendly and joyful way.

That being said, for some of us, the edge is simply to engage in play at all… and that’s an edge that I’m learning to see and understand better. In these situations, I would invite the individual to simply try the game and then to reflect on why we play… rather than focus on whatever other agenda I’m hoping to bring to the table by engaging in a game.

After all, when we play, we explore many ideas at the same time… and one of those ideas can certainly be “why do we play?”

Powerful Questions

~ Caroline Sauve ~ Leave a comment

There are many things that I’ve learned since becoming a mom… but there is nothing more powerful for me to date than learning to see the world through very young eyes.

The beauty behind a child’s approach to the world is that it is so fundamentally based in observation rather than judgement. When my daughter asks questions, she seeks to better understand what she observes. In so doing, she rarely asks “why?” but is more focused on “what?” in her line of inquiry.

From this, I’ve realized that “what?” is actually a very powerful way to question the world. Consider these examples for a moment…

Rather than asking: “Why is that?” …ask instead: “What does that mean?”

Rather than asking: “Why is she (or he) like that?” …ask instead: “What happened to her (or him)?”

Changing your stance from “Why?” to “What?” opens up your line of inquiry. You automatically move away from a place of judgement to a place of understanding. Looking at the world through the eyes of a child isn’t for every occasion… but if you are aspiring to understand and accept, it’s not a bad place to start.

Creating a Culture of Learning

~ Caroline Sauve ~ Leave a comment

“I know one thing: that I know nothing.” – Socrates

For Agile teams to meaningfully embrace change, they should also embrace a culture of learning. This idea is not unique to Agile, Lean also explicitly makes mention to the importance of learning by making it one of its’ principles.

So what can we do to create a culture of learning on our teams?

I would suggest that while it’s important to encourage learning and to create learning opportunities on the team, doing so may not be enough to truly embrace a culture of learning.

For this to happen, we first must first create the capacity for learning on the team. This means honouring the time and energy that it takes to set aside our own agendas and then divert this time and energy to learning. It also means allowing ourselves to acknowledge and dare to speak three simple words: “I don’t know.”  This can be tricky because we don’t often reward or encourage a culture of “I don’t know” in our work and personal lives. It’s unlikely that Socrates would have climbed high up the corporate ladder with his approach of “I know nothing”.

So if you are seeking to create a culture of learning on your team consider…

…do you ever hear team mates asking for help?

…is it ok for the team to acknowledge what they don’t know?

…do we honour learning on the team in the same way we do “solutions” and “results”?

The key here is to be able to accept what we don’t know and then move on to “what do we need to do to learn?” while being comfortable with the reality that we may never have perfect answers.  However, by not acknowledging what we don’t know, we risk buying into answers that don’t deliver value.

Agile for UXers

~ Caroline Sauve ~ 3 Comments

This weekend I was privileged to attend Canada’s largest non-profit UX conference, UXcamp in Ottawa. Quite a few themes emerged during the conference, but two resonated deeply with me… process and team.

Several presenters either directly or indirectly talked about the importance of applying UX principles to internal processes and teams. In addition to this, on more than one occasion, “big A agile” was explicitly mentioned and quickly dismissed… it seemed to me (perception alert!!) that many presenters wanted to distance their ideas from being in any way “big A agile”.

So I wanted to take a moment to offer up a quick overview of Agile for curious UXers out there. To begin with, I want to share how deeply committed I am to the idea that we (UXers and Agilists) are focused on the same goal of delivering high quality valuable solutions to our users.

First thing that I would like to share is that the heart of Agile isn’t process. Agile came to life with its first incarnation in XP or Extreme Programming… and if you dig a little into XP, you’ll come face-to-face with its values: feedback, communication, simplicity, courage and respect.

The next thing that I would draw attention to is the Agile Manifesto itself. Several leaders in the Agile community came together in order to define Agile’s four values: “Individuals and Interactions”, “Customer Collaboration”, “Working Software” and “Responding to Change”. These values apply to the software solution as much as the team itself. In support of this, the Manifesto also describes 12 principles that help define “how to be Agile”. The majority of these principles are focused on team.

Now, this isn’t to say that there aren’t plenty of “practices and implementations” out there calling themselves “Agile”… but I would strongly question any practice that calls itself Agile that does not honour the values and principles of the Agile Manifesto or the origins of Agile in XP values. As UXers, you are in a unique position to see this on your teams… I would encourage you to help your “big A agile” teams reconnect with their core values.

Compassion

~ Caroline Sauve ~ Leave a comment

Lately, I’ve been thinking a good deal about how Agile teams are able to deliver value.  I believe that a common trait shared by teams who skillfully deliver value is a shared vision centered around compassion for their users.

Teams who consistently can design, implement and test to deliver frequent and highly valuable products to their customers are connected to their users. Not just in the sense that they are able to interact and communicate with them, but in the sense that they clearly understand the user’s problems.

Understanding their problems means that everyone on the team…

…can clearly articulate the problem their work is attempting to solve. The whole team understands the rationale behind the solution they are implementing.
…understands the value of solving this problem. They understand why they are solving one problem over another.
…can identify with this problem and is empowered to do something about it. The team has a “two brains are better than one” approach to problem solving in general.

These compassionate teams understand that everyone on the team is working hard to solve these important problems for their users. It is this shared compassion that gives their work a sense of purpose and urgency. It is the fuel that keeps them focused every day.

True Leaders of Change

~ Caroline Sauve ~ Leave a comment

“Who’s the more foolish, the fool or the fool who follows him?” – Obi-Wan

One of the strengths of any Agile team is how easily the team can collectively embrace change. Conversely, this can be also our biggest challenge to remaining Agile.

In order to truly collectively embrace change, the whole team needs to opt-in.  This can be a rather daunting task for Agile leaders out there to facilitate. But there is something delightfully simple that I would like for us to consider.  For this, I’d like to invite you to watch this brief talk from Derek Sivers.

Agile coaches out there will no doubt identify with being the “lone nut”. I certainly do. But until I had seen Derek’s talk, I don’t think that I had truly appreciated the importance of that “first follower”. These early adopters are the people who..

…acknowledge when you are making sense. They are engaged listeners.

…raise concerns when you aren’t making sense. They are competent thinkers and have the respect and courage to speak up when they feel it will add value.

…try your ideas and add to them. They are true collaborators.

As Derek points out in the video, these first followers make room for change and transformation in others. They make change possible for the rest of the team. Sadly, as Agile leaders it’s all too easy for us to focus on those who won’t join in the movement… in fact, we can spend a lot of energy trying to support and help those who may never “get up and dance”. So much so, that we risk taking for granted those first followers who do have the courage to meaningfully lead change on the team.

After all, it’s worthwhile remembering, Obi-Wan wasn’t the real hero of the story.

Standup Is About Commitment, Not About “Giving Status” – The Story Continues…

~ Caroline Sauve ~ 3 Comments

In honour of Coaching Agile Teams (@CoachAgileTeams) generous cross post of my tiny blog, I thought that it would be worth putting together a follow-up to the original post Standup Is About Commitment, Not About “Giving Status”.

As you can well imagine, the story for my team didn’t end with reformulating the Standup as a commitment based meeting.  Here’s a sampling of some of some changes we’ve made to this meeting that have helped to keep us accountable…

1. We renamed “Standup” to “Team Commitment Checkpoint”.  Which sounds trivial, but it helped us to reconnect with the idea of commitment on a daily basis.

2. We mixed up the order of “who speaks next” and even allowed for “anyone to speak first”.  Previously, we would stand in a circle and take turns. Starting with the person next to the “highest ranking leader” and ending with this “highest ranking leader”. We used different techniques for this… from tossing a ball around to clapping and pointing to calling out the next person’s name. At first the team felt a bit self conscious and silly doing this but something interesting emerged from this simple self-organizing technique. It helped to create a shift in focus. One day, people stopped “talking to the leader” and started “talking to each other”.

3. We challenged our engaged listening skills with an exercise. First we would go through each person’s commitment(s) for the day, then we would go through the whole process again; in the same order, only this time we would verbalize the commitment of the person who spoke before us. Initially this created some stress on the team but, as we worked through the exercise together, we learned to relax and work together to remember what everyone committed to for the day.

4. We are currently in the process of connecting with what makes a “good commitment” and are aiming to develop a few protocol checks to ensure that we are all making “good commitments” on a daily basis. Maybe there’s a future blog post in that… stay tuned.

One more thing…  every day during Team Commitment Checkpoint (or TCC as we have come to call it), I make a point of sharing an “Agile Moment” with the team.  Often these are small quotes or “aha-moments” that I have had as I connect with the Agile community around the world on a daily basis.

Initially I was pleasantly surprised to note that the team seemed to appreciate these small gifts from the world of Agile… getting a few nods and the odd: “Nice”.  As time went on, I even got a few questions and the occasional: “I’d like to talk about that some more after this meeting”. Then, one day, I received the biggest gift of all from a team mate: “You know, I’m trying to put the Agile Moment you gave yesterday into practice…”

And so in turn, to the Agile community out there around the world and to my wonderful fellow team mates…   thank you for being such a source of inspiration and for helping to put these Agile moments into practice 🙂

A Retro on Retros

~ Caroline Sauve ~ 1 Comment

It seems clear to me that a lot of us out there don’t like retrospectives.  Ok… maybe you are an Agilist and you actually love them (me too)… but I feel pretty safe in saying that this feeling is not shared by all the members of your team.

I’ve been giving this a lot of thought lately and it seems to me that this “not liking” aspect can be broken down into two categories.

Retrospectives make me uncomfortable.  Examples of this would include: “I have trouble speaking up in a group setting.”; “I  have difficulty seeing different points of view especially when they are at odds with my own.”; “I don’t want to create conflict or hurt someone’s feelings.”

Retrospectives are unproductive.  Examples of this would include: “I prefer to focus on my core work than retrospect. That’s where I feel most productive.”; “What we talk about at the retro is less important than what I’m working on right now.”; “We talk and talk, but we don’t actually do anything.”

I would say that most participants in a retrospective will identify to some degree with the “uncomfortable” and / or “unproductive” views of a retrospective.  Rather than viewing this as a problem to solve, I would suggest that these “dislikes” are an opportunity for the team to explore with curiosity.  So consider…

Making retrospectives comfortable. Consider on a personal and team level: “What needs to happen so that everyone can engage with the activity?  What are different ways that we can share ideas, sample different points of view, and be at ease with different attitudes on the team?”

Making retrospectives productive. Consider on a personal and team level: “What needs to happen to make these gatherings productive? Are we talking about the most important problem impacting the team’s ability to deliver value?  If not, then what will it take for us to do that? How do we hold ourselves accountable to our decisions and actions coming out of the retrospective?”

If the retrospective is generating some dislike on your team, then perhaps the time has come to have a Retro on Retros?