Agile for UXers

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

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.

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

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

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?

Problem Constellation

Anyone who has tried to facilitate meaningful team discussion around a problem will know that it’s not easy. A common “team discussion problem” is to have one or two well intentioned individuals monopolize the conversation… leaving you to wonder, what are the others thinking? What are we not hearing or not talking about that we should? I’d like to suggest a quick and effective technique to help align the team when it seems like the discussion might be in trouble.

It’s a hack of the “Constellation” exercise… but it is focused on understanding problems, so let’s call it “Problem Constellation”.

Facilitator stands at one end of the room. Line up the team at the other end of the room facing the facilitator.

Facilitator will make statements one at a time and, for each statement, participants must take a step forward if they agree with the statement. If they cannot agree with a statement, they should not step forward. If at any point a participant cannot agree, he must stay put for the remainder of the activity (even if he agrees with subsequent statements).

During this exercise, no one should speak but the facilitator. The intention is to stop group discussion and take a moment for everyone to reconcile and become aware of his own state of mind on the problem. The facilitator then makes sure that everyone is clear on the instructions before starting with the first statement for consideration.

Here sample statements (order is important)…
1. I know that ____ is a problem.
2. I believe there is value in solving this problem.
3. I believe that ____ is the root cause of the problem.
4. I believe that ____ is the most effective solution for this problem.

At this point, it’s a good idea for everyone to take note where they are and where the rest of team is positioned. The participants closest to the facilitator are those who are in agreement with the potential solution to the problem. Those furthest away from the facilitator are the people who need to speak. Then the facilitator walks to the back of the room and begins reading the statements again, only this time, the team will hear from the people furthest away from the perceived solution.

I have found this activity to be very effective at surfacing assumptions and validating our understanding of a problem as a team. It has “quieted” the “solution influencers” for a moment and allowed relevant information to come forward. It has also “quieted” unqualified participants in the discussion… that is to say, if someone cannot attest to “knowing that there is a problem”, then their role might be to support, observe and understand rather than “drive or influence a solution”. Bringing this awareness is something that the facilitator can help to do.

I have used this technique for controversial problems as well as for teams with more introverted participants and found it to be very effective at gaining a collective understanding. The best part of it all is that the whole activity takes only a few minutes to setup and run.

Lessons in Discomfort

Once a week, I try to make it to my yoga mat and to my Yin Yoga class.  Beyond the obvious benefits of yoga, this class helps me to put into practice some important conflict management skills…

Yin Yoga is a practice whereby the student places himself in supported stretches for a length of time. So, once settled into the pose, the student connects with his breath and holds the position for approximately 5 minutes. When discomfort occurs, the student is instructed to stay in the pose and to gently bring attention and awareness to the sensitive area.   Breathing through the discomfort for the whole duration of the pose if necessary.

When I bring attention to discomfort during Yin, I usually discover that I can relax a little more and that doing so almost always brings with it relief.  This doesn’t work in every case and on some days, it’s harder to do than on others… but I have learned two things from this continued practice:

1. Shifting my position may bring temporary relief but almost always results in a displacement of the discomfort to somewhere else.

2. Adopting a mindset of attention and awareness has allowed me to stretch my body in ways that I didn’t think possible.

These lessons in discomfort are something that I try to practice every day.

When faced with an uncomfortable situation on your Agile team, try bringing gentle attention along with awareness to the discomfort. Try to resist the urge to correct or to fix. Work with the team to “relax” the situation without changing it.  Doing so will help the team to stretch in ways they may have not thought possible.

Standup Is About Commitment, Not About “Giving Status”

One of the many moments of clarity that I’ve had thanks to Lyssa Adkins (Twitter: @lyssaadkins Web: http://www.coachingagileteams.com/) is the goal behind the Standup meeting.

Standup is about commitment, not about “giving status”.

Armed with this new understanding, I facilitated a Standup meeting “reboot experiment” with my team. We started by talking about what wasn’t working with this meeting and then worked together to develop some new guidelines centered around the idea of commitment.

Now, during Standup…

We each take a turn to express what we will commit to completing between this meeting and the next.

When we aren’t speaking, we commit to listening fully to the person speaking.

We will speak up if we have information that would help the person speaking meet their commitment. Creating this connection is important… but having the full conversation may not…  so we commit to identifying side conversations when they happen.

We are committed to keeping the information shared relevant for all. We ask questions if a team member’s commitment is unclear.

We regularly check-in on the value and relevance of the meeting and re-commit as needed.

It’s worth noting that we don’t generally discuss “blockers” here, mostly because the team is empowered to seek help if they encounter an impediment rather than wait for a meeting. We also don’t generally talk about what we did in the past unless we feel it to be relevant information for the team.

Could your Standup meeting do with a little more commitment?

Agile and Quality

You may have noticed that the Agile Manifesto (http://agilemanifesto.org/) never uses the word “quality” as part of its core values. I believe this is because quality is an underlying value to the Manifesto and that “working software”, “customer collaboration”, “responding to change” as well as “individuals and interactions” are all pointing us in the direction of quality.

Looking at it this way, quality is not a role but a core value and occurs when the team…

…works with users to understand how the software can meet their needs
…gathers to review and evaluate stories
…works together on code and design
…collaborates to create automated tests
…explores the application for unexpected issues
…validates its work with users

As such, quality is expressed through the collective attention and effort of the whole Agile team throughout the cycle.

Improv and the Agile Team

While at Agile Coach Camp Canada in Toronto last month, I had the priviledge of learning about how Improv can help the team’s Agility from Todd Charron (Twitter: @toddcharron  Web: http://www.planningforfailure.com).

This was the first time that I made the connection between Agile and Improv… and it was one of those ah-ha moments for me.

Good team mates learn when it’s time to speak and when it’s time to let someone else speak. They learn to explore ideas “thrown at them” from their fellow team mates and seek to build on those ideas. Good team mates understand and appreciate the connection that they have with each other. They make room for vulnerability. They trust and support each other.

They are fearless when they are together.

In the spirit of beginning…

It seems apt, as this is my first post, to take a moment to simply acknowledge the spirit of beginning.

Beginnings are full of anticipation and promise.  Full of potential and opportunity.  Looking forward to something new and revealing, beginnings are full of creative energy.

I’d like to extend this idea to the rituals Agile teams experience regularly.  Thinking about “stand-ups”, “planning meetings” and “retrospectives”, what would change if we approached these gatherings in the spirit of beginning?