Sunday, 31 January 2016

Introverts in Agile

Being a part of a highly collaborative agile team can be challenging in many respects. One of the things that I have personally found difficult, and have observed being difficult for others, is balancing the demands for interaction against a need to reserve my ability to have good conversations.

I am an introvert. This doesn't necessarily mean that I'm shy, or quiet, or withdrawn - though occasionally I am each of those things. I like to think before I offer an opinion, but I don't think that's unique to introverts either. A simple definition of introverts that I relate strongly to is:

"Introverts give energy to conversation. Extroverts take energy from conversation.

Let me give you an example. In a previous role, I worked as a tester in an agile team running fortnightly scrum. Every Thursday morning we would have a three hour sprint planning meeting, from 9am to noon, to discuss the upcoming stories, create tasks, estimate hours, and commit to a backlog for the sprint.

This meeting wrote off my day. Some of the team would leave the meeting buzzing about what we'd agreed to and be excited to get stuck into it that afternoon. I left feeling completely drained and incapable of starting any meaningful work until Friday morning. The contrast of an extroverted versus and introverted response.

When I look back on this, we weren't doing scrum wrong. We weren't doing agile wrong either, we valued "individuals and interactions over processes and tools". But what we were doing felt wrong for me, as an individual, and I believe would pose similar challenges for other introverts in the same situation.

I'm not about to suggest that you stop talking to one another to accommodate the introverts in your team! However, I think there are a lot of practical things that agile teams can do to better accommodate introverts, and that introverts can do to improve their ability and stamina in communication.

Scheduling Meetings

If someone schedules a meeting with me, I like to spend some time prior to think about what I want to say and what I may be asked to contribute. This quiet period of preparation means that I'm ready to participate when I arrive. Similarly, at the end of a meeting I like to spend a few minutes digesting what was covered, noting my action points, and thinking about whether I have any other questions to ask.

With a lot of meetings, these extra pieces of time can add up and limit the hours I have available to complete my actual work. However, if I don't have space between meetings, then my ability to productively participate in meetings drops at an alarming rate.

Although my calendar doesn't always allow for these luxuries of preparation and reflection, it's amazing how many people schedule meetings with very little regard for their impact on the people who attend them.

There are many facets to consider here. I'd encourage you to read:

Personally, I now try to schedule meetings adjacent to lunch hours. This limits the disruption to people who "make stuff". It also maximises the opportunity for introverts who need to balance conversation with quiet time for themselves on either side of the session.

Additionally, where I need to schedule a very long session across multiple hours, I try to book these in the afternoon so that people don't have to return to work afterwards.

Agile Rituals

The agile rituals of planning, stand up and retrospective appear to be ubiquitous. I've seen them performed in a variety of ways and I believe that some formats are better suited to accommodating introverted team members.

Planning within the scrum framework can be an onerous task. The scrum guide states "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint." Eight hours! That's a full day meeting!

By contrast, adopting a kanban workflow may mean that planning is completed as work is pulled onto the board. I've been part of a team that used huddles, where at a minimum a developer, business analyst and tester would discuss the story and create tasks against it.

I've found huddles to be less taxing to prepare for and participate in, as they have a smaller audience and scope of responsibility. They also don't take long to do, which means that huddles can be scheduled by discussion at the daily stand up to properly accommodate the people who attend them.

Stand up meetings can be dominated by extroverts who are unafraid to interrupt and take conversation off topic. The most introvert-friendly stand up routine that I've been part of involved a Buzz Lightyear action figure. The stand up was re-branded as "Buzz Time" and the toy was physically passed around the team to indicate whose turn it was to speak.

This simple mechanism helped stifle interruptions and provided space for those in the team who had previously struggled to be heard by giving a clear visual cue of whose turn it was to speak.

Finally, retrospectives. Ideally the team are voicing their honest opinions. In reality, it's often a subset of the team who talk while the others mostly listen. If you see an imbalance in the perspectives being offered, try choosing a format that addresses this.

In a team with a particularly obvious void between the extroverts and introverts, I avoided open discussion when facilitating their retrospective and instead adopted structured data collection and sharing. I asked for post-it note brainstorming then requested that the quietest people, who would usually hesitate to offer an opinion, share what was written on their post-it notes first.

I found this to be a relatively good way to offer introverts time to solidify what they want to say. By sharing first, they have the opportunity to raise problems that are common across the team, avoiding the situation where their ideas are presented by others first. A clear directive of when to speak also helps minimise the anxiety of waiting to contribute, making the whole experience less draining.

Informal Communication

There's a lot of day-to-day chatter that happens when we work closely together. This may be via online channels or face-to-face, but always without warning. Though we want to remain responsive to one another, we also want to offer people the opportunity to focus. It can be hard to concentrate on a difficult problem with repeated interruptions.

I have worked with several developers who used their headphones as a social cue. If they were listening to music, it meant that they did not wish to be interrupted. Of course there were exceptions - if there was a very important problem or the building were on fire! But generally, headphones indicated an intense period of focus.

I've also worked in teams where, despite being co-located, much of the conversation happened via shared chat applications. Some members of the team would treat this similarly to email, checking in on the chat thread at various points throughout the day rather than being continuously interrupted. Again, this was something that others adapted to.

I don't believe that a desire to focus is exclusive to introverts. But my observation in each of these cases was that introverts were more likely to use these methods. Perhaps because each interruption was not just derailing their thoughts but also taking a small toll on their broader ability to think by taxing their energy levels.


A collaborative culture is important in agile delivery. I see a lot of opportunities to tweak the mechanisms by which a team communicates to enable introverts to give their best possible contribution.

As a starting point, take a step back and observe the way your team works now. Do you find it easy to distinguish your extroverted and introverted team members? Is there any variance in how much people participate in discussions during a day? Can you spot any opportunities to balance the conversations you're having?

I'd encourage you to become mindful of your meeting scheduling, the format of your agile rituals, and the way that you interact informally. Small changes could make a big difference to those who give a lot of their energy to communication.

Friday, 8 January 2016

Time to step forward in the testing community

Has anyone else noticed the recent spike in calls for volunteers and helpers from across the international testing community?

I know that these requests are partly driven by existing volunteers realising that they are overloaded by the volume of work that they've committed themselves to. But I also believe they are a sign that the testing community is growing.

It feels like there are more people attending testing conferences, registering for testing training courses, watching online testing webinars, and reading testing articles. Perhaps, in part, because the people who consume testing material are not just testers.

By comparison, there are relatively few people creating and facilitating the delivery of this content. As someone who participates in the community as a speakereditormentor and organiser, I'd like to encourage you to join these ranks. It's extremely rewarding.

Think about roles you fill in the community now and what you'd like to do next. Could you write an article, submit a proposal to speak at a conference, assist the organisers at your local testing Meet Up, review articles for a magazine, act as a mentor to encourage others, or volunteer your time to one of the initiatives above?

What will you achieve in the community this year? 

A model of the testing community

Thursday, 7 January 2016

An approach to refactoring test automation

For one of our products, we’ve been using the same front-end test automation suite for several years. We currently have ten testers across five different agile teams who contribute code, and the total number of contributors through the life of the suite must be over 100.

As with any suite of similar history, our implementation varies greatly between different functional areas of the product. Though the coverage decisions are relatively consistent, the way the code is written is unique based on who the author was. These differences are visible through all layers of the suite: in the plain English concordion specifications, our accompanying Java fixtures, and supporting WebDriver utilities.

From mid-December to late January our product is put into a release change freeze. This is the summer vacation period in New Zealand, many of our staff away on leave, and due to Christmas it’s one of the busiest banking periods for our digital channels. As development of new features slows, it’s the perfect time to focus on activities like refactoring our automation!

In mid-December I ran a brainstorming session for the testers of this product to identify the technical debt in our associated automation. We quickly came up with a list of over 20 high-level items including standardising the implementation of common actions, creating naming conventions, removing duplication, consolidating utility classes, and improving documentation.

We voted on those that were most important and two items emerged as an immediate priority:
  1. Standardise how we use waits
  2. Determining a consistent approach to login

I scheduled two coding dojos prior to Christmas and these two priorities became the objectives for these sessions. The dojos were scheduled for two hours on a Tuesday, each with 8 or 9 testers participating in the traditional dojo format where:

  • The facilitator asks questions and doesn't give answers
  • Everyone must participate in the code being written
  • Everyone must take a turn at the keyboard

Prior to each dojo, I created a refactoring branch using git. During the dojos we made changes against the branch, generally working on a single specification and associated fixture that I selected in advance. We collectively agreed on what our standard approach would be by making the first set of changes as a group.

We were working on a framework that the team use on a daily basis, so every attendee had good knowledge of the code. There were different opinions about the right way to do things; refactoring created a lot more discussion than when we used the dojo format to extend a framework into new areas. The testers were engaged in the process and stayed invested in the outcome throughout each of the two hour dojos.

After each dojo, I pushed our changes to the refactoring branch so that the testers could pull the work we had completed. Then I created a backlog of related refactoring tasks. Through the remainder of the week I asked each tester to independently pick up a task from this focused backlog so that they could immediately apply what we had decided as a group by refactoring with the same purpose in another area. Each task doubled as both a learning exercise and a way to improve our suite.

Each person who claimed these tasks worked on the same refactoring branch and pushed their changes when complete. At the end of the week, once all the backlog tasks were finished and committed against our refactoring branch, we merged our changes back to master via a peer-reviewed pull request that included the entire test team and a few developers too.

Branching strategy for refactoring via coding dojo and shared backlog

Using dojos as a tool for collaborative refactoring has worked well for us. During the session, the high level of prior knowledge of the code has created a healthy environment for discussion. The team have been passionate but flexible, and able to establish agreed standards relatively quickly.

The granular introduction of consistency in our automation gives us time to understand each decision being made and to create associated documentation with refactoring examples in our expanding how-to library. The huge amount of tidy up to be completed seems more manageable when we tackle small pieces. Using dojos makes it feel like everyone is across the desired solution rather than just a couple of people championing “the right way” to do things.

During the week following each dojo, having all the testers working on a common backlog of refactoring tasks against a single branch of the code has improved collaboration. The testing chat channel has been noticeably more active! Because the testers usually work in five different delivery teams, on five different functional areas of the application, it’s unusual for them to have to interact with such regularity.

Regular coding dojos have been the cornerstone of an inclusive, engaging and collaborative approach to refactoring our test automation.