Seeking Feedback: Value of the Agile Coach

January 2, 2014January 2, 2014 ~ Caroline Sauve ~ 3 Comments

Recently, I have been deconstructing with curiosity my role as an Agile Coach.

Let me begin by saying how committed I am personally and professionally to the deeper understanding of Agile and Lean. Putting these values and principles into practice over the past few years has given my work meaning in so many ways.

That being said, I have failed to appreciate the importance of how the organization views these skills…

I believe that a good Agile coach acts almost imperceptibly. Building courage, simplicity, communication, feedback and respect… all that a coach does in order to build a stronger and more effective team might not be obvious. Indeed, as coaches, we can become so focused on the success of the team that we may risk neglecting looking after our interests within the organization.

That is to say, there may not be clear evidence of the coach’s value to the organization. So while executives may recognize the improved effectiveness of the team, they mistakenly begin to assume that the coach’s skills have been captured by the team itself. They then conclude that this process can be reproduced (rubber stamp like) to other teams. To borrow Dave Snowden’s analogy… they believe that “having a good recipe” is the same as “having a good chef”.

As practitioners of evidence based learning and progress, how do Agile coaches provide evidence of their value to an organization? Is this even skillful or necessary to do so? I look forward, dear readers, to your feedback…

2013 Retrospective

December 31, 2013January 2, 2014 ~ Caroline Sauve ~ 1 Comment

At this time of year, it’s worthwhile taking stock of our lives… to do a retrospective of sorts. To collect both accomplishments and gratitudes for the year….

Tip: Skip past the bullet points if you are quickly seeking the punchline.

I received generous support and guidance from @eegrove who helped me to define the role of an Agile coach within the context of my work at Corel.
I spoke about UX from a developer’s point of view at NSNorth. I also met and reconnected some dedicated iOS / Mac developers and had a few pints with some brilliant people.
I joined an excellent group of volunteer organizers at Agile Ottawa and co-hosted a Fail Faire event with @BillyGarnet and@simbourk.
I attended Agile Coach Camp Canada in Toronto, where I gave a lightning talk on Agile Teaching and proposed and lead an Agile 101 session.
I completed Coaching Agile Teams training with @lyssaadkins and @mspayd. This class helped me to better understand, take ownership have confidence in my skills and abilities as an Agile Coach and, looking back on it, was a life changing experience for me.
I started to blog and am proud to say that I’ve put together 18 posts that I feel add value to the Agile community in their own small way.
I created and gave a presentation that summarizes 6 different software development methodologies in under one hour using nothing more than a marker and a whiteboard as a visual aid. I’m happy to say that the feedback from this presentation was very positive.
I helped my former team at Corel to complete a significant re-architecture of a large legacy code base. I also created a spirit of collaboration, sharing and trust on the team by facilitating, coaching, mentoring and teaching Agile values, principles and methods.
After being laid off from Corel in early December, I interviewed at a few startups and, while the job hunt continues, this experience has given me the opportunity to meet some energized and inspiring folks doing good work.
I’ve received career and life coaching and support from my dear friend @spydergrrl … over twitter, over the phone and over lattes.
On a personal note, my 4 year old started school this year and it’s been a pleasure to watch her grow out of a toddler and into a little girl with thoughts and opinions all her own. I feel privileged to be part of her journey through life.
On another personal note, to my partner in love and life… it’s been a year full of distractions, but I’m lucky to have someone that I can be completely honest with…for all the good, the bad and (sometimes) the ugly sides of me.

So what does listing some my accomplishments and gratitudes do for me? It helps me to take a deep breath when I feel that I’m not fast enough, smart enough, energized enough, or <enter perfect person quality here> enough… I can tell you that I will be coming back to this list a few times during 2014 to remind myself that I am… indeed… enough… and that I am very very lucky to be surrounded by such amazing people.

What improvements would I bring forward to 2014? Clarity, simplicity and courage in my own thoughts, words and actions. Love, compassion and respect to those who matter in my life. Mindfully choosing with awareness where I give my energy in those empty hours when I’m all alone with my own thoughts.

Ok… well… maybe these are more life goals than yearly goals… but if Agile has taught me anything, it’s that when you are faced with uncertainty, you need to be able to lean hard on your values.

Wishing you the very best in 2014. Thanks for reading 😀

Backlog Baggage

November 29, 2013December 2, 2013 ~ Caroline Sauve ~ Leave a comment

I’d like to suggest a radical strategy for backlog management. The strategy is simple, whenever you review an item and opt not to consider it for active work, destroy it. Yes, you heard me, set fire to the blighter!

This might seem a little extreme at first glance, but I think the logic behind it is pretty straight forward. First, by keeping it, you are implicitly saying that anything new that you will learn as you work is less important than the thing you just said no to. Secondly, by keeping it, you are also implicitly saying that you have no feedback mechanism whereby the item could come back to you without constantly collecting and reviewing it <insert Gollum sounds here>. And don’t get me started with the cost of maintaining all that baggage if you opt to keep it. Believe me, I understand that we love our precious items… I do. But a backlog item just doesn’t have value unless it’s being worked on meaningfully right now.

With the year end looming, this might be a good time to simply grab all that baggage in your backlog and toss it out. Trusting that if any item was really important, it will come back to you quite naturally in good time.

Creating a Culture of Learning

November 19, 2013November 19, 2013 ~ 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

November 10, 2013November 12, 2013 ~ 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.

In Defence of Waterfall…

November 7, 2013 ~ Caroline Sauve ~ Leave a comment

I recently put together a whiteboard presentation that gives an overview of 6 different software development methodologies (Waterfall, XP, Scrum, Agile Manifesto, Lean and Kanban). I started with the grand-daddy of all the methods… Waterfall.

I’m glad that I did… because doing so reaffirmed for me that Waterfall, like most software methodologies, is often misunderstood.

I want to be clear. The whole document maintenance nightmare, lack of customer feedback, hard core linear process of Waterfall is indeed still part of Waterfall. But viewing it in the historical context of the 1970s, I came to realize some of the honourable goals behind the Waterfall process. As a developer, I had to imagine a time where writing and compiling code could be extremely time consuming and costly to do. Suddenly, trying to sort out as many details before writing a single line of code started to make sense.

So when you look at a particular software development methodology, it may be worth taking into account what motivated it’s creators within their historical context. Doing so can allow you to let go of the parts that don’t necessarily fit within your own context and perhaps extract what is still meaningful for you.

Coming back to Waterfall, I extracted a few things that I think are still relevant to me today. Software development requires discipline in order to be effective and (however tempting it may be to do so) we should be careful not to skip steps in order to speed ahead. That being said, which steps are meaningful to you… well… that all depends on your context.

Compassion

October 28, 2013November 7, 2013 ~ 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

October 16, 2013July 8, 2019 ~ 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…

October 4, 2013 ~ 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

September 24, 2013November 7, 2013 ~ 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?