Years ago, we heard about a movement in software development that was more about individuals and interactions than processes and tools. It was about responding to change and not a rigid plan. Of course, I’m quoting from the Agile Manifesto.
Agile development didn’t spring to life overnight, but slowly and over time we’ve adapted as an industry a more agile approach to how we develop software. A similar change is happening in the way that we communicate, and it’s happening in the same fits and starts that agile development initially had. The change is about collaboration, not negotiation. It’s about getting things done rather than having documentation. The changes that we’re seeing in communication follow the same openness and transparency that created agile nearly 15 years ago.
One of the tools that stands to change the way that we communicate is Yammer. Microsoft purchased Yammer in 2012 and has been integrating it into its products and services, creating a future that includes Yammer integrated into the Office applications we use every day.
But the question is how does a mass-market enterprise social tools help developers write better software? Clues are in how Yammer aligns to the direction we’ve been headed for years and what we’re already doing in person for agile development. Clues can also be found in the way that we collaborate outside our enterprise, despite Yammer being described as the enterprise social network.
Stand up
The standup meeting has become a part of the modus operandi of many software development teams. It’s the daily gathering where developers talk about what they got done, what they plan to get done, and what’s in their way. Designed to be short but collaborative, the standup meeting is different from the way that projects used to be managed.
Projects used to be managed by managers scurrying from office to office and developer to developer collecting individual statuses: where they were succeeding and where they were failing. Later, the scurrying was replaced with e-mail requesting status updates.
Every once in a while there would be public floggings known as project status meetings where developers would be called out for missing their deadlines. And the demoralized and frustrated group that was the project team would retire to their offices and cubes to trudge through the project some more. There were no systems that promoted developers to work together; there was only a system of administration and bureaucracy.
This approach didn’t work because it didn’t foster group commitment to the team about what they were going to get done and—more important to how Yammer can be used to improve the development of software—it didn’t expose the problems that developers were struggling with so they could get help. Standup meetings are fundamentally built on shared commitment and openness about our struggles to meet commitments.
Extending our standup meeting to all of our communication is what Yammer does. Yammer allows us to post our successes as well as our challenges to a group so that our peers can quickly resolve our problems.
Some teams have realized that they need to be more transparent in their struggles and triumphs between standup meetings, and to document the discussions in standup meetings. As a result, there have been many attempts to find a way of communication that encourages group participation.
Wikis are popular for documenting the current state of the solution during agile development, including things learned from work on the project. However, wikis don’t lend themselves well to telling what’s happening with fellow developers or what they’re struggling with. You can be notified when pages in the wiki change, but rarely do teams use wiki pages to share their struggles.
Discussion boards are used by some teams as well, but the challenge with discussion boards has always been that it’s hard to know what you’ve seen and what you haven’t. It seems like you’re always trying to find new information that has been posted and questions that people are asking. Even on the Internet, general discussion boards have by and large lost their steam, so it’s not hard to see that too few developers ended up going out of their way to get to the discussion board, and so there were few (or no) answers. In short, discussion boards have too few answers.
E-mail distribution lists are OK too, but they tend to generate too much e-mail and they get shunted to a folder. When you’re triaging the more than 100 e-mail messages a day you’re getting, who can take the time to really dig in and answer a question? When they do work, there are still challenges around who gets what messages: What if the person who can provide the answer isn’t a part of the distribution list? How are new team members able to get the shared knowledge out of the previous discussion list messages, which they’ve never seen?
Yammer solves these problems by creating a system where you can record notes, create discussion threads, and involve people in the challenges you’re having. While posting to Yammer, it’s possible to “call out” people who you specifically want to respond. Those people are notified of a new discussion thread, but everyone else can see the thread as well. If someone knows that the person who has the information doesn’t normally check the particular Yammer group that the question was posted into, they can reply by “calling out” the person likely to have the answer. The “called out” (or tagged) people are notified—perhaps by e-mail but also when they log in to Yammer—that there are threads that are flagged for them to read.
Yammer becomes a place that people can check when they’re done with their work unit—or when they just need a break from the problem they’re solving. They don’t have to be interrupted by an e-mail, instant message or phone call. Not interrupting one another is critical to maintaining productivity.
Push vs. pull
As a developer, there is a delicate balance between “crying wolf” and grinding on a problem too long before seeking help. The balance is between interrupting someone with a “push” contact like a phone call or instant message to get an immediate answer or help, and trying to work it out yourself. Interrupting someone else costs them 15 minutes of productivity. Working on the problem without asking might cost you hours. It’s difficult to know when to ask for help and when to struggle through yourself.
The key challenge here is that you’re interrupting someone else. What if it’s possible to reach out for help without interrupting someone? In Yammer, when you’re facing something you’ve never encountered before, you can post the question or challenge to your development team and try to solve it on your own. When your peers “come up for air,” they can chip in their thoughts on Yammer, which you can check when you have time.
In this model—a pull model, where everyone browses what is happening when they’re at a good space for it—you don’t have to interrupt. You don’t have to pay the price for the interruptions, and at the same time you can get answers relatively quickly.
Consider for a moment the difference between getting calls, letters and e-mails about what’s happening in friend’s lives vs. getting updates via Facebook. Certainly, personal communication can be fun, but on the whole you’ll get many more updates from an active Facebook user than you ever would from a friend writing or calling directly. We’ve learned that we won’t see every update that every friend posts, but instead we’ll be able to dip our toes into the stream of updates whenever we have time.
However, in business, the transition from push to pull communication isn’t easy, particularly for Type A personalities that want to have tight control over what they’re asked to do and what they get done. The nagging question that lingers is, “What if I miss something important?” The answer, though uncomfortable for some (including me), is that it will come back around.
Recently I was working with a client discussing requirements for SharePoint, and we were talking about the controls that were in place to ensure that all of their invoices from vendors were paid. The “control” to make sure all invoices are paid is that the vendor will follow up with them if an invoice slips through the cracks. In the same way, if there’s something important that you need to see that you’ve missed, someone will flag it for you, resend it to you, or follow up in a way that ensures that you don’t miss it.
This is the way that our broader world works. If there’s something important in the news that we miss, we’ll hear about it from a friend. There’s too much going on in every aspect of our life to believe that we won’t miss something and that we won’t drop some ball.
You may miss the important—if the important is only mentioned once. In reality the things that are truly important tend to get repeated so that you’re less likely to miss them.
Work out loud and pick a color
Inherent in the idea of making the transition from push to pull is that everyone will do what Microsoft calls “work out loud.” It’s sort of thinking out loud in digital form. You’re letting folks know what you’re doing and when you’re doing it so that they can be aware, and more importantly so they can react and respond to it.
Working out loud isn’t telling everyone the virtual equivalent. Working out loud is about sharing the accomplishments and struggles that we’ve been talking about in this article.
What would working out loud look like for you? What if Morgan Freeman was standing behind you every day as you worked, narrating it? Would he say hello every morning? Or would he speak about the internal struggle and monologue in your head that may or may not be apparent to those who are in the same room with you?
To extend the exercise further, you might ask additional questions like, where would the musical scores of building tension fit in? If you can’t think of what Morgan Freeman would say about your work, why are you working on it?
While the transition for working out loud may be difficult, it’s perhaps more difficult to realize that you’re adding yet another communication option to an already full palette of options.
Similarly, picking your favorite color is like selecting a communication channel. Once you’re aware of the impact that you have when you interrupt your friend and team member, you’re less likely to want to interrupt them. However, there is still a great deal of confusion on when would you use different communications channels. When you’ve got so many options, how do you decide which strategy to use?
Where there is a lack of guidance there is a lack of action. If you’re concerned about how users will select a communication channel, you may need to provide them some directional guidance. One way to do that is a graphic like Figure 1, which puts urgency on one axis and the size of the audience on the other. With an understanding of these two factors, a user in can make a decision about which communication channel to use.
Yammer isn’t like handing a carpenter a single tool. Instead, it’s another tool in the toolbox—and it’s not fit for everything. However, it can be a fit for many of the lingering challenges that development teams have in their communication. One key area that seems to continue to be a struggle that Yammer can resolve is the knowledge management challenge.
Knowledge management
Research scientists are taught to create and maintain notebooks with all of their experiments, including their successes and failures. In software development, we don’t have the same conditioning to keep a record of our success and failures. Some of us have our own mechanisms for saving this information, including making it available publically through our blogs (mine is at www.thorprojects.com/blog). Others keep a set of files on our system with the information.
However, all of those mechanisms require extra effort and are sometimes neglected. As a result, we have to come back later and relearn the same information simply because we didn’t get a chance to record what we learned the first time around.
Even research notebooks are lousy from the perspective of knowledge management because they are only available to the research scientist who did the work. They’re not searchable except by thumbing through them. As developers, we need to learn from the other members of our team so that we don’t make the same mistakes other team members have made. We can search the development wiki if the last developer thought to create a post on the topic. However, we’re back to the extra effort problem that so often plagues all knowledge management.
What if the question and the answer (in their connected form) were automatically saved and searchable? There’s no extra effort and there’s no need to copy the information someplace else. That’s the promise of Yammer for groups who are willing to post their questions and concerns.
Knowledge management is something that has a substantial cumulative effect. The first week you’re on the platform, it will not have captured much knowledge for you. However, over time the repository of information becomes deeper, and there are more questions that can be answered with a search instead of a Steve (or any other developer on your team). This is what happens with Yammer. Conversations are saved over time to capture more and more of the collective knowledge of the organization.
But even a database of existing knowledge isn’t the whole story with knowledge management. Ultimately, knowledge management is often about connecting two people: one with expertise in a topic, and the other with a need to know more about that topic. Knowledge management is accomplished by allowing anyone in the organization to tag (call out) other individuals, allowing a request for expertise to walk a collection of weak ties to the ultimate answer.
Winning with a weak set of ties
When you’re looking for a new job, it’s not what you know, it’s who you know. However, not all connections are the same. There’s more to it than just where the position of your connections inside of other organizations; there’s the ability of your network to bridge you into new places. That requires a large collection of weak links.
Weak links aren’t the people you see every day. They’re the people that you bump into from time to time. They’re also called bridging connections because they allow you to bridge into new areas.
Strong ties, like the team you work on or your immediate family, give you answers that you’ll likely already know. Weak ties, on the other hand, are more likely to get you information and opportunities you didn’t know existed. Yammer is powerful at helping leverage those weak ties.
If you’re in a large organization and you’re working on something like mobile application development (which your team has never done before), asking a question to your peer group about how to handle help in a touch-based interface isn’t likely to be helpful; no one with whom you have strong ties has the experience you need. However, posting to a larger corporate group may lead you to another division’s developers who’ve already struggled you’re your problems.
No amount of in-team discussion or e-mails are likely to get you the experience, but folks whom you only know casually (or only through the corporate directory) may be more than willing to help share their experience with you.
While Yammer is described by Microsoft as enterprise social software, today organizations are more connected to one another, and not everyone you work with may be inside your organization. That’s why the benefit of Yammer to development teams extends beyond the walls of the organization.
At a broader level, Yammer allows you to create an external network that connects people inside the organization with parties outside the organization. You can create the same sort of collaboration externally as can be done internally. For instance, if you go to www.yammer.com/professionaldevelopers, you’ll find an external group I created that allows professional developers to communicate with one another. Feel free to try it out and ask for an invitation to the group—I’ll happily approve you to join.
As the creator of a group, you have the option of allowing users to go to your external network and request a link, or you can invite them manually. You can create a group for your friends, drinking buddies, or your local users group to bring people together to share knowledge with one another.
If you’re like me, whenever someone proposes a new social tool, you wonder how different can it be from existing tools. The answer is that the existing Web-based (as compared to e-mail) tools aren’t as easy to respond to and interact with, and ease of use is an important factor for generating engagement.
The historic tools for external collaboration seem clunky and out of place in today’s rapidly flowing world of communication. That’s why I invite you to join the professional developer community that I created, so you can see for yourself how you might be able to leverage Yammer in your organization to improve your development communications.
