Blog


Using Personas for Writing User Stories

I typically have a long commute, and train travel is conducive to thinking about stuff; so recently, I started to think about personas and user stories.

I am a big fan of capturing business problems in the form of user stories. It forces you to think about not only the problem you wish to solve, but also who exactly has the problem.

So in this post, I'd like to share why I am convinced we should use personas in our story writing. 

Two Types of Personas

There are two types of personas: the buyer and the user.

The buyer persona is the person that is willing to pay for products because of the benefits and the return on investment. These are sometimes referred to as marketing personas.

The user persona is the person who will use the products to solve their problem, commonly referred to as the end user.

Sometimes the buyer and the user can be one and the same. For example, if you buy a cellular phone for your own use, you are both the buyer and the user. 

How Do Personas Factor into User Stories?

When it comes to writing user stories, it is important to understand what a persona is and what it is not.

The user stories are written as problem statements in the perspective of the person who has the problem that needs solving. The persona refers to the person with the problem. 

Creating a persona is to give a name and provide a story. The story will capture personal and professional characteristics, education, demographics, buying habits and motivation, behavior, likes and dislikes etc.

The idea is to have a realistic representation of your user base. 

A persona is an archetypical character as opposed to a stereotypical character. An archetype is a quintessential representation of the ideal user of your product.

The goal is to understand the personality and the typical characteristics of the person whose problem you are trying to solve so that it will provide you with a clearer understanding of your target audience. 

Giving it a name and a personality provides a venue for socializing the characteristics, the role and the target market segment. 

For example, if your persona was "Doctor Who" (a time traveler in a TV show), you would immediately have context as to the persona and perhaps the problems he faces.

If the persona was further clarified as the Eleventh Doctor, you would not only understand he is a time traveler, but his likes and dislikes based on the personality of the Eleventh Doctor.

This would not only allow you to create the best possible problem statement, but also further explore and provide the best solution possible that would address the Eleventh Doctor’s problem. 

Examples

Let’s say we have two user stories:

User story 1: As a user, I want to have a keyless entry to my home, because I keep misplacing my key. User story 2: Matt Smith (the Eleventh Doctor) must have keyless entry to the TARDIS, because there is a chance that his companion might take the keys away. 

The user in the first story may be too generic. You may come up with a very different solution if the user was a young child coming home from school, a teenager, a family pet, the owner of the home, etc.

It may also change based on if it was a single dwelling or multi-dwelling abode. In this instance, you may decide to have several personas for your user base. 

In the second user story, the solution space is very specific to one doctor. If it were any other doctor, you may explore different options based on their specific personality, habits, likes and dislikes. 

In Conclusion

Understanding your personas and giving them a name will make story writing more interesting and relevant.

Calling them all “users” might become confusing if you have many types of users that desire a varied user experience.

For scaling agile in large organizations, creating personas become extremely helpful when multiple teams work on the same product and share the product backlog. 

Also, if you have an avatar for your persona, that's always nice, too.

Hope this was helpful, and happy story writing.

Do Engineers Like Agile Development?

I’m an engineer. I come from a long line of engineers. I married an engineer, and two of my three kids are engineers. I’ve worked with engineers my entire career, so I consider myself quite in touch with a typical engineer’s personality.

So, do engineers like agile development? If we look at the typical engineer’s personality, there will be traits that align with agile values and other areas that take engineers out of their comfort zone.

One of the most common personality type tools is the Myers-Briggs Type Indicator that results in 16 MBTI types, depending on four scales, which we’ll review below.

Engineers usually fall into the Introversion and Thinking categories. In the article, “Personality Types and Agile Development,” Richard Banks, as an INTJ, believes his own personality type is a great match for agile because INTJs are adaptable.

Banks suggests that an ISTJ would be more suited to Waterfall development because of the tendency to prefer a more methodical, traditional approach.

I can tell you as an ISTJ myself, I do prefer a plan and structure, but I believe agile methodologies do give us that, just not in the same manner as Waterfall.

With that, let’s take a look at the four Myers-Briggs scales to see how a typical engineer personality may or may not align.   

Introversion (I) vs. Extraversion (E)

The first scale is Introversion vs. Extraversion. Introverts get their energy from being alone. Most of us introverts prefer to work alone rather than as part of a group.

Think back when you had a school assignment to be done as a group. If you were an introvert, you probably inwardly groaned and just figured you’d need to do the lion’s share of the work yourself to ensure it was done “right.”

It’s not that we don’t like people, it’s just that we don’t want to have to depend on them.

The “whole team” approach used in agile is probably one of those areas that takes many engineers out of their comfort zone.

That being said, engineers are known to want autonomy, so the emphasis on self-organizing teams will most likely appeal to engineers, as long as they feel good about who’s on their team.

Sensing (S) vs. Intuition (N)

The Sensing vs. Intuition scale describes how we take in information. Do we prefer using external sources, such as our senses (S), or do we rely more on gut instincts and intuition (N)?

Those with a high “N” value are more visionaries and are comfortable with abstract, futuristic thinking. Those with a high “S” value are concrete and realistic, giving attention to present details.

I believe either of these personality preferences would feel comfortable with agile development. Though, strong S people like detail, and that detail emerges in agile development before development work is done.

However, S people may feel uncomfortable starting development without a solid framework or architecture in place.

Thinking (T) vs. Feeling (F)

Thinkers and feelers are distinguished based on how they make decisions. Thinkers make decisions based on logic and reason and feelers rely more on subjective feelings based on their value system.

Engineers are almost always strong T personality types. They are logical and rational.

Though this type of personality works well with coding tasks and getting work done, engineers may feel uncomfortable with some of the team-building activities encouraged on agile teams.

In my experience, engineers bond best by solving tough problems together and may view an outing as a waste of time.

Judging (J) vs. Perceiving (P)

The Judging and Perceiving categories have to do with how much structure and planning in daily life is preferable. Those who have strong J personality types like schedules, plans and lists. Those who are stronger P types act spontaneously and decide things more at the last minute.

Agile development teaches us to plan “just in time,” remain adaptable and accept frequent change. This would cater more to the P personality type.

However, the J personality type takes great pleasure in bringing tasks to closure, so the agile style of decomposition with a specific set of tasks to accomplish will tend to align well with engineers who have a strong J personality type.

In sum, there are bound to be some things that engineers like about working on an agile team and some things that make them uncomfortable.

It would be best for the Scrum Master or agile leader to recognize the individual personality preferences of each team member and perhaps discuss as a team.

While each individual is different, when they all understand and respect one another's tendencies and preferences, they will undoubtedly become a stronger team.

Choosing a Retrospective Topic

I am a firm believer that the best retrospectives tend to be focused on a specific topic. Picking a theme and exploring what we currently think of it, and how we can improve in that area is almost always more productive for a team than having a general "how can we get better" conversation.

But how do you pick the topic? There are a few common ways for teams to do this ...

Ask The Team

Dedicate some time at the start of the retrospective to ask the team what they think the topic should be.

This could be as simple as giving each member of the team three sticky notes and asking them to write a topic on each, then gathering them all on the wall and looking to see if there is a clear majority winner such as "Dealing wiht bugs."

Perhaps there are some connections that make sense to tackle together.

Alternatively, we could ask each team member to write three feelings on sticky notes and do the same exercise of clustering them on the wall.

We might then end up having a retrospective on frustrattion. Why are we frustrated? How could we become less frustrated in our next sprint?

Ballot Box

Technically, this is still in the "ask the team" area, but there is a difference in that this is anonymous and in real time before the retrospective as opposed to at the start of the meeting.

With ballot box, a box is placed in the team area where team members can post cards with an idea for a retrospective topic as they occur during the sprint.

Then, at the start of the retrospective, we just empty the box and see what ideas we have, and make a decision.

ScrumMaster Choice

In my Scrum Mastery course, I explain that I believe ScrumMasters should always reserve the right to pick the topic that the team should explore in a retrospective.

An elephant in the room is what the English refer to as an obvious truth that is going unaddressed.

 

Sometimes the team may be too nervous to address the topic that really needs addressing and in those cases, the ScrumMaster should be prepared to help the team by highlighting it. 

As with anything, if the elephant is avoided for long enough, the team will develop coping mechanisms.

The problem is, these coping mechanisms don’t deal with the issue and actually make the problem even less likely to be removed because it doesn’t seem quite as necessary any more.

Great ScrumMasters courageously expose, and encourage teams to explore, the elephants in the room as soon as they notice them.

They don’t judge, but neither will they let their team tolerate and get dragged down by these problems.

Instead, they offer to lead an exploration. For example, the elephant in the room could be that one of the team members is getting into the office later and later.

The team is accommodating him by shifting the daily scrum and, sometimes, writing up their conversations, but this is leading to inefficient teamwork and resentment is growing in the team. 

Before this spirals into outright anger and rebellion, the team should confront and solve the problem.

A great ScrumMaster acts as a mirror for the team so she can reflect back what is happening in the team.

This is not a finger-pointing exercise but done with as much compassion as ruthlessness so that the team feels this is important enough to tackle but not defensive about admitting it needs tackling.

I recently blogged on compassionate ruthlessness here.

There is always room for good old ScrumMaster intuition. During the sprint, ScrumMasters are in a privileged position, able to see a lot of what is going on with a certain detachment.

They can -- and should -- be listening to what is being said and what is not being said, looking out for good examples of team dynamics and development as well as opportunities for further team growth.

Great ScrumMasters have no issue with starting the retrospective with a challenge based on their own observations, for example:

“This sprint, I have noticed a larger proportion of time than normal has been spent on fixing defects. I wonder if it would be a good idea to take some time out to explore why this might be and what we could do about it.”

Set The Team Up

Whichever method you choose, and you will definitely take the context of the situation into account, it's almost always a great idea to start the retrospective with a compelling goal that engages the team and helps set them up for success.

Most of the time, this goal will come from the team, but sometimes, it's OK for the ScrumMaster to step in and challenge the team with a compelling challenge to explore. 

 

Valve's Culture, Self-Organization and Scrum

“If you don’t like change, you’re going to like irrelevance even less.” 
- General Eric Shinseki

Valve Corporation is an enormously successful game development and digital distribution company headquartered in Bellevue, Wash. In the spring of 2012, Valve's New Employee Handbook was released.

Its release has led to a number of discussions about the merit of The Cabal (what Valve calls their approach of having small cross-functional teams implement core features for their games). For me, it's hard to argue with success and everything I've read about Valve being a great place to work, so I read the handbook closely.

Since first reading about The Cabal in 1999 and attending a few of their conference sessions since, I've been inspired. That inspiration helped lead me to agile thinking.  

I felt there was a connection with agile and the kind of place, like Valve, where I wanted to work. A place where rigid process and hierarchies were considered a mismatch to creative development.

Valve's handbook states this belief near the start:

Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily. But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish. Self-Organization

The handbook goes on to describe the role of an employee in this environment. The criticisms I've heard about The Cabal often say that you need the right kind of people for this to work.  

I agree, but I think that the potential pool of such people is larger if you provide mentoring to help the transition into such an environment.  

The handbook acknowledges this as a challenge:

There are a number of things we wish we were better at: -Helping new people find their way. We wrote this book to help, but as we said above, a book can only go so far. -Mentoring people. Not just helping new people figure things out, but proactively helping people to grow in areas where they need help is something we’re organizationally not great at. Peer reviews help, but they can only go so far. 

This is a common challenge in any studio that is attempting to improve self-organization. People have to unlearn a lifetime pattern first imposed in our public education systems, which train children how to work in a task-driven, top-down hierarchical organization.  

It's an even greater challenge for a studio that has been hierarchical, since it threatens the status quo (more on this later).

Self-organization and hierarchies aren't mutually exclusive. Gabe Newell leads Valve; it's not a pure democracy, but Valve doesn't have many layers between him and an artist creating texture maps.

Nor is the artist being handed a list of texture maps he or she is assigned to create during the week. The artist is expected to be a professional and is treated like an adult by being allowed to be personally accountable.  

What self-organization does is to flatten hierarchies and reduce the number of lines of communication between people that need to communicate.

Scrum and The Cabal Have the Same Goals

Scrum is a framework for iterative and incremental product development based around self-organizing teams.

Team size, sprint durations, Scrum roles, etc. are meant to foster self-organization. Every two to three weeks, the team inspects their work and practices and seeks ways to improve both.  

The roles provide for clear interfaces and areas of ownership. The benefit is that after awhile, every individual should find motivation in seeking these improvements.

This motivation builds on itself, accelerates and leads to a better working environment.  

Good working environments and profitability aren't exclusive. While Valve says it enjoys high retention rates, in 2011, Forbes pointed out it also makes more profit per employee than even Google or Apple!

The goal of Scrum adoption is not to "do Scrum perfectly" but to establish a framework that will lead to such a culture. It's been referred to as a starting script for self-organization.

Why Is It So Hard Then?

So why do few companies ever achieve similar cultures? Why is it so challenging for organizations that adopt the Scrum framework to become like Valve?

This is the big question.  

I believe it mostly lies in cultural resistance. As mentioned earlier, an organization that grows in a hierarchical pattern resists the adoption of self-organization.  

This applies to managers as well who see their value tied to a command-and-control structure. Even in the face of studio extinction, these forces resist change.

I once heard the comparison of a manager resisting change in a failing studio to that of the Titanic passenger with the finest cabin refusing to evacuate!

Resistance comes from developers as well who focus on their tasks and discipline, and leave accountability to their bosses. This feels safe, especially in a culture that hands out blame like candy during Halloween.

Valve has the benefit of fostering self-organization and found growth through hiring people that worked well in that environment.  

It doesn't hurt that Valve is self-funded and somewhat isolated from external customers. It also doesn't hurt that they own their intellectual property.  

But this doesn't mean the path to self-organization is impossible to move to from a hierarchical culture. It's definitely hard and it does takes time.

There is a revolution taking place right now in how we work that may take a generation to become commonplace.  

We have more examples every year that show us how to get there and what the benefits are. Scrum can help that transition occur, if the values, not necessarily the practices, are followed.

A major goal of my "Agile Game Development: Essential Gems" course was to offer the gems of transition from practices to values.

Note: This is an updated version of an original blog post that was previously published here.

The Coffee of Destiny

A few years ago, I pulled into one of the many local Starbucks, like I did everyday. But on this day, the world changed for me. 

We had been applying Scrum successfully on our games for a while, but we had a problem with applying it during production. 

Often, games go through at least two phases before they launch. One is pre-production, where the core gameplay features and engine are developed. 

The second is production, where the hours of gameplay content (levels, characters, story) are developed using those features and technology. 

As much as we tried to be agile, we couldn’t eliminate that separation of phases. 

The problems were that during production there is more of a flow of handoffs from one discipline to the other, and large assets, such as levels, took far longer than a single sprint to complete. 

This led to a lot of unfinished work at the end of every sprint and bottlenecks between the handoffs. 

Now, if you are a straight-coffee drinker who frequents Starbucks, like me, you probably appreciate that you don't have to wait for all the lattes, cappuccinos, etc. ordered ahead of your cup of coffee to be made first. 

The barista works on those exclusively and the cashier can directly pour your coffee for you.   

That day at Starbucks, the light bulb turned on.

I thought, maybe we can learn something from this. A bit of Googling showed that Starbucks was applying a practice called Kanban.

Kanban roughly translates to “signal card” in Japanese. It’s a set of practices that focuses on the flow of work and uses the state of the work in progress to signal to the people doing the work what they should do. 

At Starbucks, the empty coffee cups, marked with your misspelled name and order details are the Kanban. Based on how many there are between the cashier and barista, this informs them of what they should do next. 

Looking at the Kanban board above, my coffee goes from the "order" column to the "leave" column directly. 

Based on the size of the line, the barista and cashier might help one another out. If the line is long and the barista has nothing to do, they’ll ask people in line what drink they want and start making that before the cashier takes their order. 

Conversely if the line empties, but there is a backlog of unfinished drinks, the cashier will join the barista in making drinks. 

This benefits everyone. A key metric for Starbucks is the customer cycle time: the amount of time it takes between walking in the door and when you walk out with your drink.   

The critical path for coffee drinkers and latte drinkers isn't the same, but it isn't entirely separate; much as I personally would enjoy it, there is no separate cashier line for coffee drinkers. 

Starbucks has chosen not to optimize specifically for us straight-coffee drinkers for good reason. 

This is similar to the approach you might use for asset types. Although every asset will have a large variation of effort needed (like that between coffee and a latte) and partially separate paths, measuring every asset's cycle time will still give us valuable information.   

The goal isn't to achieve a uniform cycle time for all assets, just as people who order lattes should expect to wait longer at Starbucks than us super-efficient coffee drinkers. 

Let's look at the Kanban board that shows various assets going through a game asset production pipeline:

This board includes assets that might need particle FX or animation applied to them, or neither. The important principles apply. 

We're going to measure the throughput and limit the work-in-progress (WiP) regardless of which steps are taken. Some assets will skip some steps like me skipping the barista. 

Doing this can improve the entire system. As a coffee drinker, I don't care how quickly the barista can make a latte, but I greatly appreciate when the under-tasked barista helps fill coffee orders. 

This can happen in an asset production pipeline as well. As we measure throughput, we can create such policies in a production pipeline: Starbucks has far shorter coffee cycle times than barista-drink cycle times and that is fine for everyone.   

The key is to measure throughput for different asset classes and explore where and when improvements for classes can improve their cycle time without impacting the other classes. 

Most production pipelines are far more complex than this, but the same principles apply. Start by simply modeling what you're doing now. Then measure throughput and reduce WiP.  

Adding Disruption to Spark Creativity

We learn with ShuHaRi that as we move to new levels of mastery, we must continue to experiment – to step out of our comfort zones and do things differently than they’ve been done before.

In his TED Talk about disruption, journalist and economist, Tim Harford, gives us examples of how being forced to deal with unexpected challenges can spark creativity and open up new and better ways of doing things.

He starts with a story about a pianist who needed to play a concert on a defective piano in a new way, which ended up being the best-selling piano recording in history.

Harford goes on to give other examples and says that research has shown that people experience discomfort, yet “unexpected advantages of having to cope with a little mess.”

Around the 8-minute mark, Harford describes how we solve complex problems, including software development, step by step, just as we encourage with agile development:

“You have some kind of prototype and you tweak it, you test it, you improve it.”

He agrees that this is a good way to solve a complicated problem, but tells the audience what would make it an even better way:

“A dash of mess. You add randomness, early on in the process. You make crazy moves, you try stupid things that shouldn’t work, and that will tend to make the problem-solving work better. And the reason for that is, the problem with the step-by-step process, the reason for the marginal gains, is they can walk you gradually down a dead end. And if you start with the randomness, that becomes less likely, and your problem-solving becomes more robust.”

Harford’s next example was from social psychology describing an experiment in which two groups were asked to solve murder mystery problems.

One group was a team of four friends and the second group was a team of three friends and a stranger.

The groups with the three friends and a stranger were 25 percent more effective at solving the problem; however, what Harford found even more interesting was how the teams felt.

The teams who performed better, felt doubt and were not as confident or comfortable, because working with a stranger added disruption:

“Disruptions help us solve problems, they help us become more creative. But we don’t feel like they’re helping us. We feel like they’re getting in the way. And so we resist.”

Harford’s final example was the story of Brian Eno, a brilliant ambient composer and catalyst behind some of the greatest rock ‘n’ roll albums of the last 40 years, having worked with David Bowie, U2, Devo and Coldplay.

Eno purposely creates disruption for bands through the use of a deck of cards called the Oblique Strategies.

When they're stuck in the creative process, they grab a card and they need to follow the instructions.

Examples include: “Swap instrument roles,” “Look closely at the most embarrassing details. Amplify them.” “Make a sudden, destructive, unpredictable action. Incorporate.”

Harford says that though the musicians hate the cards, they’ve proved their worth album after album. Though these experiments are uncomfortable, the musicians ended up realizing something: Just because you don’t like it, doesn’t mean it isn’t helping you.

In the software development world, disruption is often introduced, not purposely, but by the unexpected request or obstacle. We could look at these obstacles as opportunities to creatively solve problems.

What if we were to create an Oblique Strategy deck for agile teams? What kinds of things would they include?

How about switching roles for an iteration? How about swapping team members? How about making all meetings optional?

Besides helping promote creativity, if we purposely introduce “mess,” might it also help us better cope with the unintentional messes that are thrown our way?

Experimentation is disruptive, but encouraged in agile communities. Though Scrum and other agile methodologies give us a framework, as teams mature, take time to experiment with new ideas and creatively grow as a team.

Harford ends his talk reminding us that even though it’s uncomfortable, disruptive behavior helps us grow and learn:

“All of us, from time to time, need to sit down and try to play the unplayable piano.”

How Agile Can Remedy a Bad System

Do you want to know who you can blame for the latest fighter jets running hundreds of billions of dollars over budget, getting delayed for years and never living up to their potential?

You can blame me!

Well, you can blame me and thousands of others who have worked on fighters like the F-22 and F-35. These “next generation” planes are examples of what happens when the people making them don’t communicate with one another very well.

Let me tell you a story of a usual day working on the avionics for the F-22, back in 1990.

I was a software engineer working on some code that helped the F-22 communicate digitally with other planes. This was something fighters hadn’t done before and it was an important “feature” of the jet.

If the F-22 could receive digital radar information from a large radar plane 100 miles back behind the fight, it wouldn’t have to use its own radar and expose itself.

A bad system

So this new feature required unique software and hardware. It also used encrypted data, which classified the work as secret. Much of the rest of the jet had parts that were secrets as well. Maybe the name of the jet and the wheels were the only things that weren’t secret.

So, in developing this software for prototype hardware in development, I often had questions for the people who made the prototype. Unfortunately these people were in a different state.

In fact, people working in more than 35 states created the F-22. The reason for this was that in order for congress to approve the enormous cost of the plane, most congress people had to have constituents working on it. So Lockheed Martin broke up the work to ensure congress would approve.

Now it’s hard enough for people separated by a few time zones to communicate, but when they have to communicate about something with a secret classification, it gets downright near impossible.

So the conversation process was set up like this:

-I had to request permission from security to have a conversation on the phone.
-Security had to contact the hardware people and schedule a conversation. The earliest was a week away.
-I had to find something else to do for a week.
-When the appointment arrived, I was escorted to a secure room that had a scrambled phone.
-A secure room had “pink noise” (which sounds like a washing machine filling up with water) to mask any sound from leaking out.
-The scrambled phone degrades the sound quality of whoever is speaking.
-A security officer has to be present on both sides of the call.

Finally when I was able to speak to the hardware engineer about the problem I was having with his hardware, we were not allowed to have any casual conversation to start (in case I learn something about his classified details).

With the pink noise and scrambled phone connection, he was very hard to hear. So I started yelling a question into the receiver about my problem, but before I could get my first sentence out, the security officer in the room interrupts me and says I can’t go into specifics on secret technology.

I try to ask him what the point of having the call in the secure room and the scrambled phone was, but he wasn’t budging.

The conversation I waited a week for was reduced to: “I’m having a problem with something you made.”

Obviously the hardware engineer could offer little help beyond suggesting I reboot the hardware.

As a result, we had to put off getting much of the avionics to work for a year until we were able to integrate it all in a shared lab we all visited.

As you may imagine, integration was a disaster and delayed the plane for at least a year. However, we did solve the digital communication problem in a different way, described below.

Fixing a bad system

The managers I worked for on the F-22 program knew the policies of secure communication and had some control over them, but they didn’t fix them, and there was no urgency to do so.

We developers had a sense of urgency, but no power to change the policy, so we stopped communicating with our distant colleagues, which was bad.

The obvious solution is to couple the sense of urgency with the power to create change. This is a core principle in agile. It raises the urgency for fixing these problems to those in power through transparency, and it raises the power and accountability of the developers who are closest to the problems through self-organization.

Creating transparency

Transparency is created through frequent inspection of “what” we are making and “how” we are making it. In Scrum, every one to three weeks, we are reconciling what we achieved in a sprint review with what we forecasted we thought we might achieve in sprint planning.

The cost and impact of practices like secure phone conversations would become more apparent because they slow the velocity of adding features such as digital communication.

It’s harder to hide behind a complex schedule or hope that the problems will magically go away in some distant integration phase. We integrate as much as possible every sprint.

This transparency and velocity are tools for experimenting with inspecting the policy of secure communications and adapting to new policies that should increase velocity.

Creating self-organization

Scrum also defines the retrospective that allows the developers to discuss what is slowing them down every iteration, and to experiment with new ways of working to improve their velocity.

If developers don’t have this power to try new ways of working, this virtuous cycle does not occur. Fortunately we had a manager that trusted us and let us experiment.

Developers on secret programs have little power to override security protocols, but we can innovate within them to improve “how” we work.

In this case, when requested, our manager gave us permission to fly out and meet with our distant colleagues instead of calling them. For some reason, security policies allowed us to be left alone in a secure room with the hardware to discuss whatever we felt like.

Although it took more time to fly than to dial, we were able to solve many integration problems quickly in a day of meeting together. As the young, single engineer, I was the one that traveled the most to discuss the hardware and, after a few trips, became a limited expert on the hardware.

From then on, whenever a software engineer at our location had a problem with the hardware, they’d first come to me. If I couldn’t fix their problem, I would add it to my list of things to talk about during my next trip.

The same goes for games, actually

As a result of this new way of working, the digital communication part of the avionics did not have the integration problems that other areas did.

When I switched my career to video game development, I found similar problems occurring with distributed teams.

Although the security policies weren’t to blame, there were other problems with culture and organization that separated disciplines and put a systemic burden on their work, much like I experienced earlier.

So when someone asks me why it’s valuable to have cross-discipline teams who are co-located as much as possible, I remember the F-22.

Distributed or discipline-centric teams might not have the communication barriers I did in 1990, but when there are thousands of cross-discipline conversations that need to occur over the course of development, any barrier in the way of those, such as management tools or chains of communication or a long hallway to walk down, add delay – or worse: eliminate crucial conversations.

The moral of the story is that if your teams aren’t performing, take a look at how they’re organized. As W. Edwards Deming said, “A bad system will beat a good person every time.”

The Problem with the 6th Agile Principle on Communication

The sixth agile principle from the Agile Manifesto states: 

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This may be true. Certainly, there are a lot of reasons that face-to-face communication is a rich form of communication. However, a lot of changes have happened since 2001 when the Manifesto was first written and we now have opportunities to take advantage of different types of communication.

Social media, the cloud, and mobile technologies give employees the opportunity to work from anywhere, and most of us want to take advantage of that flexibility. However, many employers don’t allow this because “it’s not agile.”

But what about that principle? Is it “anti-agile” to participate on a distributed team? Though I don’t know if all agile coaches would agree with me, my answer to that is a big, fat “No!”

Personally, I think it’s kind of anti-agile to insist that teams must be co-located, but I also think it’s anti-agile to call anything anti-agile, so let’s just say the agile thing to do is to adapt to your context and circumstances.

Understand the issues and the pros and cons of different solutions or why a certain practice (in this case, face-to-face communication) is encouraged, and ensure that objective is being fulfilled.

We want the team to effectively and efficiently communicate, but there are ways to do that in today’s modern world, without having to work on face to face daily.

Before getting into some of the advantages of distributed teams, first let’s look at some negative outcomes I’ve seen as a result of the insistence of face-to-face communication being necessary for effectiveness:

- If there are any “remote” members – even if they’re temporarily traveling or working from home – they feel excluded and don’t have the latest information because the team is using processes and tools that depend on physical locality.

- People who are face to face feel that they are communicating “more effectively and efficiently” than those who are remote. This may result in a self-fulfilling prophecy. If teams feel they’re at a disadvantage, their mindset and attitude will be different than if they feel positive about the diversity and advantages of distributed teaming.

- Teams that are globally distributed may ask some team members to come to daily Scrum meetings outside of business hours in the name of having face-to-face meetings over telepresence or webcam. However, because of cultural differences or communication difficulties such as heavy accents, written communication may be easier and clearer for everyone. Being forced to come in off-hours may build resentment, not closeness between team members.

- Though strong team relationships can form from the bonds and friendships that grow from co-location, this may result in clique-ish behavior. Strong communication and teamwork is something that needs to be fostered, not only between team members, but also between stakeholders, other teams and various supporting groups. Invariably, these people will not all be co-located.

- Agile team members may be asked to come into the office every day when their colleagues who don’t work on agile teams are allowed the flexibility of some work-from-home days. This can lead to resentment at not being allowed the same privileges as others.

- Agile team members may be asked to sit in a workspace that promotes “osmotic communication.” However, the resulting additional noise and lack of privacy can frustrate the team member who will often wear headphones to drown out the noise, thus defeating the purpose.

- When there’s a conversation without follow-up documentation, there is later debate about what was discussed and agreed to. Two parties often remember things differently or have different understandings. Documentation can help to make sure everyone is on the same page.

While, again, there are advantages of face-to-face communication – deeper trust, the ability to read body language, the deeper relationships that can be formed, positive osmotic communication, the ease in explaining a technically challenging concept – we now have tools that weren’t available in 2001 when the sixth principle was created that can help us with these objectives.

As agilists, let’s remember to adapt and look at all the additional forms of communication we have available to us in 2016, and use those to foster teamwork, regardless of where team members physically work.