Time and time again, I have uncovered issues that have been ignored and/or hidden by exploring “over reactions”.  They are indicators that there is more to the story.  For example, one of teams that I was leading was very frustrated with how much time we were spending estimating stories.  Their frustration eventually culminated in some of the team members refusing to participate in team estimation meetings.  As you can imagine this created significant tension between the developers and the business team.

While some teams do take too long to estimate, this team generally spent less than 1 percent of their month estimating cards.  With this unequal and opposite reaction focusing my attention I began to interview team members one-on-one.  These conversations confirmed that there was a problem, but failed to adequately explain why.

At this point I approached the Project Lead and requested that we all sit down and discuss the estimation process.  At the conclusion of this meeting two things were clear.  First, the development team did not trust the business team’s motivations for gathering estimates.  Second, they did not feel like decision makers were adjusting their expectations based on the estimates that they received.

This conversation helped both sides understand each other.  While this was not a magical cure, it did realign the action of estimating and the team’s reactions.  This may still seem like it was not worth addressing.

On the contrary, exaggerated emotional investment can be a significant source of waste.  This type of waste is often expressed through frustrations, confusion, fear, and/or apathy.  Individual opinions spread throughout teams and become a significant source of waste.  The only way to reduce this waste is to understand the root causes.  I do not have a perfect approach to efficiently identify these sources.  In my experience it takes patience and persistence to uncover the truth.

These principles also apply to under reactions.  Some teams that have lost hope will withdraw.  The under reactions that will follow are just as important to address as over reactions.  Remember to pay attention to wheels that are abnormally quiet while you are oiling squeaky wheels.

As technical people we often shy away from feelings, however like it or not our teams are made up of people.  People that have feelings that are formed by their experiences and perceptions.  Ultimately people want to be heard and understood.  Once this occurs, teams tend to realign their reactions.

First off, there is no way to learn a language in one year; it’s not possible. There are so many things to learn, and so many variables in that space, that unless you work with it every day for multiple hours a day, there’s just no way to learn and become proficient in that amount of time. The 10,000 hour rule states that to excel and have success, you must practice a specific task for around 10,000 hours. In one year, there’s a good possibility that you won’t even hit 1,000 hours. But after that one year, even though you may become knowledgeable in a language, the amount you won’t know is so vast that all the time spent learning something new may have been better spent learning more about the current languages you already have a firm grasp of.

Another problem is the time of one year. One year is a long time; the end is far, far away. I have vague ideas of what I’ll be doing, and what I wish I will be doing a year from now, but one year is too long of a time period to measure any real goal. Six months is even too long! The reason working on a project using Agile methodologies, and in this context I’m speaking specifically on iterative development, is so much better than waterfall is that there are real goals in a foreseeable future. If my team agrees to do X amount of work over the next three weeks, it’s easy to see where I am now, where I’m going, and the amount of time it should take to get there. I can see my goal progressing every day and it’s encouraging.

Learning a language, though, is subjective, so there is no real finish line to cross. Throw in the one year time frame and your well-intentioned goal is sabotaged before you even start.

All that being said, I am looking to learn something new in the near future, so any suggestions in the comments will be appreciated. If you totally disagree and think I’m off my rocker, your comments are welcomed as well!

When developing software, you need to be aware of all of the different customers you have. Even though they might not be represented in the meetings, whether or not your software satisfies their needs will determine your project’s success.

Shortly after Sam and I began speaking we were joined by another individual.  I’ll call this guy “Ted”.  We made introductions around and then I asked Ted what his company did.  Ted seemed to struggle with his description of his business.  After Ted circled the bulls eye for several minutes Sam asked him to boil his business model down to the basic value proposition. Ted seemed to struggle with this too and so Sam helped him through the short conversation with some prompting.

I found the conversation about a basic value statement interesting.  Once we’d arrived at Ted’s business the conversation became less interesting.  Ted began expounding the benefits of his favorite flavor of technology.  Before I wandered off I heard things like “no viruses”, “lower cost of ownership” and “a true Unix operating system…”.  Not much real information and not much in a message structure that I found entertaining.

Here are a few quick tips for the “Teds” out there:

1. Always be ready to quickly describe your value proposition. You should practice that statement regardless of your position in the company.
2. Keep the value proposition short and relatively non-technical. It doesn’t need to be so simple that Uncle Joe could understand it, unless Uncle Joe works in your industry, but it does need to be basic enough that others in your industry understand quickly, with minimum effort.
3. If someone asks you what you do and you are able to respond with a concise answer then by all means also give them your contact information!  Hand them your business card; provide them with a URL or something else memorable.  Write that information on a matchbook, cocktail napkin or just scratch it into their forearm with your car keys.  Don’t assume that someone will remember your business contact information after a casual conversation, especially if that causal environment also includes libations.
4. Read your audience.  Be cautious about providing too much detail unless you are confident the person you are speaking to understands your topic and wants to dive into it.  There are some people I just don’t get into elevators with.  Zealots are always near the top of that list.

I just got done reading Release It by Michael Nygard. I don’t remember the exact numbers he used, but he made the point that any system of sufficient size should expect to experience more than one “once in a million” situations. Assume that your system performs 1000 transactions a day, 365 days a year; after three years you will have processed over a million transactions. I don’t know about you, but saying something will happen about once every three years sounds a lot different than once in a million. So next time you’re in the car, waiting for traffic, start thinking about “what if.”

At Source Allies, continuous learning takes place in many forms including:

• Training – courses attended over the past year include: AFS & Kerberos Best Practices, No Fluff Just Stuff, Tuning and Improving your Agility and Spring One 2GX. 
• Reading – Source Allies has an internal book club that meets on a weekly basis to review a specific book.  Books that have been and are currently being read and reviewed include TDD by Example and Effective Java, 2nd Edition. 
• Weekly meetings – each Monday, after hours, the Source Allies team meets to discuss current projects and share techologies that are being used on these projects. 
• Technical presentations – team members present at least yearly on the technologies they are involved closely with.
• Internships
• Mentoring

The examples above are just a small sample of the continuous learning opportunities available to our team at Source Allies.

Continuous learning should be an important part of your career development goals.  What do you want to learn?  How do you want to apply what you learn at your client site and to your projects?  During this time of year, many of us are reviewing our personal career goals.  In doing so, make sure you identify and include your learning goals… but don’t stop there!  Make sure you focus on these goals and review your progress often throughout the year.

You’ll notice that when you are focused on learning, it will not only grow your value but it also makes you more passionate about your projects and work in general.  It’s easy to get in a rut if you’re not focusing on staying ahead of the learning curve.

Specific knowledge and skills become obsolete with time but learning how to and having a passion for learning is a permanent skill that will carry you throughout your career and beyond!