The "I" in Team

We often hear the expression, "There is no I in team!" Let's take another look at that. Where are the I's in team? To me, the first thing I think of is the individuals that make up the team. Some “I's” that are associated with the individual are individuality, initiative, imagination, insight and intrinsic motivation.

I know some of you are going to find this hard to believe, but individuals don't always agree on everything all the time! Individuality and respectfully differing opinions should be welcomed on the team. It makes us stop and think about why we should take one approach and not another. We have some creative people on our teams, so we shouldn't be surprised that there will be multiple (noncompatible) solutions offered. Perhaps we can splice and merge together from the solutions offered to create an even better solution!

It will help in these times of differing opinion to consider that the other person, like us, is working toward the same common goal. A shared vision for a common good has been embraced by the team. It is important that there be open, respectful communication within the team since there will be people with differing personalities and skill sets. In a team setting like this, we come to expect that individuals who are subject matter experts will work with other members to achieve the common goal and to mentor and help them grow as well. The individual is truly valuable in what they bring to the overall health of the team.

Our team members show initiative! If they spot or think of a potential problem, they will bring it to the manager’s attention and most likely already have thought of a solution. Individuals bring value to the team when they've exercised initiative to find a better way of completing a common task and share it with the team. For instance, if a team member demonstrates to the team a refactoring feature, or does something with an advanced language feature, the whole team benefits.

One of the most valued aspects of the individual is his or her imagination. Software development is a creative endeavor, especially UI design. The UI designer must think about how a user will interact with the software, keeping in mind principles such as "least surprise" and "expected default" and presenting a visually pleasing interface. The business layer developer must think about how the classes will work with each other and consider where inheritance and polymorphism make sense. The difficult part for managers is knowing when and how to interject their own individual view on the solution.

Our team members bring valuable insight into our business processes. It is especially true that, in information technology, our development teams gain a deeper insight and understanding of the business practices the longer they have been with the organization. Oftentimes this insight can answer the question, "Why?" Be sure to create an environment that fosters true teamwork, pairing and cross training among all people on the team.

This individual we have been discussing is also likely intrinsically motivated to achieve his or her job goals and to continue professional development, while being a professional and doing high-quality work. Software standards and processes can be mandated and taught. However, until they become an intrinsic part of the individual’s personal software process, the team will not see the benefit.

A team is not merely the sum of the individuals that make up the team. I believe when you look at truly productive teams, you will find an environment of communication and shared vision working toward a goal of common good.

Bad coffee pot! X^(

I know, I know! Back to the coffee pot. We were trying to make adjustments to the process and having trouble. The management (my wife) noticed the problems I was experiencing. Most noticeable were the backed up coffee and grinds overflowing onto the counter.

So, we were losing time, precious resources (beans), creating a mess and had nothing to show for it. Management said, enough!

The coffee pot was removed and we went in search of a replacement. We ended up with a high quality (and high initial expense) specialized single cup brewer. This works out really well since I am the only coffee drinker in the house.

I've gotta say, after the team metaphor with the last post, my team was really dismayed to hear that the coffee pot got swapped out! The moral of this post is therefore left as an exercise to the reader.

New Team, New Rules

I have had my old coffee pot for years.  It uses a basket filter.  I grind my coffee beans right before brewing.  Over time I had figured out the proper amount of beans and the correct granularity of the grind.  The result was great coffee every time! :)

My wife recently got me a new coffee pot.  It is much nicer with features like a clock, timer and higher capacity pot.  The new machine uses #4 filters instead of the basket style filters.

So, I followed the instructions for doing the initial “cleaning” runs.  I went to make my first full pot of coffee and I used the amount of coffee and the granularity that I have been used to using.  Then I heard the sound of coffee on burner.  What?  The grounds had gotten up and around the filter and clogged the dispensing hole.  :(  I chalked it up to the shorter filter.

Tried another full pot on another day with a new improved bigger filter.  Similar result, grounds in my coffee.  No bueno!

Then it occurred to me, I was grinding finer than “drip” granularity and this was causing the problem.  Maybe the cone style basket doesn’t need as many grounds either.  I guess I’ll have to check the manual!

As always, I’m thinking of how do these lessons translate to software development?  To me, I pull away that we can’t use the same procedures we’ve always used when we have a new environment.  In this case the environment consisted of the coffee maker, water, filter, beans and grinder.  (Let’s not consider condiments!)  Change any of these critical components and you can’t expect the same results.

So, if your team changes, your management changes, the tools you use change, etcetera, expect that your process must change as well.

What does TEAM mean to you?

Some people use the word team to say that they work with other people together. For instance in the traditional big shop, the Architect works with the developers and testers. Everyone has their pigeon holed tasks.

In our small team, team means that anyone is capable of doing the job. While I may be responsible for overall direction as team lead, anyone can do all of the tasks. From working to manage the work, the needed documentation/status reports, business analysis, development and testing. This arrangement has been very beneficial for us in terms of integrating new people and coping while people are out a week at a time.

Because everyone can do the work doesn't mean there aren't specialities.  Quite the contrary.  A really good team will be a blend of people with different backgrounds, skills and strengths which complement each other.  A shared vision with a project that has been broken down into achievable goals helps to focus the team on the work.

Another very important aspect of the team is respectful communication and understanding.  Feedback is important. In a functional team the members let each other know when they are not understanding the other persons view or actions as well as when things are going well.  Don't delay the feedback.