A Master of the Agile Arts

In the years that I have been working as a Scrum Master and Agile Coach, I have been blessed with superb mentors who I look up to.  I believe that having a mentor is key to continuous improvement and growth. My current mentor is Ken Furlong. He is the Director of Product in eComEngine and he is an experienced Lean and Agile Coach.

I would often sit-in on meetings where Ken would discuss Lean and Agile principles to new employees joining the company.  I learn a lot from observing how he presents and shares ideas and insights.  He is confident and comfortable in his delivery, there’s a certain finesse in how he answers questions showing his deep knowledge and practical wisdom of Agile principles and Lean practices. He speaks clearly, is concise and straight to the point.  I already have a collection of the analogies he uses to explain principles in a way that people can relate to, making it more easy for the audience to understand the principles.

I asked Ken some questions, centered on being Agile while working with remote teams,  and on this post I am sharing them along with Ken’s answers.

As an Agile Coach what is your “plan of attack” when you first start working with a remote team?

The plan is generally the same as when beginning work with a co-located team.  The coach needs to orient themselves to the team’s environment and spend most of their time observing dynamics and just getting to know the team members.  As with a co-located team, part of that process is paying special attention to how their environment (physical or virtual) impacts (for better or worse) the team’s communication and collaboration.  Just as physical space and physical distance can encourage or discourage communication and collaboration, so too can “virtual space” and “virtual distance” (think tooling and infrastructure).  The general principles a coach brings to bear on the situation are pretty much the same, what changes are the specific tactics and recommendations that can vary widely depending on the context.

What do you think are the top three traits of a successful remote Agile team?

It’s hard to force rank traits in general because each situation is different and the different contexts may require different traits on the part of the team.  That being said, it will be hard for any remote team to be successful without these three:

1. Individuals are self-motivated
2. The entire team is aligned on the team’s goal(s)
3. The team has high communication saturation and individuals are highly interactive with one another throughout the day

It’s not to say that those three are sufficient for the team to be successful but they are necessary, in my experience.

As an Agile leader what are the top 5 challenges you have faced when effecting change in a company composed of remote employees?

1. A lack of engaged team members (which is often bred by siloing, that itself is a result of the remote environment not being compensated for properly)
2. A dearth of feedback (verbal and non-verbal) to the coach (often exacerbated by a lack of good communication tools, but fundamentally based on the fact that you are not physically co-located)
3. A lack of data about the team members’ behavior day-to-day
4. An inability to simply observe without having to “set it up” over a phone or video conversation
5. An inability to respond to moment-to-moment successes, failures, surprises, learnings, etc.

The Master of the Scrum Master

Back in 2011, I have been fortunate to be able to work with Lynn Rogala. I remember she joined the company I was working for back then as the Director of Engineering. She introduced us to Scrum and mentored me in becoming one of the firsts Scrum Masters in the company. It’s an understatement to say that I have learned a lot. Right off the bat she has instilled in me the correct set of values, enabling me to be successful in performing my role. Lynn shared lessons on how it is important to appreciate the value a framework brings to help you embrace it. One of my favorite quote from Lynn is: “make the team feel the pain”, this is on how to make the team move away from a bad habit.

I can go on forever but what I really wanted to share on this blog post are Lynn’s answers to some interesting questions from me:

What was the biggest challenge you faced when you worked with remote teams? How did you overcome it?

By far the biggest challenge for me personally was the time difference. I was separated by hours from the development team, so staying connected with them a lot throughout the day was not possible. The team worked hard to be flexible enough that we could have regular meetings by phone to help stay in touch. In the early days the team did some fun in-person training that doubled as introduction to agile and team building. That helped build the trust and commitment to each other. We wanted success for each other as much as for ourselves.

To fill the rest of the gap we used the Atlassian suite with Confluence and JIRA helping us stay in touch near real-time. No one wants to go to a lot of meetings, so once the team realized that using the tools for collaboration kept our meetings down they really embraced it. I like this suite because it supports “real” work rather than requiring a lot of extra work. As the team kept their items updated I could observe what was happening without breaking their stride. That part wasn’t much different from how I manage co-located Agile teams.

From the Agile Manifesto we have: “individuals and interactions over processes and tools”, how do you think we should follow this principle when we work remotely? In that situation it seems processes and tools are very important as well. Your thoughts?

I think it comes down more to how you look at the processes and tools. If they are in place to support the individual and interactions they support everything we love about agile. It’s when the process or tool becomes more important that what is happening in the work or on the team that it becomes a problem. Even in the manifesto they don’t say to throw out processes and tools. It’s just that we value the individuals and interactions more. We were able to use the Atlassian suite as a way to really value people working together. The team even used Confluence to arrange gaming parties, and I loved that. It meant they were really embracing the tools as a way to stay connected. It was never about the tools being primary. As an aside, this is why I absolutely loathe Gantt charts and Microsoft Project as they are usually used on projects. It becomes about keeping the chart up to date, rather than how the team is producing results for the customer.

What are the top three values you impart on the teams you guide? Why are those values your top three?

Having members of the team be personally empowered is what I value the most, easily. It’s something I value simply as a human being – to see others reach the best version of themselves. I love to help people connect with how amazing they really are. It’s a lot of fun to watch and it has the bonus benefit of producing the best results on the team. When that becomes what the team values – that everyone is empowered to produce – it leads to other things like teamwork, respect and commitment. And people are happy and growing and taking on greater challenges. One of my favorite moments with a new team is when I tell them after a Sprint or two that they are taking on WAY more work than I would ever assign them.

Next is accountability. It’s really the other side of the coin of empowerment. It’s like saying “Ok, team. I’m going to treat you like adults and let you choose what to commit to. I will empower you. In exchange you’re going to be accountable for what you say you will do.” I want my teams to be happy and growing. But I’m also not afraid to hold their feet to the fire when they aren’t accountable. And that doesn’t mean things don’t slip or fail sometimes. It just means I expect the team to own it and then use a retrospective to learn from it. With an attitude of accountability, mistakes can be just as valuable as success. Empowerment doesn’t work without accountability. The two of them together make up ownership, which is what adults do.

The last one doesn’t really have a name. I could say it’s communication, but what I really mean is everyone has a chance to speak up. For some team members that means learning to listen while others speak. And for some team members it means learning to speak while others listen. This is what makes planning poker so much fun. Everyone has to say at least something! The best designs come from collaboration because we can’t all know everything. There’s always some piece of information one person has that no one else has. That person needs to speak up. I like the stand ups for the same reason.

How do you deal with difficult team members who resist changes and don’t want to be Agile?

That’s difficult to answer, because it’s not the same answer depending on the how and why of the resistance. With any change you have innovators, early-adopters, early majority, late majority and laggards. Geoffrey Moore’s book “Crossing the Chasm” is must read for anyone championing change because it gives you this crucial framework. And agile is still a “change champion” situation with some organizations. You can even look at the organizations themselves as somewhere in that list. In the US, for example, an organization just now considering agile is probably a late majority customer. In other parts of the world we are still in the early-adopter/early-majority market around agile. Knowing what kind of *company* you’re in will affect your influence strategy, which in turn determines how you deal with team members. The culture of an early-adopter company is different from a late majority company.

When you influence team members to change you have to ask yourself are you working with or against the company culture? That’s important to know. Whenever I’m introducing a change I look for the people who will be champions of change. There are always people who just “get it” early on. People like you, Kevin. 🙂 As you build allies in innovators and early adopters, that can sometimes be enough to influence the team culture to get the resisters to come along. This is the point where you can find out if they just want to know it’s going to work, if they’re a little afraid or if they are just digging in their heels. You can go a long way with results. I’m sure you remember early in the project we worked on together we persuaded a reluctant customer that agile was the right way to go by producing amazing, accelerated results in our software. Sometimes that is enough. Some people need extra training, skills development or simple reassurance that they are still valuable on the team. Sometimes you will have a true laggard who simply refuses to change without being forced. And someone forced to be on an agile team is not usually engaged enough to be on that team, and sometimes you need to find other places for that person. I like to at least try to influence, train and reassure before it gets to that point. But I’m not willing to sacrifice the velocity and success of the rest of the team for someone who will never be happy on an agile team.

Thank you Lynn!

Even now I am still learning from you. Apparently the Padawan has not yet surpassed the Jedi Master.

“I want to learn the ways of the Force and become a Jedi like my father.”

Luke Skywalker to Obi Wan Kenobi, Star Wars Episode 4 – A New Hope