Notes from the trenches: remote collaboration helpers, killers, and technologies in-between

There is no question that being in the same room, at the same time, and looking at the same monitor is the best way to collaborate effectively.  Barring that, there are tools and technologies that help working together over time and space. Also, there are things that masquerade as remote-work enablers, that actually steal away productive time and energy while delivering little value. And then there are helpers that could be useful in some situations, but not others.

Great tools to bridge time and space

• Phone or VoIP technology.  Dialing a team member should be a one-click (or close to it) endeavor.  Skype and Lync work well, so do smart phone systems (mobile or landline).  Traditional phone that requires a 10+ digits to get anywhere is not in this category.
• Desktop-sharing technology.  One picture is worth a lot of words, and to collaborate successfully it is important to be able to share the view.  Old Remote Desktop still works, so does Lync.  Skype used to be able to do that, but newer versions lost that functionality.  I also put screen capture tools in that category, because they help share a view, albeit a static view.  Windows’ Sniping tool is great, because it makes it easy to draw on the picture, to direct attention to a particular portion of the image.
• Online workflow tools.  Teams work better when using a visual Agile Board, and a distributed team will benefit from having access to a similar visual tool as well. There are several solutions on the market, including Rally, VersionOne, and tools by Atlassian.   The choice is rarely clear, but it is important to pick one tool and keep all work in it, so that there is a single comprehensive view of work flowing through.
• Remote meeting technology.  Again, there are plenty of choices available, not all created equal.  Lync and Skype allow to create group conversations with online chat and audio.  Lync also permits to add screen sharing and transfer control between participants.   Add a good-quality speaker/mic, and distributed team meeting is off to a great start.

Tools and technologies that promise to help, but don’t

• Traditional phone conference lines.  There is usually a complicated dial up scenario - up to 20+ digits, up to a minute of listening to the automatic prompts, exacerbated by random drop-offs which require the dial-up procedure to be repeated.  These conferences require a clearly defined host, who starts and ends the call, which goes against the concept of a self-organizing team with shared responsibility for success.  
• Remote meeting technology that works similar to traditional phone conferences.  WebEx takes a lot of tinkering to set up, so does GoToMeeting.  They also require a clearly defined host who starts and must remain through the meeting.
• Speakers on traditional phones.  The quality tends to be fairly low, with a lot of noise, and small range of pickup.

Technologies that can be tremendously helpful (but only if your team uses them properly)

• The top one is email.  It is at everyone’s fingertips, it’s easy, so it is tempting to use – a lot.  But mailboxes are hard to search, emails are hard to categorize, and information tends to get lost. 
• Wiki, FAQ, online postings are great – if you are going to have the discipline to maintain them, remove irrelevant and outdated postings, make sure the terminology stays consistent across articles.  Out-of-date and incorrect Wikis and FAQs can be harmful, and not knowing which articles can be trusted and which cannot will cost your team dearly.   
  

KISS [Keep it Simple]

I believe in keeping it simple.  Programmers have come up with an acronym KISS – “Keep it simple, stupid”.  But the idea applies to more than just programming, or even software development in general.

The best tools for keeping on top of projects, tracking who is doing what and how, and how much progress is being made are the most simple ones: whiteboard, board with multi-colored stickies, or a drawing board with stickies attached.  The materials are cheap and simple, little training or specialized technology is needed, and the setup is basically disaster-proof.

Conversely, a large-scale software development process management tool is expensive, requires extensive setup and training, and is highly sensitive to environmental failures. Many specialized tools provide nice-to-have features that are not available from the board with stickies. However, these tools are hardly any better than the simplest setup at the core functionality – provide an overall view of the project progress and allow to update it quickly and easily.

Another example of simplicity is paper survey forms that are passed around to attendees at user groups, classes and conferences, to gather feedback.  Paper forms tend to be easier and less error-prone, and also more likely to be completed – compared to survey link sent to participants the next day, or mobile survey site that participants need to access via their own smartphones or laptops after the class. 

Paper and pencil are easy and have universal interface, so that everybody can use them in the same way, regardless of which flavor gadget they happened to carry.  Survey on paper is impervious to WiFi being down, server not accepting connections, or DoS attacks. 

Just as important, paper and pencil have limited appeal, so they are easier to put down once the survey is completed, and turn the attention to the next class or presentation.  It is a lot harder to tear people away from their phones, than from a boring piece of paper. Unless it’s been folded into a paper airplane.  But that’s also good feedback.

Agile Manifesto: value individuals over process.

Manifesto for Agile Software Development starts with a very interesting notion that for better ways of developing software it is important to value

Individuals and interactions over processes and tools.

Seems simple enough: people should always be more important than tools, if the industry hopes to harness the benefits of individuals’ knowledge, creativity, and commitment.  

However, Agile methodology is largely about process. SCRUM, a popular Agile framework, requires very tight adherence to its many processes and ceremonies.  Other agile approaches are also about process – iterative process, light-weight process, but a process nevertheless.   No Agile book recommends letting the individuals interact freely, with no structure or process to guide them.   

The idea of valuing the individuals over the process means that a process is necessary – but the actual process used is continuously tailored to the individuals involved. The value of the process is determined by how well it serves the goal of successfully delivering value to the client, and the needs of the Agile team. Any measure intrinsic to the process itself is largely irrelevant.

Individuals and interactions emerge the process, just like the team emerges the product – bit by bit, feature by feature, continuously improving the understanding of what works, and what fits the particular project and the group.    

Optimize for value, not busyness or resource utilization

Recently, in several different project conversations, there surfaced an amazing argument.   The exchange went something like this:

-          We need to do X, Y and Z, since these are most valuable, risky and fundamental things for the project.   Once we complete X, Y and Z, we’ll be able to make other important decisions and move on to the following priorities.  

-          But doing X, Y and Z only requires XX people. Our team is XZ people.  We need to pick something else, to make sure everyone is busy. 

There is value in doing the best known and most important pieces now, and there is value in postponing decisions until the last responsible moment.  There is no value in making more people busy. 

Entry-level microeconomics courses offer this example: more chefs in the kitchen allows for more pies cooked, but only up to a point.  After that, adding people actually reduces productivity.

X axis: number of people on the team
Y axis: overall productivity of the team, number of widgets per time period

The concern is overall productivity of the team, measured in value delivered to the customer.  Number of people and working hours is only important if it is too high. People-hours metric is completely irrelevant when it is lower than certain allowed maximum.

If X, Y and Z are the most and only valuable items to work on right now, that is what the team should work on, and nothing else.  People, whose skills are not needed at this point in the project, can go home, learn some new skills, provide peer review to others, work on setting up infrastructure, etc.. The important part is to optimize for the project value, and not for resource utilization.

Agile teams: location matters

A team is the single most important point of success or failure for a project. Team culture and leadership have a great influence on productivity, and team communication is essential for effective and sustainable product delivery. Co-located teams have a better chance to create great team culture and leadership, than teams that do not communicate face-to-face. Interacting in-person helps build trust and respect, common vision and shared responsibility faster and more deeply.   

Having a fully co-located team requires an open-space environment, set hours to maximize face time, and sometimes even lunches together, so that the team spends the most time in face-to-face interactions.  In the pursuit of co-location other valuable things get dropped. Better specialists are not willing to work the exact hours, or are not available in a set location. Introverts suffer from too many hours in the open-space environment. And, because all communication is face-to-face, the team never has to develop the skills to communicate in any other way.

However, while co-location brings a significant benefit, it also comes with a cost. Getting every member of the team in the same room at the same time for the duration of the project often requires a change. Sometimes that cost is trivial. For example, if team members are scattered around the organizations' campus for historical reasons. Co-locating a team like that is as simple as designating a team room, arranging furniture in an open pattern, and moving the team members over. Chances are, the organization is better off getting the team co-located, and reaping the benefits of improved team dynamics. But there are plenty of situations where co-location is very expensive - or even impossible. For example, a project team must include a specialist who resides in another city or country, or a key person on the team has to work from home some days. Co-location may not be an option, but the team can still deliver. 

It is harder to build Agile culture of trust, open communication and shared responsibility in a distributed team, but it can be done. Communication is a skill, one that teams can develop, if there is the will, training, and positive reinforcement.  Remote teams can get very good at communicating using different channels.  Regular (or even occasional) travel to get the team together allows to build strong relationships, that last long after everybody went back to their original, possibly far away, locations.  

There are many distributed teams that do great work, are Agile, deliver value, and enjoy great team culture.  Co-location is one way to achieve these goals, but it is not the only way.

Join us on May 17th at Minute Maid Park, Houston, TX

Estimation agility

How good are your estimates?

Well, it depends.  If the project is slow-moving, the team is stable and has been at it for awhile, the platform is well-known and doesn't change much, and requirements are more along the lines of “get me some more of this”, rather than asking for something completely new and unknown – maybe the estimates are right on the money.  For the rest of us, working in the real world and on real projects, with real people involved, estimates are mostly guesses, often – very bad guesses.

Yet there is all that great pressure to get the estimates right early on.  The business side needs to know how much will be done when.  The clients have to understand when the product will be available for use.  Marketing is in dire need to make an announcement.  It has to go into the contract.  Salesperson already swore to it on building manager’s dog’s grave.

The estimate, which is often pure guesswork, rules the fate of the project, the development team, the customer’s hopes and the business success.  Never mind that the guess has been made at the worst possible time, when hardly anything is known about the project and no patterns have yet been established.   Rather than iterating on estimates, deadlines, project scopes, the tendency is to push for more overtime, less testing, more risk-taking – and more blame going around.

If the estimate is wrong, there is very little the project team can do to overcome an overly aggressive or too-far-out estimate.  Adding or removing people, and making the team work more hours has been shown to waste resources and reduce quality, rather than increase the speed of development.  Piling pressure to work “better and faster” helps even less.  

The only reasonable solution is to iterate on the estimate, refining and re-setting expectations as the project goes forward and new information becomes available.

Protect yourself from harmful emails

“Sign up for our email list to get information and announcements.” 

It seems like every group out there, whether professional, hobby-based, or commercially-organized, communicates by email.  They send emails, and expect their messages to be looked at.  Or not.   The second option is more likely, because there is so much email.  An individual message sent out to a subscribers’ list, as opposed to a personal email, is not likely to get much attention when and if it is read, and even less likely to be remembered when needed.

Once emails are – maybe – read, the information needs to be stored away for future reference. There is simply no chance to remember it all.  And there comes the pain – how to organize all that data.   Events can be added to the calendar, so that they can remind about themselves in due time.  Documents can be saved with relevant projects.  Purchase receipts and travel arrangements can get sorted into their proper folders. 

But what to do with ongoing conversations?  Questions and answers, discussions, group decision-making? How to keep the thoughts from being lost?   It is important to keep track of who said what, when, and why – but it is not practical to re-read everything every time, and there is no easy way to summarize.  Being able to search through the emails helps, but requires good memory for keywords, excellent usage of unique-enough keywords, and doesn’t fully solve the problem even if all the conditions are met.

The only way to deal is to use old trusted “divide and conquer” method.  Conduct technical conversations on StackOverflow, professional networking on LinkedIn, idle chit-chat and social calendar on Facebook, other special topics on forums and in blog comments.    By picking a most conductive location for each conversation it becomes possible to categorize and to frame the discussion, have just the right amount of history, threading, and “search-ability”.  It also reduces noise – there is no longer a need to surf through numerous car-buying discussion messages when checking RSVPs for the next house party.

---

Looking for great agile training with industry experts? Hunting questions to help your everyday work? Climbing the agile mountain and stuck? Not to worry, AgileDotNet is coming!

Finding the value

What is the most valuable goal of  a project?  A software project is usually about getting the users features that they will enjoy and that will make them more productive, getting it out on time, and making it work well.  But what is more important:

• making users happy
• getting more users to use the application (but not necessarily elated)
• hitting the deadline
• never making a mistake
• being able to trace and correct every single mistake on the back end
• ... lots of other choices?

"All of the above" is never a good answer, because time and expertise are limited resources.

Sometimes an organization will have a clear preference, based on its overall culture and nature of the project.  For example, some systems are deadline-driven, such as software that supports Mother's day or Christmas sales season, systems used in elections, tax-preparation applications.  In others, being able to trace and correct an error is essential, for example, in software dealing with money.

However, in a lot of cases the project owner faces a choice, and being aware and deliberate in making that choice can make or break a project.

Agile steps

The teacher looked a bit glamorous and very assured of himself.   “The most important thing is steps.  We do a step forward, a step sideways, a step backward, and another sideways.”   The class tried, lots of stepping on other people’s feet ensued.  A few students missed the first bit, and found themselves off by a step, confusing their neighbors.   

A brave soul raised his hand and asked out loud: “What if people next to me are doing something else?” The teacher responded with authority: “They will know to do these steps.”

A lot of Agile learning takes their students through similar ordeal.  Steps are shown, expectations are announced, and students are told that the rest of the world will just fall in line.  With that people are sent out to their regular workplaces and teams to create beautiful new work successes with Agile. 

Class discussion is often framed differently than in the real world, and there is a lot of pressure to agree with the teacher and with the other students.  Make no mistake, a group of professionals taking an Agile training does not represent a regular workplace crowd, a typical organization, or a normal project team. Students participating in an Agile class are different in that they all agreed to learn Agile, are curious and open-minded enough to consider a different work philosophy and methodology, and are willing to challenge themselves with training.   

When the class is over, and everybody goes back to work, the students will need something other than just Agile steps or procedures to guide their every day work. If the organization is serious about switching to Agile and getting the benefits of the new approach, everybody needs to get the underlying philosophy, the ways to get into the rhythm and on the right step.  The team needs to be able to stay in sync,  while realizing that someone will inevitably drop the ball and require help.  When going through training in Agile, practitioners must learn to realize when they’re off beat, when other people are off, and how help the team to all follow the rhythm.    

Steps are necessary, but they are simple and easy to do. Agile training should be about being and doing Agile in the real world, where someone will always be off-beat, and not know the steps.    

---

Registration for AgileDotNet 2013 in Dallas, TX is open now - the most advanced discussion on Agile and technology in the real world.