Salary Surveys

Visual Studio Magazine’s 2012 .NET Developer Salary Survey

Our first annual salary survey shows that developers aren’t just surviving, but thriving.

• By Kathleen Richards
• 01/04/2012

When we set out late last year to do our first-ever salary survey, we weren’t sure what we’d find. The global economy continues to limp along, and unemployment in the United States remains stagnant. Layoffs are still a very real possibility for many, and employers remain hesitant to hire with future uncertainty. That’s why our results were so encouraging: The survey reflects numerous positive trends for software developers, from job security to bonuses to the future outlook to job satisfaction. Yes, it’s a good time to be a developer.

We polled software development professionals who subscribe to Visual Studio Magazine and related eNewsletters (.NET Insight and Redmond Developer News) in November 2011. More than 1,300 subscribers who currently work in the United States participated in the survey and filled out the online questionnaire. The median base salary was $92,000. On average, VSM Salary Survey respondents were college graduates with a four-year degree or higher level of education and more than a decade of industry experience.

The single-biggest survey takeaway is that 59 percent of respondents reported higher salaries in the last 12 months. More than half of those surveyed received bonuses during the same time period. The average reported base salary was $92,754, not including bonuses and additional compensation. More than one-third (38 percent) of survey respondents said their current annual base salaries, not including bonuses, fell into the six-figure range ($100,000 or more).

Bucking the Trend Despite the gloomy global outlook, many Microsoft software development professionals appear to be bucking the “back to the future” trend.

“Microsoft software development gives us a strong future in the sense that there is some security in it,” says Rafique S., who has worked as a software engineer and application developer for almost a decade at a manufacturing company (non-computer-related) outside of Los Angeles, Calif. “There is always going to be a demand for that type of skill and that type of work — it’s a good skill set to have,” he says. “Our company has been stable and we’re still hiring more people. We haven’t had freezes or significant reductions. It’s a little bit more conservative and the compensation that we’re seeing has been about average for the last three or four years.” That includes slight increases in salary and “token” bonuses around the holidays, which are based on corporate profitability.

Long tenures with the same employer may have helped some people ride out the economic rollercoaster in the technology sector. More than 43 percent of VSM Salary Survey respondents have been with their current employers for a decade or more — 22.8 percent of that group have worked for the same organization for more than 15 years.

Survey respondents who worked for an independent software vendor (14 percent) reported the highest average salary, at $106,435. Those who worked for consulting firms, training companies and systems integrators also fell into the six-figure range on average at $103,635, not including bonuses and additional compensation. The majority of survey respondents, however, worked for corporate IT/IS (43.9 percent), with an average base of $95,015. Those employed by state and federal government, the education sector and non-profits (22.7 percent) earned less, reporting $78,688 on average. Average salaries might more closely reflect urban pay scales (see Average Salary by Location) because 65 percent of survey respondents worked in cities (200,000 to 500,000 residents) and major metropolitan areas (more than 500,000 residents).

Despite some job movement — 16.2 percent have been with their current employer for one year or less and 4.5 percent have been laid off in the last 12 months — by and large Visual Studio and .NET developers have skirted some of the harsher realities felt by stagnant or depressed job markets. But not everyone: while 59 percent received higher salaries in the last 12 months, 8.3 percent reported making less, based on budget cuts. Some government employees told us they experienced “5 percent cuts across the board,” and federal employees are under a salary freeze mandated by Congress.

About 90 percent (89.7) of respondents indicated that they anticipated working in Visual Studio and .NET development in five years. And the rest (10.3 percent) expect to move beyond .NET for a variety of reasons. Here are some of the comments from people who might be headed elsewhere:

• Will be retired within five years
• Not sure where the development trends are heading
• My company is moving toward open source products
• Leave it to the younger guys
• I think I’ll be working more with Windows Phone development than .NET development
• Not Sure — HTML5 and CSS don’t require a commercial IDE
• Career change out of IT for more money
• Microsoft Marketing will have re-branded it by then
• Going toward medical software
• Judging from the Windows 8 articles that I’ve read, the .NET app development may be a thing of the past
• Tired of Microsoft not listening to developers
• T-shirt sales by the beach
• It’s so hard to predict the future in this field. Who knows what we’ll have in 5 years?

– K.R

Timing:

30 minutes including prep and debrief

Overview:
A simple little game to help Scrum teams learn the importance of having a common understanding of a story.

So a while back I was having seeing a team have different interpretations of a story causing some confusion. Differing interpretations of the feature caused a little backtracking and introduced waste into the sprints.. nothing awful, just not ideal.

I came up with a very simple exercise to help the team understand that we can too easily make assumptions that everyone understand exactly what we mean, and the in fact our mental models are often quite different.

So I asked them to write down how they make Spaghetti Bolognese (or if you prefer, like me, Ragu*), a dish most us were likely to know. So they spent a few minutes thinking about it, and after everyone was done we went round the team reading out the ingredients.

Can you guess what happened?

Everyone had similar ingredients, but not the same. Most people had Mince, Onion, Carrot, Tomatoes.. some extended it into Celery (correct), a few added mushrooms (wrong), I had both Beef & Pork mince as well as Pancetta, Red Wine, Nutmeg, Oregano, Milk and Beef stock and not Spaghetti but Tagliatelle (I was taught this way by an 84yr old Italian Nonna, any deviation was food crime in her eyes ).

Learning Points:

So what did it tell us? We all know what Spaghetti Bolognese (*cough*  Tagliatelle al Ragu) is, but all had different interpretations. The team could draw the parallel from this to the assumptions we were making about other peoples understanding of a feature. It led to some very interesting discussions and a team habit of reiterating to each other the feature under development during sprint planning.

It eliminated much of the confusion and helped the team pull in a single direction.

Link to Game:

Ragu or Bolognese?

*Not Ragu the brand, Ragu is the correct name for the dish we know as Spaghetti Bolognese.

Timing: 30 minutes – 1 hour including prep and reflection.

Materials: One game of Battleships

People: 2 Teams, or 1 vs 1

Overview:

This is a game I use to introduce people to iterative development. The aim is to help the players to understand that upfront large plans are pointless the minute they are created. Helmuth (quoted above), for me, was one of the first proponents of an iterative approach. He didn’t necessarily create grand plans, conversely he didn’t disregard planning altogether, but he was smart enough to plan just enough and adjust his plan to meet the changing reality. Often my experience of working on projects with large up front plans, the opposite is true and the owner of that plan tries to adjust the reality to fit the plan.

So how do you play it?

Simple, one player (Player A) is given 40 pegs and told to place their ships and all their planned attacks up front. The second player (Player B) simultaneously places their ships. Once that has been done, the first player reads out the 40 pre-planned attacks and is given the hits and misses. Player B then get to play each attack (up to 40) separately, getting feedback on hits & misses for each.

It’s pretty obvious what will happen, most of the time Player B’s turn (iterative) based play will allow him to adjust and change his plans as he scores hits. Player A (large plan) will score hits, but is far less likely to sink all the opponents ships. So player B being limited to 40 moves also may sink the whole fleet or not, typically though that player will score more hits than the other.

What does this tell us?

Predictive planning is unreliable and is akin to reading crystal balls, reading tea leaves or any other clairvoyant technique you care to mention. Ultimately you’re predicting the future based on an infinite number of possible outcomes, effects and variables. The iterative approach is empirical, each time Player B hits his opponents ships, he can instantly change plans and target nearby locations to sink it.

Occasionally Player A wins, this is a bit like the fortune teller coincidentally getting something right, it’s often more luck than judgement.

Learning Points:

Iterative development allows you greater flexibility to the changing world, environments and needs of the business.

Often the player with the large upfront plan will score hits but not sink the ships, this could be a metaphor for a testing phase of a traditional waterfall project not being completed before time or money runs out.

Link to Game:

You Sunk My Methodology

Read more here at the conference website.

http://www.agilegames2012.com/index.php/8-news/36-callforgames

As the website says, AgileDotNet Dallas will be hosted at the Addison Convention Center, which is right near the Addison Circle and the big blue sculpture art thing.  There are topics for everyone, weather you’re new to agile concepts or an experienced developer.  For you PMI types, there are 7 PDUs (personal development units) up for grabs to help maintain your certification.  The price is only $50 per person, which helps cover the cost of the venue and the food.  Lunch is served and there’s a panel discussion with experienced leaders in the industry answering your questions.  Come check it out!

An analogous dynamic is commonly observed in distributed software development teams, where the internal employees mistakenly see the outsourced vendors as on a different team.  In these instances, managers can find themselves saying, “same team guys, same team…” much too often.  In addition to causing managers headaches, the “Us versus Them” dynamic can ultimately threaten the success of an engagement.  Standard conflict resolution techniques do not always apply, but here are some basic strategies managers can use to mitigate this risk.

Know your audience

Managers should always be mindful about the impact reporting and language can have on the perception of team members.  When reporting back to the team, managers can augment team cohesion by using metrics that apply to the entire team’s effort rather than separating out specific groups.  The metrics used should not allow team members to differentiate the progress of the external resources.  Likewise, the language used in the report should reference the team, i.e. use the language of “We”.

Managers will of course want to track the value obtained from their outsourcing efforts, but reporting progress to team members should vary greatly from reporting valuation to senior management.

In short, be mindful of your audience and report accordingly.

Team alignment

Pairing external with internal resources for story points or tasks can go a long way to create trust and teamwork.  For example, an internal resource can work on creating an API while an external resource is working on the front-end that will utilize the API.  They collaborate on the hooks to tie their work together.

Managers should know their resources sufficiently well to identify requirements that are best suited for a pairing, but an easy way to identify these opportunities is to pair a senior with a junior team member.  Senior resources generally appreciate the opportunity to flex their mental muscles and mentor a more junior resource.  On the other side, junior resources will generally respect the more extensive knowledge of a senior resource.

Empowering successful collaboration fosters camaraderie and respect.

Rural sourcing

A large part of the Us versus Them dynamic is due to superficial differences.  Whether it is language, culture, or schedule, no matter how superficial, differences can create serious rifts in a team.  Finding common ground outside of a project can be challenging for managers.  So, simply eliminating the differences where possible can be very effective to avoid the rift.

Given the similar language, schedules, and culture, rural sourcing is an excellent solution to mitigate the “Us versus Them” risk of distributed development.

• See also:
• 2009
• 2010

It sounds trite, but 2011 seemed to have flown by. Every year life seems to move a little faster than the year before.

At first glance, my photography seemed to have taken a back seat this year. That is until I considered two notable changes in my habits as compared to the past:

• I used my iPhone camera almost as much as my SLR. The iPhone 4′s camera was significantly improved over previous models. It’s quality and portability helped capture some moments that would have otherwise been missed.
• Flickr is no longer my only sharing destination for photos. This year Facebook started storing the original size photo, and added very powerful person/place tagging, making it superior to Flickr in many ways.

Please enjoy!

Person-to-person interactions in teams where everybody works in the same room often tend to happen (or not) almost by accident, simply because people spend a lot of time in close proximity. Teams fail if and when these spontaneously happening interactions are not sufficient to effectively pass around technical information, share successes and failures, and establish common goals. In contrast, it takes deliberate effort to organize successful communication for the team where members work remotely. It is very visible whether team members share a common vision of success, have good working relationships, and are comfortable working together closely. One approach that has been shown to be successful in facilitating such communication is to create communication patterns around a formal required communication element.

One of the teams I worked on had a formal requirement for each team member to write a weekly report. The reports included information about team members’ activities, what problems they were working on, and what they have accomplished in the last few days. These reports were then posted for the entire team to view, and also discussed in the regular meetings. Because everybody on the team could see what the others were doing, people noticed trends – problems that came up again and again, someone being stuck on a task for a long time, or several people working independently on the same problem. The issues were then addressed quickly – new tools researched and incorporated to deal with repeating problems, people who were spending too much time on their tasks got help and additional training, team members who were dealing with similar tasks tackled the problems together. For some team members, it was more comfortable to list the problem on the report as a way to request help and advice, instead of having to admit failure and ask for assistance directly.

On another project the team included several groups of people who worked from different locations. Every day people organized in pairs to work on different tasks. Occasionally, both people in a pair were in the same location, but more commonly, they were not. To work together, people would create a separate chat channel and screen share, send screen shots and pictures of decision trees by email. In addition to work communication, people also got to chat about lunch plans, families, and other life issues. Working in pairs allowed team members to establish human contact and get to know each other, as well as achieve good results at work.

Successful projects and teams often have a distinct feel that comes from well established, effective communication. Close communication within the team is of crucial importance to projects’ success, and it takes deliberate effort and smart strategy to get people talking to each other regularly and openly. Teams with remote members often pay a lot more attention to facilitating communication within the team, and thus are more successful.

To register, go to www.agiledotnet.com

Improving Enterprises in conjunction with Microsoft will once again bring together the world of .NET development with the world of Agile methods for an exciting one-day experience of discovery, learning and exchange.

Attendees can expect informative presentations based on real-world experience from some of the industry’s leading Developers, Project Managers, and Executives who have embraced Agile principles within .NET development environments.

Come see how both the experts and the beginners apply Agile concepts using the Microsoft .NET framework, Visual Studio, and Visual Studio Team System.

This year will be a unique experience; so don’t miss out – REGISTER NOW!

Co-location is often impossible for a variety of reasons.   Mid to large sized companies often have multiple offices, and it is logistically difficult (or cost prohibitive) to do all project work in one location.    Also, in order to enjoy wage arbitrage benefits by engaging team members in less costly locations, those people must remain at their home base.

While experts in agile software development practices often promote co-location, the actual reasons that distributed teams struggle should be understood.  Understanding these challenges can open the door to overcoming them.  Let’s look at the three most common problems that distributed teams encounter:

1. Shy/introverted people tend to under-communicate.

Software projects require a lot of communication.   The more we communicate, the more questions we answer and the more problems we resolve.   When shy/introverted people are geographically distributed, far less communication occurs than if they were sitting near one another.

STRATEGY: The manager should work hard to facilitate high bandwidth frequent interaction, offering encouragement to those who tend to under-communicate.

2. Email is a suboptimal communication tool

Email communication is fraught with problems – delayed feedback, misunderstood tone, missed body language, and no real time interaction.   Geographically separated teams tend to rely heavily on email for communication.

STRATEGY: Motivate the use of two-way communication tools such as voice calls or instant messenger.  Adding video and screen sharing increases the richness of the experience, which can boost productivity and enhance the quality of the results of the interaction.

3. Meeting attendance by remote attendees can be a waste of time.

The term “meeting” ought to be retired and replaced with terms that better describe the purpose of a group of team members getting together.   Often, not everyone attending a meeting is needed there.  This is true whether attendees are on the phone or sitting in the room with the meeting organizers.  Active collaboration can be very productive, but passive meeting attendance can be wasteful and inhibit productivity no matter where the attendees are located.

STRATEGY: Focus on interacting and collaborating instead of on just “meeting”.  Be attentive to the goal of each interaction event, and limit attendance to those who are best qualified to solve the problem(s) at hand.  While there may be value in having passive attendees listen, there is often more value in having them work actively on solving other problems that need their direct attention.

Distributed teams require strong leadership.  Leaders of distributed teams should spend much of their time cultivating and possibly facilitating optimal levels of communication among the members of the team.   A strong leader is mindful of communication gaps and works swiftly to reconcile them

• 1 hour

Players (5..8 recommended):

• Project manager or facilitator
• Internal team

Ingredients:

• internet access
• a goal

Directions:
Circles of Influence, created by Deb Colden, can help you achieve your action potential by identifying connections that will lead you to success. Take advantage of this game to expand your network and turn your thoughts into plans.

Clicking on the image to the right will start an “instant play” game at innovationgames.com. Here, these two circles will be used as the “game board,” which will help you organize your connections and support. As a group, define your goals by dragging the blue stars from the upper left corner to the top of the board and describing what each represents. Then, move on to the circles.

• Left circle: “Circle of the Task”
• Right Circle: “Board of Directors”

The “Circle of the Task” represents people who can help you accomplish your goal. “Board of Directors,” is for people who will help you no matter what, and on whom you can rely on to provide encouragement and advice.

There will be two different icons that players can drag onto the circles and describe to represent your network:

• Green people – those in your “Circle of the Task”
• Blue people – those on your “Board of Directors”

All moves can be seen in real time by each participant, so everyone can edit the positions and descriptions of the icons. Also, the integrated chat facility allows you and your players to collaborate to uncover your connections.

Key Points:
This game involves visual organization and extensive collaboration to identify people who will help you reach your destination. By writing specific names, you can turn potential connections into beneficial relationships, and form a more focused approach on how to achieve your objective. Get the job done by expanding your network while utilizing the support of those who know you best.

This release incorporates a small API change to produce a list of OptionSpecs that correspond to the options detected on a parse, in the order in which the options occurred on the command line.

Happy parsing!

A physical-participation disentanglement puzzle that helps a group learn how to work together (self-organize) and can be used to illustrate the difference between self-organization and command-control management or simply as a get-to-know-you icebreaker. Standing in a circle, group members reach across to connect hands with different people. The group then tries to unravel the “human knot” by unthreading their bodies without letting go of each other people’s hands.

Why you’d use it:

As a management-awareness game to illustrate required change in behavior and leadership on a management level (e.g., illustrate the change from ‘task-oriented’ management towards ‘goal/value-oriented’ management).

Timing: 15-30 minutes

Materials and environment: space (indoor or outdoor) big enough for a groups of 7-16 people (can scale for up to 200 people)

Instructions (from Holden Leadership Center):

1. If necessary split the entire group into smaller groups of 7 to 16 people (too many people in a human knot becomes extremely difficult). Groups of 10-12 are ideal.
2. Arrange group members in a circle, standing shoulder to shoulder.
3. Tell everyone to put his or her right hand up in the air and then grab the hand of someone across the circle.
4. Everyone then puts his or her left hand up in the air and grabs the hand of a different person.
5. Check to make sure that everyone is holding the hands of two different people and that not holding hands with someone directly next to him or her.
6. Tell group members to untangle themselves to make a circle without breaking the chain of hands.
7. If group members break the chain they need to start over.

Notes: 

• To illustrate the concept of centralized, top-down decision-making vs. self-organizing, run the activity twice: The first time, have a “manager” tell the participants how to solve the knot (they must obey); the second time, remove the manager (or let the manager observe and answer questions for the team) and let the participants solve for themselves.
• You can give teams a time limit on this activity to make it more challenging.
• You can also mute/ blindfold participants throughout the activity.
• Instead of making groups start over when the chain is broken you can create penalties like blinding or muting a group member.

Debrief/ discussion questions:

1. How did it feel to be successful/ unsuccessful?
2. How did it feel to be mute? Blind?
3. What strategy did your team end up using to complete the task?
4. Who were the leaders in this activity?
5. Did the team reach consensus on a plan of action? What process did the team go through to reach consensus?
6. How do you feel your team communicated during this activity?

Links:

• http://leadership.uoregon.edu/resources/exercises_tips/team_builders/human_knot
• http://wilderdom.com/games/descriptions/HumanKnot.html

Culture, at times, might seem like a taboo subject when discussing distributed teams.  One of the main reasons people make the leap to thinking it is not a politically correct subject is because they assume that a distributed team is going to have team members from off-shore components.  It is true that many teams do contain off- or near-shore members.  However, I’ve worked on several distributed teams which have engineers all within the same U.S. State.

There are several cultural challenges to be considered when working with a distributed team. This post may not address all of them but, hopefully, it will address some of the most risky.  A few of the most common cultural challenges are: holidays, vacation, work hours, and work communications.

Many companies and many locations, in which a distributed team might have members, will have different sets of observed holidays and different policies about taking holidays.  Not only do different countries have different holidays from the U.S. but also even different states within the U.S. observe different holidays.  For example, I recently had a project where some team members were in Salt Lake City, Utah.  I found out that Utah celebrates “Pioneer Day” which is unique to that state.  Likewise other countries will observe different state and religious holidays.  It is VERY important to flush out these days when negotiating a contract with distributed resources.  Ensure this is done prior to the beginning of the project so that the team is not blindsided on short notice.

The same attention should be paid to vacation schedules/policies when negotiating contracts with distributed team elements.  Different companies and countries will have different rules, laws and policies towards vacations.  Some countries may insist that employees be allowed to take all their entitled vacation prior to the end of an annual or fiscal year.  Likewise, some companies may have a use it or lose it policy.  Either of these could be detrimental to a project if, at the end of the year, you find out several team members are due vacation.  Again, vacation policies should be discovered when the contract is being created and thought should be made to when team members are able to take their vacation.

There are two facets to be considered when thinking about project team member work hours:  how many and when.   Some countries do have a reduced-hour work week (E.g.: 35 or 36 hours instead of 40) and some companies might have a flexible work week (E.g. allow 4 days a week at 9 hours a day and then only 4 hours on Friday).   As always, work hours should be flushed out during contract negotiations.  Also, using an Agile approach or a method which measures a team’s actual velocity on a continuous basis for use in projected productivity will help obviate some hour-related risk.   Another consideration to the “when” component is if there is a large difference in time zones between the distributed team members.  This was addressed in the “Pitfalls #2″ post on September 27, 2011.

Communications is a very cultural subject.  Some people are raised to be very communicative and open.  Some are raised to be more quiet and hold their opinions closer.  Different cultures (even from state to state within the U.S.) breed differing senses of humor.  Some people tend to migrate towards dry humor, some interject side humor, others use exaggeration as humor – the list goes on and on.   Likewise different dialects, accents, and languages spur different colloquialisms and usage.  The best way to overcome communications challenges on a distributed team is to get the team together, face-to-face, at the beginning of the project and periodically during the project.  Part of the face-to-face time should be purely social.  A wise adage (not sure of the source) is that you can learn more about a person over a beer than you will all week at work.  I feel this is true.   It doesn’t have to be a beer but get the team out together so they may socialize, find out how the other team members talk, what they laugh at, what they’re passionate about.  One social event will bring a team closer than a month of status meetings.

As with the previous two “Potential Pitfalls” posts, many of the challenges can be obviated by a little due diligence during contract negotiations.  Determine what each distributed-team company requires for holidays, vacations, and work hours.  Part of the preparation should also address the who, what, when, where, and how of getting the distributed team members together so they can bond.  These proactive practices will go a long way to mitigating potential cultural pitfalls for the distributed team.

Crossroads Career Transition Workshop

November 12, 2011

9am-4:30pm

Spring 2012 dates

January 14, February 11, April 14 & May 12

Instructors:

Gail Houston and Leslie Mason from Intuit

Locke Alderson with Alderson & Associates

Gayle Bridgeman with LHH

Lori Davis with DISYS

Dirk Spencer – Creator of Resume Psychology ©

What:

Crossroads Bible Church’s Career Transition Network, one of the Dallas area’s first church-based groups to help people searching for employment, is hosting another free Career Transition Workshop.

Human Resource professionals specialized in recruitment and staffing will teach advanced skills, techniques and secrets for job-hunting strategies:

·         Utilizing the Internet in your job search

·         Job search strategies

·         Resume writing

·         Networking

·         Interviewing

·         Negotiating techniques

The workshop is for those who are un-employed, under-employed or just seeking new employment. Many participants have taken the workshop more than once because of the encouragement it provides.
We open the workshop with a time of prayerful support and encouragement from God’s Word, the Bible. People get to know one another and exchange information about possible employment.
We also connect people via the Internet to a wide variety of local job leads.

·         Dress code is casual. It’s a cell phone friendly environment so you won’t miss that important call.

·         Bring a resume – recruiters are on site to review and make suggestions.

·         Bring business cards for networking with others if you have them.

·         The workshop is free, continental breakfast and lunch is included along with a workbook.

Location & Directions:

From Dallas go north on I-35E to Justin Road (FM 407). Exit Justin Road (FM 407), and go west on Justin Road (FM 407) 4.2 miles.
The church is on the left. (At the southwest corner of FM 407 & Chinn Chapel)

From the airport go north on FM 2499 to Justin Road (FM 407). Turn left, go 1/2 mile. (At the Southwest corner of FM 407 & Chinn Chapel)

Sherry Alpert

Crossroads Bible Church

8101 FM 407

Double Oak, TX 75077

Email ctw@crossroadsbible.org

http://crossroadsbible.org/community.asp

This release incorporates a small API change to allow compile-time arrays as the supplier of default values for an argument-accepting option, as well as removing some internal unused methods and classes.

Happy parsing!

What is the goal?

Most of the failed outsourced projects I’ve worked directly with were doomed before work even began.  Are you hiring a team to write code to fulfill your requirements?  You’ve already set yourself up for failure.  Any team, internal or outsourced, must have a goal of solving business problems.

Do you want a partner or a plain worker?

When a team’s goal is to code, that will be the focus.  The team’s goal is to write code to satisfy my customer’s requirements.  Given a list of requirements, at the best you will get those requirements satisfied.

If your team is instead a partner with the right goals, you will find out that your requirements are wrong, cover too much territory, don’t allow for early feedback, or can even be solved without any coding at all.  The most satisfying solution is often one that doesn’t require any coding at all.

Let’s make some of those a little more concrete from the perspective of an outsourced developer with the goal of solving your business problems.

1. Wrong requirements.  As stories and requirements are fleshed out over the course of the project, I’m constantly thinking of how your business works, and how it can be improved.  If and when I discover a disconnect between your requirements and your business, I’m going to work with you to find a better solution.  Don’t build the wrong thing.
2. Cover too much territory.  This is basic to agile.  In theory thorough requirements seem like a great idea.  But the farther you look into the future, the less precise and correct your requirements can be.  If there is any constant, it’s change.
3. Don’t allow for feedback.  This plugs right back into the previous point.  Feedback early and often is crucial to building the right solution.  The farther off the road you get, the harder it is to make corrections to get back on track.
4. Solutions not code.  Code isn’t necessarily always the solution.  If code isn’t my goal, then I will consider all solutions.  Perhaps a small shift in your business process will solve a problem and no new software is necessary.

Focusing on your business

Is your outsourced team thinking about business value?  When faced with a problem that can be solved with software, and my goal is to code, I will naturally want to write code to solve the problem.

As an example, let’s say our business has a call center application with a minor user interface flaw.  It sure is a nuisance, and it costs a total of an hour wasted per day across the call center.  That sounds painful.  It will take my team (3 people) one week to fix it, including coding, testing, rollout.  That is 3 man weeks, or 120 hours of work.  If team members averaged $75/hour and the call center $25/hour, it would take a full year to recoup the cost.

It doesn’t’ stop there, though.  In addition to the cost of the 3 man weeks, we also have an opportunity cost of 3 man weeks where work that could provide far more value could be done.

Are your outsourced teams thinking this way?

Why would Rural Sourcing be better?

In order to work together toward a common goal, communication is crucial.  Frankly, the closer your team is the better.  The farther you get away, geographically, time zone, and culturally, the harder communication becomes.   This makes Rural Sourcing a great choice to balance common-goal oriented consulting and cost.

Many State Universities offer lower tuition and more scholarships to residents who are local. Why? It doesn’t cost them any different to educate someone from out-of-state than someone in state. The reason why many universities do this is because they understand that students in the state are a better investment, so to speak. Universities expect that students who already live in the state are more likely to stay after graduation. Whether it is because they have family nearby, or they like the weather, or their favorite baseball team plays in the next city over. For the university, that means one more person contributing to the economy and society that help pay for and build up the university. In short, universities expect that what they gave will be given back when those students become productive members of the society that supports the university. In the end, it is beneficial to both parties.

A similar line of thinking can be applied to rural sourcing. Not only do you get the (not inconsiderable) benefits mentioned in many of the other posts here (cultural, time and time zone, customer experience, etc.), but you help foster the types of experiences described by Will, Allen, and Ben in their posts regarding students. Who knows? The students who get valuable learning at a rural source office your company hired may one day be applying to your company, or providing the next big IT service to the world. And you’ll not only have helped support that, but you’ll have developed a relationship with them already. Rural sourcing, like universities that give lower tuition for local students, is not just a smart investment for a better software development experience, but a good investment in local people who could very well one day be giving back to your company in their own way.

I'm pleased to have received community contributions since moving the project to GitHub. This release incorporates some of those contributions. Of note is the ability to have short options that accept arguments in a cluster. If such an option occurs in a cluster, the remaining parts of the cluster, if any, are taken to be the argument to the option.

Happy parsing!

I'm pleased to have received community contributions since moving the project to GitHub. This release incorporates some of those contributions.

Happy parsing!

Project Initiation
For project initiation, there is only one factor I would like to point out which is cost. The cost of a rural source team cannot beat the cost of an offshore team. Period. The cost of living in the rural areas is low but it can’t compare to where the teams are off shore. Also, since we assumed the quality of the products are equal, then we safely say that we want to pay less and go with the offshore team. We will have more money in the end so of course we will be happier!

Development Phase
During the development phase, we can expect the customer to engage with the team to answer any questions the team may have, give valuable feedback, and make any necessary requirement changes along the way.

On a holiday like Memorial Day or Labor Day, I sometimes make the mistake of going to the store to find out the store is closed for the holiday. It isn’t a big deal at times, but what if I had invited friends over for a barbeque and decided to wait to the last minute to get the meat at that store on that holiday? I should be frustrated and disappointed in myself for not realizing that, but I rather blame the store for not being open. Either way, I won’t be happy. Through the development phase, if the development team has a day off for a holiday on the same day as the customer is working because he or she does not have a holiday, then the customer would not be able to reach the development team. If there happens to be a critical production issue, the customer would have to patiently wait until after the holiday to reach the development team. Similarly, if there are major time zone differences, then the customer may have to wake up in the middle of the night or have an irregular work schedule to be able to collaborate and communicate with the development team. With an offshore team, that is the frustration and pain that the customer will go through. The rural source team does not face these challenges since they follow the same holiday calendar and live in the same time zone or close to the same as the customer.

When the customer and the team finally get to communicate, are they really speaking the same language? The customer and the team may be using the same language to communicate, but the real meaning and point of the conversation can be misled by nuances in the language on top of the missing body language in a voice communication. Speaking to a team with the same culture and is native or fluent in the customer’s language will definitely minimize the miscommunication. That can be found with a rural source team, and not an off shore team. If the customer chooses to go with an off shore team, expect repeating or rewording what is said and even receiving a product where the requirements do not meet the customer’s standard due to misinterpretation.

Finally, what if the customer wants to meet face to face? Travel comes to mind. The worse case scenario for the customer to meet the rural source team is to book a domestic flight. A couple of hours of the customer’s time will be lost due to travel. If the customer is to meet an offshore team, then the customer is required to book an international flight. A whole day can be lost for that. Not to mention, the process to go through on an international flight is much more of a hassle than a domestic flight. Less hassle means less frustration. Travel to the rural source team will definitely be less painful for the customer.

Summary

Happier Customer: Rural Source or Offshore

As far as I can tell, there is a chance that the customer may receive gray hair sooner if he/she decides on choosing an offshore team. If the increased growth rate of gray hair caused by stress is actually a myth, then we can still say that choosing a rural source team will give the customer a much better experience.

When deciding to choose either a rural source team or an offshore team, don’t forget the most important factor, the customers!

Timing:

Prep: Printing out the handouts

Activity: 45 – 60 minutes, depending on the size of the group

Materials:

Handouts, pads of paper (# attendees / 2), pens (same as pads of paper)

Instructions:

This activity will occur in two rounds. The first round involves each person in the audience working along. You will ask them to write a story about something interesting that happened to them at work recently. Give them five minutes to write. At the end of the five minutes, ask for volunteers to share their stories. Two or three should be sufficient. Expect that generally they will be somewhat mundane/pedestrian, and also be prepared that someone might be very funny or fascinating.

The second round involves pairing. Each pair will write a short story (fiction), based on “requirements” (see The Requirements below). The pair will take turns working on the story, alternating as indicated below.

Activity will be broken into two minute turns.

During each turn, one member of the pair will write, while the other will watch and ensure that the constraints are met (see The Rules below).

At the end of each turn, you will have them switch roles.

There will be seven turns.

At the end of the time (all seven turns), you will give them two more minutes to “refactor” their stories.  Then you will give as many pairs as possible an opportunity to read their stories aloud to the rest of the class. Expect a mix of boring/mundane (john said and then mary said) and incredibly creative/funny.

1. Introduce the setting: work, geography, industry, weather, time of day,…
2. Introduce character one: gender, name, age, education, single/married/paired/whatever
3. Introduce character two: gender, name, age, education, pet(s), hobbies
4. Introduce character one’s job
5. Conversation between One and Two about a problem at work
6. Manager appears and participates in conversation
7. All three go out for lunch: where, what kind of food, how do they get there

The Rules

• No sentences longer than twenty words – shoot for ten or less.
• Character names no more than two syllables.
• No paragraphs longer than five sentences.
• No “he said” and “she said” – must use names.
• No sentence may begin with “So” or “And” or “But”.
• Use adjectives judiciously.
• Locale must be a real place.

Gomez Goobers was a happy place to work. GG, as it is known in the industry, is in the heart of Chicago’s South Loop. In September, the weather was cooling off and people were walking the streets for pleasure.

GG’s lead programmer, Tim Thomas, loved living in Chicago. After college, he met Mary, whom he married two years later. Tim and Mary have been married for three years now. Tim and Mary live in a small, two-bedroom house in a nearby suburb of Chicago.

Tim’s counterpart was Billie Bliss, the lead QA. Billie, who is an avid dog lover, lives in town in an apartment overlooking the lake with her Beagle named Bugle. Everyone wonders where Billie got the money to afford a place like that. At twenty-five, she’s too young to have accumulated much. Her co-workers speculate, and her family and friends aren’t telling.

After completing both a bachelor’s and master’s degree in computer science, Tim came to work at GG. He loves technology, loves programming, and has progressed rapidly in the year and a half he’s been at GG. He has already worked in several programming languages and on several operating systems. These days, he’s focused on Ruby on Rails on a Linux platform.

Tim and Billie have been struggling with getting their teams to work together more effectively. Unfortunately, they are plagued by…

Decide who is going to write, and who is going to observe for the first turn.

Learning Points:

• Working in pairs produces results that we would never produce on our own
• Creativity is increased by pairing
• Pairing can be fun
• Pairing produces more effective results than working alone

Timing:

• Prep time: 30 – 60 minutes
• Execution time: 45 – 60 minutes

Materials:

One set of LEGO per team. Each set should include the necessary pieces to build a cube (see images in ZIP file) plus some random pieces. You can include base pieces or not. I don’t, because it adds to the challenge and the fun, having them figure out how to make the pieces stick together. Include at least a few flat pieces in each set, though, because it’s almost impossible without.

Instructions:

The participants should be divided into project teams that have between 4 and 8 people (smaller teams are preferable). Each project team should have two halves, call them left half and right half. Each half will have between 2 and 4 people. There should be as many project teams as necessary to include all participants.

Room = 15 people
Project Team = 5 people (3 project teams in room)
Left Half: 3 people
Right Half = 2 people

Here’s another way to split 15 people:

Project Team: 7 or 8 people (2 project teams)
Left Half: 4 people
Right Half: 3 or 4 people

With a group of 10 people:

This exercise will be done in two rounds. In round one (The Waterfall Way), the halves of each project team will build a specific object, using LEGO, based on a set of “specs” – three pictures of their finished “subsystem.”

In round two (Continuous Integration), the halves of each project team will build the same object, but in iterations, performing integration at the end of each iteration.

Both rounds lead to the same goal: at the end of the round, the two subsystems fit together cleanly to create the final “system.”

The pictures below reflect the finished “system.”

Each half of each project team (left and right) receives their specs, and is given 3 minutes to look over their LEGO and to discuss what they’re going to build.

Left Half builds the object specified in the set of specs named left-finished-xxx.pdf.

Right Half builds the object specified in the set of specs named right-finished-xxx.pdf.

• Neither pair gets to see the other pair’s specs
• Neither pair gets to see the other pair’s work in progress
• Both pairs first get to see the other pair’s “subsystem” when both pairs are done
• When both pairs are done, they will try to fit their subsystems together
• They will make modifications until they are successful
• Record the time when both pairs first say they’re done, and then record the time it takes to get the two subsystems to fit together (build time, integration time, total time)
• You will probably need to get the pairs or project teams to track their own times, depending on the size of your group
• Expect that the teams will not finish simultaneously, so track the time per team for build
• Expect that the two subsystems will not fit together properly – let them struggle with deciding which team should make which modifications
• Encourage them to talk about the “specs” and figure out how to get the subsystems to fit together properly
• Hopefully, this will be somewhat painful and frustrating for them

As with the Waterfall examples, the project teams will be divided into two halves.

This exercise will be conducted in five iterations.

Before starting this second half, give the following instructions:

For each iteration, there is a set of specs that incrementally add to the previous iteration’s results.

Iteration one is very simple – just a flat rectangle – in order to get them accustomed to building and working together in pairs, plus giving them their first experience of continuous integration with an easy one that can’t fail.

Before starting this exercise, have the pairs switch – that is, Pair Left becomes Pair Right and vice versa.

Each Iteration follows the same pattern:

1. Receive specs
2. 2 minutes to review and discuss specs
3. Build (they will record the time to build)
4. Integrate (they will record the time to integrate)

Instructions are the same as for the first exercise:

• Neither pair gets to see the other pair’s specs for each iteration
• Neither pair gets to see the other pair’s work in progress during an iteration
• Both pairs first get to see the other pair’s “subsystem” when both pairs are done in each iteration
• When both pairs are done, they will try to fit their subsystems together at the end of the iteration

At the end, they will total their build and integration times.

Learning Points: 

There is a bug in the specs. In the waterfall first round, the two halves cannot come together without a couple of tweaks. The same is true in round two, but they should get there more quickly.

• While it is expected that each Integration stage will take a bit longer than the last in round two, each should still be pretty quick
• One or more teams will not complete their cubes during round one. This is an opportunity for learning.
• Some may not finish in round two, but that’s less likely.
• Learning questions for the final debrief:
  • Did your team feel more confident in the product you were delivering each iteration?
  • How long was the integration phase in Waterfall compared to the total time spent in integration over the several XP iterations? (When overall time is roughly equal, this could be a key insight: XP teams have an easier time integrating even when the overall project timeline appears roughly identical to a waterfall Gantt chart)
  • Were there any features that could not be delivered in Waterfall because integration was too difficult/costly, whereas in XP the same features were delivered successfully?

Handouts and the slide deck I use are here: 

http://www.stevenlist.com/files/ciwithlego/continuous-integration-with-lego.zip

Last September I weighed 198 pounds, had a BMI of 30 (obese), 25+% body fat, pre-hypertension, digestion problems, acne, and borderline high cholesterol. Chasing after my two girls was followed by a half-hour recovery period and a shower.

Then: Puffy and docile—Now: Stone cold predator

Today, one year later, I’m a lean (10-11% body fat) 145 pounds. My vitals are now perfect. I’ve lost 5 inches in my waistline, 2 1/2 ring sizes (new ring!), 1 1/2 shoe sizes, and went from a men’s large shirt to a small.

It’s still strange to say this out loud—I’m fit and healthy.

The perfect storm happened last October. My 30th birthday was looming, I spent 8 hours a day in a room with the ever-handsome and fit Dustin Askins, and my close friend and business partner Steve Brewer had made his own decision to take control of his health (and kicked-ass at it). On a whim, I decided to kick my five or six can a day soda habit. Cold turkey.

I dropped nearly ten pounds the two weeks. This was a wake-up call.

Over the next three months I obsessively counted calories and started cycling with Steve. Eight mile bike rides turned into 50 or 60 mile bike rides pretty quickly.

Fun fact: If you restrict your calorie intake to 1,600 a day and burn 1,000 calories per day on the bike, weight will melt off of you. Also, you’ll fall asleep at 8pm every night.

Thanks to calorie-counting, I dropped about 25 or 30 pounds from October to December. All good, right? I still had digestion problems, I still had high blood pressure, and I was still eating garbage (albeit, carefully metered portions of garbage). The calorie-counting became a ritual, my poor wife…

Finding My Inner Cave Man

My wife went gluten and dairy free late last year after discovering that she had a severe intolerance. I was her biggest skeptic. After doing some research of my own, I found Robb Wolf’s Paleo Solution and our lives completely changed.

Allow me to repeat myself: Our lives have completely changed since discovering the paleo diet.

No more gluten or grains, no legumes, no dairy, no industrial seed oils, no sugar. When you eliminate these things from your diet you immediately realize the detrimental effects that they have on your health. It’s also important to note that Paleo is not a low carb diet, however, by cutting out grains, sugars, and glutens your daily carbohydrate intake is significantly reduced. But don’t worry, you won’t die, your body knows what to do.

Today we follow a very satiating diet of beef, chicken, pork, seafood, eggs, green vegetables, “safe” starches, nuts, and fats.

Crossfit

Back in February, Steve, myself, Dustin, and Burin all joined a Crossfit Gym (Myself, Burin, and Dustin at Grapevine and Steve at Dallas Crossfit Central). I’ve spent the last eight months learning how to run, jump, lift heavy weights over my head, walk on my hands, and row without throwing up. I’ve also made a lot of really great friends.

I push myself to the limit every Monday, Wednesday, and Friday. How many people can say that?

Me, an athlete? Yep.

Show Me Some Stats, BRO

Thank You

I couldn’t have done it alone.

• My wife Kristi for putting up with the cold-turkey diet changes, food quality obsessions, and constant flexing in front of the mirror. She’s also lost over 30 pounds thanks to the Paleo diet.
• Steve, Dustin, Burin, and Ryan for being great workout partners. You four give me something to chase.
• Brandon and Bevin at Grapevine Crossfit have taught me how to be an athlete. They push me everyday.
• Robb Wolf and Nicki Violetti— The Brad and Angelia of the Paleo/Primal Nutrition Community. I’ve been lucky enough to befriend them both. This Paleo gig (Robb’s words) has changed my life.

Want To Know More?

• Robb Wolf’s quick start guide
• Primal Blueprint 101
• The Archevore Diet—Highly recommended. My diet is very similar to Dr. Kurt Harris’s.
• Paleo Hacks

The offset in time zones between different parts of a geographically diverse development team can be anywhere from insignificant (same time zone or +/- an hour or two) to very drastic (+/-12 hours).   When different parts of a team are only separated by a couple hours or less they, obviously, have less coordination challenges than teams with several hours of separation.  However, all distributed teams risk productivity when time-zone differences are not considered.

Even though there can be varying time deltas, dependent upon where the team’s resources are located, there are a few practices which can help mitigate some of the challenges regardless of  time difference.  These are: Setting team collaboration expectations; identifying and setting up tools and; setting up a common time reference.  It is important to implement these at the beginning of the project so that that every team member has the chance to hit the ground running.  Even if these are left to the team to determine and/or implement ensure it is the first thing they do on the project (sprint zero, etc.).

For team collaboration, it is very important that consideration is given to how team members will interact on both a daily and repetitive basis.   As much as possible, ensure recurring meetings are set up for the entire project and expectations are set as to who(m) might need to stay late or come in early.  With a large time delta it might even be necessary to have one team work a late or early shift so that all team members are in the office at the same time.  If you are off-shoring, remember that you are paying the off-shore team, not the other way around.  It is not uncommon to have a contract which states the off-shore team will work  a late shift.  It is important to have all team members available for each other as often as possible.

Tools should not drive the team however, the proper tools should be selected to support the team in the most efficient way.  This is especially true for distributed teams.  Ensure that person-to-person collaboration tools such as  e-mail, an on-line messenger, and phone contacts are considered.  All team members should have all other team members contact information.  Put in place team collaboration tools such as on-line meeting spaces, document sharing/collaboration tools, and Configuration Management.   If using an agile methodology find tools which support on-line story pointing, project boards, etc.

At times, especially for teams with resources in multiple time zones, it is helpful to select a common time to reference. For example, Greenwich Mean Time (a.k.a.: GMT, Zulu, Z, UTC) is commonly used by many organizations as a reference instead of local time.  Even if there are multiple one-hour delta time zones to contend with, it is much easier if each office has a Zulu clock to reference.  Most meeting scheduling tools adjust for time zone when sending a meeting invitation.  However, leading up to that there will probably be some discussion around the meeting time.  Just within the U.S. I’ve had teams in Eastern Time, Central Time, and Mountain Time.  On calls and e-mails, anyone referencing a meeting time would need to list all three.  It is much easier to use one reference time.  Calculation to local time becomes second nature after a while.

On any project it is important to ensure that the proper environment is set up for the team prior to project start.    However, this is even more important with a distributed team.   I’m sure many can relate to projects which start without all the pieces in place.   Some theorize they are even saving time by “just getting things started” and that “things will fall into place”.  However, even co-located teams lose time with this approach and it could be amplified with geographically diverse teams.  Give the team an honest chance to be productive from day one.  If something is not working for them it can most likely be changed but at least they have a benchmark from which they can start.

Unfortunately, unplugging the monitor may not be so easy if you have several external drives. By using Applescript, you can basically create an “undock” application that you can simply open when you want to unplug the display. I’ve also provided the app for you: Undock.app

1. Open “AppleScript Editor.app” found in the Applications -> Utilities folder
2. Paste the following code into “Untitled” applescript window:

   tell the application "Finder"
   	eject (every disk whose ejectable is true)
   end tell

3. Go to File -> Save. Name the file “Undock” and choose “Application” as the file format. You can now run this from Spotlight or create a shortcut in your dock if you prefer; just as with any other application. Your external drives will be ejected after running this script.

They are a 3rd party provider of customer service, inbound/outbound calls, as well as technical support. He was impressed by their long list of well-known clients such as JCPenny, Crate and Barrel, GameStop, among many other retailers. Ocassionally I’ll have to call into Crate and Barrel and didn’t realize this was the company responsible for their customer service – good job. In this day and age, it’s hard to find good customer service, especially among retailers. Check out Global Response if you are in need of this service — www.globalresponse.com

I don’t think there is much argument that collocated teams will always out-perform distributed teams. However, the reality is most enterprise software development projects must deal with some sort of team separation. Cost, domain knowledge, technical knowledge are all factors in this.

At Improving, we work with many distributed teams and through trial and error, and collaborative and technological innovation, we’ve been able to manage most of the usual obstacles. However, the one sticking factor that comes back time and time again, is time.

We see European teams find ways to cope just fine with their Indian counterparts. The same for Eastern American and European teams or teams spread across the Americas.

When teams can spend at least part of their day together, bonds can be formed, collaboration strengthened, and other common distributed factors such as culture and language can be overcome.

If teams cannot spend any part of their regular work day together, then:

• email becomes the biggest form of communication. For reasons this may be a problem, read ‘The Problem with Email’.
• teams spend less time bonding and building trust.
• since we cannot work together as much, we divide the responsibilities up more, which makes ‘Us & Them’ attitudes more prevalent.
• more turn-over. If team members are expected to stay extra late or come in extra early, retaining and attracting top-talent becomes more difficult.
• turn-around time on problems with cross-team dependencies is dragged out. If I run into a block in Dallas, TX at the start of my day, then I have to wait until the next day for my counterpart in Shanghai, China to resolve the block and for me to get back to work on it.

These are the most common factors I have run in to with these ‘hyper-dispersed’ teams that have 7 hours or more between them.

Have you run in to others? I’d love to hear about them.

A couple of the previous contributor’s posts on this blog discussed the importance of communications on projects.  Specifically on projects with distributed teams.  This post will discuss one of the many potential distributed team pitfalls- the Point of Contact (POC) – which risk effective communication and project progress .  Unfortunately, this potential pitfall is sometimes  actually planned into a distributed-team project.  This post will focus on the reasons why this is NOT a good idea.

Typically, especially when off-shore resources are involved, the consulting company suggests to implement a POC structure.  In this “process” the off-shore team has a POC which communicates with the on-shore POC.  Each of the individual POCs then communicates with the respective teams to disseminate information.  The POC hierarchy creates several challenges which complicate effective communications.

A common example of the first challenge is the child’s game of  ”telephone”.  Children sit  in a circle and a statement is whispered to the first child. That child then whispers the same statement to the second child, and the second child to the third and so on until the statement gets back to the first child.  Then the final/resulting statement is compared to the original.  They are never the same.  In this same way, an explanation provide to one POC, which is then provided to their counterpart POC, and then to an engineer on the other side is at high risk of being incorrect.  The more people whom are in this serial chain of communication the more risk there is that the information will be corrupt.

Another challenge with the POC implementation is timeliness.  How quickly is the information being relayed.  In an on-shore/off-shore environment there is likely already a major time difference to be considered.  Near-shore or Rural-Shore options reduce this time delta significantly however, if an engineer is only able to talk with one POC whom must talk with another POC then the project is tied to both POC’s availability.

A third, more organic risk is team “face time” and camaraderie.  Team members whom get to know their fellow teammates are more productive.  Even in a geographically diverse team, separating the team members with a POC artificial barrier adds just one more layer of separation which does not allow team members to get to know one another.  As stated in previous blogs, the more one knows about fellow team members the better one is able to interpret nuisances during phone and e-mail conversations which could be mistaken otherwise.  A mistaken comment which could be perceived incorrectly as rude, non-caring, etc. could drive a wedge between different parts of the team.

The potential pitfall of a POC is easily avoided.  In this great technological world in which we live there are so many tools available which allow the collaboration necessary to have an effective project team.  There is no need to have the POC mentality.  Technology should not drive the project but the project team should select the tools necessary to ensure effective person-to-person communications.   Getting the team together with video teleconferencing helps put a face to a name.  Using on-line resources for project planning, tracking and document sharing ensures everyone on the team is on the same sheet of music.

Ensuring open team member to team member collaboration will allow the distributed team to reduce the schedule risks associated with corrupt or misinterpreted  communications and maximize their productivity and Return on Investment (ROI).

• 1 hour

Players (5..8 recommended):

• Project manager or facilitator
• Internal team, partners, or customers

Ingredients:

• internet access
• a to-do list

Directions:
The goal of this activity — based on A. Roger Merrill, Rebecca R. Merrill, and Steven Covey’s description in their book First Things First — is to prioritize your to-do list in a way that helps you plan ahead and work efficiently.

Clicking on the image to the right will start an “instant play” game at innovationgames.com. Here, this 2×2 matrix will be used as the “game board,” and will help you organize the urgency and importance of your tasks. Each cell has a different significance:

• Cell 1: Urgent, important – these tasks should be at the top of your to-do list
• Cell 2: Not urgent, important – these items are likely to be neglected, but are necessary for long-term success. Set aside time each week to focus on these in order to be more productive. This cell is highlighted to remind you of its significance.
• Cell 3: Urgent, not important – these tasks suck your time and are often the result of poor-planning. They should be minimized or eliminated.
• Cell 4: Not urgent, not important – these items are trivial time-wasters that should be eliminated

There will be two different icons that players can drag onto the chart and describe to represent the tasks:

• Green squares – priority tasks that require attention
• Red square – tasks to minimize/eliminate

All moves can be seen in real time by each participant, so everyone can edit the positions and descriptions of the icons. Also, the integrated chat facility allows you and your players to collaborate to form the most efficient to-do list.

Key Points:
When it comes to our to-do lists, we tend to focus on urgent items while disregarding the importance of planning for tasks that are necessary to reach our overall goal. This negligence leads to even more stress in the long run, as everything will eventually become urgent if not prepared for. Play Merrill Covey Matrix to identify the purpose and value of your tasks and to minimize or eliminate time-wasters. Plan ahead to avoid busy work and to accomplish your goal in a productive manner.

Ever run into a situation where you are an administrator on a machine, but your account is not an administrator in SQL server? Read below for my situation and the solution I found to fix it!

The project I’m on currently has a shared virtual machine that is given to new developers when they come onto the project. It’s done this way because of some legacy software SDKs that are installed that only work on Windows XP, as well as some legacy VB6 code that requires the IDE to compile properly. I’m not complaining about this, but the virtual machine was created with Microsoft VirtualPC and I happen to be working on a Mac. Rather than booting my bootcamp VM, and starting the VM inside there (tedious and slow), I opted to migrate the VPC image to a VMWare Fusion image.

The transition was not easy, and required several steps that were not intuitive, but I finally got there and the VM is responsive and performs fairly well now. But I ran into a problem – the VM relied on share Windows authentication that mapped my Bootcamp user with a user in the VM called ‘dev’. Dev had administrative rights to the SQL Server, but during the transition the account disappeared and I lost all rights to do anything in the database other than connect!

I found a script that will map a given user to a given SQL server instance with the sysadmin rights. This saved me a ton of time and got me up and working again. The script does require administrative rights to the machine, so it should not be a security concern. All in all, I’m very happy to have regained access to my 2008 SQL Express instance so SSMS can enable intellisense on this rather complex database!